From: qballlives AT aol DOT com (QBallLives)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Problem with Optimizer in GCC
Lines: 85
Message-ID: <1998041709064100.FAA05191@ladder01.news.aol.com>
NNTP-Posting-Host: ladder01.news.aol.com
Date: 17 Apr 1998 09:06:41 GMT
Organization: AOL http://www.aol.com
References: <6aee7044 DOT 352a72cc AT aol DOT com>
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

>The following problem pertains to MSDOS.
>
>When compiling enquire.c using optimizer level three, serious
>problems occur.  For example, enquire reports that the number
>of bits in the significand of a float is 64.  It says exactly
>the same thing for type double.
>
>Several other errors occurred during testing as shown in the
>listing which I have included in enquire.zip (attached).  It
>is especially troubling that an execution of the program will
>often leave the FP processor in an error state.  The result
>is a status dump which I have also included in the zip file.
>
>I note also that the following comments follow the run:
>
>    Float expressions are evaluated in double precision
>    Double expressions are evaluated in double precision
>    Long double expressions are evaluated in double precision
>
>Under ordinary circumstances, namely other compiler options
>such as -O2, the expressions are evaluated in long double
>precision.
>
>The attached zip file, enquire.zip, contains
>
>    1. enquire.c
>    2. normal.run - normal output from enquire under option -O2
>                    gcc -o enqgnuO2 -O2 enquire.c
>    3. buggy.run  - buggy output from enquire under option -O3
>                    gcc -o enqgnuO3 -O3 enquire.c
>    4. sigfpe.dmp - output from a run subsequent to the buggy run
>                    doesn't happen every time - just often enough
>                    to be unnerving
>
>K.B. Williams
>Melbourne Beach, FL 32951-2030
>407.728.2774

Well... I have had some trouble with the -O2 switch myself... though it does
improve the speed of the exes I make with it...

I don't know if this will help with your specific problem.. but you could try
making your variables volatile (put the word volatile in the declaration)

I've had alot of problems with code that worked without -O2 locking up w/ O2 -
here's an example of code... and my attempt at explaining why it worked that
way...

if (key_table[MAKE_SPACE])
{
      // wait until user lifts the key before continuing

      while (key_table[MAKE_SPACE]){};

      // continue

      // do this, that, and the other thing
} // end if MAKE_SPACE

The code above is for a keyboard ISR I've used... and what I'm doing is... if
the key is pressed, THEN - first wait until it's released - then do whatever...

with the -O2 switch... the final code is unaware that key_table[MAKE_SPACE] can
change...

even if I do:

if (key_table[MAKE_SPACE])
{
      // wait until user lifts the key before continuing

      while (!key_table[BREAK_SPACE]){};

      // continue

      // do this, that, and the other thing
} // end if MAKE_SPACE

It still doesn't work - UNLESS - I make the key_table volatile..

I didn't get to check out that code.... it wasn't attached to the post..
Jim the loiterer
aloiterer AT juno DOT com
http://members.xoom.com/JimMcCue/index.htm