[PATCH][AARCH64]PR60034

Marcus Shawcroft marcus.shawcroft@gmail.com
Thu Feb 27 11:32:00 GMT 2014


On 21 February 2014 04:24, Kugan <kugan.vivekanandarajah@linaro.org> wrote:

> Compiling inline asm results in ICE (PR60034). Alignment calculation in
> aarch64_classify_address for (symbol_ref:DI ("*.LANCHOR4") [flags
> 0x182])) seems wrong here.

Hi Kugan,

+      else if (SYMBOL_REF_FLAGS (sym))
+ align = GET_MODE_ALIGNMENT (GET_MODE (sym));

This is inserted into the LO_SUM handling in the function
aarch64_classify_address(), the code in question is checking the
alignment of the object to ensure that a scaled address instruction
would be valid. The proposed code is testing if any of a bunch of
unrelated predicate flags have been set on the symbol and using that
to gate whether GET_MODE_ALIGNMENT would give accurate alignment
information on the symbol. I'm not convinced that the presence of
SYMBOL_REF_FLAGS states anything definitive about the relevance of
GET_MODE_ALIGNMENT.   The test looks like it fails because a section
anchor has been introduced and we fail to determine anything sensible
about the alignment of a section anchor.  How about this instead?

 if (SYMBOL_REF_BLOCK (sym))
   align = SYMBOL_REF_BLOCK (sym)->alignment;

>
> Fixing this also  caused a regression for pr38151.c, which is due to
> complex type being allocated with wrong alignment. Attached patch fixes
> these issues.

It ~might~ be beneficial to increase data_alignment here as suggest
for performance reasons, but the existing alignment should not cause
breakage... this issue suggest to me that the SYMBOL_REF_FLAGS
approach is at fault.

Cheers
/Marcus



More information about the Gcc-patches mailing list