test compilation warnings

[algrobman]

I'm getting following warnings:

riscv-arch-test/riscv-test-suite/rv32i_m/C/src/cadd-01.S: Assembler messages:
riscv-arch-test/riscv-test-suite/rv32i_m/C/src/cadd-01.S:37: Warning: shift count out of range (-1 is not between 0 and 63)
riscv-arch-test/riscv-test-suite/rv32i_m/C/src/cadd-01.S:47: Warning: shift count out of range (-1 is not between 0 and 63)
riscv-arch-test/riscv-test-suite/rv32i_m/C/src/cadd-01.S:62: Warning: shift count out of range (-1 is not between 0 an

... is this expected?

[pawks]

This looks incorrect. It is not an expected warning message.

[algrobman]

And what should I do about this?

[pawks]

This is mostly a problem in the LI macros. Its not due to your execution environment. I don't see any problem in the loaded values. You can ignore these warnings for now. They will be fixed soon.

[algrobman]

the only problem is that if riscof fails - my terminal is filled with these warning messages, I don't see real reason for the failure ..

[allenjbaum]

Which version of the arch_test.h macro are you using? I thought that issue was fixed.

On Mon, Feb 13, 2023 at 6:36 AM algrobman @.***> wrote:

the only problem is that if riscof fails - my terminal is filled with these warning messages, I don't see real reason for the failure ..

— Reply to this email directly, view it on GitHub https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1428046911, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJVKCJSL2ZUQFHUQK2TWXJBH3ANCNFSM6AAAAAAUY5JYLE . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[pawks]

I see this issue on the main branch of arch-test.

[allenjbaum]

OK, then LI needs to be fixed; can you send an example of where that occurred and any values that are possible to extract to cause this? This is the first I've heard of it, so it must have something to do with the linker relocations, right?

On Tue, Feb 14, 2023 at 12:53 AM S Pawan Kumar @.***> wrote:

I see this issue on the main branch of arch-test.

— Reply to this email directly, view it on GitHub https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1429349407, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJSBPJI6CFIQ3QGBW73WXNBYXANCNFSM6AAAAAAUY5JYLE . You are receiving this because you commented.Message ID: @.***>

[algrobman]

I didn't change a character in the test sources and env files .

These warnings are not seen if all tests pass, but fill shell window if any of the test fail for whatever reason, including signature comparison

[allenjbaum]

Hmm, cause or effect? Can you send the failure report, and possibly the linker scripts?

On Wed, Feb 15, 2023 at 10:46 AM algrobman @.***> wrote:

I didn't change a character in the test sources and env files .

These warnings are not seen if all tests pass, but fill shell window if any of the test fail for whatever reason, including signature comparison

— Reply to this email directly, view it on GitHub https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1431844840, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJTNT5DOO6M5B7IDHO3WXUQARANCNFSM6AAAAAAUY5JYLE . You are receiving this because you commented.Message ID: @.***>

[algrobman]

I did not change anything from the tests repo, including linker scripts.

[allenjbaum]

If that's the case, you must be comparing Spike with Sail, and there were no failures when we did it. If instead you were comparing Sail or Spike vs your DUT, then you are responsible for the DUT linker script, aren't you?

On Wed, Feb 15, 2023 at 7:59 PM algrobman @.***> wrote:

I did not change anything from the tests repo, including linker scripts.

— Reply to this email directly, view it on GitHub https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1432476461, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJW2GCODSUHE5NMQ74LWXWQZNANCNFSM6AAAAAAUY5JYLE . You are receiving this because you commented.Message ID: @.***>

[algrobman]

Again, I ran riscof as is without changing files from the tests repo.

[allenjbaum]

But you also said that you didn't see the message when all tests pass, only when they fail, which implies that there were test failures - but when we ran the tests from the test suite, we got no failures (and if we did, we would not have merged any new changes). So which tests failed, and what were the signature mismatches?

On Thu, Feb 16, 2023 at 6:03 AM algrobman @.***> wrote:

Again, I ran riscof as is without changing files from the tests repo.

— Reply to this email directly, view it on GitHub https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1433137078, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJULOAZKG4UYGWR56O3WXYXTJANCNFSM6AAAAAAUY5JYLE . You are receiving this because you commented.Message ID: @.***>

[algrobman]

I had failure due two issues 1) my core supported misaligned load/stores, but sail was not configured with that. 2) when DUT simulations timed out/killed before I increased the run timeout as I was advised. this 2nd case was pretty confusing since this happened after I added B-ext tests, but the failing was a I-ext test and I couldn't see the failure reason as whole the shell window was overloaded with these warnings . I think you can model this issue if you set execution timeout to let say 1s

[allenjbaum]

Ah, thanks for that extra information. This starts to make sense, though I can't say why those warnings are generated.

On Thu, Feb 16, 2023 at 9:38 AM algrobman @.***> wrote:

I had failure due two issues 1) my core supported misaligned load/stores, but sail was not configured with that. 2) when DUT simulations timed out/killed before I increased the run timeout as I was advised. this 2nd case was pretty confusing since this happened after I added B-ext tests, but the failing was a I-ext test and I couldn't see the failure reason as whole the shell window was overloaded with these warnings . I think you can model this issue if you set execution timeout to let say 1s

— Reply to this email directly, view it on GitHub https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1433464859, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJRD6YLEZOLI7JIVCIDWXZQXZANCNFSM6AAAAAAUY5JYLE . You are receiving this because you commented.Message ID: @.***>

[allenjbaum]

To reiterate: you say you are not changing any scripts, but you needed to configure Sail to support misaligned (which will be fixed at some point), and you changed the timeout value (are you running on a particularly slow server?) and you had to supply your own custom linker script. IT is completely unclear for the above description if those warning and failures go away when misaligned is supported and the timeout is increased or not - you are not giving us enough information. IF you are still seeing these issues, please send us a copy of the shell window so we can see what is going on. If not - it would still be useful to figure out why a timeout - or an actual test failure - would cause the specific error message that you're seeing.

[algrobman]

@allenjbaum , Are you reading the thread? @pawks sees the same issue. (i.e. warnings caused by LI instructions). Assembler warnings don't kill the tests and seems the tests are simulated correctly. But 1) the tests shouldn't generate warnings if written correctly. 2) if something is going wrong, these warnings from all these tests just fill shell history, making hard to figure out the failure reason.

Regarding my updates - I'm changing only sail simulator and DUT python plugins, just adding -m option for sail run command and updating execution command for my RTL simulator . Running verilog simulation more than 5min for more than 100 tests seems to me quite reasonable. Again I do not change any file from the RISCV tests repository, so you should be able reproduce these warnings and fix your tests

[algrobman]

if you run make with one test target you can see all these warnings.

[algrobman]

these warnings come from your super complex macro: (arch_test,h)

#define LI(reg, imm)                                                            ;\
  .option push                                                                  ;\
  .option norvc                                                                 ;\
  .set even,    (1-BIT(imm, 0)) /* imm has at least 1 trailing zero     */      ;\
  .set immx,    (imm & MASK)    /* trim to XLEN (noeffect on RV64)      */      ;\
  .set imm12,   (SEXT_IMM(immx))                                                ;\
  .set absimm,  ((immx^(-BIT(immx,XLEN-1)))&MASK) /* cvt to posnum to simplify code */  ;\
  .set imme,    ((immx^(-BIT(immx,0     )))&MASK) /* cvt to even, cvt back at end */    ;\
  .set cry,     (BIT(immx, IMMSGN))                                             ;\
  .set cryh,    (BIT(immx, IMMSGN+32))                                          ;\
  .set pos,      0                                                              ;\
  .set edge1,   -1              /* 1st "1" bit pos scanning r to l      */      ;\
  .set edge2,   -1              /* 1st "0" bit pos scanning r to l      */      ;\
/**** find 1st 0->1, then 1->0 transition fm LSB->MSB given even operand ****/  ;\
  .rept XLEN                                                                    ;\
    .if     (edge1<0)           /* looking for first edge?              */      ;\
      .if (BIT(imme,pos)==1)    /* look for falling edge[pos]           */      ;\
        .set  edge1,pos         /* fnd falling edge, don’t chk for more */      ;\
      .endif                                                                    ;\
    .elseif (edge2<0)           /* looking for second edge?             */      ;\
      .if (BIT(imme,pos)==0)    /* yes, found rising edge[pos]?         */      ;\
         .set  edge2, pos       /* fnd rising  edge, don’t chk for more */      ;\
      .endif                                                                    ;\
    .endif                                                                      ;\
    .set    pos,  pos+1         /* keep looking (even if already found) */      ;\
  .endr                                                                         ;\
  .set immxsh, (immx>>edge1)    /* *sh variables only used if positive  */      ;\
  .set imm12sh,(SEXT_IMM(immxsh))/* look @1st 12b of shifted imm val    */      ;\
  .set crysh,     (BIT(immxsh, IMMSGN))                                          ;\
  .set absimmsh, immxsh         /* pos, no inversion needed, just shift */      ;\
/*******does it fit into std li or lui+li sequence****************************/ ;\
  .if     ((absimm>>IMMSGN)==0) /* fits 12b signed imm (properly sgnext)? */    ;\
       li   reg, imm12         /* yes, <= 12bit, will be simple li       */    ;\
  .elseif (XLEN < 64 || (absimm+ (cry << IMMSZ) >> WDSGN)==0) /* fits 32b sgn imm?(w/ sgnext)?    */    ;\
        lui  reg, (((immx>>IMMSZ)+cry) & LIMMMSK) /* <= 32b, use lui/addi */    ;\
    .if   ((imm&IMMMSK)!=0)     /* but skip this if lower bits are zero   */    ;\
        addi reg, reg, imm12                                                    ;\
    .endif                                                                      ;\
 /*********** look for various masks 0s->1s->0s, etc **********************/    ;\
  .elseif ( even && (edge2==-1))        /* only rising  edge, so 111000   */    ;\
         li      reg, -1                                                         ;\
        slli    reg, reg, edge1         /* make 111s --> 000s mask        */    ;\
  .elseif (!even && (edge2==-1))        /* only falling edge, so 000111   */    ;\
        li      reg, -1                                                         ;\
        srli    reg, reg, XLEN-edge1    /* make 000s --> 111s mask        */    ;\
  .elseif (imme == (1<<edge1))          /* check for single bit case      */    ;\
        li      reg, 1                                                          ;\
        slli    reg, reg, edge1         /* make 0001000 sgl bit mask      */    ;\
    .if   (!even)                                                               ;\
        xori    reg, reg, -1            /* orig odd, cvt to 1110111 mask  */    ;\
    .endif                                                                      ;\
  .elseif (imme == ((1<<edge2) - (1<<edge1))) /* chk for multibit case    */    ;\
       li      reg, -1                                                         ;\
        srli    reg, reg, XLEN-(edge2-edge1) /* make multibit 1s mask     */    ;\
        slli    reg, reg, edge1         /* and put it into position       */    ;\
    .if   (!even)                                                               ;\
        xori    reg, reg, -1            /* orig odd, cvt to 1110111 mask  */    ;\
    .endif                                                                      ;\
  /************** look for 12b or 32b imms with trailing zeroes ***********/    ;\
  .elseif ((immx==imme)&&((absimmsh>>IMMSGN)==0))/* fits 12b after shift? */    ;\
        li      reg, imm12sh            /* <= 12bit, will be simple li    */    ;\
        slli    reg, reg, edge1         /* add trailing zeros             */    ;\
  .elseif ((immx==imme)&&(((absimmsh>>WDSGN)+crysh)==0)) /* fits 32 <<shft? */  ;\
        lui     reg, ((immxsh>>IMMSZ)+crysh)&LIMMMSK /* <=32b, use lui/addi*/    ;\
    .if   ((imm12sh&IMMMSK)!=0)         /* but skip this if low bits ==0  */    ;\
        addi    reg, reg, imm12sh                                               ;\
    .endif                                                                      ;\
        slli    reg, reg, edge1         /* add trailing zeros             */    ;\
  .else                                 /* give up, use fixed 8op sequence*/    ;\
   /******* TBD add sp case of zero short imms, rmv add/merge shifts *******/   ;\
        lui     reg, ((immx>>(XLEN-LIMMSZ))+cryh)&LIMMMSK /* 1st 20b (63:44)*/  ;\
        addi    reg, reg, SEXT_IMM(immx>>32)            /* nxt 12b (43:32) */   ;\
        slli    reg, reg, 11    /* following are <12b, don't need SEXT     */   ;\
        addi    reg, reg, (immx>>21) & (IMMMSK>>1)      /* nxt 11b (31:21) */   ;\
        slli    reg, reg, 11                            /* mk room for 11b */   ;\
        addi    reg, reg, (immx>>10) & (IMMMSK>>1)      /* nxt 11b (20:10) */   ;\
        slli    reg, reg, 10                            /* mk room for 10b */   ;\
    .if   ((imm&(IMMMSK>>2))!=0) /* but skip this if lower bits are zero   */   ;\
        addi    reg, reg, (immx)     & (IMMMSK>>2)      /* lst 10b (09:00) */   ;\
    .endif                                                                      ;\
    .if (XLEN==32)                                                              ;\
        .warning "Should never get here for RV32"                               ;\
    .endif                                                                      ;\
 .endif                                                                         ;\

BTW, just curious, why isn't just assembly 'li' pseudo instruction sufficient?

[allenjbaum]

I was quite certain that it came from LI; what I would like to know is which immediate is causing that to happen; I don't recall seeing it when we tested it, and looking through the code, it shouldn't be possible (with the latest version of the macro) It shifts by edge1 (which is the result of a count_trailing_zeros loop on an even number), so must be in the range 1..XLEN-1 If it all zeroes, it is -1, but the all-zeros case never shifts anything (because it fits into a 12bit immediate) IF there is an escape in this logic, I'd like to find it.

But, that's a good question - why our own version. The answer is that we need these to have the same length, regardless of toolchain, and we couldn't guarantee that all tochains did that, or even if they did, used exactly the same instructions. So we guaranteed it by making our own definition.

On Mon, Feb 20, 2023 at 3:05 PM algrobman @.***> wrote:

these warnings come from your super complex macro: (arch_test,h)

define LI(reg, imm) ;\

.option push ;\

.option norvc ;\

.set even, (1-BIT(imm, 0)) / imm has at least 1 trailing zero / ;\

.set immx, (imm & MASK) / trim to XLEN (noeffect on RV64) / ;\

.set imm12, (SEXT_IMM(immx)) ;\

.set absimm, ((immx^(-BIT(immx,XLEN-1)))&MASK) / cvt to posnum to simplify code / ;\

.set imme, ((immx^(-BIT(immx,0 )))&MASK) / cvt to even, cvt back at end / ;\

.set cry, (BIT(immx, IMMSGN)) ;\

.set cryh, (BIT(immx, IMMSGN+32)) ;\

.set pos, 0 ;\

.set edge1, -1 / 1st "1" bit pos scanning r to l / ;\

.set edge2, -1 / 1st "0" bit pos scanning r to l / ;\

/ find 1st 0->1, then 1->0 transition fm LSB->MSB given even operand / ;\

.rept XLEN ;\

.if     (edge1<0)           /* looking for first edge?              */      ;\

  .if (BIT(imme,pos)==1)    /* look for falling edge[pos]           */      ;\

    .set  edge1,pos         /* fnd falling edge, don’t chk for more */      ;\

  .endif                                                                    ;\

.elseif (edge2<0)           /* looking for second edge?             */      ;\

  .if (BIT(imme,pos)==0)    /* yes, found rising edge[pos]?         */      ;\

     .set  edge2, pos       /* fnd rising  edge, don’t chk for more */      ;\

  .endif                                                                    ;\

.endif                                                                      ;\

.set    pos,  pos+1         /* keep looking (even if already found) */      ;\

.endr ;\

.set immxsh, (immx>>edge1) / sh variables only used if positive */ ;\

.set imm12sh,(SEXT_IMM(immxsh))/ look @1st 12b of shifted imm val / ;\

.set crysh, (BIT(immxsh, IMMSGN)) ;\

.set absimmsh, immxsh / pos, no inversion needed, just shift / ;\

/***does it fit into std li or lui+li sequence****/ ;\

.if ((absimm>>IMMSGN)==0) / fits 12b signed imm (properly sgnext)? / ;\

   li   reg, imm12         /* yes, <= 12bit, will be simple li       */    ;\

.elseif (XLEN < 64 || (absimm+ (cry << IMMSZ) >> WDSGN)==0) / fits 32b sgn imm?(w/ sgnext)? / ;\

    lui  reg, (((immx>>IMMSZ)+cry) & LIMMMSK) /* <= 32b, use lui/addi */    ;\

.if   ((imm&IMMMSK)!=0)     /* but skip this if lower bits are zero   */    ;\

    addi reg, reg, imm12                                                    ;\

.endif                                                                      ;\

/*** look for various masks 0s->1s->0s, etc **/ ;\

.elseif ( even && (edge2==-1)) / only rising edge, so 111000 / ;\

     li      reg, -1                                                         ;\

    slli    reg, reg, edge1         /* make 111s --> 000s mask        */    ;\

.elseif (!even && (edge2==-1)) / only falling edge, so 000111 / ;\

    li      reg, -1                                                         ;\

    srli    reg, reg, XLEN-edge1    /* make 000s --> 111s mask        */    ;\

.elseif (imme == (1<<edge1)) / check for single bit case / ;\

    li      reg, 1                                                          ;\

    slli    reg, reg, edge1         /* make 0001000 sgl bit mask      */    ;\

.if   (!even)                                                               ;\

    xori    reg, reg, -1            /* orig odd, cvt to 1110111 mask  */    ;\

.endif                                                                      ;\

.elseif (imme == ((1<<edge2) - (1<<edge1))) / chk for multibit case / ;\

   li      reg, -1                                                         ;\

    srli    reg, reg, XLEN-(edge2-edge1) /* make multibit 1s mask     */    ;\

    slli    reg, reg, edge1         /* and put it into position       */    ;\

.if   (!even)                                                               ;\

    xori    reg, reg, -1            /* orig odd, cvt to 1110111 mask  */    ;\

.endif                                                                      ;\

/** look for 12b or 32b imms with trailing zeroes ***/ ;\

.elseif ((immx==imme)&&((absimmsh>>IMMSGN)==0))/ fits 12b after shift? / ;\

    li      reg, imm12sh            /* <= 12bit, will be simple li    */    ;\

    slli    reg, reg, edge1         /* add trailing zeros             */    ;\

.elseif ((immx==imme)&&(((absimmsh>>WDSGN)+crysh)==0)) / fits 32 <<shft? / ;\

    lui     reg, ((immxsh>>IMMSZ)+crysh)&LIMMMSK /* <=32b, use lui/addi*/    ;\

.if   ((imm12sh&IMMMSK)!=0)         /* but skip this if low bits ==0  */    ;\

    addi    reg, reg, imm12sh                                               ;\

.endif                                                                      ;\

    slli    reg, reg, edge1         /* add trailing zeros             */    ;\

.else / give up, use fixed 8op sequence/ ;\

/ TBD add sp case of zero short imms, rmv add/merge shifts / ;\

    lui     reg, ((immx>>(XLEN-LIMMSZ))+cryh)&LIMMMSK /* 1st 20b (63:44)*/  ;\

    addi    reg, reg, SEXT_IMM(immx>>32)            /* nxt 12b (43:32) */   ;\

    slli    reg, reg, 11    /* following are <12b, don't need SEXT     */   ;\

    addi    reg, reg, (immx>>21) & (IMMMSK>>1)      /* nxt 11b (31:21) */   ;\

    slli    reg, reg, 11                            /* mk room for 11b */   ;\

    addi    reg, reg, (immx>>10) & (IMMMSK>>1)      /* nxt 11b (20:10) */   ;\

    slli    reg, reg, 10                            /* mk room for 10b */   ;\

.if   ((imm&(IMMMSK>>2))!=0) /* but skip this if lower bits are zero   */   ;\

    addi    reg, reg, (immx)     & (IMMMSK>>2)      /* lst 10b (09:00) */   ;\

.endif                                                                      ;\

.if (XLEN==32)                                                              ;\

    .warning "Should never get here for RV32"                               ;\

.endif                                                                      ;\

.endif ;\

BTW, just curious, why isn't just assembly 'li' pseudo instruction sufficient?

— Reply to this email directly, view it on GitHub https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1437653467, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJXJ7FR5OZKSCCHVJSDWYP2EXANCNFSM6AAAAAAUY5JYLE . You are receiving this because you were mentioned.Message ID: @.***>

[algrobman]

The answer is that we need these to have the same length, regardless of toolchain,

Could you please elaborate, what do you mean by "the same length" (or length of what) and why did you need this? - the goal of LI is just to set a register a value. Thus for 64 bits CPU li translates to different number of instructions than for 32 bit CPUs.
Also the compiler can exploit constant value to use less instructions. Looking in your macro, seems it generates different number of instructions as well, depending on the constant, and uses different instructions too.

We always use LI/LA pseudos' in our tests with no need in special macro.

I was quite certain that it came from LI; what I would like to know is which immediate is causing that to happen;

see initial description. the warnings point to exact test code lines .

[allenjbaum]

The same length means the same number of ops/bytes in the expansion of the LI. If LI generates differing lengths, (between the reference and the DUT), then trap signatures will have different xEPC, and xTVAL values. Because the linker scripts can be different as well, we compensate by adjusting EPC and TVAL (when it holds an address) to be an offset from the rvtest_data_begin and rvtests_code_begin labels. But that doesn't compensate for random different offsets caused by different sized li pseudoops. , .align directives can also magnify the effect of that (or remove it...).

We have a fixed sized version that does a .align before, and a .align after, but it really blows up the length of the tests, which is why I wanted something much more compact. This isn't perfect, but captures most of the use cases for the trap handler. Tests are stuck with using that form of LA, though, especially as a bare "la" won't work with different linker scripts. The trap handler has been updated to remove almost all cases of LA from it (that will be in the next version), at the cost of requiring tests that create/update/modify page tables have to update trp handler data structures to match.

On Mon, Feb 20, 2023 at 5:55 PM algrobman @.***> wrote:

The answer is that we need these to have the same length, regardless of toolchain,

Could you please elaborate, what do you mean by "the same length" (or length of what) and why did you need this? - the goal of LI is just to set a register a value. Thus for 64 bits CPU li translates to different number of instructions than for 32 bit CPUs. Also the compiler can exploit constant value to use less instructions. Looking in your macro, seems it generates different number of instructions as well, depending on the constant, and uses different instructions too.

We always use LI/LA pseudos' in our tests with no need in special macro.

I was quite certain that it came from LI; what I would like to know is which immediate is causing that to happen;

see initial description. the warnings point to exact test code lines .

— Reply to this email directly, view it on GitHub https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1437753396, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJQUVVS3QQJGG6QMYVLWYQOCZANCNFSM6AAAAAAUY5JYLE . You are receiving this because you were mentioned.Message ID: @.***>

[allenjbaum]

What is strange is we have test code using those constants, and it compiled correctly. For RV32, it should always generate either should always generate the sequence addi, reg, x0, imm for small numbers in the range -2048..2047 inclusive, or

addi, reg, x0, (imm+(cry<<12)>>12; addi reg, reg, SEXT_IMM(imm) otherwise, with no shifting - all that other cod in that complicated macro is essentially for RV64 (or 128, I suppose) I don't suppose you could produce a disassembly listing of this test...?

On Mon, Feb 20, 2023 at 9:42 PM Allen Baum @.***> wrote:

The same length means the same number of ops/bytes in the expansion of the LI. If LI generates differing lengths, (between the reference and the DUT), then trap signatures will have different xEPC, and xTVAL values. Because the linker scripts can be different as well, we compensate by adjusting EPC and TVAL (when it holds an address) to be an offset from the rvtest_data_begin and rvtests_code_begin labels. But that doesn't compensate for random different offsets caused by different sized li pseudoops. , .align directives can also magnify the effect of that (or remove it...).

We have a fixed sized version that does a .align before, and a .align after, but it really blows up the length of the tests, which is why I wanted something much more compact. This isn't perfect, but captures most of the use cases for the trap handler. Tests are stuck with using that form of LA, though, especially as a bare "la" won't work with different linker scripts. The trap handler has been updated to remove almost all cases of LA from it (that will be in the next version), at the cost of requiring tests that create/update/modify page tables have to update trp handler data structures to match.

On Mon, Feb 20, 2023 at 5:55 PM algrobman @.***> wrote:

The answer is that we need these to have the same length, regardless of toolchain,

Could you please elaborate, what do you mean by "the same length" (or length of what) and why did you need this? - the goal of LI is just to set a register a value. Thus for 64 bits CPU li translates to different number of instructions than for 32 bit CPUs. Also the compiler can exploit constant value to use less instructions. Looking in your macro, seems it generates different number of instructions as well, depending on the constant, and uses different instructions too.

We always use LI/LA pseudos' in our tests with no need in special macro.

I was quite certain that it came from LI; what I would like to know is which immediate is causing that to happen;

see initial description. the warnings point to exact test code lines .

— Reply to this email directly, view it on GitHub https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1437753396, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJQUVVS3QQJGG6QMYVLWYQOCZANCNFSM6AAAAAAUY5JYLE . You are receiving this because you were mentioned.Message ID: @.***>

[allenjbaum]

We think that this may be a quirk in the way assembler macros are processed; e.g. it generates all possible code paths, then chooses the right one depending on the conditions it has evaluated, but that process generates warnings that are not suppressed in code that is generated but not selected. We could fix this for RV32, but unclear if we can for RV64 (which is where the bulk of the code is used)

[algrobman]

What I care about is RV32 for now. You could have two versions of the macro - one for 32 and another for 64 bits platforms

[allenjbaum]

I'm working on that theory. To be clear: you can pass all the tests when misaligned is properly configured in sail, and timeouts are increased - but still get those warnings, and you want the warnings removed.

On Tue, Feb 21, 2023 at 6:10 AM algrobman @.***> wrote:

What I care about is RV32 for now. You could have two versions of the macro - one for 32 and another for 64 bits platforms

— Reply to this email directly, view it on GitHub https://github.com/riscv-non-isa/riscv-arch-test/issues/313#issuecomment-1438561021, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJVC4ARNELD5V35PG53WYTEHDANCNFSM6AAAAAAUY5JYLE . You are receiving this because you were mentioned.Message ID: @.***>

[algrobman]

but still get those warnings, and you want the warnings removed.

Exactly - warning removal/fix was the original intent of this issue! . Other stuff is just ways to see the warnings impact on user. One more way to see these warnings probably is to corrupt one of the tests to make it fail compilation ..