From: Bernd Schmidt <bernds@redhat.com>
To: <philb@gnu.org>
Cc: <gcc-gnats@gcc.gnu.org>, <gcc-patches@gcc.gnu.org>,
	<gcc-bugs@gcc.gnu.org>
Subject: Re: target/2309: arm-linux: unrecognizable insn
Date: Tue, 3 Apr 2001 11:39:44 +0100 (BST)

 On 17 Mar 2001 philb@gnu.org wrote:
 
 > The attached testcase (actually part of GNU binutils) produces this error:
 >
 > gcc -DHAVE_CONFIG_H -I. -I../../bfd -I. -D_GNU_SOURCE -I. -I../../bfd -I../../bfd/../include -I../../bfd/../intl -I../intl -W -Wall -O2 -c pepigen.c -o pepigen.o
 > pepigen.c: In function `pe_print_pdata':
 > pepigen.c:1687: internal error--unrecognizable insn:
 > (insn 564 558 566 (set (reg:SI 176)
 >         (mem/s:SI (plus:SI (reg/v:SI 36)
 >                 (subreg:SI (reg:DI 132) 0)) 0)) -1 (nil)
 >     (nil))
 
 An analysis of this problem can be found at
 
   http://gcc.gnu.org/ml/gcc-patches/1999-06/msg00419.html
 
 I originally planned to fix it by modifying GO_IF_LEGITIMATE_ADDRESS et al.
 in arm.h, but then I decided to avoid the problem in the loop optimizer.
 If it affects mips and arm, it'll probably affect more targets as well.
 
 I'll install the following patch on the 2.95 branch.  We may want to consider
 it for the mainline and for 3.0 as well if there are targets in the current
 sources that don't allow SUBREGs in memory references.
 
 
 Bernd
 
 Index: ChangeLog
 ===================================================================
 RCS file: /cvs/gcc/egcs/gcc/ChangeLog,v
 retrieving revision 1.3667.4.348
 diff -u -p -r1.3667.4.348 ChangeLog
 --- ChangeLog	2001/04/03 10:34:15	1.3667.4.348
 +++ ChangeLog	2001/04/03 10:37:01
 @@ -5,6 +5,10 @@
  	Remove ia32 linux PIC kludge and move it...
  	* config/i386/linux.h (CRT_END_INIT_DUMMY): ...here.
 
 +	* loop.c (combine_movables): Restrict combinations of constants with
 +	different modes so that we don't introduce SUBREGs into memory
 +	addresses.
 +
  2001-03-30  Bernd Schmidt  <bernds@redhat.com>
 
  	* jump.c (delete_barrier_successors): Fix error in last change.
 Index: loop.c
 ===================================================================
 RCS file: /cvs/gcc/egcs/gcc/loop.c,v
 retrieving revision 1.156.4.20
 diff -u -p -r1.156.4.20 loop.c
 --- loop.c	2001/01/25 14:03:18	1.156.4.20
 +++ loop.c	2001/04/03 10:37:04
 @@ -1481,10 +1481,16 @@ combine_movables (movables, nregs)
  		      width as M1.  The check for integer is redundant, but
  		      safe, since the only case of differing destination
  		      modes with equal sources is when both sources are
 -		      VOIDmode, i.e., CONST_INT.  */
 +		      VOIDmode, i.e., CONST_INT.
 +
 +		      For 2.95, don't do this if the mode of M1 is Pmode.
 +		      This prevents us from substituting SUBREGs for REGs
 +		      in memory accesses; not all targets are prepared to
 +		      handle this properly.  */
  		   (GET_MODE (m->set_dest) == GET_MODE (m1->set_dest)
  		    || (GET_MODE_CLASS (GET_MODE (m->set_dest)) == MODE_INT
  			&& GET_MODE_CLASS (GET_MODE (m1->set_dest)) == MODE_INT
 +			&& GET_MODE (m1->set_dest) != Pmode
  			&& (GET_MODE_BITSIZE (GET_MODE (m->set_dest))
  			    >= GET_MODE_BITSIZE (GET_MODE (m1->set_dest)))))
  		   /* See if the source of M1 says it matches M.  */
 

Responsible-Changed-From-To: unassigned->pb
Responsible-Changed-Why: .

From: Philip Blundell <philb@gnu.org>
To: bernds@redhat.com, richard.earnshaw@arm.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: target/2309: [ARM] SUBREG in memory reference
Date: 22 Jan 2002 20:48:23 +0000

 Does anybody know what the status of this is now?
 
 I don't seem to have a copy of the original testcase any more, and the
 one in GNATS appears to be corrupt, so I can't easily test whether the
 bug still happens.  (Even if I did have that testcase, I guess there's a
 good chance that it would no longer generate the problematic RTL in any
 case
 
 From a quick look at GO_IF_LEGITIMATE_ADDRESS in arm.h from the 3.0
 branch, it seems to me that it's still not prepared to handle SUBREGs in
 memory expressions.
 
 

From: Richard Earnshaw <rearnsha@arm.com>
To: Philip Blundell <philb@gnu.org>
Cc: bernds@redhat.com, richard.earnshaw@arm.com, gcc-gnats@gcc.gnu.org
Subject: Re: target/2309: [ARM] SUBREG in memory reference 
Date: Wed, 23 Jan 2002 10:23:17 +0000

 > Does anybody know what the status of this is now?
 > 
 > I don't seem to have a copy of the original testcase any more, and the
 > one in GNATS appears to be corrupt, so I can't easily test whether the
 > bug still happens.  (Even if I did have that testcase, I guess there's a
 > good chance that it would no longer generate the problematic RTL in any
 > case
 > 
 > From a quick look at GO_IF_LEGITIMATE_ADDRESS in arm.h from the 3.0
 > branch, it seems to me that it's still not prepared to handle SUBREGs in
 > memory expressions.
 > 
 > 
 
 I have the original post as sent out by gnats, but I can't even extract 
 the testcase from that.  So I think it must either have been corrupted 
 right up front, or have been a bad attachment in the first place.
 
 However, sleuthing shows that the problem may have been fixed:
 
 http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00131.html
 http://gcc.gnu.org/ml/gcc-patches/1999-06/msg00419.html
 
 R.
 

From: Phil Blundell <pb@nexus.co.uk>
To: Richard Earnshaw <rearnsha@arm.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: target/2309: [ARM] SUBREG in memory reference
Date: 23 Jan 2002 10:36:30 +0000

 On Wed, 2002-01-23 at 10:26, Richard Earnshaw wrote:
 >  I have the original post as sent out by gnats, but I can't even extract 
 >  the testcase from that.  So I think it must either have been corrupted 
 >  right up front, or have been a bad attachment in the first place.
 >  
 >  However, sleuthing shows that the problem may have been fixed:
 >  
 >  http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00131.html
 
 That patch doesn't seem to have been applied to the 3.0 branch or the
 trunk.  They both just say:
 
 			 Note this assumes that the target dependent
 			 files treat REG and SUBREG equally, including
  			 within GO_IF_LEGITIMATE_ADDRESS and in all the
 			 predicates since we never verify that replacing
  			 the original register with a SUBREG results 
 			 in a recognizable insn.  */
 
 >  http://gcc.gnu.org/ml/gcc-patches/1999-06/msg00419.html
 
 Do you think GO_IF_LEGITIMATE_ADDRESS in arm.h wants the same treatment
 that mips.h got here, ie this kind of thing:
 
 	   while (GET_CODE (xinsn) == SUBREG)
 	     xinsn = SUBREG_REG (xinsn);
 
 p.
 

From: Dara Hazeghi <dhazeghi@yahoo.com>
To: philb@gnu.org, pb@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: target/2309: [ARM] SUBREG in memory reference
Date: Sat, 17 May 2003 02:48:17 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=2309
 
 Hello,
 
 what's the status of this PR? It looks like there was indeed a patch  
 for the problem? Was the patch every applied? Is the bug fixed? Thanks,
 
 Dara
 

State-Changed-From-To: open->closed
State-Changed-Why: Appears to be fixed.

From: Philip Blundell <philb@gnu.org>
To: Dara Hazeghi <dhazeghi@yahoo.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: target/2309: [ARM] SUBREG in memory reference
Date: 17 May 2003 11:43:48 +0100

 On Sat, 2003-05-17 at 10:48, Dara Hazeghi wrote:
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-
 > trail&database=gcc&pr=2309
 > 
 > Hello,
 > 
 > what's the status of this PR? It looks like there was indeed a patch  
 > for the problem? Was the patch every applied? Is the bug fixed? Thanks,
 
 I think it's probably fixed.  We no longer seem to have a copy of the
 original testcase, but I haven't seen any further reports of this bug in
 the past couple of years.
 
 I've closed the PR.
 
 p.