On 20/02/14 20:18, Matthew Gretton-Dann wrote:
On 12 February 2014 02:29, Kugan kugan.vivekanandarajah@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:
- Is the in-line asm valid? Look ok to me.
- 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