Bug 18309 - ICE on valid code in print_operand_address, at config/rs6000/rs6000.c:9678 (procps-3.2.4)
Summary: ICE on valid code in print_operand_address, at config/rs6000/rs6000.c:9678 (p...
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.4.2
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2004-11-05 15:31 UTC by lu_zero
Modified: 2005-07-23 22:49 UTC (History)
2 users (show)

See Also:
Host: powerpc-unknown-linux-gnu
Target: powerpc-unknown-linux-gnu
Build: powerpc-unknown-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:

Attachments
preprocessed sources (8.00 KB, text/plain)
2004-11-05 15:34 UTC, lu_zero 		Details
clean source (466 bytes, text/plain)
2004-11-05 15:35 UTC, lu_zero 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description lu_zero 2004-11-05 15:31:51 UTC 
cc -c -D_GNU_SOURCE -I proc -I/usr/include/ncurses -fno-common -ffast-math -W
-Wall -Wshadow -Wcast-align -Wredundant-decls -Wbad-function-cast -Wcast-qual
-Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -O2
-s -m64 -Wdeclaration-after-statement -Wpadded -Wstrict-aliasing
-frename-registers -fomit-frame-pointer -fno-inline-functions -DSHARED=1 -fpic
proc/alloc.c -o proc/alloc.o
proc/alloc.c: In function `xcalloc':
proc/alloc.c:21: internal compiler error: in print_operand_address, at
config/rs6000/rs6000.c:9678
Comment 1 lu_zero 2004-11-05 15:34:29 UTC 
Created attachment 7479 [details]
preprocessed sources
Comment 2 lu_zero 2004-11-05 15:35:25 UTC 
Created attachment 7480 [details]
clean source
Comment 3 lu_zero 2004-11-05 15:49:15 UTC 
seems -m64 is causing the issue.
Comment 4 Alan Modra 2004-11-23 23:48:32 UTC 
This is an ICE in your system compiler, for which you haven't explicitly
specified a version.  I could not reproduce the failure using current mainline
or gcc-3.4 branch compilers, so it seems like this problem (if real, ie. not due
to a miscompiled system compiler) has already been fixed.