[Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change

2021-12-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-12-23

--- Comment #5 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change

2021-01-09 Thread tkoenig at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552

--- Comment #4 from Thomas Koenig  ---
Yes, I think that translating a DO loop into something like

int i;

for (i=0; i

[Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change

2021-01-06 Thread tobi at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552

--- Comment #3 from Tobias Schlüter  ---
Don't ask how long I'd been staring at the assembly in disbelief until I
figured out what had gone wrong :-)

In this particular case the problem can be addressed by passing  into the
function instead of , so I wonder why the Fortran f.e. can't do that?  One
possible problem is that if j's address escapes (in the sense that the compiler
assumes that subsequent function calls can do whatever to it), you'd need a new
fake memory location.

[Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change

2021-01-06 Thread tkoenig at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552

--- Comment #2 from Thomas Koenig  ---
(In reply to Tobias Schlüter from comment #1)
> There's a typo in the example, /= instead of !=.  Fixed example below:

The disease of a Fortran programmer writing C, I guess :-)

[Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change

2021-01-05 Thread tobi at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552

Tobias Schlüter  changed:

   What|Removed |Added

 CC||tobi at gcc dot gnu.org

--- Comment #1 from Tobias Schlüter  ---
There's a typo in the example, /= instead of !=.  Fixed example below:

I sprinkled const's all over foo's prototype and 'i' still gets reloaded so it
stands to reason that the compiler doesn't see the optimization opportunity. 

==

void foo (int *);

void bar (int n)
{
  int i;
  for (i=0; i

[Bug tree-optimization/98552] Make more use of __builtin_undefined for assuring that variables do not change

2021-01-05 Thread tkoenig at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98552

Thomas Koenig  changed:

   What|Removed |Added

Version|unknown |11.0
   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=31593
   Severity|normal  |enhancement