On Tue, Dec 10, 2013 at 2:25 PM, Tejas Belagod <belagod.te...@gmail.com> wrote: > 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. >
Looks like it. I am rebuilding and retesting Kirill's patch + Vladimir's patch. -- H.J.
