c/7872: ICE on legal code, regression from 3.0 and 2.9*

c/7872: ICE on legal code, regression from 3.0 and 2.9*

[Richard Zidlicky]

>Number:         7872
>Category:       c
>Synopsis:       ICE on legal code, regression from 3.0 and 2.9*
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          ice-on-legal-code
>Submitter-Id:   net
>Arrival-Date:   Mon Sep 09 14:36:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Richard Zidlicky
>Release:        3.2
>Organization:
>Environment:
native and crosscompiled
target: m68k-unknown-linux-gnu
configured with: ../gcc-3.2/configure --enable-languages=c --disable-checking --with-newlib --without-headers --target=m68k-linux
>Description:

/data/rz/build-m68k-3.2-release/gcc/cc1 -O0  -m68020-60 x3.i
 QMExecuteLoop
x3.i: In function `QMExecuteLoop':
x3.i:15: internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
rz@rz:/home/rz/test > /data/rz/build-m68k-3.2-release/gcc/cc1 -O1  -m68020-60 x3.i
 QMExecuteLoop

	
>How-To-Repeat:


extern void (**table)(void);

typedef unsigned short uw16;
typedef unsigned int gshort;
void ExceptionProcessing(void);
short extraFlag;

register uw16 *pc asm("%a4");
register gshort code asm("%d6");
register int nInst asm("%d7");

void QMExecuteLoop(uw16 *oldPC)
{
            table[code=(*(uw16*)(pc++))]();
}



>Fix:

The cause of the problem is that gen_lowpart() returns a (REG ...)
instead of a (SUBREG ...) in some obscure cases.

This patch fixes the problem:


--- gcc-3.2-cvs/gcc/simplify-rtx.c.rz	Wed Mar  6 17:43:21 2002
+++ gcc-3.2-cvs/gcc/simplify-rtx.c	Sat Aug 24 23:06:34 2002
@@ -2618,6 +2618,7 @@
      suppress this simplification.  If the hard register is the stack,
      frame, or argument pointer, leave this as a SUBREG.  */
 
+#if 0
   if (REG_P (op)
       && (! REG_FUNCTION_VALUE_P (op)
 	  || ! rtx_equal_function_value_matters)
@@ -2662,6 +2663,7 @@
 	  return x;
 	}
     }
+#endif
 
   /* If we have a SUBREG of a register that we are replacing and we are
      replacing it with a MEM, make a new MEM and try replacing the

>Release-Note:
>Audit-Trail:
>Unformatted:
 
 

Re: c/7872: ICE on legal code, regression from 3.0 and 2.9*

[Wolfgang Bangerth]

The following reply was made to PR c/7872; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Richard Zidlicky <rz@linux-m68k.org>
Cc: bangerth@dealii.org, <gcc-bugs@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org>
Subject: Re: c/7872: ICE on legal code, regression from 3.0 and 2.9*
Date: Mon, 16 Dec 2002 14:41:09 -0600 (CST)

 On Sat, 14 Dec 2002, Richard Zidlicky wrote:
 
 > On Wed, Nov 27, 2002 at 03:45:46PM -0000, bangerth@dealii.org wrote:
 > > Synopsis: ICE on legal code, regression from 3.0 and 2.9*
 > > 
 > > State-Changed-From-To: open->feedback
 > > State-Changed-By: bangerth
 > > State-Changed-When: Wed Nov 27 07:45:44 2002
 > > State-Changed-Why:
 > >         Richard, same here: I don't have an m68k so cannot check your problem.
 > you can, the bugreport should have enough information to configure the 
 > cross-compiler and all the necessary input to test the problem on any
 > architecture.
 
 I've never done it, and would not know whether the results I get are right 
 or wrong. So I prefer to leave things like that to people who are more 
 familiar with that than me, and rather concentrate on further searching 
 the database for reports.
 
 
 > >         What happened to the patch you appended? I does not seem
 > >         to have been applied...
 > 
 > Unfortunately untill now I have seen absolutely no response to this 
 > bugreport, thanks for looking at it.
 > 
 > Quite possible my solution is not the correct or best one, I noticed
 > the problem would also go away if m68k had CLASS_CANNOT_CHANGE_MODE 
 > defined. However the gcc docs describe this as something that should 
 > affect floating point only so I am not sure about this.
 
 Try to find the maintainers of the code and ask them for their opinion, 
 possibly in private mail. Maybe that helps, I see too many bugs slipping 
 through the cracks. Otherwise you may also send the patch to the list, and 
 put a "Unreviewed patch" in the subject to indicate that this is a 
 long-pending matter.
 
 Regards
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 

Re: c/7872: ICE on legal code, regression from 3.0 and 2.9*

[Richard Zidlicky]

The following reply was made to PR c/7872; it has been noted by GNATS.

From: Richard Zidlicky <rz@linux-m68k.org>
To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
        nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c/7872: ICE on legal code, regression from 3.0 and 2.9*
Date: Sat, 14 Dec 2002 20:38:21 +0100

 On Wed, Nov 27, 2002 at 03:45:46PM -0000, bangerth@dealii.org wrote:
 > Synopsis: ICE on legal code, regression from 3.0 and 2.9*
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: bangerth
 > State-Changed-When: Wed Nov 27 07:45:44 2002
 > State-Changed-Why:
 >         Richard, same here: I don't have an m68k so cannot check your problem.
 you can, the bugreport should have enough information to configure the 
 cross-compiler and all the necessary input to test the problem on any
 architecture.
 
 >         What happened to the patch you appended? I does not seem
 >         to have been applied...
 
 Unfortunately untill now I have seen absolutely no response to this 
 bugreport, thanks for looking at it.
 
 Quite possible my solution is not the correct or best one, I noticed
 the problem would also go away if m68k had CLASS_CANNOT_CHANGE_MODE 
 defined. However the gcc docs describe this as something that should 
 affect floating point only so I am not sure about this.
 
 Richard