Bug 22374 - segfault (a real one :)
segfault (a real one :)
Product: Red Hat Raw Hide
Classification: Retired
Component: gcc (Show other bugs)
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2000-12-15 18:30 EST by Need Real Name
Modified: 2007-04-18 12:30 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-02 15:19:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2000-12-15 18:30:24 EST
a number of latest gcc src.rpms can't compile themselves with optimizations turned on. I used various previous versions down to 2.95.2. Latest error is this: "../../gcc/libgcc2.c: in function `__muldi3.o'::\n../../gcc/libgcc2.c:199: Internal error: Segmentation fault. Please submit a full bug report." So I did. HTH. Logs & dumps, other info available on request (not shure which is needed, if at all). I use linux 2.2.17, redhat-based distrib being upgraded slowly to rawhide, libc is glibc-2.2-5 (7.0 rpm recompiled) kernel with applyied reiserfs & international pp. Now I'll try to compile it without optimisations at all.
Comment 1 Need Real Name 2000-12-15 18:35:08 EST
Segfault is persistent, my memory is fine :(
Comment 2 Need Real Name 2000-12-15 19:44:12 EST
Yes, it compiles with -O0. But it's still the 2.96 fault, cause it segfaults in

stage1 with optimisations turned on. Maybe I should try to compile it with 

different options (-march=k6), but not now :(
Comment 3 Jakub Jelinek 2000-12-16 05:17:21 EST
What exact optimizations are you bootstrapping gcc with?
I'm bootstrapping this gcc with -O2 -mcpu=i686 on ia32
(-O2 on alpha, -O2 -mcpu=ultrasparc -m32 resp. -O2 -mcpu=ultrasparc -m64
on sparc) several times a week without any problems.
By chance, are you using one of -m{arch,cpu}={athlon,k6}?
Those are surely less tested than other options.
Comment 4 Jakub Jelinek 2000-12-16 15:35:19 EST
BTW: gcc-2.96-68 bootstraps succeeded today with both -O2 -march=athlon
and -O2 -march=i586, so I really wonder what have you passed to it so that
it crashed during bootstrap.
Comment 5 Need Real Name 2000-12-16 18:27:17 EST
Ok, here it goes:

-Os -fstrength-reduce -falign-loops=2 -falign-jumps=2 -falign-functions=2 -falign-labels=1 -mpreferred-stack-boundary=2 -Wno-return-type -fcaller-saves -freg-struct-return -fshared-data -fforce-addr -fschedule-insns2 -ffor-scope -fallow-single-precision -ffloat-store -mfancy-math-387 -mno-align-double -fregmove -fgcse -fstrict-aliasing -ffast-math -finline-functions -fmove-all-movables -pipe -Wall -march=k6 -fomit-frame-pointer -fhosted -felide-constructors -fvtable-thunks -fconserve-space -fnonnull-objects -D_GNU_SOURCE -Wall -freduce-all-givs -fstrict-prototype -foperator-names -foptimize-sibling-calls -fsingle-precision-constant -freorder-blocks -mmmx.

And not, I am not a sadist :) BTW, gcc-2.96-65, compiled previously with -O0, now

failed to compile itself with optimisations. gdb ./gencheck core gives me this:

GNU gdb 5.0

Copyright 2000 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "i586-redhat-linux"...

Core was generated by `./gencheck'.

Program terminated with signal 11, Segmentation fault.

Reading symbols from /lib/libc.so.6...done.

Loaded symbols for /lib/libc.so.6

Reading symbols from /lib/ld-linux.so.2...done.

Loaded symbols for /lib/ld-linux.so.2

#0  0x80482f9 in _start ()

Breakpoint 1 at 0x162ee4

.gdbinit:8: Error in sourced command file:

../../gcc/.gdbinit:92: Error in sourced command file:

Function "fancy_abort" not defined.

(gdb) bt

#0  0x80482f9 in _start ()

#1  0x804828d in _init ()

#2  0x14fd52 in __libc_start_main () from /lib/libc.so.6

#3  0x7de808ec in ?? ()

Cannot access memory at address 0x83e58955


Comment 6 Jakub Jelinek 2000-12-18 04:49:37 EST
Do you really pass all these options on the command line?
If yes, then I can just wonder why do you do that, some options
above are clearly against other options (e.g. -Os optimizes for size
while e.g. -finline-functions or -fschedule-insns2 are speed optimizations
which enlarge binary size etc.
Also, libstdc++ knows itself which options to pass for which parts,
so passing them specifically some C++ options is a wrong thing to
BTW: What do you need smallest possible compiler for? If you
need to save space in some environment, you save best by not including
development environment at all and cross compile from other host.
Just wondering...
Comment 7 Need Real Name 2000-12-18 19:17:12 EST
1. These opts are in rpmrc and i586blah/macros files, of course I'm not typing

them. Some are also doubled in spec file.

2. They are NOT against each other, if it's not clear:

   I optimize for size 'as a whole', while keeping inline functions inline.

BTW, specifying just -O2 or -Os is a Microsoft way of doing things, I wish

to choose various tradeoffs myself. I wonder why you asked this, being working

at RedHat :)

3. Your BTW remark smells like insult. I need smallest possible compiler cause

I live in a poor country and can't afford more memory. Besides, I do my work

(Tex publishing, which means running X, xemacs,latex & ghostscripts simult.) and

secondary work (c++ programming) simultaneously, having only 64 Megs RAM. No

problems till this time. Also I like download something at the same time, too.

Alas, If you give me login on your machine, I can cross-compile from it :|

But to the deal: gcc, compiled with -O0 segfaults because it thinks it is a

cross-compiler, - so maybe this is a stupid non-bug report. I'll try to remove

wine files and recompile.
Comment 8 Need Real Name 2000-12-18 20:37:35 EST
I checked cross-compiler configure message, it comes as a result of trivial program comitting segfault, so problem persists...

HTH. I'll switch back to 2.95.3 for now, anyway I can't help resolve this, it seems.

All the best,


P.S. Whatever my means are, it is bad when documented option makes compiler crash, so this is important even if smallest compilers do not matter at all...
Comment 9 Jakub Jelinek 2000-12-19 02:28:44 EST
My reply was not meant as any insult. If you're compiling C++ code,
what really matters memory-wise is how many templates and other
memory consuming stuff you are using in your source, as the compiler
eats an order of magnitude more memory during compilation then it
is its binary size. -finline-functions heuristic is not influenced
by optimize_size at all, which means that really most of the -Os
savings will be replaced by the inlined functions size increase, that's
why I was asking.
If you post here a preprocessed input - together with exact options
passed to gcc - which cause the compiler to crash (you can get
preprocessed output from -save-temps -v), I'll try to debug it,
but if the thing is that N-th stage compiler got somehow miscompiled
and crashes building N+1th compiler, then it is less likely I'd
find time to analyze and fix it.
Anyway, I still wonder what options were really passed in *FLAGS to
configure (ie. not expanded using specs).
Comment 10 Need Real Name 2000-12-19 20:10:51 EST
sorry for flames. strange fact: I recompiled with "-O0", no options in specs.

As a result a got all binary rpms, but after installing any program compiled

crash, configure detects cross-compiler because of that. Considering this, would

preprocessed input help? To get Prepr. input for first case, I need to put back all this hairy stuff in specs & rpmrcs ( but I'll do it tomorrow).

BTW configure was passed $RPM_OPT_FLAGS, which had exactly options I posted.

in specs were only some of them and no others. (in the first case; in second

case specs wasn't hacked at all, RPM_OPT_FLAGS was set to "-O0". my LDFLAGS are

-Wl,--sort-common -s)

thanks for size-optimizing info. Never thought options may conflict or ignore

each other :(

P.S. Ok, to be more precise: RPM_OPT_FLAGS was set to all posted options, in

that exact order, CFLAGS was set to "-Os -fstrict-aliasing -ffast-math

-finline-functions -fmove-all-movables -freduce-all-givs -march=k6

-fomit-frame-pointer -fhosted ", all other options mentioned in RPM_OPT.. were

in specs.

Comment 11 Jakub Jelinek 2004-10-02 15:19:21 EDT
GCC 2.96-RH is too old now, if you are able to reproduce something
similar with contemporary GCC's, please reopen.

Note You need to log in before you can comment on or make changes to this bug.