* Crossposted in OS2PROG
* Crossposted in OS2.PROG.GER
* Crossposted in OS2NET.PROGRAMMIERUNG.GER

======================================================================
* Forwarded von Thomas Seeling (2:244/1130.42)
* Area : emx
======================================================================
From: hrv{at}xs4all.nl (Hans R. Visser)


Greetings,

I'd like to draw your attention to the following 'feature' that can
occur when using the GCC's optimize options (-Ox) on a 386/486/586
platform. Consider the following test program.

***** test1.c
#include 
#include 
#define Pi   3.1415926535897932384626433
void main()
{
    double d,D;

    D = d = 2.*atan2(1.,0.);
    if (d>Pi)   d -= 2.*Pi;
    printf("d=%f   %.20e\n",d,D);
}

When compiled with GCC, this program behaves differently depending on
whether the optimization option is used or not. Running the program
compiled without optimization yields

d=3.141593   3.14159265358979311600e+00

whilst compiled with -O, the output becomes

d=-3.141593   3.14159265358979311600e+00

The difference is caused by the fact that the optimized program stores
the variable 'd' in a register with a higher floating point precision
than if it were stored in memory, as is the case with the variable
'D'. The higher precision gives a different result of the 'if'-test,
and thus a different program flow.

This behaviour can be suppressed by either not using optimization at
all, or compiling with the -ffloat-store option.

Interestingly, the following program does not suffer from this
unpredictability. This program is identical to test1.c, but contains a
dummy printf("") statement, which presumably prevents the optimization
routine from allocating a register to the variable d.

***** test2.c
#include 
#include 
#define Pi   3.1415926535897932384626433
void main()
{
    double d,D;

    D = d = 2.*atan2(1.,0.);
    printf("");
    if (d>Pi)   d -= 2.*Pi;
    printf("d=%f   %.20e\n",d,D);
}


I don't know how well-known this phenomenon is, but it took me a while
to locate its roots when it occured in a real-life program. Note that
it is not a 'bug' as such, for everything behaves according to
specification. It is a bit odd, though.


Hans Visser
-------------
To unsubscribe send a message to majordomo{at}IAEhv.nl with in the body:
unsubscribe emx 
Report serious problems at: emx-owner{at}.IAEhv.nl.
======================================================================

--- E3-32/1.11-32/2.51+