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.