[Bug tree-optimization/66512] PRE fails to optimize calls to pure functions in C++, ok in C

2020-11-24 Thread i at maskray dot me via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512

Fangrui Song  changed:

   What|Removed |Added

 CC||i at maskray dot me

--- Comment #4 from Fangrui Song  ---
Should this be reopened?

https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html 'const' is
not clarified on its interaction with threads
(https://gcc.gnu.org/legacy-ml/gcc/2015-09/msg00365.html)

and 

void f()
{
  for (;;)
g(p());
}

is still pessimized for C++ (I tend to agree that 'const' should imply
'nothrow'; even if no, the #c2 case should be resolved properly)

[Bug tree-optimization/66512] PRE fails to optimize calls to pure functions in C++, ok in C

2015-06-18 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512

--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Alexander Monakov from comment #2)
 In that case I'd like to contribute a documentation patch to make that clear
 in the pure/const attribute information, but I need more explanation.  I see
 that
 
 int p(void) __attribute__((const));
 void f()
 {
   p();
   p();
 }
 
 is optimized to an empty function, even though p may throw.  Is that not a
 bug?

I would say so.  But this has quite some implementation issues, also with...

 Also, could you please expand your explanation in the first paragraph, i.e.
 this:
 
   What we miss here is the fact that it should only matter
   if p throws internally for IL consistency.  Of course it
   still matters for observing other side-effects if p throws
   and after the transform now does so before side-effects
   that should be observed otherwise.
 
 I'm probably missing a lot of contextual knowledge to understand that.  TIA.

... this, the side-effect ordering of stores and the throwing p() call is
not properly represented.


[Bug tree-optimization/66512] PRE fails to optimize calls to pure functions in C++, ok in C

2015-06-15 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512

--- Comment #2 from Alexander Monakov amonakov at gcc dot gnu.org ---
In that case I'd like to contribute a documentation patch to make that clear in
the pure/const attribute information, but I need more explanation.  I see that

int p(void) __attribute__((const));
void f()
{
  p();
  p();
}

is optimized to an empty function, even though p may throw.  Is that not a bug?

Also, could you please expand your explanation in the first paragraph, i.e.
this:

  What we miss here is the fact that it should only matter
  if p throws internally for IL consistency.  Of course it
  still matters for observing other side-effects if p throws
  and after the transform now does so before side-effects
  that should be observed otherwise.

I'm probably missing a lot of contextual knowledge to understand that.  TIA.


[Bug tree-optimization/66512] PRE fails to optimize calls to pure functions in C++, ok in C

2015-06-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66512

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Because p may throw.  What we miss here is the fact that it should only matter
if p throws internally for IL consistency.  Of course it still matters for
observing other side-effects if p throws and after the transform now does so
before side-effects that should be observed otherwise.  Consider


 for (;;)
   {
 printf(foo);
 g(p())
   }

and p throwing.

So you miss a nothrow attribute or a throw() specification here.  const
does _not_ imply nothrow.