[Bug tree-optimization/67781] Wrong code generated on mips32 with -O1 -fexpensive-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #3 from Mikael Pettersson --- SPARC (big-endian) is also affected. gcc-6 and gcc-5 generate wrong code with -O2 or -O1 -fexpensive-optimizations, but working code with just -O1. gcc-4.9 generates working code at all optimization levels.
[Bug tree-optimization/67781] Wrong code generated on mips32 with -O1 -fexpensive-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781 --- Comment #5 from Mikael Pettersson --- m68k is also affected, so it looks like all big-endian targets have this bug: --- shift.s-m68k-r2108422015-12-12 18:50:53.358503028 +0100 +++ shift.s-m68k-r2108432015-12-12 18:54:43.938357653 +0100 @@ -9,10 +9,7 @@ .type main, @function main: link.w %fp,#0 - move.l s,%d0 - lsl.l #8,%d0 - or.b s+4,%d0 - move.l %d0,-(%sp) + move.l s,-(%sp) pea .LC0 jsr printf clr.l %d0
[Bug tree-optimization/67781] Wrong code generated on mips32 with -O1 -fexpensive-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781 Mikael Pettersson changed: What|Removed |Added CC||thomas.preudhomme at arm dot com --- Comment #4 from Mikael Pettersson --- A bisection using a cross to sparc64-linux identified r210843 as the starting point of this wrong-code regression. The code generation difference at that revision for this test case is: --- shift.s-r210842 2015-12-12 18:39:22.878875236 +0100 +++ shift.s-r210843 2015-12-12 18:36:37.938974547 +0100 @@ -15,12 +15,8 @@ sethi %hi(.LC0), %o0 lduw[%g1+%lo(s)], %o1 or %o0, %lo(.LC0), %o0 - mov 0, %i0 - ldub[%g1+%lo(s)+4], %g1 - sll %o1, 8, %o1 - or %g1, %o1, %o1 callprintf, 0 -srl%o1, 0, %o1 +mov0, %i0 return %i7+8 nop .size main, .-main that is, the "<< 8" and "| s.b" parts of the expression were lost. Adding author to CC.
[Bug tree-optimization/67781] Wrong code generated on mips32 with -O1 -fexpensive-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781
Steve Ellcey changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-12-08
CC||sje at gcc dot gnu.org
Component|rtl-optimization|tree-optimization
Ever confirmed|0 |1
--- Comment #2 from Steve Ellcey ---
It looks like this is going wrong in the bswap pass (tree-ssa-math-opts.c) that
is only done with expensive optimizations. It also looks like it only affects
big-endian targets, but I think it affects all big-endian targets.
If I compile the test program with -O1 -fdump-tree-all
-fexpensive-optimizations
I get this code before the bswap pass:
main ()
{
uint32_t c;
unsigned int _2;
unsigned int _3;
unsigned char _4;
unsigned int _5;
:
_2 = s.a;
_3 = _2 << 8;
_4 = s.b;
_5 = (unsigned int) _4;
c_6 = _3 | _5;
printf ("%x\n", c_6);
return 0;
}
And this code after the bswap pass:
main ()
{
uint32_t c;
unsigned int _2;
unsigned int _3;
unsigned char _4;
unsigned int _5;
uint32_t * load_src_8;
:
load_src_8 =
c_6 = MEM[(void *)load_src_8];
_2 = s.a;
_3 = _2 << 8;
_4 = s.b;
_5 = (unsigned int) _4;
printf ("%x\n", c_6);
return 0;
}
