Re: BUG #2162: Same as bug #1679 - finite() - unresolved symbol

> In principle an aggressive compiler could still determine that the
> global variable is modified nowhere else in the executable.

Yes, it can determine that the variable content is constant but what is
important here is that it cannot determine its value at compile time. This way,
either it replaces the call with a macro, and it is OK, or it has to keep the
call. The only problem is to find a global value, which cannot be determined at
compile time.

First, I tested your suggestion : 'return finite(1.0) ? 0 : 1;'. It doesn't
work, the call is removed. With this test, we see that the optimizer does not
remove the line because the result is unused, as I thought, but more probably
because it is able to compute it at compile time. Which means that finite()
becomes a reserved function in gcc, as I checked that the call is removed even
if we don't include <math.h> :-(

Then, I looked for something using a global value, and compatible with the
autoconf skeleton. I tried 'return finite(*((float *)main));'. And it works :
the call is not removed, even with '-O4'. In my opinion, this syntax cannot be
removed by the optimizer, as it should be impossible to determine at compile
time if the float stored at address 'main' is a finite number. So, as it is the
best solution I have so far, I propose it.

About isinf():
The case is more complex, as isinf is a macro in <math.h>.
Actually :
isinf(x);
is translated to :
((sizeof(x)==sizeof(float))?_Isinff(x):_Isinf(x))
And only _Isinff is kept ! But it can be considered as correct, as it is a
sizeof comparison (allowed at compile time). If you want to make it more
robust, it can be replaced by something like above :
return isinf(*((float *)main));
I tested and it works too.

About sigsetjmp :
I just checked that the symbol is still present with '-O2' and '-O4'. And as I
never use these f... setjmp mechanism, I cannot suggest any more robust test.

Regards

François