report is being submitted to debian-bugs as well. this error occured during a build of sendmail-8.9.3 on the netwinder. the build which caused the error was the sendmail source package from debian potato (slink and woody fail as well). the attached file is a gziped copy of the domain.c file which is causing the error. cc -O2 -I. -I/usr/include/db2 -DNEWDB -DNIS -DMAP_REGEX -DHASFLOCK=1 -DTCPWRAPPE RS=1 -D_FFR_MAX_MIME_HEADER_LENGTH=1 -D_FFR_MAX_HEADERS_LENGTH=1 -D_PATH_SENDMAI LCF=\"/etc/mail/sendmail.cf\" -include ../../debian/el33t.h -DCMDDIR=\"/usr/lib/ sm.bin\" -DPATH=\"/usr/bin:/bin\" -D_PATH_SENDMAIL=\"/usr/sbin/sendmail\" -c - o domain.o domain.c domain.c: In function `getmxrr': domain.c:380: internal error--unrecognizable insn: (insn 1818 1817 319 (set (reg:SI 4 r4) (umin:SI (reg/v:SI 4 r4) (const_int 8192 [0x2000]))) -1 (nil) (nil)) make[2]: *** [domain.o] Error 1 Release: 2.95.2 (debian rev 13) Environment: armv4l (rebel.com netwinder) How-To-Repeat: attempt to build sendmail with gcc-2.9.5.2-13. ssh access to affected machine can be granted if needed.
Fix: unknown
State-Changed-From-To: open->analyzed State-Changed-Why: Bug confirmed to exist (indeed, positively notorious)
From: Phil Blundell <pb@nexus.co.uk> To: gcc-gnats@gcc.gnu.org Cc: Subject: Re: target/491 Date: 18 Jan 2002 17:43:22 +0000 Some analysis of this bug is at http://gcc.gnu.org/ml/gcc-bugs/1999-10n/msg00097.html
From: Richard Earnshaw <rearnsha@arm.com> To: pb@gcc.gnu.org, chris@cgnet.cx, pb@nexus.co.uk, gcc-gnats@gcc.gnu.org Cc: Richard.Earnshaw@arm.com Subject: Re: target/491: [ARM 4l] unrecognizable insn Date: Fri, 18 Jan 2002 18:11:59 +0000 > Bug confirmed to exist (indeed, positively notorious) I don't think this can occur in gcc-3.0 or later, since the way reload handles these sort of problems has been radically altered.
From: Phil Blundell <pb@nexus.co.uk> To: Richard.Earnshaw@arm.com Cc: pb@gcc.gnu.org, chris@cgnet.cx, gcc-gnats@gcc.gnu.org Subject: Re: target/491: [ARM 4l] unrecognizable insn Date: 18 Jan 2002 18:20:30 +0000 On Fri, 2002-01-18 at 18:11, Richard Earnshaw wrote: > > Bug confirmed to exist (indeed, positively notorious) > > I don't think this can occur in gcc-3.0 or later, since the way reload > handles these sort of problems has been radically altered. Okay, great. I'll have a go at re-testing it with 3.0. What are we doing about bugs that are fixed in 3.0 and/or the trunk, but still in 2.95? I guess there needs to come a time when keeping track of 2.95 bugs becomes more trouble than it's worth, but I dunno if that time is now. p.
Responsible-Changed-From-To: unassigned->pb Responsible-Changed-Why: .
State-Changed-From-To: analyzed->feedback State-Changed-Why: Can you confirm this is now fixed?
State-Changed-From-To: feedback->closed State-Changed-Why: No feedback. According to audit trail, problem was likely fixed already for 3.0.