Re: gcc -O2 produces faulty code : gcc 3.0.3 and gcc 3.0.4

[Andrew Pinski <pinskia at physics dot uc dot edu>]

I see that the functions: getDouble and RKtoDouble are violating C 
aliasing rules.

I think that is the problem.

Thanks,
Andrew Pinski

On Monday, March 11, 2002, at 01:42 , Russell Ruby wrote:

>
> I forgot to mention:
>
> For what it's worth, I also compiled the xlhtml package with the
> Sun workshop 6 (forte) compiler at the highest level of optimization,
> "-xO5", and it produces correct output for integer cell values.
> (The usual -xO2 works fine too).
> Consequently, "gcc -O2" seems more likely to be the culprit rather than
> something strange in the xlhtml.c source which is being optimized away.
> And even if so, the Sun compiler was smart enough not to do so :)
>
> russ
>
>>
>> Systems:
>>
>>  Sparc Solaris 8 with gcc 3.0.3 and gcc 3.0.4
>> and
>>  IBM AIX with unknown version of gcc
>>
>> Problem description:
>>
>> xlhtml is a package (see last paragraph) which renders microsoft
>> 97/2000 excel documents into html.
>>
>> When compiled with optimization "-O2", xlhtml renders integers
>> entered as "general" cell values in excel97/2000 spread sheets as
>> garbage floating point numbers, e.g. "6.95357380974837e-310".
>>
>> However, if all the source files in the xlhtml-0.4.9.0 distribution
>> except xlhtml.c are still compiled with "-O2", but xlhtml.c is
>> compiled with either no optimization or "-O", then integer cell entries
>> are correctly written as integers in the html output.
>>
>> For example, here is a snippet of html output when xlhtml.c
>> is compiled with "-O2".
>>
>> <TR VALIGN="bottom">
>> <TD>Waymire</TD>
>> <TD>6.95357380974822e-310</TD>
>> <TD>A-J</TD>
>> <TD>KIDDER 364</TD>
>> <TD>Rabimov</TD>
>> <TD>6.95357380974832e-310</TD>
>> <TD>6.95357380974837e-310</TD>
>> <TD>&nbsp;</TD>
>> <TD>&nbsp;</TD>
>> <TD>&nbsp;</TD>
>> </TR>
>>
>> Here is the same output section when xlhtml.c is compiled as "-O",
>>
>> <TR VALIGN="bottom">
>> <TD>Waymire</TD>
>> <TD>20</TD>
>> <TD>A-J</TD>
>> <TD>KIDDER 364</TD>
>> <TD>Rabimov</TD>
>> <TD>61</TD>
>> <TD>119</TD>
>> <TD>&nbsp;</TD>
>> <TD>&nbsp;</TD>
>> <TD>&nbsp;</TD>
>> </TR>
>>
>> My apologies for not supplying a succinct C source code
>> example demonstrating the problem.  From experimenting by
>> changing individual bytes in the six byte chunks in excel
>> documents corresponding to "general" integer value cells,
>> what happens would be consistent with pointer arithmetic/dereferencing
>> getting out of whack under "-O2", but that is just a lame guess.
>> Again, the problem is in the file xlhtml.c, and not in the "cole" 
>> library
>> which is used to parse and read the "file system" embodied in the
>> actual excel "xls" file.
>>
>> The package xlhtml-0.4.9.0 is normally available from www.xlhtml.org,
>> but since it is temporarily offline because of hardware problems,
>> I have placed the source package on our anonymous ftp site as:
>>  ftp://ftp.math.orst.edu/pub/xlhtml-0.4.9.0.tar.gz
>>
>> thanks,
>>
>> Russell Ruby   russ@math.orst.edu
>>
>
>