[Bug middle-end/109967] [10/11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

2023-06-05 Thread amonakov at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #4 from Alexander Monakov  ---
See PR 90348 for the discussion of problematic lifetime semantics.

[Bug middle-end/109967] [10/11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

2023-06-05 Thread davmac at davmac dot org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967

Davin McCall  changed:

   What|Removed |Added

 CC||davmac at davmac dot org

--- Comment #3 from Davin McCall  ---
-fdisable-tree-cunroll avoids it.

This is the take of someone who is new to poking GCC internals, so take this
with a grain of salt, but:

It looks like cunroll duplicates (partially unrolls, I suppose) the inner loop,
meaning that `g' is live in two disjoint ranges, with a CLOBBER between them.

Then later passes (fre5, but disabling it doesn't seem to help) recognise that
 and  are the same in both ranges and so use a single temporary for both.
This confuses cfgexpand (as Andrew Pinski notes) because the memory dereference
of the temporary isn't seen as an access of g (in
add_scope_conflicts()/add_scope_conflicts_1()/visit_conflict()). 

I don't understand the IR semantics well enough to know the right fix - perhaps
cunroll should be removing the clobber (does a clobber affect storage lifetime
or only value?), or perhaps cfgexpand should be more conservative when it sees
a memory access.

[Bug middle-end/109967] [10/11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

2023-05-26 Thread rguenth at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Last reconfirmed||2023-05-26
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug middle-end/109967] [10/11/12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

2023-05-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109967

Andrew Pinski  changed:

   What|Removed |Added

Summary|Wrong code at -O2 on|[10/11/12/13/14 Regression]
   |x86_64-linux-gnu|Wrong code at -O2 on
   ||x86_64-linux-gnu
   Target Milestone|--- |10.5
  Known to work||6.1.0
  Known to fail||7.1.0

--- Comment #2 from Andrew Pinski  ---
The problem is the Partition code in expand.

Without the ={0,0}, we get:
Partition 1: size 20 align 16
g   f

With we get:
Partition 1: size 20 align 16
g
Partition 0: size 16 align 16
f