Menu
▾
▴
#99 gcc 4.1.2: -O2 or -O3 -c does not produce .o file
I am doing a test built of gcc 4.1.2 to see if there are any problems. I know there is no official mingw release yet for gcc 4.1.2.
I found that gcc.exe quits without producing an ".o" output file if -O3 is used. There is no error report. -O2 has the same result. -O1 does produce an output file.
Compile attempts:
gcc -Wall -mtune=pentium4 -O3 -c program.c -fno-exceptions (normally used)
gcc -Wall -mtune=pentium4 -O3 -c program.c
gcc -Wall -O3 -c program.c
gcc -Wall -pedantic -O3 -c program.c
gcc -Wall -mtune=pentium4 -O2 -c program.c
All of the above have the problem. No error reported and no ".o" output file. Errorlevel returned = 1.
These parameters do not have the problem:
gcc -Wall -mtune=pentium4 -O1 -c program.c
gcc 3.4.2 has no problem for
gcc -Wall -mtune=pentium4 -O3 -c program.c -fno-exceptions
Version information:
OS: Windows XP SP2
gcc -v
Using built-in specs.
Target: mingw32
Configured with: ../../source/gcc-4.1.2/configure --prefix=/mingw --host=mingw32
--target=mingw32 --program-prefix= --with-as=/mingw/bin/as.exe --with-ld=/mingw
/bin/ld.exe --with-gcc --with-gnu-ld --with-gnu-as --enable-threads --disable-nl
s --enable-languages=c,c++ --disable-win32-registry --disable-shared --without-x
--enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 4.1.2
ld -v
GNU ld version 2.17.50 20060824
built using:
bison-2.1.bin.zip
flex-2.5.4a-1-bin.zip
libiconv-1.9.2-1.bin.zip
libintl-0.14.4-bin.zip
binutils-2.17.50-20060824-1.tar.tar
gcc-core-3.4.5-20060117-1.tar.tar
mingw-runtime-3.12.tar.tar
MSYS-1.0.10.exe
w32api-3.9.tar.tar
gcc-core-4.1.2.tar.bz2
gcc-g++-4.1.2.tar.bz2
Used these instructions to built gcc 4.1.2:
http://www.mingw.org/MinGWiki/index.php/How%20to%20Compile%20GCC%204.1
_mingw.h
#define __MINGW32_VERSION 3.12
w32api.h
#define __W32API_VERSION 3.9
$ uname -a
MINGW32_NT-5.1 name 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown
I tried some of these 4.1.2 builds too:
http://www.develer.com/oss/GccWinBinaries
http://nuwen.net/mingw.html
http://winports.sourceforge.net/
http://www.tdragon.net/gcc412.html
With similar results. What can I do to pinpoint the problem? Does this look like a known problem?
Thanks!
Logged In: YES
user_id=11494
Originator: NO
You fail to provide problem.c, so I cannot reproduce your problem.
The only time I have seen this sort of behaviour is when the compiler itself runs out of stack address space. Try rebuilding gcc with bigger stack reserve (the default is 2MB). See ld.info for help on --stack option
D.
Logged In: YES
user_id=1020291
Originator: YES
Thanks for the answer. Unfortunately I don't have a sample file available, the original file has 40,000 lines of code.
I tried this make line:
make CFLAGS="-O2 -fomit-frame-pointer" CXXFLAGS="-mthreads -fno-omit-frame-pointer -O2" LDFLAGS="-s --stack=0x400000" bootstrap2
I've tried to build with the "--stack 0x400000" parameter, but this fails: on the command line "--stack=0x400000" seems to work (no error), but it doesn't work when used from make, leaving out the '=' sign, or using two '-' signs causes an error in stage-1.
checking for mingw32-gcc... gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
make[2]: *** [configure-stage1-intl] Error 77
make[2]: Leaving directory `/gcc-work/build/gcc'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/gcc-work/build/gcc'
make: *** [bootstrap2] Error 2
Last line in config.log: configure:7345: gcc -c -g -O2 -fkeep-inline-functions conftest.c 1>&5.
One '-' sign before stack will not cause this error, but later on in the process errors are displayed about it being an unknown parameter.
Am I doing something wrong here?
If not, is it possible to hack the make file to make it use "--stack=0x400000"?
I tried changing "LDFLAGS_FOR_TARGET = " on line 348 to 'LDFLAGS_FOR_TARGET =--stack=0x400000 " and use the old command line: make CFLAGS="-O2 -fomit-frame-pointer" CXXFLAGS="-mthreads -fno-omit-frame-pointer -O2" LDFLAGS=-s bootstrap2
This make is now running.
Any comments are appreciated.
Logged In: YES
user_id=1020291
Originator: YES
Following up
The "make" has quit with the same error.
mkdir -p -- ./fixincludes
Configuring in ./fixincludes
configure: creating cache ./config.cache
checking build system type... i386-pc-mingw32
checking host system type... i386-pc-mingw32
checking target system type... i386-pc-mingw32
checking for mingw32-gcc... /gcc-work/build/gcc/./gcc/xgcc -B/gcc-work/build/gcc/./gcc/ -L/gcc-work/build/gcc/mingw32/winsup/mingw -L/gcc-work/build/gcc/mingw32/winsup/w32api/lib -isystem /gcc-work/source/gcc-4.2.0-20070501/winsup/mingw/include -isystem /gcc-work/source/gcc-4.2.0-20070501/winsup/w32api/include -B/mingw/mingw32/bin/ -B/mingw/mingw32/lib/ -isystem /mingw/mingw32/include -isystem /mingw/mingw32/sys-include
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
make[1]: *** [configure-fixincludes] Error 1
make[1]: Leaving directory `/gcc-work/build/gcc'
make: *** [bootstrap2] Error 2
Logged In: YES
user_id=11494
Originator: NO
Look in your Makefile
LDFLAGS is used as part of GCC invocation, eg
cc1$(exeext): $(C_OBJS) cc1-checksum.o $(BACKEND) $(LIBDEPS)
$(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) cc1-checksum.o \ $(BACKEND) $(LIBS)
So your LDFLAGS need to be prefaced with -Wl, (eg, LDFLAGS="-s -Wl,--stack=0x800000") .
The GCC driver automatically passes the -s on the linker so you don't need to do so explicitly. Actually it would probably be better to leave the debug in until you've tested the compiler :).
D
Logged In: YES
user_id=1020291
Originator: YES
Thanks! LDFLAGS="-s -Wl,--stack=0x800000" works and it solves the compiler problem.