Bug 15259 - [3.4/4.0 regression] segv
Summary: [3.4/4.0 regression] segv
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-invalid-code
: 16778 16811 21864 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-05-03 09:37 UTC by Ivan Godard
Modified: 2005-07-23 22:49 UTC (History)
3 users (show)

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


Attachments
compiler output (without -v -save-temps) (224 bytes, text/plain)
2004-05-03 09:39 UTC, Ivan Godard
Details
Compiler output (-v -save-temps) (531 bytes, text/plain)
2004-05-03 09:39 UTC, Ivan Godard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Godard 2004-05-03 09:37:35 UTC
 
Comment 1 Ivan Godard 2004-05-03 09:39:03 UTC
Created attachment 6215 [details]
compiler output (without -v -save-temps)
Comment 2 Ivan Godard 2004-05-03 09:39:35 UTC
Created attachment 6216 [details]
Compiler output (-v -save-temps)
Comment 3 Ivan Godard 2004-05-03 09:44:49 UTC
No source code attached - it never got far enough to make a .ii. The problem is in the command line, where there's a "-I" missing that should be on "../../../members/common/include". That's a directory, not a file, so you might be able to reproduce this by putting a directory on the command line. But part of the noise mentions "too many files", so maybe the problem is not that it's a directory (gcc legal?) but it has a lot of files. Anyway, it segv's.
Comment 4 Wolfgang Bangerth 2004-05-03 13:04:05 UTC
I keep getting messages like 
 
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ /usr/include 
/usr/include: file not recognized: Is a directory 
collect2: ld returned 1 exit status 
 
But then, you didn't tell us what exactly your command line was. Can 
you clarify? 
 
Thanks 
  Wolfgang 
Comment 5 Ivan Godard 2004-05-03 18:56:37 UTC
Command line was as in the first attachment, but here it is again:

~/ootbc/members/common/src$ g++ -o2 -g -I. ../../../members/common/include -I/home/ivan/ootbc/common/include -I/home/ivan/ootbc/common/xptsys/include -c -o attribute.o attribute.cc
g++: ../../../members/common/include: linker input file unused because linking not done
cc1plus: ../../../members/common/include: No such file or directory
cc1plus: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Comment 6 Wolfgang Bangerth 2004-05-11 14:48:28 UTC
OK, I can finally reproduce this: 
 
g/x> rm x.cc 
g/x> touch x.cc 
g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ /usr/include -o x.o -c x.cc 
c++: /usr/include: linker input file unused because linking not done 
cc1plus: /usr/include: No such file or directory 
cc1plus: internal compiler error: Segmentation fault 
Please submit a full bug report, 
with preprocessed source if appropriate. 
See <URL:http://gcc.gnu.org/bugs.html> for instructions. 
 
The trick is to ask the compiler to both compile /usr/include (a directory) 
and x.cc (a file), and at the same time to give an output file via -o. 
 
However, this is already fixed on mainline: 
 
g/x> rm x.cc 
g/x> touch x.cc 
g/x> /home/bangerth/bin/gcc-3.5-pre/bin/c++ /usr/include -o x.o -c x.cc 
c++: /usr/include: linker input file unused because linking not done 
 
Strictly speaking, this bug is a regression in 3.4 against 3.3.4, which 
doesn't ICE on this input. However, given the bogosity of the input  
and that it is already fixed on mainline, I predict that nobody will feel 
a real great urge to fix it on 3.4.x as well, so I'll just close the PR. 
Thanks anyway! 
 
W. 
Comment 7 Falk Hueffner 2004-07-27 08:21:49 UTC
*** Bug 16778 has been marked as a duplicate of this bug. ***
Comment 8 Andrew Pinski 2004-07-28 21:49:40 UTC
*** Bug 16811 has been marked as a duplicate of this bug. ***
Comment 9 Wolfgang Bangerth 2005-06-01 19:00:51 UTC
*** Bug 21864 has been marked as a duplicate of this bug. ***