On 21 February 2014 04:24, Kugan <kugan.vivekanandara...@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
