This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 02 Sep 2011 15:48:44 +0000
- Subject: [Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate
- Auto-submitted: auto-generated
- References: <bug-50191-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-09-02 15:48:44 UTC ---
Ok, I've now managed to reproduce the unspecs in a fresh cross build.
Perhaps adjust_mems could try harder and call targetm.delegitimize_address on
all the expressions if it is !amd->store, or perhaps just set some flag when it
sees an UNSPEC and requests that outer expressions from within the same call
are then targetm.delegitimize_address processed until a single adjust_mem_uses
finishes.
But that doesn't explain what the problem is, because the unspecs I've looked
at are successfully delegitimized into SYMBOL_REF etc. during
mem_loc_descriptor.
So, what exactly is the problematic assembly part in the .debug_info?
I admit I haven't went through all the unspecs, just some of them.