On 20/02/14 20:18, Matthew Gretton-Dann wrote: > On 12 February 2014 02:29, Kugan <kugan.vivekanandara...@linaro.org> wrote: >> Hi, >> >> I finally got around to checking the attached patch for the >> https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1270789 >> >> I noticed attached patch causes regression for pr38151.c in gcc test-suite. >> >> A reduced test-case that triggers this is: >> static unsigned long global_max_fast; >> int __libc_mallopt (int param_number, int value) >> { >> __asm__ __volatile__ ("# %[_SDT_A2]" :: [_SDT_A2] "nor" >> ((global_max_fast))); >> global_max_fast = 1; >> } >> >> In this regard I have couple of questions: >> >> 1. Is the in-line asm valid? Look ok to me. >> 2. For the pr38151.c regression, asm diff is as shown below. >> >> < add x0, x0, :lo12:.LANCHOR0 >> < ldr x0, [x0] >> --- >>> ldr x0, [x0,#:lo12:.LANCHOR0] >> >> This causes: >> pr38151.c:(.text+0x10c): relocation truncated to fit: >> R_AARCH64_LDST64_ABS_LO12_NC against `.rodata' >> collect2: error: ld returned 1 exit status. >> >> If I however increase the alignment of .rodata where .LANCHOR0 is >> defined, this passes. Is alignment of BITS_PER_UNIT valid for >> SYMBOL_REF? If I change it as I am doing this attached patch, is there >> anything else I need to do. > > From the ARMARM: > http://infocenter.arm.com/help/topic/com.arm.doc.ddi0487a.b/index.html > > The range on an LDR is: > <simm> Is the signed immediate byte offset, in the range -256 to 255, > encoded in the "imm9" field. > <pimm> For the 32-bit variant: is the optional positive immediate > byte offset, a multiple of 4 in the range 0 to 16380, defaulting to 0 > and encoded in the "imm12" field as <pimm>/4. > <pimm> For the 64-bit variant: is the optional positive immediate > byte offset, a multiple of 8 in the range 0 to 32760, defaulting to 0 > and encoded in the "imm12" field as <pimm>/8. > > So in this case where we're taking the low 12-bits of ANCHOR0 we > should be ensuring it is aligned to 8-bytes (or less than 256 - but we > can't necessarily tell that at compile time). > > So I think your patch is correct - the symbol needs to be aligned to > the size of the thing the symbol points to.
Sorry for not being clear with my query. With my earlier patch, I was accessing the mentioned label assuming that it is aligned. But the label was emitted without required alignment. Therefore, I wanted to know what I should do to force alignment to the label so that it is consistent. I think it is a latent problem with alignment requirement for complex type and is exposed by my patch. That is, we are not handling alignments for COMPLEX_TYPE. Fixed that as well. Posted the patch as http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01282.html. Thanks, Kugan _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
