Bug 20491 - internal compiler error: in subreg_regno_offset, at rtlanal.c:3042
Summary: internal compiler error: in subreg_regno_offset, at rtlanal.c:3042
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.0.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2005-03-16 02:17 UTC by Arno Schuring
Modified: 2010-03-23 14:42 UTC (History)
5 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: hppa64-*-hpux11.*
Build:
Known to work:
Known to fail: 4.0.0 4.1.0
Last reconfirmed: 2010-03-11 17:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arno Schuring 2005-03-16 02:17:21 UTC
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
Comment 1 Andrew Pinski 2005-03-16 02:27:50 UTC
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.
Comment 2 Alexandre Oliva 2005-03-24 09:25:23 UTC
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}
Comment 3 Alexandre Oliva 2005-03-24 10:46:12 UTC
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}
Comment 4 Richard Kenner 2005-03-24 12:33:18 UTC
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?
Comment 5 Andrew Pinski 2005-03-24 18:07:56 UTC
This started to ICEing after 2004-12-11.
Comment 6 Alexandre Oliva 2005-03-25 13:41:04 UTC
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.

Comment 7 Richard Henderson 2005-03-28 22:11:27 UTC
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~
Comment 8 CVS Commits 2005-03-29 21:36:28 UTC
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

Comment 9 CVS Commits 2005-03-29 21:36:31 UTC
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

Comment 10 Alexandre Oliva 2005-03-29 21:48:10 UTC
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}
Comment 11 Alexandre Oliva 2005-03-29 22:23:10 UTC
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.
Comment 12 Joseph S. Myers 2005-03-30 16:21:53 UTC
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.
Comment 13 Andrew Pinski 2005-03-30 18:51:43 UTC
I still can reproduce it also on x86.
Comment 14 Alexandre Oliva 2005-03-30 19:00:09 UTC
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.
Comment 15 Alexandre Oliva 2005-03-30 19:28:09 UTC
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}
Comment 16 Richard Henderson 2005-03-31 22:09:42 UTC
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~
Comment 17 CVS Commits 2005-04-02 16:56:31 UTC
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

Comment 18 CVS Commits 2005-04-02 16:56:57 UTC
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

Comment 19 Alexandre Oliva 2005-04-02 16:57:25 UTC
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}
Comment 20 Alexandre Oliva 2005-04-02 17:07:38 UTC
Fixed for real this time :-)
Comment 21 Joseph S. Myers 2005-04-03 15:21:38 UTC
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
Comment 22 Andrew Pinski 2005-04-03 17:04:34 UTC
(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.
Comment 23 John David Anglin 2005-04-03 18:19:25 UTC
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))
Comment 24 joseph@codesourcery.com 2005-04-04 18:20:13 UTC
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).

Comment 25 Joseph S. Myers 2005-04-05 11:50:37 UTC
As per comment#23, it *is* still the same problem.
Comment 26 Andrew Pinski 2005-04-05 14:59:19 UTC
(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.
Comment 27 CVS Commits 2005-04-16 10:37:47 UTC
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

Comment 28 CVS Commits 2005-04-16 10:43:31 UTC
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

Comment 29 Mark Mitchell 2005-04-17 04:01:20 UTC
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
Comment 30 Joseph S. Myers 2005-04-17 10:59:07 UTC
hppa64-hpux is indeed the only target I now see this failing on on gcc-testresults.
Comment 31 John David Anglin 2006-06-03 19:47:18 UTC
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.  
Comment 32 John David Anglin 2006-10-16 01:06:00 UTC
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

Comment 33 John David Anglin 2006-10-16 01:08:13 UTC
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

Comment 34 John David Anglin 2006-10-16 01:09:31 UTC
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

Comment 35 John David Anglin 2006-10-16 01:40:59 UTC
I think the PR can be closed.
Comment 36 Kaveh Ghazi 2010-03-11 17:00:00 UTC
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?
Comment 37 Jakub Jelinek 2010-03-18 20:35:44 UTC
The latter.