[RFC: Patch, PR 60158] gcc/varasm.c : Pass actual alignment value to output_constant_pool_2

[Jeff Law]

On 05/05/2015 01:59 AM, rohitarulraj@freescale.com wrote:
>>> 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.
Thanks.  Even though I wasn't able to trigger the bug with the testcase 
from 65018, I went ahead and committed this patch to the trunk.  It 
can't hurt and it's the right thing to do.

Thanks for your patience,

Jeff