[Bug tree-optimization/101080] wrong code with "-O3"

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101080

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1) 
> But it's a nice testcase.

The other PR has basically the same testcase even already and about the same
size.

[Bug tree-optimization/101080] wrong code with "-O3"

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101080

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Andrew Pinski  ---
It is a dup of the other SRA issue.
PR 100453

*** This bug has been marked as a duplicate of bug 100453 ***

[Bug tree-optimization/101080] wrong code with "-O3"

[rguenth at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101080

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2021-06-16
 Ever confirmed|0   |1
 CC||jamborm at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Confirmed.  Also happens with -O3 -fno-tree-vectorize which produces

Program received signal SIGSEGV, Segmentation fault.
0x004003b7 in main ()
(gdb) disassemble
Dump of assembler code for function main:
   0x004003a0 <+0>: movzbl 0x200c95(%rip),%eax# 0x60103c

   0x004003a7 <+7>: cmp$0x14,%al
   0x004003a9 <+9>: je 0x4003da 
   0x004003ab <+11>:nopl   0x0(%rax,%rax,1)
   0x004003b0 <+16>:add$0x4,%eax
   0x004003b3 <+19>:cmp$0x14,%al
   0x004003b5 <+21>:jne0x4003b0 
=> 0x004003b7 <+23>:andb   $0xf8,0x186(%rip)# 0x400544 
   0x004003be <+30>:movl   $0x0,0x200c70(%rip)# 0x601038

   0x004003c8 <+40>:movq   $0x0,0x200c5d(%rip)# 0x601030

   0x004003d3 <+51>:movb   $0x14,0x200c62(%rip)# 0x60103c

   0x004003da <+58>:xor%eax,%eax
   0x004003dc <+60>:ret

simpler IL testcase (elide g) - note the inlining is critical.

struct a {
  unsigned b : 3;
} const c;
char d;
int e;
long f;
static void g(const struct a h)
{
  for (; d != 20; d = d + 4) {
  int i = h.b;
  e = h.b;
  f = h.b || 0;
  }
}
int main()
{
  g(c);
}

so the issue is we store to 'c' which resides in .rodata - suspect this is
a dup of the pending SRA issue.  -fno-tree-sra fixes it.

But it's a nice testcase.