Bug 8343 - [m68k] [3.2 regression] m68k-elf/rtems ICE at instantiate_virtual_regs_1
Summary: [m68k] [3.2 regression] m68k-elf/rtems ICE at instantiate_virtual_regs_1
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.2
: P3 normal
Target Milestone: ---
Assignee: Jan Hubicka
URL:
Keywords: ice-on-valid-code
: 8301 9248 9389 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-10-24 14:56 UTC by Joel Sherrill
Modified: 2003-07-25 17:33 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
m68k-ice.c.bz2 (22.86 KB, application/octet-stream)
2003-05-21 15:17 UTC, Joel Sherrill
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joel Sherrill 2002-10-24 14:56:01 UTC
THis appears to be related to the optimization level but
not the CPU model as it happens for nearly all RTEMS 
BSPs when compiled without an optimization level specified.

Also Peter Barada has narrowed it down to being a regression
since 3.0.

m68k-ice.c: In function `rtems_capture_task_time':
m68k-ice.c:7223: Internal compiler error in instantiate_virtual_regs_1, at function.c:3972
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

Release:
3.2 branch, 3.1 branch but not 3.0 branch

Environment:
m68k-elf/rtems
Comment 1 Joel Sherrill 2002-10-24 14:56:01 UTC
Fix:
Unknown
Comment 2 Joel Sherrill 2002-10-25 05:59:45 UTC
State-Changed-From-To: open->feedback
State-Changed-Why: Peter Barada has this important piece of information which
    should be a big clue to fixing it:
    
    Ok, I've narrowed your ICE down to between two version, one 525 days
    ago(where it worked) and 523 days ago (where it failed).
    
    The verion from each is:
    
    Fail: version 3.1 20010519
    Work: version 3.1 20010517
Comment 3 Joel Sherrill 2002-10-25 14:05:18 UTC
Responsible-Changed-From-To: unassigned->hubicka
Responsible-Changed-Why: Tracked to patch you committed. :)
    ===================================
    FInal feedback from Peter.
    
    'cvs update -D "2001/05/19 04:24:49" gcc' works
    'cvs update -D "2001/05/19 04:29:50" gcc' fails
    
    The only thing of interest changing is gcc/gcc/recog.c, from version
    1.102 to version 1.103.
    
    The log for gcc/gcc/recog.c looks like:
    
    revision 1.103
    date: 2001/05/19 08:24:50;  author: hubicka;  state: Exp;  lines: +85 -150
            * recog.c (general_operand): Prohibit nonzero subreg bytes on
            subregs containing mem.
    
    
    This was with the following testcase:
    
    extern unsigned foo;
    unsigned long long
    bar (void)
    {
       unsigned long long t = foo;
       return t * foo;
    }
    
    
    ===================================
Comment 4 pbarada 2002-10-25 15:27:34 UTC
From: Peter Barada <pbarada@mail.wm.sps.mot.com>
To: graham.stott@btinternet.com
Cc: joel@gcc.gnu.org, ccj@acm.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
        joel@OARcorp.com, nobody@gcc.gnu.org, Peter.Barada@motorola.com,
        gcc-gnats@gcc.gnu.org
Subject: Re: target/8343: m68k-elf/rtems ICE at instantiate_virtual_regs_1
Date: Fri, 25 Oct 2002 15:27:34 -0400

 > Synopsis: m68k-elf/rtems ICE at instantiate_virtual_regs_1
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: joel
 > State-Changed-When: Fri Oct 25 05:59:45 2002
 > State-Changed-Why:
 >     Peter Barada has this important piece of information which
 >     should be a big clue to fixing it:
 >     
 >     Ok, I've narrowed your ICE down to between two version, one 525 days
 >     ago(where it worked) and 523 days ago (where it failed).
 >     
 >     The verion from each is:
 >     
 >     Fail: version 3.1 20010519
 >     Work: version 3.1 20010517
 
 I've narrowed it even further :-)
 
 'cvs update -D "2001/05/19 04:24:49" gcc' works
 'cvs update -D "2001/05/19 04:29:50" gcc' fails
 
 The only thing of interest changing is gcc/gcc/recog.c, from version
 1.102 to version 1.103.
 
 The log for gcc/gcc/recog.c looks like:
 
 revision 1.103
 date: 2001/05/19 08:24:50;  author: hubicka;  state: Exp;  lines: +85 -150
 	* recog.c (general_operand): Prohibit nonzero subreg bytes on
 	subregs containing mem.
 
 
 This was with the following testcase:
 
 extern unsigned foo;
 unsigned long long
 bar (void)
 {
    unsigned long long t = foo;
    return t * foo;
 }
 
 Hope this helps someone find what's broken...
 
 Now back to seeing if I can make any sense out of target/8309.
 
 -- 
 Peter Barada                                   Peter.Barada@motorola.com
 Wizard                                         781-852-2768 (direct)
 WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)
Comment 5 graham.stott 2002-10-25 18:18:53 UTC
From: Graham Stott <graham.stott@btinternet.com>
To: joel@gcc.gnu.org,  ccj@acm.org,  gcc-bugs@gcc.gnu.org, 
 gcc-prs@gcc.gnu.org,  joel@OARcorp.com,  nobody@gcc.gnu.org, 
 pbarada@mail.wm.sps.mot.com,  gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: target/8343: m68k-elf/rtems ICE at instantiate_virtual_regs_1
Date: Fri, 25 Oct 2002 18:18:53 +0100

 joel@gcc.gnu.org wrote:
 > Synopsis: m68k-elf/rtems ICE at instantiate_virtual_regs_1
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: joel
 > State-Changed-When: Fri Oct 25 05:59:45 2002
 > State-Changed-Why:
 >     Peter Barada has this important piece of information which
 >     should be a big clue to fixing it:
 >     
 >     Ok, I've narrowed your ICE down to between two version, one 525 days
 >     ago(where it worked) and 523 days ago (where it failed).
 >     
 >     The verion from each is:
 >     
 >     Fail: version 3.1 20010519
 >     Work: version 3.1 20010517
 >     
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8343
 > 
 
 The original test case can be cut down to the following
 which fails at -O0 on cvs head
 ----------------------------------------------------------
 extern unsigned foo;
 
 unsigned long long
 bar (void)
 {
    unsigned long long t = foo;
 
    return t * foo;
 }
 ----------------------------------------------------------
 

Comment 6 Jan Hubicka 2002-10-26 01:38:57 UTC
From: Jan Hubicka <jh@suse.cz>
To: joel@gcc.gnu.org, ccj@acm.org, gcc-bugs@gcc.gnu.org,
	gcc-prs@gcc.gnu.org, hubicka@gcc.gnu.org, joel@OARcorp.com,
	nobody@gcc.gnu.org, pbarada@mail.wm.sps.mot.com,
	gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: target/8343: m68k-elf/rtems ICE at instantiate_virtual_regs_1
Date: Sat, 26 Oct 2002 01:38:57 +0200

 > Synopsis: m68k-elf/rtems ICE at instantiate_virtual_regs_1
 > 
 > Responsible-Changed-From-To: unassigned->hubicka
 > Responsible-Changed-By: joel
 > Responsible-Changed-When: Fri Oct 25 14:05:18 2002
 > Responsible-Changed-Why:
 >     Tracked to patch you committed. :)
 
 That just adds check for bugs elsewhere... OK I will check at monday.
 
 Honza
 >     ===================================
 >     FInal feedback from Peter.
 >     
 >     'cvs update -D "2001/05/19 04:24:49" gcc' works
 >     'cvs update -D "2001/05/19 04:29:50" gcc' fails
 >     
 >     The only thing of interest changing is gcc/gcc/recog.c, from version
 >     1.102 to version 1.103.
 >     
 >     The log for gcc/gcc/recog.c looks like:
 >     
 >     revision 1.103
 >     date: 2001/05/19 08:24:50;  author: hubicka;  state: Exp;  lines: +85 -150
 >             * recog.c (general_operand): Prohibit nonzero subreg bytes on
 >             subregs containing mem.
 >     
 >     
 >     This was with the following testcase:
 >     
 >     extern unsigned foo;
 >     unsigned long long
 >     bar (void)
 >     {
 >        unsigned long long t = foo;
 >        return t * foo;
 >     }
 >     
 >     
 >     ===================================
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8343

Comment 7 Jan Hubicka 2003-01-09 11:03:00 UTC
From: hubicka@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: target/8343
Date: 9 Jan 2003 11:03:00 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Changes by:	hubicka@gcc.gnu.org	2003-01-09 03:03:00
 
 Modified files:
 	gcc            : ChangeLog 
 	gcc/config/i386: athlon.md i386.md 
 	gcc/config/m68k: m68k.md 
 	gcc/java       : keyword.h 
 
 Log message:
 	* i386.md (*mul*): FIx constraints; remove confused comment; fix
 	athlon_decode attributes
 	(imul/k8 optimization peep2s): New.
 	
 	* athlon.md (athlon_ssecmp*): Handle ssecomi as well.
 	* i386.md (type attribute): Add ssecomi.
 	(unit, memory, prefix attributes): Handle ssecomi.
 	(cvt?2? patterns): Fix athlon_decode attribute
 	(comi patterns): Set attribute to ssecomi.
 	
 	PR target/8343
 	* m68k.md (umulsidi, mulsidi expanders): Use register operand.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.16304&r2=1.16305
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/athlon.md.diff?cvsroot=gcc&r1=1.4&r2=1.5
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&r1=1.410&r2=1.411
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/m68k/m68k.md.diff?cvsroot=gcc&r1=1.52&r2=1.53
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/keyword.h.diff?cvsroot=gcc&r1=1.10&r2=1.11
 

Comment 8 Jan Hubicka 2003-02-25 11:40:38 UTC
From: hubicka@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: target/8343
Date: 25 Feb 2003 11:40:38 -0000

 CVSROOT:	/cvs/gcc
 Module name:	gcc
 Branch: 	gcc-3_3-branch
 Changes by:	hubicka@gcc.gnu.org	2003-02-25 11:40:37
 
 Modified files:
 	gcc            : ChangeLog 
 	gcc/config/m68k: m68k.md 
 
 Log message:
 	PR target/8343
 	* m68k.md (umulsidi, mulsidi expanders): Use register operand.
 
 Patches:
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.225&r2=1.16114.2.226
 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/m68k/m68k.md.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.51.14.1&r2=1.51.14.2
 
Comment 9 Jim Wilson 2003-02-26 21:47:20 UTC
State-Changed-From-To: feedback->closed
State-Changed-Why: The patch was already on the trunk and the 3.3 branch.  I added it to the 3.2 branch after verifying that it worked for the testcase on the 3.2 branch.