public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "sje at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/57921] New: Alias change causes perl from SPEC 2006 to abort on MIPS Date: Wed, 17 Jul 2013 22:15:00 -0000 [thread overview] Message-ID: <bug-57921-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57921 Bug ID: 57921 Summary: Alias change causes perl from SPEC 2006 to abort on MIPS Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sje at gcc dot gnu.org Created attachment 30517 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30517&action=edit 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.
next reply other threads:[~2013-07-17 22:15 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-17 22:15 sje at gcc dot gnu.org [this message] 2013-07-17 22:16 ` [Bug rtl-optimization/57921] " sje at gcc dot gnu.org 2013-07-17 22:17 ` sje at gcc dot gnu.org 2013-07-17 22:24 ` pinskia at gcc dot gnu.org 2013-07-17 22:50 ` sje at gcc dot gnu.org 2013-07-23 22:25 ` sje at gcc dot gnu.org 2013-07-27 20:56 ` dgilmore at mips dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-57921-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).