> -----Original Message----- > From: Jeff Law [mailto:l...@redhat.com] > Sent: Thursday, April 30, 2015 9:14 PM > On 04/30/2015 09:34 AM, rohitarul...@freescale.com wrote: > > > > > >> -----Original Message----- > >> From: Jeff Law [mailto:l...@redhat.com] > >> Sent: Thursday, April 30, 2015 8:32 PM > >> To: Dharmakan Rohit-B30502; gcc-patches@gcc.gnu.org; > >> rguent...@suse.de; Jakub Jelinek > >> Cc: Alan Modra; David Edelsohn; Wienskoski Edmar-RA8797 > >> Subject: Re: [RFC: Patch, PR 60158] gcc/varasm.c : Pass actual > >> alignment value to output_constant_pool_2 > >> > >> On 04/29/2015 04:30 AM, rohitarul...@freescale.com wrote: > >>>> > >>> > >>> Jeff, I have made the changes as per your comments and attached the > >> patch. > >>> If the patch is OK, I will proceed with the regression tests. > >> This patch refers back to 60158 and based on what I see in 60158, it > >> appears I should be looking for a .data.rel.ro.local section which > >> contains the address of a string constant. But the constants are > >> being put into .rodata.str1.4. And if the issue is we're putting > >> bits into the wrong section and don't have an appropriate .fixup > >> section, then ISTM that the test should be compiled, then objdump used > to verify the sections and/or relocations. > >> > >> An additional concern is that I get the same code for the included > >> testcase with or without your changes. This is with a > >> powerpc-softfloat-linux-gnuspe configured compiler -- which matches > what I saw in pr 60158. > >> > >> So while the patch seems reasonable, I'm concerned that I've been > >> unable to show it changing anything. > >> > >> Thoughts? > >> > > > > Jeff, the issue is still reproducible with GCC v4.8 branch but not with GCC > v4.9 or trunk. > Was it fixed by some other approach or has the bug gone latent? > Obviously if the former, then the patch is only relevant to gcc-4.8 if the > latter, > then we'll still want to get it fixed on the trunk and possibly in the release > branches. > > Can you please investigate if the bug has been fixed by other means or if it's > just gone latent on the trunk?
Jeff, Just to summarize: By default in GCC v4.7.x, all the constants are put into '.rodata.str1.4' section. In GCC v4.8.x from r192719 onwards, one of the move instruction of the string constant ".LC0" is getting spilled. The reload pass, for any constants that aren't allowed and can't be reloaded in to registers tries to change them into memory references. Then while emitting that string constant to asm code (A:varasm.c: output_constant_pool_1), it explicitly passes the alignment as 1 which prevents the generation of fix-up table entries in 'B: rs6000.c:rs6000_assemble_integer' because the data is considered unaligned now. The bug seems to have gone latent with an unrelated trunk commit r204695 [* tree-ssa-loop-ivopts.c (force_expr_to_var_cost): Refactor the code. Handle type conversion.]. This commit chooses different spill candidates hence all the string constants are being put in to '.rodata.str1.4´section. The check I had in the test case is that if there is a '.data.rel.ro.local', then there should be '.fixup' section generated. Please let me know if you need any other details. Regards, Rohit
