[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200401090843.i098h12n002108@imega-bsd.ub.uni-mainz.de>
From: ks at ub.uni-mainz.de (Kurt Schreiner)
Subject: gcc: Internal compiler error: program cc1 got fatal signal 11
Hi,
> 3) This is why it *will* segfault at runtime. If it *fails* to segfault at runtime,
> you have a *very* weird system indeed (or possibly very weird compiler flags ;)
just tried this on solaris9/sparc:
>-349: uname -a
SunOS sb1001 5.9 Generic_112233-05 sun4u sparc SUNW,Sun-Blade-1000
using:
>-333: gcc -v
Reading specs from /opt/nb/gcc-3.3/lib/gcc-lib/sparc-sun-solaris2/3.3/specs
Configured with: ./configure --prefix=/opt/nb/gcc-3.3 --host=sparc-sun-solaris2 --enable-languages=c,c++,f77,objc,ada --enable-shared
Thread model: posix
gcc version 3.3
>-339: cat gcc-muell.c
int main(void)
{
printf("%c","msux"[0xcafebabe]);
}
>-340: gcc gcc-muell.c
[Compiles w/o compaints!]
>-341: ./a.out
user=0.00 sec, sys=2.50 sec, elapsed=0:06.58 min, cpu use=37.9%
[Runs w/o complaints!]
>-342: truss ./a.out
execve("a.out", 0xFFBFF8EC, 0xFFBFF8F4) argc = 1
...
[...library mapping stuff...]
...
getustack(0xFFBFF53C)
getrlimit(RLIMIT_STACK, 0xFFBFF534) = 0
getcontext(0xFFBFF370)
setustack(0x7FB43944)
ioctl(1, TCGETA, 0xFFBFEA04) = 0
fstat64(1, 0xFFBFE920) = 0
write(1, "\0", 1) = 1
_exit(2141995056)
user=0.04 sec, sys=2.40 sec, elapsed=0:06.28 min, cpu use=38.8%
allocates a large bunch af mem (top says ~750MB) and print's the byte
it's told to print... nice, eh???
Just for fun:
>-345: /opt/.awaySUNWspro/bin/cc -V
cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15
usage: cc [ options] files. Use 'cc -flags' for details
>-346: /opt/.awaySUNWspro/bin/cc gcc-muell.c
>-347: ./a.out
user=0.00 sec, sys=2.41 sec, elapsed=0:05.17 min, cpu use=46.6%
same as above...
Just my 0.02 Euros,
-kurt
Powered by blists - more mailing lists