[Bug c/29186] optimzation breaks floating point exception flag reading

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pavel.morozkin at gmail dot com

--- Comment #27 from Andrew Pinski  ---
*** Bug 101063 has been marked as a duplicate of this bug. ***

[Bug c/29186] optimzation breaks floating point exception flag reading

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

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

--- Comment #26 from Richard Biener  ---
(In reply to Richard B. Kreckel from comment #25)
> (In reply to Richard Biener from comment #24)
> > So you're just lucky indeed ...
> 
> This makes me wonder if there is still a way to trigger this.
> 
> You suggest this has been fixed for the division (is there a PR or
> reference?) and I am not able to create a similar bug using addition,
> multiplication, etc. using GCC 10.

You just need to give GCC the incentive to break it.  Like with

#include 
#include 
int main()
{
   double x = (double)printf("") + 1.0; // one
   double y = (double)printf(""); // zero
   double breakme = x / y;
   feclearexcept(FE_ALL_EXCEPT);
   double z = x / y;  // should set FE_DIVBYZERO
   if (fetestexcept(FE_ALL_EXCEPT)) {
   printf("flag set after call.\n");
   }
   printf("%f/%f==%f\n",x,y,z + breakme);
}

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de via Gcc-bugs]

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

--- Comment #25 from Richard B. Kreckel  ---
(In reply to Richard Biener from comment #24)
> So you're just lucky indeed ...

This makes me wonder if there is still a way to trigger this.

You suggest this has been fixed for the division (is there a PR or reference?)
and I am not able to create a similar bug using addition, multiplication, etc.
using GCC 10.

[Bug c/29186] optimzation breaks floating point exception flag reading

[rguenth at gcc dot gnu.org]

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

--- Comment #24 from Richard Biener  ---
For the division when GCC doesn't know the divident is not zero I think we
actually fixed the bug but yes, in general FP operation reordering wrt FP
env access isn't fixed.

But GCC needs to consider that feclear/testexcept exit the program and since
the division may trap it cannot hoist it before the feclearexcept call.
It might move it after the fetestexcept call though (delaying traps is OK).

As soon as we start to put more knowledge about feclearexcept into GCC this
will break again.  Oh - we actually do know this since GCC 8 ...

So you're just lucky indeed ...

[Bug c/29186] optimzation breaks floating point exception flag reading

[glisse at gcc dot gnu.org]

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

--- Comment #23 from Marc Glisse  ---
(In reply to Richard B. Kreckel from comment #22)
> I can't reproduce this bug any more,

I think you are just lucky, I am sure it hasn't been fixed and gcc will still
happily swap FP operations with function calls like fetestexcept. You still
need something like volatile to protect your operation, and even then the
compiler could theoretically move some unrelated FP op just before
fetestexcept, which would set more flags than the operation you wanted to test.

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

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

--- Comment #22 from Richard B. Kreckel  ---
I can't reproduce this bug any more, with any of the optimization settings on
x86 or x86_64 going back as far as GCC 4.9.2. Delighted to see that this has
been addressed in the meantime (even without supporting that pragma.)

I suppose this bug can just be closed. I don't know about 30568. (Don't
understand why it's related at all).

[Bug c/29186] optimzation breaks floating point exception flag reading

[egallager at gcc dot gnu.org]

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

--- Comment #21 from Eric Gallager  ---
(In reply to Richard B. Kreckel from comment #20)
> So, Joseph explained that the code should execute as expected, at least with
> -frounding-math as a workaround. However, with GCC 4.4 it is still not
> possible to write code that takes advantage of those advanced features of
> IEEE754, even on hardware that supports it directly. Could someone, please,
> set this bug's status to something less inappropriate than "unconfirmed"?

I would, but I don't know what'd be more appropriate...

[Bug c/29186] optimzation breaks floating point exception flag reading

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-12-29 21:48:42
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

--- Comment #20 from kreckel at ginac dot de  2009-05-04 06:47 ---
So, Joseph explained that the code should execute as expected, at least with
-frounding-math as a workaround. However, with GCC 4.4 it is still not possible
to write code that takes advantage of those advanced features of IEEE754, even
on hardware that supports it directly. Could someone, please, set this bug's
status to something less inappropriate than "unconfirmed"?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[rguenth at gcc dot gnu dot org]

--- Comment #19 from rguenth at gcc dot gnu dot org  2006-11-19 12:14 
---
The problem is that the division is in no ways special to optimizers.  One
possibility I see would be to introduce either a builtin function or a new
tree-code to access the exception flags.  Of course the fact that flags are
supposed to accumulate doesn't help to simplify things here...

It would be the frontends task to emit compound expressions.  Like instead
of

  D.2529 = x / y;

emit

  { D.2529 = x / y; __builtin_update_except (D.2529); }

(note that __builtin_update_except has to be subject to read/write global
memory to support exception flow across the call-graph).

I bet it's a mess to optimize this stuff correctly without some "clever"
hacks.  Like

  { D.2529 = x / y; *__builtin_flags = __builtin_update_except (D.2529,
*__builtin_flags); }

where we can then make __builtin_update_except const [ideally *__builtin_flags
would just be a special alias tag used and clobbered by the various
exception functions]


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

--- Comment #18 from kreckel at ginac dot de  2006-11-19 11:22 ---
An idea: Would it help if feholdexcept, fetestexcept and all those standard
functions accessing the status and control flags were implemented as builtins,
not as extern libcalls?

This probably wouldn't help against elimination of unused statements that
nevertheless trigger side effects. But it would inhibit the worst cases of code
reordering, I suppose.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

--- Comment #17 from kreckel at ginac dot de  2006-11-06 22:23 ---
(In reply to comment #15)
> Maybe scheduling would have the same issue. The fact that the result of the
> division is not used is a red herring, though. Of course, the assumption is
> that it's actually used.

For the record: Andrew was right and above statement is wrong. The standard
explicitly mandates that unused code must not be removed unless the compiler
can determine that it cannot raise an exception flag [F.8.1]:

: Concern about side effects may inhibit code motion and removal of seemingly
: useless code. For example, in
: #include 
: #pragma STDC FENV_ACCESS ON
: void f(double x)
: {
:  /* ... */
:  for (i = 0; i < n; i++) x + 1;
:  /* ... */
: }
: x + 1 might raise floating-point exceptions, so cannot be removed. And since
: the loop body might not execute (maybe 0 ³ n), x + 1 cannot be moved out of
: the loop. (Of course these optimizations are valid if the implementation can
: rule out the nettlesome cases.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

--- Comment #16 from kreckel at ginac dot de  2006-10-31 11:48 ---
A quote from :

"While on the subject of miscreant compilers, we should remark their
increasingly common tendency to reorder operations that can be executed
concurrently by pipelined computers. C programmers may declare a variable
volatile to inhibit certain reorderings. A programmer's intention is thwarted
when an alleged 'optimization' moves a floating-point instruction past a
procedure-call intended to deal with a flag in the floating-point status word
or to write into the control word to alter trapping or rounding. Bad moves like
these have been made even by compilers that come supplied with such procedures
in their libraries. (See _control87 , _clear87 and _status87 in compilers for
Intel processors.) Operations’ movements would be easier to debug if they
were highlighted by the compiler in its annotated re-listing of the
source-code. Meanwhile, so long as compilers mishandle attempts to cope with
floating-point exceptions, flags and modes in the ways intended by IEEE
Standard 754, frustrated programmers will abandon such attempts and compiler
writers will infer wrongly that unexercised capabilities are unexercised for
lack of demand."


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

--- Comment #15 from kreckel at ginac dot de  2006-10-25 13:22 ---
(In reply to comment #14)
Maybe scheduling would have the same issue. The fact that the result of the
division is not used is a red herring, though. Of course, the assumption is
that it's actually used.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[pinskia at gcc dot gnu dot org]

--- Comment #14 from pinskia at gcc dot gnu dot org  2006-10-25 07:57 
---
So what is happening is there explict barrier for the divide so we assume we
can move it.  I don't know what the correct thing is really, scheduling will
have the same issue and so will being able to delete the divide as it is not
used (and that is not a regression).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

--- Comment #13 from kreckel at ginac dot de  2006-10-25 07:54 ---
(In reply to comment #12)
> It doesn't disappear with -fno-tree-ter, as I would assume if it were a TER
> bug.

I just discovered that it does disappear with -fno-tree-sink, though.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

-- 

kreckel at ginac dot de changed:

   What|Removed |Added

   Severity|enhancement |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

--- Comment #12 from kreckel at ginac dot de  2006-09-24 16:51 ---
(In reply to comment #11)
> This is a TER bug then and I really doubt it can be fixed easy.

It doesn't disappear with -fno-tree-ter, as I would assume if it were a TER
bug.


-- 

kreckel at ginac dot de changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[pinskia at gmail dot com]

--- Comment #11 from pinskia at gmail dot com  2006-09-24 00:34 ---
Subject: Re:  optimzation breaks floating point exception flag
reading

On Sat, 2006-09-23 at 23:02 +, joseph at codesourcery dot com wrote:
> In that case you have a bug that is not a duplicate of the lack of 
> FENV_ACCESS pragma support.  The relevant semantics are meant to be 
> supported by these command line options.

This is a TER bug then and I really doubt it can be fixed easy.

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[joseph at codesourcery dot com]

--- Comment #10 from joseph at codesourcery dot com  2006-09-23 23:02 
---
Subject: Re:  optimzation breaks floating point exception flag
 reading

On Sat, 23 Sep 2006, kreckel at ginac dot de wrote:

> I am still not entirely sure whether we are really talking about the same
> problem. The original problem was that the compiler optimized assuming that 
> the
> floating point division cannot have side effects, such that the offending
> division happens after the call to fetestexcept(3):

> Neither -ftrapping-math, nor -frounding-math change anything, as long as -O1 
> is
> turned on: The printf inside the if statement is *not* executed.

In that case you have a bug that is not a duplicate of the lack of 
FENV_ACCESS pragma support.  The relevant semantics are meant to be 
supported by these command line options.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

--- Comment #9 from kreckel at ginac dot de  2006-09-23 22:58 ---
(In reply to comment #8)
I am still not entirely sure whether we are really talking about the same
problem. The original problem was that the compiler optimized assuming that the
floating point division cannot have side effects, such that the offending
division happens after the call to fetestexcept(3):

#include 
#include 
int main()
{
   double x = (double)printf("") + 1.0; // one
   double y = (double)printf(""); // zero
   feclearexcept(FE_ALL_EXCEPT);
   double z = x / y;  // should set FE_DIVBYZERO
   if (fetestexcept(FE_ALL_EXCEPT)) {
   printf("flag set after call.\n");
   }
   printf("%f/%f==%f\n",x,y,z);
}

Neither -ftrapping-math, nor -frounding-math change anything, as long as -O1 is
turned on: The printf inside the if statement is *not* executed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[joseph at codesourcery dot com]

--- Comment #8 from joseph at codesourcery dot com  2006-09-23 22:19 ---
Subject: Re:  optimzation breaks floating point exception flag
 reading

On Sat, 23 Sep 2006, kreckel at ginac dot de wrote:

> 
> 
> --- Comment #7 from kreckel at ginac dot de  2006-09-23 22:11 ---
> (In reply to comment #6)
> > Use -frounding-math to enable FENV_ACCESS for the whole translation unit, 
> 
> Sorry, I fail to see what -frounding-math has to do with this. The example in
> comment #5 was about overflows and divisions by zero. Anyway, adding
> -frounding-math does not change anything in the case at hand.

Exceptions are meant to be covered by -ftrapping-math, which is on by 
default; with -frounding-math the whole of FENV_ACCESS should be enabled.

Although we don't implement the pragmas for control of these features in 
particular regions of code, we *do* have options that are meant to enable 
them for whole translation units.  So any failure of those options to 
disable problem optimizations is a bug which is *not* a duplicate of the 
lack of the pragmas.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

--- Comment #7 from kreckel at ginac dot de  2006-09-23 22:11 ---
(In reply to comment #6)
> Use -frounding-math to enable FENV_ACCESS for the whole translation unit, 

Sorry, I fail to see what -frounding-math has to do with this. The example in
comment #5 was about overflows and divisions by zero. Anyway, adding
-frounding-math does not change anything in the case at hand.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[joseph at codesourcery dot com]

--- Comment #6 from joseph at codesourcery dot com  2006-09-23 21:52 ---
Subject: Re:  optimzation breaks floating point exception flag
 reading

On Sat, 23 Sep 2006, kreckel at ginac dot de wrote:

> According to C99, 7.6.1, you are technically right. But still: an
> implementation that does not allow access to floating point flags irritates 
> me.

Use -frounding-math to enable FENV_ACCESS for the whole translation unit, 
but note the warnings in the documentation of that option.  If that option 
does not meet all the requirements of FENV_ACCESS, file a new bug report 
for each specific problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

--- Comment #5 from kreckel at ginac dot de  2006-09-23 21:41 ---
(In reply to comment #3)
> So this is not a bug except for the fact GCC does not implement "#pragma STDC
> FENV_ACCESS "

According to C99, 7.6.1, you are technically right. But still: an
implementation that does not allow access to floating point flags irritates me.
Couldn't that be outright dangerous, in certain circumstances?

Consider a hypothetical train control unit:

#define FE_CRITICAL (FE_DIVBYZERO|FE_INVALID|FE_OVERFLOW|FE_UNDERFLOW)
double compute_speed(double measurement)
{
return -1./(measurement); // in reality, some rather hairy computation
}

// Adjusts speed towards nominal speed, given measurement of speed sensor.
// May decelerate, in unforeseen cases.
void control(double nominal_v, double measurement)
{
#pragma STDC FENV_ACCESS on
feclearexcept(FE_CRITICAL);
double v = compute_speed(measurement);
if (fetestexcept(FE_CRITICAL)) {
// Unexpected error: should not trust the computed speed.
decelerate();
return;
}
if (v > nominal_v*1.001) {
printf("v==%f\n",v);
decelerate();
return;
}
if (v < nominal_v*0.999) {
accelerate();
return;
}
}

Would you board that train if the train control unit were compiled with GCC?

The function decelerates the train if something unforeseen happens inside the
speed computation. At least it did that when it was compiled with GCC 3.3.x,
3.4.x, or 4.0.x. Now, with GCC 4.1.x, all bets are off. Also, no compiler
version seems to care to print a warning.

Having the users lulled in a false sense of safety for so long, this changed
behavior with a allusion to the standard ("we need not return something
meaningful") strikes me as, excuse me, somewhat careless.

Maybe somehone can provide other suggestions how to program defensively? In
principle, the functionality used above (testing floating point flags) has been
promised since two decades (it's IEEE 754) and has been implemented in almost
every major hardware since as long. Can GNU-C not be used for such simple
things?


-- 

kreckel at ginac dot de changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[kreckel at ginac dot de]

--- Comment #4 from kreckel at ginac dot de  2006-09-22 22:34 ---
(In reply to comment #1)
> This is not really a bug in C99 unless you use:
> #pragma STDC FENV_ACCESS on
> 
> But then again we don't implement that pramgma yet 

Okay, I was not aware of that pragma. Thank you for pointing it out. But what I
find hard to grasp is why it works with previous releases. We have this library
call fetestexcept(3) and with gcc 4.1 it basically stopped working. I would say
this even qualifies as a regression, right?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-09-22 19:27 ---
So this is not a bug except for the fact GCC does not implement "#pragma STDC
FENV_ACCESS "

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-09-22 19:25 ---
PR 20785 has a patch but it has not been applied.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||20785
   Severity|normal  |enhancement


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186

[Bug c/29186] optimzation breaks floating point exception flag reading

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-09-22 19:24 ---
This is not really a bug in C99 unless you use:
#pragma STDC FENV_ACCESS on

But then again we don't implement that pramgma yet 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186