The following code causes an ICE in gcc4: === static void _evas_yv12torgb_sse (); const volatile unsigned short _const_32 [4] = {1,2,3,4}; void evas_common_convert_yuv_420p_601_rgba() { _evas_yv12torgb_sse(); } static void _evas_yv12torgb_sse() { int xx, yy; __asm__ __volatile__ ("movq" " %0, %%" "mm4" : : "X" (*_const_32)); } === (this code originally comes from e17 library evas) The 4.0 compiler I have used was from 20041205 (5 dec 2004), haven't tested a more recent version on the 4.0 branch. backup@golem:~$ uname -a Linux golem 2.6.11-wol #2 Tue Mar 8 21:47:08 CET 2005 i686 AuthenticAMD unknown GNU/Linux backup@golem:~$ gcc --verbose Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/sources/gcc-CVS/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++,java,objc Thread model: posix gcc version 4.1.0 20050315 (experimental) backup@golem:~$ gcc -O2 -c evas2.c -o evas.o evas2.c: In function 'evas_common_convert_yuv_420p_601_rgba': evas2.c:9: internal compiler error: in subreg_regno_offset, at rtlanal.c:3042 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. backup@golem:~$ gcc -c evas2.c -o evas.o /tmp/ccmmTLDP.s: Assembler messages: /tmp/ccmmTLDP.s:39: Error: suffix or operands invalid for `movq' I hope this is enough info to work on
Confirmed, reduced testcase: volatile unsigned short _const_32 [4] = {1,2,3,4}; void evas_common_convert_yuv_420p_601_rgba() { __asm__ __volatile__ ("" : : "X" (*_const_32)); } Note really X should not be used as you showed with -O0.
Subject: [PR middle-end/20491] combine generates bad subregs Combine doesn't ensure the subregs it generates are valid. In most cases, insn recog will reject the invalid subregs, or reload will somehow make them fit, but if the constraint of the insn or the asm operand is "X", this won't work, so I think we're better off ensuring we don't ever introduce subregs of non-REGs. Does this look like a reasonable change to make? If so, ok to install if bootstrap and regtest on amd64-linux-gnu and i686-pc-linux-gnu succeed? Index: gcc/ChangeLog from Alexandre Oliva <aoliva@redhat.com> PR middle-end/20491 * combine.c (subst): Make sure we don't create invalid subregs. Index: gcc/combine.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/combine.c,v retrieving revision 1.484 diff -u -p -r1.484 combine.c --- gcc/combine.c 22 Mar 2005 03:48:44 -0000 1.484 +++ gcc/combine.c 24 Mar 2005 09:10:00 -0000 @@ -3689,15 +3689,22 @@ subst (rtx x, rtx from, rtx to, int in_d if (GET_CODE (new) == CLOBBER && XEXP (new, 0) == const0_rtx) return new; - if (GET_CODE (x) == SUBREG - && (GET_CODE (new) == CONST_INT - || GET_CODE (new) == CONST_DOUBLE)) + /* If we changed the reg of a subreg, make sure it's + still valid. For anything but a REG, require the + SUBREG to be simplified out. */ + + if (GET_CODE (x) == SUBREG && new != SUBREG_REG (x)) { enum machine_mode mode = GET_MODE (x); + enum machine_mode submode = GET_MODE (SUBREG_REG (x)); + + if (GET_CODE (new) == REG) + x = simplify_gen_subreg (mode, new, submode, + SUBREG_BYTE (x)); + else + x = simplify_subreg (mode, new, submode, + SUBREG_BYTE (x)); - x = simplify_subreg (GET_MODE (x), new, - GET_MODE (SUBREG_REG (x)), - SUBREG_BYTE (x)); if (! x) x = gen_rtx_CLOBBER (mode, const0_rtx); } Index: gcc/testsuite/ChangeLog from Alexandre Oliva <aoliva@redhat.com> PR middle-end/20491 * gcc.dg/asm-subreg-1.c: New. Index: gcc/testsuite/gcc.dg/asm-subreg-1.c =================================================================== RCS file: gcc/testsuite/gcc.dg/asm-subreg-1.c diff -N gcc/testsuite/gcc.dg/asm-subreg-1.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gcc/testsuite/gcc.dg/asm-subreg-1.c 24 Mar 2005 09:10:14 -0000 @@ -0,0 +1,14 @@ +/* PR middle-end/20491 */ + +/* { dg-do compile } */ +/* { dg-options "-O2" } */ + +/* Combine used to introduce invalid subregs for the asm input. */ + +volatile unsigned short _const_32 [4] = {1,2,3,4}; +void +evas_common_convert_yuv_420p_601_rgba() +{ + __asm__ __volatile__ ("" : : "X" (*_const_32)); +} + -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
Subject: Re: [PR middle-end/20491] combine generates bad subregs On Mar 24, 2005, Alexandre Oliva <aoliva@redhat.com> wrote: > Combine doesn't ensure the subregs it generates are valid. In most > cases, insn recog will reject the invalid subregs, or reload will > somehow make them fit, but if the constraint of the insn or the asm > operand is "X", this won't work, so I think we're better off ensuring > we don't ever introduce subregs of non-REGs. > Does this look like a reasonable change to make? Ugh. It failed building libgcc for stage 1, after simplifying (subreg:QI (subreg:SI (reg:HI))) to (subreg:QI (reg:HI)), leaving op0_mode set to SImode, causing an error in combine_simplify_rtx(), when it called simplify_subreg with the wrong mode. Index: gcc/ChangeLog from Alexandre Oliva <aoliva@redhat.com> PR middle-end/20491 * combine.c (subst): Make sure we don't create invalid subregs. Index: gcc/combine.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/combine.c,v retrieving revision 1.484 diff -u -p -r1.484 combine.c --- gcc/combine.c 22 Mar 2005 03:48:44 -0000 1.484 +++ gcc/combine.c 24 Mar 2005 10:01:17 -0000 @@ -3689,15 +3689,24 @@ subst (rtx x, rtx from, rtx to, int in_d if (GET_CODE (new) == CLOBBER && XEXP (new, 0) == const0_rtx) return new; - if (GET_CODE (x) == SUBREG - && (GET_CODE (new) == CONST_INT - || GET_CODE (new) == CONST_DOUBLE)) + /* If we changed the reg of a subreg, make sure it's + still valid. For anything but a REG, require the + SUBREG to be simplified out. */ + + if (GET_CODE (x) == SUBREG && new != SUBREG_REG (x)) { enum machine_mode mode = GET_MODE (x); + enum machine_mode submode = op0_mode; + + if (GET_CODE (new) == REG) + x = simplify_gen_subreg (mode, new, submode, + SUBREG_BYTE (x)); + else + x = simplify_subreg (mode, new, submode, + SUBREG_BYTE (x)); + + op0_mode = VOIDmode; - x = simplify_subreg (GET_MODE (x), new, - GET_MODE (SUBREG_REG (x)), - SUBREG_BYTE (x)); if (! x) x = gen_rtx_CLOBBER (mode, const0_rtx); } Index: gcc/testsuite/ChangeLog from Alexandre Oliva <aoliva@redhat.com> PR middle-end/20491 * gcc.dg/asm-subreg-1.c: New. Index: gcc/testsuite/gcc.dg/asm-subreg-1.c =================================================================== RCS file: gcc/testsuite/gcc.dg/asm-subreg-1.c diff -N gcc/testsuite/gcc.dg/asm-subreg-1.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gcc/testsuite/gcc.dg/asm-subreg-1.c 24 Mar 2005 09:10:14 -0000 @@ -0,0 +1,14 @@ +/* PR middle-end/20491 */ + +/* { dg-do compile } */ +/* { dg-options "-O2" } */ + +/* Combine used to introduce invalid subregs for the asm input. */ + +volatile unsigned short _const_32 [4] = {1,2,3,4}; +void +evas_common_convert_yuv_420p_601_rgba() +{ + __asm__ __volatile__ ("" : : "X" (*_const_32)); +} + -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
Subject: Re: [PR middle-end/20491] combine generates bad subregs Combine doesn't ensure the subregs it generates are valid. In most cases, insn recog will reject the invalid subregs, or reload will some how make them fit, but if the constraint of the insn or the asm operand is "X", this won't work, so I think we're better off ensuring we don't ever introduce subregs of non-REGs. Aside from calling recog combine doesn't check that *anything* it generates is valid. Why should subregs be different?
This started to ICEing after 2004-12-11.
Subject: Re: [PR middle-end/20491] combine generates bad subregs On Mar 24, 2005, kenner@vlsi1.ultra.nyu.edu (Richard Kenner) wrote: > Combine doesn't ensure the subregs it generates are valid. In most > cases, insn recog will reject the invalid subregs, or reload will > some how make them fit, but if the constraint of the insn or the asm > operand is "X", this won't work, so I think we're better off ensuring > we don't ever introduce subregs of non-REGs. > Aside from calling recog combine doesn't check that *anything* it generates > is valid. Why should subregs be different? Because, as I said, generating an invalid subreg at that point, without any opportunity to fix it up later, will cause us to crash when the time comes to remove all subregs.
Subject: Re: [PR middle-end/20491] combine generates bad subregs On Thu, Mar 24, 2005 at 07:45:44AM -0300, Alexandre Oliva wrote: > * combine.c (subst): Make sure we don't create invalid subregs. Ok. r~
Subject: Bug 20491 CVSROOT: /cvs/gcc Module name: gcc Changes by: aoliva@gcc.gnu.org 2005-03-29 21:36:10 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/torture: asm-subreg-1.c Log message: PR middle-end/20491 * gcc.dg/torture/asm-subreg-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5233&r2=1.5234 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
Subject: Bug 20491 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: aoliva@gcc.gnu.org 2005-03-29 21:36:20 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/torture: asm-subreg-1.c Log message: PR middle-end/20491 * gcc.dg/torture/asm-subreg-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.74&r2=1.5084.2.75 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
Subject: Re: [PR middle-end/20491] combine generates bad subregs On Mar 28, 2005, Richard Henderson <rth@gcc.gnu.org> wrote: > On Thu, Mar 24, 2005 at 07:45:44AM -0300, Alexandre Oliva wrote: >> * combine.c (subst): Make sure we don't create invalid subregs. > Ok. As it turned out, the bug seems to have been fixed by some other patch, because I no longer get the error in mainline or in the 4.0 branch. Since my patch actually introduced a regression on i686-pc-linux-gnu: gcc.dg/i386-rotate-1.c. Because of the ruled-out combines, we prevented the complete transformation from taking place. I actually wrote another, more complex patch, that fixed it, by using the same machinery used by later portions of combine to push the invalid subreg into the shift operands, i.e., turn (subreg (ashift (reg) (const_int))) into (ashift (subreg (reg)) (const_int)), but then I decided I was working too hard and figured I might be better off fixing the problem elsewhere. To my surprise, after reverting the patch I had, the problem no longer occurred. I tried some CVS searching, but couldn't locate the patch that fixed the problem. In fact, I couldn't even find a relatively-recent tree that triggered the bug, although I'm pretty sure the tree in which I triggered the bug was no older than some date early last week. Oh well... I'm attaching the patch I had, in case you still think we should avoid creating such invalid subregs, followed by the testcase patch I installed in the 4.0 branch in mainline. Index: gcc/ChangeLog from Alexandre Oliva <aoliva@redhat.com> PR middle-end/20491 * combine.c (subst): Make sure we don't create invalid subregs. Index: gcc/combine.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/combine.c,v retrieving revision 1.484 diff -u -p -r1.484 combine.c --- gcc/combine.c 22 Mar 2005 03:48:44 -0000 1.484 +++ combine.c 25 Mar 2005 21:21:40 -0000 @@ -3689,15 +3689,36 @@ subst (rtx x, rtx from, rtx to, int in_d if (GET_CODE (new) == CLOBBER && XEXP (new, 0) == const0_rtx) return new; + /* If we changed the reg of a subreg, make sure it's + still valid. For anything but a REG, require the + SUBREG to be simplified out. */ + if (GET_CODE (x) == SUBREG - && (GET_CODE (new) == CONST_INT - || GET_CODE (new) == CONST_DOUBLE)) + && ! rtx_equal_p (new, SUBREG_REG (x))) { enum machine_mode mode = GET_MODE (x); + rtx orig = x; + + x = simplify_gen_subreg (mode, new, op0_mode, + SUBREG_BYTE (orig)); + + /* This will propagate the subreg into the operand, + if appropriate. */ + if (GET_CODE (x) == SUBREG + && GET_CODE (SUBREG_REG (x)) != REG) + x = force_to_mode (x, mode, GET_MODE_MASK (mode), + NULL_RTX, 0); + + /* Now make sure we didn't create a subreg of + something that is not a reg. */ + if (GET_CODE (x) == SUBREG + && GET_CODE (SUBREG_REG (x)) != REG) + x = simplify_subreg (mode, SUBREG_REG (x), + GET_MODE (SUBREG_REG (x)), + SUBREG_BYTE (x)); + + op0_mode = VOIDmode; - x = simplify_subreg (GET_MODE (x), new, - GET_MODE (SUBREG_REG (x)), - SUBREG_BYTE (x)); if (! x) x = gen_rtx_CLOBBER (mode, const0_rtx); } Index: gcc/testsuite/ChangeLog from Alexandre Oliva <aoliva@redhat.com> PR middle-end/20491 * gcc.dg/torture/asm-subreg-1.c: New test. Index: gcc/testsuite/gcc.dg/torture/asm-subreg-1.c =================================================================== RCS file: gcc/testsuite/gcc.dg/torture/asm-subreg-1.c diff -N gcc/testsuite/gcc.dg/torture/asm-subreg-1.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gcc/testsuite/gcc.dg/torture/asm-subreg-1.c 29 Mar 2005 21:31:55 -0000 @@ -0,0 +1,14 @@ +/* PR middle-end/20491 */ + +/* { dg-do compile } */ + +/* Combine used to introduce invalid subregs for the asm input, and + we'd crash later on, when removing all subregs. */ + +volatile unsigned short _const_32 [4] = {1,2,3,4}; +void +evas_common_convert_yuv_420p_601_rgba() +{ + __asm__ __volatile__ ("" : : "X" (*_const_32)); +} + -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
Seems to have been fixed by some recent patch that went into both mainline and 4.0 branch, but I couldn't pinpoint exactly what patch it was. This recent change affected the initial rtl dump, such that it no longer contained the extension and truncation, particularly the truncation subreg that triggered the bug in combine. Since we now have a testcase in place, I'm closing this bug.
Are you sure the bug is fixed? The testcase is failing for me with today's mainline compiler on i686-pc-linux-gnu, ia64-hp-hpux11.23 and hppa64-hp-hpux11.{11,23}. Failure on i686-pc-linux-gnu is that quoted in the bug report (at -O2; not at -O0 or -O1). Same failure on ia64-hpux. On hppa64-hpux get instead, at -O1 and above, /home/gcc/nightlies/gcc-mainline-2005-03-30/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c: In function 'evas_common_convert_yuv_420p_601_rgba': /home/gcc/nightlies/gcc-mainline-2005-03-30/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c:12: error: 'asm' operand requires impossible reload gcc-testresults shows failures on other platforms, including on 4.0 branch.
I still can reproduce it also on x86.
I'm now sure it wasn't fixed. Somehow I forgot the problem didn't occur on x86_64-linux-gnu, not even with -m32, even though it did on i686-pc-linux-gnu. I I had only one i686-only bug, and I knew it was a different one. Sorry about that, I'll try to come up with a reasonable fix.
Subject: Re: [PR middle-end/20491] combine generates bad subregs On Mar 29, 2005, Alexandre Oliva <aoliva@redhat.com> wrote: > On Mar 28, 2005, Richard Henderson <rth@gcc.gnu.org> wrote: >> On Thu, Mar 24, 2005 at 07:45:44AM -0300, Alexandre Oliva wrote: >>> * combine.c (subst): Make sure we don't create invalid subregs. >> Ok. > As it turned out, the bug seems to have been fixed by some other > patch, because I no longer get the error in mainline or in the 4.0 > branch. Or perhaps it never actually failed on x86_64-linux-gnu, which is where I was trying to trigger it again. Not even with -m32. A build on i686-pc-linux-gnu was enough to trigger it. Yay me! :-) So, the patch posted in my previous e-mail still stands, but if you, like me, find that it's working too hard to avoid such subregs, here's an alternative patch that also fixes the problem, at least as long as the X-constrained asm operand is not actually used in the asm output pattern. Index: gcc/ChangeLog from Alexandre Oliva <aoliva@redhat.com> PR middle-end/20491 * final.c (alter_subreg): Don't call subreg_regno for a non-REG. Index: gcc/final.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/final.c,v retrieving revision 1.344.12.1 diff -u -p -r1.344.12.1 final.c --- gcc/final.c 22 Mar 2005 13:39:12 -0000 1.344.12.1 +++ gcc/final.c 30 Mar 2005 19:21:02 -0000 @@ -1,6 +1,7 @@ /* Convert RTL to assembler code and output it, for GNU compiler. Copyright (C) 1987, 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, - 1998, 1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc. + 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 + Free Software Foundation, Inc. This file is part of GCC. @@ -2638,7 +2639,7 @@ alter_subreg (rtx *xp) if (new != 0) *xp = new; - else + else if (REG_P (y)) { /* Simplify_subreg can't handle some REG cases, but we have to. */ unsigned int regno = subreg_regno (x); -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
Subject: Re: [PR middle-end/20491] combine generates bad subregs On Wed, Mar 30, 2005 at 04:27:50PM -0300, Alexandre Oliva wrote: > - else > + else if (REG_P (y)) > { > /* Simplify_subreg can't handle some REG cases, but we have to. */ > unsigned int regno = subreg_regno (x); The next line is gcc_assert (REG_P (y)); you should remove that. Ok with that change. r~
Subject: Bug 20491 CVSROOT: /cvs/gcc Module name: gcc Changes by: aoliva@gcc.gnu.org 2005-04-02 16:56:27 Modified files: gcc : ChangeLog final.c Log message: PR middle-end/20491 * final.c (alter_subreg): Don't call subreg_regno for a non-REG. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8087&r2=2.8088 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/final.c.diff?cvsroot=gcc&r1=1.349&r2=1.350
Subject: Bug 20491 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: aoliva@gcc.gnu.org 2005-04-02 16:56:45 Modified files: gcc : ChangeLog final.c Log message: PR middle-end/20491 * final.c (alter_subreg): Don't call subreg_regno for a non-REG. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.114&r2=2.7592.2.115 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/final.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.344.12.1&r2=1.344.12.2
Subject: Re: [PR middle-end/20491] combine generates bad subregs On Mar 31, 2005, Richard Henderson <rth@gcc.gnu.org> wrote: > On Wed, Mar 30, 2005 at 04:27:50PM -0300, Alexandre Oliva wrote: >> - else >> + else if (REG_P (y)) >> { >> /* Simplify_subreg can't handle some REG cases, but we have to. */ >> unsigned int regno = subreg_regno (x); > The next line is > gcc_assert (REG_P (y)); > you should remove that. Ok with that change. Thanks, here's what I'm checking in. Index: gcc/ChangeLog from Alexandre Oliva <aoliva@redhat.com> PR middle-end/20491 * final.c (alter_subreg): Don't call subreg_regno for a non-REG. Index: gcc/final.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/final.c,v retrieving revision 1.349 diff -u -p -r1.349 final.c --- gcc/final.c 1 Apr 2005 15:27:58 -0000 1.349 +++ gcc/final.c 1 Apr 2005 20:19:02 -0000 @@ -2547,11 +2547,10 @@ alter_subreg (rtx *xp) if (new != 0) *xp = new; - else + else if (REG_P (y)) { /* Simplify_subreg can't handle some REG cases, but we have to. */ unsigned int regno = subreg_regno (x); - gcc_assert (REG_P (y)); *xp = gen_rtx_REG_offset (y, GET_MODE (x), regno, SUBREG_BYTE (x)); } } -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
Fixed for real this time :-)
The test still fails on some platforms, at least on mainline: On ia64-hp-hpux11.23: Executing on host: /scratch/gcc/nightly-2005-04-03-mainline/ia64-hp-hpux11.23/build_gcc/build/gcc/xgcc -B/scratch/gcc/nightly-2005-04-03-mainline/ia64-hp-hpux11.23/build_gcc/build/gcc/ /home/gcc/nightlies/gcc-mainline-2005-04-03/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c -O2 -S -milp32 -o asm-subreg-1.s (timeout = 300) /home/gcc/nightlies/gcc-mainline-2005-04-03/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c: In function 'evas_common_convert_yuv_420p_601_rgba': /home/gcc/nightlies/gcc-mainline-2005-04-03/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c:13: internal compiler error: in rws_access_regno, at config/ia64/ia64.c:4815 On hppa64-hp-hpux11.23: Executing on host: /scratch/gcc/nightly-2005-04-03-mainline/hppa64-hp-hpux11.23/build_gcc/build/gcc/xgcc -B/scratch/gcc/nightly-2005-04-03-mainline/hppa64-hp-hpux11.23/build_gcc/build/gcc/ /home/gcc/nightlies/gcc-mainline-2005-04-03/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c -O1 -S -o asm-subreg-1.s (timeout = 300) /home/gcc/nightlies/gcc-mainline-2005-04-03/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c: In function 'evas_common_convert_yuv_420p_601_rgba': /home/gcc/nightlies/gcc-mainline-2005-04-03/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c:12: error: 'asm' operand requires impossible reload
(In reply to comment #21) > The test still fails on some platforms, at least on mainline: > > On ia64-hp-hpux11.23: This is a target problem and most likely deserves a new PR instead as it might not be a regression. > On hppa64-hp-hpux11.23: This one is weird as X means any constraint and it might also be another target related problem. I would file this one seperate too instead of reopening this bug as they both look not related to or even a regression.
On hppa64-hp-hpux*, I think we still have the same bug. Combine is still generating an insn that reload can't handle: (insn 16 15 17 0 (asm_operands/v ("") ("") 0 [ (mem/s/v/j:HI (mem/u/c:DI (lo_sum:DI (plus:DI (reg:DI 27 %r27) (high:DI (symbol_ref:DI ("_const_32") <var_decl 8000 03fffef92340 _const_32>))) (unspec:DI [ (symbol_ref:DI ("_const_32") <var_decl 800003fff ef92340 _const_32>) ] 2)) [0 S8 A64]) [0 _const_32+0 S2 A32]) ] [ (asm_input:HI ("X")) ] ("/test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c") 12) -1 (nil) (nil))
Subject: Re: [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042 On Sun, 3 Apr 2005, danglin at gcc dot gnu dot org wrote: > On hppa64-hp-hpux*, I think we still have the same bug. Combine is > still generating an insn that reload can't handle: FWIW the current instance of the bug is a regression on ia64 but not on hppa64 (based on testing with 3.4 branch compilers). Given that at least the hppa64 case is the same bug I think it should be reopened (but the target milestone would need adjusting).
As per comment#23, it *is* still the same problem.
(In reply to comment #25) > As per comment#23, it *is* still the same problem. But it is not as the x86 one was about combine generating bad subregs but combine in this case is not generating bad subregs but (mem (mem symbol_ref )), There are a couple of different bugs about that.
Subject: Bug 20491 CVSROOT: /cvs/gcc Module name: gcc Changes by: jsm28@gcc.gnu.org 2005-04-16 10:37:31 Modified files: gcc : ChangeLog gcc/config/ia64: ia64.c Log message: PR middle-end/20491 * config/ia64/ia64.c (rtx_needs_barrier): Recurse instead of falling through from SUBREG case to REG. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8319&r2=2.8320 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&r1=1.354&r2=1.355
Subject: Bug 20491 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-4_0-branch Changes by: jsm28@gcc.gnu.org 2005-04-16 10:43:07 Modified files: gcc : ChangeLog gcc/config/ia64: ia64.c Log message: PR middle-end/20491 * config/ia64/ia64.c (rtx_needs_barrier): Recurse instead of falling through from SUBREG case to REG. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.161&r2=2.7592.2.162 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.347.2.2&r2=1.347.2.3
Joseph, if I understand correctly, this is now an hppa64-hp-hpux* problem only, and is not a regression. If that's correct, would you please (a) fill in the target field, (b) update the summary line to remove the rgression marker, and (c) remove the target milestone? Thanks, -- Mark
hppa64-hpux is indeed the only target I now see this failing on on gcc-testresults.
The test will fail on any hppa target with the addition of "-fPIC". I tend to think the use of the 'X' constraint is bogus, and that the test should be xfailed on hppa64. While it might be possible to add support to handle this particular reload, it's not something that's needed for the patterns in pa.md. As Kenner noted, combine doesn't check that anything it generates is valid.
Subject: Bug 20491 Author: danglin Date: Mon Oct 16 01:05:51 2006 New Revision: 117766 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117766 Log: PR middle-end/20491 gcc.dg/torture/asm-subreg-1.c: Skip on hppa*64*-*-*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c
Subject: Bug 20491 Author: danglin Date: Mon Oct 16 01:08:04 2006 New Revision: 117767 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117767 Log: PR middle-end/20491 gcc.dg/torture/asm-subreg-1.c: Skip on hppa*64*-*-*. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c
Subject: Bug 20491 Author: danglin Date: Mon Oct 16 01:09:23 2006 New Revision: 117768 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117768 Log: PR middle-end/20491 gcc.dg/torture/asm-subreg-1.c: Skip on hppa*64*-*-*. Modified: branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/torture/asm-subreg-1.c
I think the PR can be closed.
I'm seeing failures for gcc.dg/torture/asm-subreg-1.c on armv5tel-unknown-linux-gnueabi on mainline and 4.4/4.3 branches when using -fpic or -fPIC and optimizing. See: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00638.html The error message is: > asm-subreg-1.c: In function 'evas_common_convert_yuv_420p_601_rgba': > asm-subreg-1.c:13:3: error: 'asm' operand requires impossible reload > compiler exited with status 1 Is this a bug or skip it like hppa?
The latter.