This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/14146] New: GCC 3.3-branch (only) has an ICE for sparc64
- From: "gcc-bugzilla at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 Feb 2004 14:36:48 -0000
- Subject: [Bug c/14146] New: GCC 3.3-branch (only) has an ICE for sparc64
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
when building netpbm's "exif.c" with any optimisation, any GCC3.3 release
compiler will have an ICE, eg:
foo.i: In function `ProcessExifDir':
foo.i:83: error: insn does not satisfy its constraints:
(insn:HI 219 214 471 13 0x404c3aa0 (set (reg:DI 31 %i7 [32])
(fix:DI (fix:DF (reg:DF 32 %f0 [169])))) 166 {fix_truncdfdi2} (insn_list 215 (nil))
(nil))
foo.i:83: internal compiler error: in reload_cse_simplify_operands, at reload1.c:8345
i first reduced the code to the smallest test case i could find, and then
looked at top-of-CVS for GCC to see if the bug was still present. i was
actually unable to reproduce this at any date of the GCC mainline for the
past 16 months. i found that this change on the GCC 3.3 branch introduced
this regression, but why it does not for mainline i can not say:
+ 2003-03-11 Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
+
+ PR bootstrap/9994
+ Backport from mainline:
specifically, the call to the new sbitmap_resize() in reload.c causes the
problem to occur.
(this exact same bug also occurs with kdegraphics 3.1.4's "exif.cpp" file.)
Environment:
System: NetBSD phat-bass.eterna.com.au 1.6ZG NetBSD 1.6ZG (_phat_) #8: Sat Dec 6 18:19:50 EST 2003 mrg@phat-bass.eterna.com.au:/home/obj/i386/usr/src/sys/arch/i386/compile/_phat_ i386
host: i386-unknown-netbsdelf1.6ZG
build: i386-unknown-netbsdelf1.6ZG
target: sparc64-unknown-netbsd
configured with: /home/mrg/src/gcc-current/gcc-date/configure --target=sparc64-netbsd --enable-languages=c
How-To-Repeat:
compile the following input with a sparc64-cc1 from GCC 3.3 branch. this
code is extremely sensitive to avoiding the failure. removing or changing
almost any part of this will mask the problem.
------>8-------->8-------->8-------->8-------
typedef struct {
unsigned char * ThumbnailPointer;
unsigned ThumbnailSize;
} ImageInfo_t;
static double ConvertAnyFormat(void * ValuePtr, int Format)
{
return *(signed char *)ValuePtr;
}
static void ProcessExifDir(unsigned char * DirStart,
unsigned char * OffsetBase, unsigned ExifLength,
ImageInfo_t * const ImageInfoP,
int const ShowTags,
unsigned char ** const LastExifRefdP )
{
int de;
int NumDirEntries;
unsigned ThumbnailOffset = 0;
unsigned ThumbnailSize = 0;
NumDirEntries = Get16u(DirStart);
if (DirStart > (OffsetBase+ExifLength))
pm_error("Illegally sized directory");
if (ShowTags)
pm_message("Directory with %d entries",NumDirEntries);
for (de=0;de<NumDirEntries;de++){
int Tag, Format, Components;
unsigned char * ValuePtr;
int ByteCount;
unsigned char * DirEntry;
DirEntry = DirStart+2+12*de;
Tag = Get16u(DirEntry);
Format = Get16u(DirEntry+2);
Components = Get32u(DirEntry+4);
ByteCount = Components;
if (ByteCount > 4){
unsigned OffsetVal;
OffsetVal = Get32u(DirEntry+8);
if (OffsetVal+ByteCount > ExifLength){
pm_error("Illegal pointer offset value in EXIF. "
"Offset %d bytes %d ExifLen %d\n",
OffsetVal, ByteCount, ExifLength);
}
ValuePtr = OffsetBase+OffsetVal;
} else {
ValuePtr = DirEntry+8;
}
switch(Tag){
case 0x0201:
ThumbnailOffset = (unsigned)ConvertAnyFormat(ValuePtr, Format);
break;
case 0x0202:
ThumbnailSize = (unsigned)ConvertAnyFormat(ValuePtr, Format);
break;
}
if (Tag == 0x8769 || Tag == 0xa005){
unsigned char * SubdirStart;
SubdirStart = OffsetBase + Get32u(ValuePtr);
if (SubdirStart > OffsetBase+ExifLength)
pm_error("Illegal subdirectory link");
ProcessExifDir(SubdirStart, OffsetBase, ExifLength, ImageInfoP,
ShowTags, LastExifRefdP);
continue;
}
}
if (ThumbnailSize && ThumbnailOffset){
if (ThumbnailSize + ThumbnailOffset <= ExifLength){
ImageInfoP->ThumbnailPointer = OffsetBase + ThumbnailOffset;
ImageInfoP->ThumbnailSize = ThumbnailSize;
}
}
}
------>8-------->8-------->8-------->8-------
------- Additional Comments From mrg at eterna dot com dot au 2004-02-14 14:36 -------
Fix:
using -O0 stops the bug from occuring.
--
Summary: GCC 3.3-branch (only) has an ICE for sparc64
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrg at eterna dot com dot au
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-unknown-netbsdelf1.6ZG
GCC host triplet: i386-unknown-netbsdelf1.6ZG
GCC target triplet: sparc64-unknown-netbsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14146