RE: compiling GHC with a custom path to GCC
On 17 February 2005 11:12, Remi Turk wrote:
when compiling the new ghc pre-releases made my gcc 2.95.3 die with "internal compiler error", I tried to compile it with gcc 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that died, compiled+installed gcc 3.4.3, tried again, say it die again and only then noticed it was actually still using 2.95.3 ;) but had quite some difficulty to actually get it to compile with, in my case, /usr/local/bin/gcc3
When using the following command-line
CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3
stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc that's documented)
Really? --with-gcc should set the gcc for stage1, AFAIK. Is there a bug here? I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x. Cheers, Simon
Simon Marlow wrote:
On 17 February 2005 11:12, Remi Turk wrote:
when compiling the new ghc pre-releases made my gcc 2.95.3 die with "internal compiler error", I tried to compile it with gcc 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that died, compiled+installed gcc 3.4.3, tried again, say it die again and only then noticed it was actually still using 2.95.3 ;) but had quite some difficulty to actually get it to compile with, in my case, /usr/local/bin/gcc3
When using the following command-line
CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3
stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc that's documented)
Really? --with-gcc should set the gcc for stage1, AFAIK. Is there a bug here?
I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x.
This is a known problem in all the 3.x compilers, and also occurs, although less often, with 2.9x versions. I've seen no difference in frequency comparing FreeBSD to Linux and NetBSD. The only solution, which is of course highly annoying, is to simply restart the make. For whatever reason this always works, sometimes until the end of the build, and sometimes until some other crash. My theory is that it is related to the temporary files that gcc creates, mostly for templates. While a royal PITA, the resulting code is correct.
Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
!DSPAM:421483e7114671125015511!
On Thu, Feb 17, 2005 at 04:48:54AM -0700, Seth Kurtzberg wrote:
Simon Marlow wrote:
On 17 February 2005 11:12, Remi Turk wrote:
when compiling the new ghc pre-releases made my gcc 2.95.3 die with "internal compiler error", I tried to compile it with gcc 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that died, compiled+installed gcc 3.4.3, tried again, say it die again and only then noticed it was actually still using 2.95.3 ;) but had quite some difficulty to actually get it to compile with, in my case, /usr/local/bin/gcc3
When using the following command-line
CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3
stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc that's documented)
Really? --with-gcc should set the gcc for stage1, AFAIK. Is there a bug here?
I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x.
This is a known problem in all the 3.x compilers, and also occurs, although less often, with 2.9x versions. I've seen no difference in frequency comparing FreeBSD to Linux and NetBSD.
The only solution, which is of course highly annoying, is to simply restart the make. For whatever reason this always works, sometimes until the end of the build, and sometimes until some other crash. My theory is that it is related to the temporary files that gcc creates, mostly for templates.
While a royal PITA, the resulting code is correct.
Cheers, Simon
I'm afraid finding a workaround for compilers dying on compiler-generated code isn't going to be much fun... Anyway, I just replaced a ifneq "$(INSTALL_LIBS)" "" by ifneq "$(strip $(INSTALL_LIBS))" "" (see my glasgow-haskell-bugs message of today, this usage is recommended in make's "info" for strip.) Now I could install ghc, remove the build-tree and get enough free space to start compiling again. This time I'll log everything and come back when I'm sure what exactly is going on. (As I "remember" that 1) --with-gcc doesn't do what it should and 2) the gcc-2.95-crash on linux seems to be repeatable.) -- Nobody can be exactly like me. Even I have trouble doing it.
Remi Turk wrote:
On Thu, Feb 17, 2005 at 04:48:54AM -0700, Seth Kurtzberg wrote:
Simon Marlow wrote:
On 17 February 2005 11:12, Remi Turk wrote:
when compiling the new ghc pre-releases made my gcc 2.95.3 die with "internal compiler error", I tried to compile it with gcc 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that died, compiled+installed gcc 3.4.3, tried again, say it die again and only then noticed it was actually still using 2.95.3 ;) but had quite some difficulty to actually get it to compile with, in my case, /usr/local/bin/gcc3
When using the following command-line
CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3
stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc that's documented)
Really? --with-gcc should set the gcc for stage1, AFAIK. Is there a bug here?
I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x.
This is a known problem in all the 3.x compilers, and also occurs, although less often, with 2.9x versions. I've seen no difference in frequency comparing FreeBSD to Linux and NetBSD.
The only solution, which is of course highly annoying, is to simply restart the make. For whatever reason this always works, sometimes until the end of the build, and sometimes until some other crash. My theory is that it is related to the temporary files that gcc creates, mostly for templates.
While a royal PITA, the resulting code is correct.
Cheers, Simon
I'm afraid finding a workaround for compilers dying on compiler-generated code isn't going to be much fun...
Anyway, I just replaced a ifneq "$(INSTALL_LIBS)" "" by ifneq "$(strip $(INSTALL_LIBS))" "" (see my glasgow-haskell-bugs message of today, this usage is recommended in make's "info" for strip.)
Now I could install ghc, remove the build-tree and get enough free space to start compiling again. This time I'll log everything and come back when I'm sure what exactly is going on. (As I "remember" that 1) --with-gcc doesn't do what it should and 2) the gcc-2.95-crash on linux seems to be repeatable.)
I'm not positive about 2.95, but I know that on 3.x it crashes in different places, and even compiling different source files. With each 3.x release, they fix some of them, but others pop up to take their place. Clearly the gcc people don't know what's going on.
On Thu, Feb 17, 2005 at 05:05:18AM -0700, Seth Kurtzberg wrote:
Remi Turk wrote:
I'm afraid finding a workaround for compilers dying on compiler-generated code isn't going to be much fun...
Anyway, I just replaced a ifneq "$(INSTALL_LIBS)" "" by ifneq "$(strip $(INSTALL_LIBS))" "" (see my glasgow-haskell-bugs message of today, this usage is recommended in make's "info" for strip.)
Now I could install ghc, remove the build-tree and get enough free space to start compiling again. This time I'll log everything and come back when I'm sure what exactly is going on. (As I "remember" that 1) --with-gcc doesn't do what it should and 2) the gcc-2.95-crash on linux seems to be repeatable.)
I'm not positive about 2.95, but I know that on 3.x it crashes in different places, and even compiling different source files. With each 3.x release, they fix some of them, but others pop up to take their place. Clearly the gcc people don't know what's going on.
Sounds like it just was about time to get a C-- backend ;o) [off-topic] Btw, how bad is it to get "Bad eta expand" warnings during compilation of GHC? Greetings, Remi -- Nobody can be exactly like me. Even I have trouble doing it.
On Thu, Feb 17, 2005 at 11:29:41AM -0000, Simon Marlow wrote:
On 17 February 2005 11:12, Remi Turk wrote:
when compiling the new ghc pre-releases made my gcc 2.95.3 die with "internal compiler error", I tried to compile it with gcc 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that died, compiled+installed gcc 3.4.3, tried again, say it die again and only then noticed it was actually still using 2.95.3 ;) but had quite some difficulty to actually get it to compile with, in my case, /usr/local/bin/gcc3
When using the following command-line
CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3
stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc that's documented)
Really? --with-gcc should set the gcc for stage1, AFAIK. Is there a bug here?
I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x.
Cheers, Simon
I seem to have been mistaken. When configuring with --with-gcc it does use gcc 3.4.3. I'm letting it continue till completion to be entirely sure. (As IIRC the compiler-errors came rather late in the build and it's only compiling for about an hour now.) I'll try to reproduce the 2.95 internal compiler error later. Btw, at first I misunderstood the following comment in docs/building/building.xml to mean that --with-gcc only specified the compiler for actual .c files in the ghc-distribution. (Which explains my "(okay, for --with-gcc that's documented)") <term><literal>--with-gcc=<parameter>path</parameter></literal> <indexterm><primary><literal>--with-gcc</literal></primary></indexterm> </term> <listitem> <para>Specifies the path to the installed GCC. This compiler will be used to compile all C files, <emphasis>except</emphasis> any generated by the installed Haskell compiler, which will have its own idea of which C compiler (if any) to use. The default is to use <literal>gcc</literal>.</para> </listitem> To be more precisely, to me "the installed Haskell compiler" was "the (stage[12] of the) Haskell compiler to be installed once it's compiled". Groeten, Remi -- Nobody can be exactly like me. Even I have trouble doing it.
[Resent, with a few #ifdef FOO's removed from the body (still in the attachement, and using gzip instead of bzip2 to prevent "awaiting moderation ;)] On Thu, Feb 17, 2005 at 11:29:41AM -0000, Simon Marlow wrote:
On 17 February 2005 11:12, Remi Turk wrote:
when compiling the new ghc pre-releases made my gcc 2.95.3 die with "internal compiler error", I tried to compile it with gcc 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that died, compiled+installed gcc 3.4.3, tried again, say it die again and only then noticed it was actually still using 2.95.3 ;) but had quite some difficulty to actually get it to compile with, in my case, /usr/local/bin/gcc3
When using the following command-line
CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3
stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc that's documented)
Really? --with-gcc should set the gcc for stage1, AFAIK. Is there a bug here?
I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x.
Cheers, Simon
In case you've got nothing else left to do.. ;) The ghc command which perfectly repeatable kills gcc: make[2]: Entering directory `/var/tmp/ghc-6.4.20050216/ghc/compiler' ../../ghc/compiler/stage1/ghc-inplace -H16m -O -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/compMan -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-haskell -package unix -package readline -DUSE_READLINE -package Cabal -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -recomp -Rghc-timing -H16M '-#include "hschooks.h"' -c cmm/MachOp.hs -o stage2/cmm/MachOp.o -ohi stage2/cmm/MachOp.hi /tmp/ghc32662.hc: In function `s5dU_ret': /tmp/ghc32662.hc:11210: Internal compiler error in `build_insn_chain', at global.c:1756 The dying gcc command: gcc -x c cmm/MachOp.hc -o /tmp/ghc15388.raw_s -DDONT_WANT_WIN32_DLL_SUPPORT -fno-defer-pop -fomit-frame-pointer -fno-builtin -DSTOLEN_X86_REGS=4 -S -Wimplicit -O -D__GLASGOW_HASKELL__=604 -ffloat-store -I cmm -I stage2 -I . -I codeGen -I nativeGen -I parser -I /var/tmp/ghc-6.4.20050216/libraries/readline/include -I /var/tmp/ghc-6.4.20050216/libraries/unix/include -I /var/tmp/ghc-6.4.20050216/libraries/base/include -I /var/tmp/ghc-6.4.20050216/ghc/includes The (naively) relevant part of the generated HC-file appears to be the next "function" (with some code which doesn't seem to matter for the crash removed). I have no idea whether this is of any help for nailing this kind of nastiness down, so I'm not going to spend more of my night on it ;) I did attach the complete failing HC-file. Greetings, Remi // compile The Killing Line #define BAR 1 IF_(s5dU_ret) { W_ _c5ec; FB_ #if BAR if (_c5ec < 0x5) goto _c5en; #endif _c5eo: _c5eu: R1.p = (P_)(W_)GHCziBase_True_closure; Sp=Sp+1; JMP_((*((P_)((*Sp) + (-0x14)))) + (*Sp)); _c5en: switch (_c5ec) { case 0x0: goto _c5eo; case 0x1: goto _c5eo; case 0x2: goto _c5eu; case 0x3: goto _c5eo; case 0x4: goto _c5eo; } FE_ } -- Nobody can be exactly like me. Even I have trouble doing it.
rturk:
[Resent, with a few #ifdef FOO's removed from the body (still in the attachement, and using gzip instead of bzip2 to prevent "awaiting moderation ;)]
On Thu, Feb 17, 2005 at 11:29:41AM -0000, Simon Marlow wrote:
On 17 February 2005 11:12, Remi Turk wrote:
when compiling the new ghc pre-releases made my gcc 2.95.3 die with "internal compiler error", I tried to compile it with gcc 3.4.3 (or rather, I thought it compiled with 3.4.1, and when that died, compiled+installed gcc 3.4.3, tried again, say it die again and only then noticed it was actually still using 2.95.3 ;) but had quite some difficulty to actually get it to compile with, in my case, /usr/local/bin/gcc3
When using the following command-line
CC=gcc3 CXX=g++3 nice ./configure --enable-hopengl --prefix=/var/tmp/ghc --with-gcc=/usr/local/bin/gcc3
stage1 still used gcc 2.95.3 to compile stage2 (okay, for --with-gcc that's documented)
Really? --with-gcc should set the gcc for stage1, AFAIK. Is there a bug here?
I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x.
Cheers, Simon
In case you've got nothing else left to do.. ;)
The ghc command which perfectly repeatable kills gcc:
make[2]: Entering directory `/var/tmp/ghc-6.4.20050216/ghc/compiler' ../../ghc/compiler/stage1/ghc-inplace -H16m -O -istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn -istage2/specialise -istage2/simplCore -istage2/stranal -istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -istage2/profiling -istage2/parser -istage2/cprAnalysis -istage2/compMan -istage2/ndpFlatten -istage2/iface -istage2/cmm -istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-haskell -package unix -package readline -DUSE_READLINE -package Cabal -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -recomp -Rghc-timing -H16M '-#include "hschooks.h"' -c cmm/MachOp.hs -o stage2/cmm/MachOp.o -ohi stage2/cmm/MachOp.hi /tmp/ghc32662.hc: In function `s5dU_ret': /tmp/ghc32662.hc:11210: Internal compiler error in `build_insn_chain', at global.c:1756
This is a known problem with gcc-2.95. We came across it back in September. It was noticed in the nightly builds: http://www.haskell.org/pipermail/cvs-all/2004-September/035116.html And then we chased it up: http://www.haskell.org/pipermail/cvs-all/2004-September/035122.html http://www.haskell.org/pipermail/cvs-all/2004-September/035134.html http://www.haskell.org/pipermail/cvs-all/2004-September/035259.html http://www.haskell.org/pipermail/cvs-all/2004-September/035268.html http://www.haskell.org/pipermail/cvs-all/2004-September/035293.html The bug was dealt with in gcc-3.01 I think, and upgrading to gcc-3.3x certainly stopped it occuring in the OpenBSD nightly builds. Try adding: --with-gcc=gcc-3.x Works for me. If you really need gcc-2.95, then constructing a patch along the lines of the one proposed to solve the test case should probably do it, though it would be a pain. -- Don
On Fri, Feb 18, 2005 at 12:02:06PM +1100, Donald Bruce Stewart wrote:
rturk:
In case you've got nothing else left to do.. ;)
The ghc command which perfectly repeatable kills gcc:
This is a known problem with gcc-2.95. We came across it back in September.
It was noticed in the nightly builds: http://www.haskell.org/pipermail/cvs-all/2004-September/035116.html
And then we chased it up: http://www.haskell.org/pipermail/cvs-all/2004-September/035122.html http://www.haskell.org/pipermail/cvs-all/2004-September/035134.html http://www.haskell.org/pipermail/cvs-all/2004-September/035259.html http://www.haskell.org/pipermail/cvs-all/2004-September/035268.html http://www.haskell.org/pipermail/cvs-all/2004-September/035293.html Ah, it's nice to see I was on the right track though ;)
The bug was dealt with in gcc-3.01 I think, and upgrading to gcc-3.3x certainly stopped it occuring in the OpenBSD nightly builds. Try adding: --with-gcc=gcc-3.x
Works for me. If you really need gcc-2.95, then constructing a patch along the lines of the one proposed to solve the test case should probably do it, though it would be a pain.
-- Don
I already succeeded in compiling it with 3.4.3, but thanks anyway. It was merely an attempt to help Simon a little:
On Thu, Feb 17, 2005 at 11:29:41AM -0000, Simon Marlow wrote:
I've noticed gcc 2.95 crashing on my FreeBSD box too. I should look into whether there's a workaround, otherwise we're hosed on FreeBSD 4.x.
(though I now assume it probably isn't even the same bug?) Cheers, Remi -- Nobody can be exactly like me. Even I have trouble doing it.
participants (4)
-
dons＠cse.unsw.edu.au -
Remi Turk -
Seth Kurtzberg -
Simon Marlow