https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #16 from chenglulu <chenglulu at loongson dot cn> --- (In reply to rguent...@suse.de from comment #15) > On Thu, 13 Apr 2023, xry111 at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357 > > > > --- Comment #14 from Xi Ruoyao <xry111 at gcc dot gnu.org> --- > > (In reply to rguent...@suse.de from comment #13) > > > On Thu, 13 Apr 2023, chenglulu at loongson dot cn wrote: > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357 > > > > > > > > --- Comment #10 from chenglulu <chenglulu at loongson dot cn> --- > > > > (In reply to Xi Ruoyao from comment #5) > > > > > The test fails on loongarch64-linux-gnu. foo is kept in > > > > > 114t.threadfull1, > > > > > but removed in 135t.forwprop3. > > > > > > > > > > Does this mean something is wrong for LoongArch, or we should simply > > > > > check > > > > > the tree dump in a later pass (for e.g. 254t.optimized)? > > > > > > > > If the definition of the macro DEFAULT_SIGNED_CHAR is changed to 0, the > > > > test > > > > case can pass the test. I guess it is because the definition of > > > > DEFAULT_SIGNED_CHAR affects the optimization of the ccp pass, resulting > > > > in some > > > > blocks that cannot be removed, resulting in the failure of this test > > > > case. > > > > > > Can you check if making b unsigned fixes the test for you? If so > > > that's what we should do. > > > > It works? > > > > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c > > b/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c > > index 44c457b7a97..79cf371ef28 100644 > > --- a/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c > > +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr108357.c > > @@ -1,7 +1,7 @@ > > /* { dg-do compile } */ > > /* { dg-options "-O2 -fdump-tree-threadfull1" } */ > > > > -static char b; > > +static unsigned char b; > > static unsigned c; > > void foo(); > > short(a)(short d, short e) { return d * e; } > > > > But I'm still wondering why this is not an issue for x86_64. > > Yes, that's interesting to see. It does change how b is extended > in b ^ 9854 (but for the value zero it doesn't matter). I think the problem is hereļ¼ In adjust_alignment, the intermediate result output of loongarch and x86 is as follows: LoongArch: ... b.2_1 = bD.2176; # RANGE [irange] short int [-128, 127] _2 = (short intD.12) b.2_1; # RANGE [irange] short int [-16384, -1][1, 16383] _3 = _2 ^ 9854; # RANGE [irange] unsigned short [1, 16383][49152, +INF] e.1_6 = (unsigned short) _3; _7 = e.1_6 * 5; _8 = (short intD.12) _7; # .MEM_15 = VDEF <.MEM_4(D)> bD.2176 = 0; if (_8 != 0) goto <bb 3>; [67.00%] else goto <bb 6>; [33.00%] ... c.4_9 = 0; _10 = c.4_9 == 0; # RANGE [irange] int [0, 1] NONZERO 0x1 _11 = (intD.1) _10; # RANGE [irange] int [-32768, -1][1, 32767] _12 = (intD.1) _8; ... X86: ... b.2_1 = bD.2738; # RANGE [irange] short int [-128, 127] _2 = (short intD.17) b.2_1; # RANGE [irange] short int [-16384, -1][1, 16383] _3 = _2 ^ 9854; # RANGE [irange] unsigned short [1, 16383][49152, +INF] e.1_7 = (unsigned short) _3; _8 = e.1_7 * 5; _9 = (short intD.17) _8; # RANGE [irange] int [-32768, 32767] _4 = (intD.6) _9; d_10 = (short intD.17) _4; # .MEM_17 = VDEF <.MEM_5(D)> bD.2738 = 0; if (d_10 != 0) goto <bb 3>; [67.00%] else goto <bb 6>; [33.00%] ... There is an additional intermediate variable _9 in x86 and loongarch does not, but _8 is used, but _8 is used twice, so if (_8 != 0) goto <bb 3>; [67.00%] else goto <bb 6>; [33.00%] is not deleted when ccp2 passes. That's why the test case failed. I think if loongarch can generate an intermediate variable like x86, the test will pass.
