Bug 57921 - Alias change causes perl from SPEC 2006 to abort on MIPS
Summary: Alias change causes perl from SPEC 2006 to abort on MIPS
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: alias
Depends on:
Blocks:
 
Reported: 2013-07-17 22:13 UTC by Steve Ellcey
Modified: 2013-07-27 20:56 UTC (History)
1 user (show)

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


Attachments
What the CSE phase generated prior to checkin r200133 (4.29 KB, text/plain)
2013-07-17 22:13 UTC, Steve Ellcey
Details
What the CSE phase generated after checkin r200133 (4.27 KB, text/plain)
2013-07-17 22:14 UTC, Steve Ellcey
Details
Test case cut down from perl benchmark in SPEC 2006 (465 bytes, text/x-csrc)
2013-07-17 22:15 UTC, Steve Ellcey
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Ellcey 2013-07-17 22:13:52 UTC
Created attachment 30517 [details]
What the CSE phase generated prior to checkin r200133

With the latest GCC (as of version r200133) the perl benchmark in SPEC 2006 is
failing for me on the mips-linux-gnu target.  The patch that caused it to start
failing is to the alias analysis phase of GCC and it affects the rtl CSE phase
of GCC.  Before this change CSE was generating this RTL:

r234 = address of PL_curpad
r211 = mem[r234]
.
.
r215 = $2 (return pointer from a function)
r237 = mem[r211]
mem[r237+4] = r215
r220 = mem[r237]

The important bit is the last statement where r220 is loaded using the
address in r237.

After the change we have:

r234 = address of PL_curpad
r211 = mem[r234]
.
.
r215 = $2 (return pointer from a function)
r237 = mem[r211]
mem[r237+4] = r215
r238 = mem[r211]
r220 = mem[238]

Instead of reusing r237, we load r238 and use that to load r220.  I believe
that PL_curpad (address in r234) is set up to have the value of its own
address minus 4.  That would mean that when we store to 'mem[r237+4]' we
changed what r238 has vs. what r237 has.  Now this actually seems like it
is more correct then the first version, but the first version worked (I could
compile and run perl) and the second version does not (perl allocate aborts
and goes into an infinite loop).

I can see this change in x86 RTL but the change in code on x86 does not seem
to cause an outward change in the behaviour of perl.  I don't know if GCC
is doing something wrong or if the code in perl is wrong.  I have attached
a cutdown test case from Perl_pp_entersub (pp_hot.c) with this bug report.
The code cannot be run but if compiled it shows the RTL differences I describe
above.
Comment 1 Steve Ellcey 2013-07-17 22:14:49 UTC
Created attachment 30518 [details]
What the CSE phase generated after checkin r200133
Comment 2 Steve Ellcey 2013-07-17 22:15:34 UTC
Created attachment 30519 [details]
Test case cut down from perl benchmark in SPEC 2006
Comment 3 Andrew Pinski 2013-07-17 22:22:13 UTC
This does look like an alias bug in the source code of perl?
Comment 4 Steve Ellcey 2013-07-17 22:48:39 UTC
Digging around on the SPEC web page led me to this:

http://www.spec.org/cpu2006/Docs/400.perlbench.html

Known portability issues

There are some known aliasing issues. The internal data structures that represent Perl's variables are accessed in such as a way as to violate ANSI aliasing rules. Compilation with optimizations that rely on strict compliance to ANSI C aliasing rules will most likely produce binaries that will not validate.
Comment 5 Steve Ellcey 2013-07-23 22:25:10 UTC
Given the SPEC comments about perl not obeying aliasing rules and the fact that I can compile this correctly with -fno-strict-aliasing I am going to close this out as 'invalid'  I.e. it is not a GCC bug.
Comment 6 Doug Gilmore 2013-07-27 20:56:13 UTC
I wonder if this should be marked as a duplicate of bug 33383?