This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
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
Fix: Unknown
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
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; } ===================================
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)
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; } ----------------------------------------------------------
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
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
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
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.