On 10 December 2013 21:51, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>> On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson <r...@redhat.com> wrote:
>>> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
>>>> Sorry, I don't understand.  I never said it was invalid.  I said
>>>> (subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) represents
>>>> a single register.  On a little-endian target, the offset cannot be
>>>> anything other than 0 in that case.
>>>>
>>>> So the CANNOT_CHANGE_MODE_CLASS code above seems to be checking for
>>>> something that is always invalid, regardless of the target.  That kind
>>>> of situation should be rejected by target-independent code instead.
>>>
>>> But, we want to disable the subreg before we know whether or not (reg:V4SF 
>>> X)
>>> will be allocated to a single hard register.  That is something that we 
>>> can't
>>> know in target-independent code before register allocation.
>>
>> I tried Kirill's patch.  But LRA isn't prepared to handle it:
>>
>> spawn -ignore SIGHUP /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
>> -B/export/build/gnu/gcc/build-x86_64-linux/gcc/
>> /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-1.c
>> -B/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libatomic/
>> -L/export/build/gnu/gcc/build-x86_64-linux/x86_64-unknown-linux-gnu/32/libatomic/.libs
>> -latomic -fno-diagnostics-show-caret -fdiagnostics-color=never -O1
>> -std=c11 -pedantic-errors -lm -m32 -o ./c11-atomic-exec-1.exe^M
>> /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-1.c:
>> In function 'test_simple_assign':^M
>> /export/gnu/import/git/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-1.c:81:1:
>> internal compiler error: Maximum number of LRA constraint passes is
>> achieved (30)^M
>> ^M
>> 0x88ed77 lra_constraints(bool)^M
>>         /export/gnu/import/git/gcc/gcc/lra-constraints.c:3871^M
>> 0x87fe8c lra(_IO_FILE*)^M
>>         /export/gnu/import/git/gcc/gcc/lra.c:2331^M
>> 0x840f76 do_reload^M
>>         /export/gnu/import/git/gcc/gcc/ira.c:5455^M
>> 0x840f76 rest_of_handle_reload^M
>>         /export/gnu/import/git/gcc/gcc/ira.c:5584^M
>> 0x840f76 execute^M
>>         /export/gnu/import/git/gcc/gcc/ira.c:5613^M
>>
>
> I got several hundred failures like this in GCC
> testsuite with -m32 and -m64 on Linux/x86-64.
>

I think this is the same as:

http://gcc.gnu.org/ml/gcc/2013-12/msg00086.html

LRA does not seem to know how to resolve subregs with non-zero offsets
that don't map to a full-hardreg.

Thanks,
Tejas.

Reply via email to