User account creation filtered due to spam.

Bug 17865 - Bad code generation (using -O2 and -O3) on x86 target when using the listed snippet
Summary: Bad code generation (using -O2 and -O3) on x86 target when using the listed s...
Status: RESOLVED DUPLICATE of bug 21920
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.3.2
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2004-10-06 18:12 UTC by davidel
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: 3.3.2
Target: 3.3.2
Known to work:
Known to fail:
Last reconfirmed:

Test program (204 bytes, text/plain)
2004-10-06 18:12 UTC, davidel
Code generated (465 bytes, text/plain)
2004-10-06 18:13 UTC, davidel
Intermediate output (8.96 KB, text/plain)
2004-10-06 18:13 UTC, davidel

Note You need to log in before you can comment on or make changes to this bug.
Description davidel 2004-10-06 18:12:21 UTC
When compiling the simple program below using -O1 and -O{2,3}, you will get
different results.

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

#define __HI(x) ((int *) &(x))[1]

double test(double v) {
        int hi;
        hi = __HI(v);
        return hi + v;

int main(int ac, char **av) {
        double v = 2.30912;
        if (ac > 1)
                v = atof(av[1]);
        printf("val=%lf\n", test(v));
        return 0;

Looking at the code generation you will notice that the offset of the "fildl" is
clearly wrong, being it accessing the uninitialized part of the stack (it should
have been "12(%ebp)"):

        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        fildl   -4(%ebp)
        faddl   8(%ebp)
Comment 1 davidel 2004-10-06 18:12:57 UTC
Created attachment 7296 [details]
Test program
Comment 2 davidel 2004-10-06 18:13:24 UTC
Created attachment 7297 [details]
Code generated
Comment 3 davidel 2004-10-06 18:13:52 UTC
Created attachment 7298 [details]
Intermediate output
Comment 4 Andrew Pinski 2004-10-06 18:20:33 UTC
You are violating aliasing rules.
Comment 5 davidel 2004-10-06 18:30:16 UTC
Note that this code works with -O1, and it is part on the NetLib math library
that worked for ages. Now, there are many ways to achieve the same thing, but if
aliasing rules wants to be enforced, the should be enforced with every
optimization level, and not break with -O2/3 and work just fine with -O1. A lot
of existing C code alias values in this or similar way, and if this breaks other
stuff will too. 
Comment 6 Andrew Pinski 2004-10-06 18:34:57 UTC
Yes but -O2 enables -fstrict-aliasing which means follow the ANSI/ISO C
aliasing rules which you/the program is violating.
Use either -fno-strict-aliasing or an union which GCC defines (unlike the ANSI/
ISO C standard where it is undefined too).
Comment 7 Wolfgang Bangerth 2004-10-06 18:41:37 UTC
Andrew is right: some codes break because only higher optimization 
levels do certain aggressive transformations, and work when lower 
optimizations are used. There is not much we can do about it, apart 
from asking our users to fix their codes. The manual contains a 
section on aliasing problems, and how to avoid them. 
Comment 8 davidel 2004-10-06 18:50:56 UTC
Oh, I agree. But in this case a clear error instead of a warning would be
better. Error better fits the bad code generation, instead of a warning.
Comment 9 Andrew Pinski 2004-10-06 19:00:16 UTC
It cannot be an error since this only undefined at runtime and not undefined
at compile time.
Comment 10 Wolfgang Bangerth 2004-10-06 19:03:40 UTC
Well, to be more precise: if we knew how to formulate the conditions under 
which we are sure that an aliasing violation happens, we'd be happy to  
provide clearer compiler diagnostics. However, this has been discussed many 
times on the mailing lists, and somehow nobody ever came up with a real 
good way to determine wether the aliasing rules are violated or not. 
So for the moment: we're sorry, but we don't know how to do that. Your 
code is invoking undefined behavior at runtime, and the standards allow 
the compiler to let this slip by with no diagnostic required. 
Comment 11 Andrew Pinski 2005-06-05 08:59:26 UTC
Reopening to ...
Comment 12 Andrew Pinski 2005-06-05 08:59:45 UTC
Mark as a dup of bug 21920.

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