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.
Segfault is persistent, my memory is fine :(
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 :(
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.
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.
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 HTH, August
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 do. 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...
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.
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, August 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...
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).
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.
GCC 2.96-RH is too old now, if you are able to reproduce something similar with contemporary GCC's, please reopen.