Bug 17765 - optimizer generates wrong code for inlined function
optimizer generates wrong code for inlined function
Status: RESOLVED DUPLICATE of bug 21920
Product: gcc
Classification: Unclassified
Component: c++
4.0.0
: P2 normal
: ---
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-01 02:33 UTC by p.van-hoof
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments
the offending code (491 bytes, text/plain)
2004-10-01 02:34 UTC, p.van-hoof
Details
offending code, Sparc version (491 bytes, text/plain)
2004-10-01 02:37 UTC, p.van-hoof
Details

Note You need to log in before you can comment on or make changes to this bug.
Description p.van-hoof 2004-10-01 02:33:13 UTC
When the attached test case is compiled without optimization, it produces the
folowing output:

dogbert> g++ -O0 f.cc
dogbert> a.out
1

With optimization turned on, it produces this:

dogbert> g++ -O2 f.cc
dogbert> a.out
0

A minimum of -O2 is needed. This problem occurs with all release versions of the
3.3 and 3.4 branch, as well as the mainline (version 20040908). Actually the
mainline crashes on a segfault for all levels of optimization (including -O0) on
the IA32 platform, but shows the behavior shown above on the AMD64 platform. A
slightly modified version of the code (to account for the fact that this is a
big-endian platform) can also reproduce the same problem on a Sparc platform for
the 3.3 and 3.4 branch; the status of the mainline on Sparc is currently
unknown. Apparantly this problem is platform independent. The 3.2.3 version of
the code behaves correctly on all mentioned platforms, hence this appears to be
a regression.
Comment 1 p.van-hoof 2004-10-01 02:34:22 UTC
Created attachment 7251 [details]
the offending code
Comment 2 p.van-hoof 2004-10-01 02:37:02 UTC
Created attachment 7252 [details]
offending code, Sparc version

This is the version of the code that reproduces the problem on Sparc platforms.
Some of the array indices have been swapped to account for the big-endian
nature of the platform.
Comment 3 Andrew Pinski 2004-10-01 03:04:43 UTC
	long long x[2];
		int* y = reinterpret_cast<int*>(x);

you are violating aliasing rules.
Comment 4 p.van-hoof 2004-10-01 04:48:10 UTC
(In reply to comment #3)
> you are violating aliasing rules.

You have to forgive my ignorance. If this is violating aliasing rules, shouldn't
the compiler warn about that?
Comment 5 Andrew Pinski 2004-10-01 04:50:07 UTC
We do for some cases in C but not all, for C++ there is another bug about warning it already.
Comment 6 Andrew Pinski 2005-06-05 08:58:20 UTC
Reopening to ...
Comment 7 Andrew Pinski 2005-06-05 08:58:35 UTC
Mark as a dup of bug 21920

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