[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linaro-toolchain
Subject:    Re: "invalid expression as operand" in aarch64 inline asm
From:       Kugan <kugan.vivekanandarajah () linaro ! org>
Date:       2014-02-21 4:29:16
Message-ID: 5306D61C.5050302 () linaro ! org
[Download RAW message or body]



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:
>>
>> 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
[prev in list] [next in list] [prev in thread] [next in thread]