Howdy,
I'm new to the list. I've been trying to build PD devel_0_39 on a linux box using scons and GCC without success.
I have been getting internal compiler floating point errors using both GCC 3.4.3 and GCC 4.0.0. at which point scons refuses to go any further.
Has anyone else experienced such difficulties?
The CPU on that machine is an AMD Athlon XP, if that is relevant.
I've run memory diagnostics on that machine (MEMTEST86) without reported errors.
I'm new to the list. I've been trying to build PD devel_0_39 on a linux box using scons and GCC without success.
I have been getting internal compiler floating point errors using both GCC 3.4.3 and GCC 4.0.0. at which point scons refuses to go any further.
can you post any details?
cheers ... tim
Tim Blechmann writes:
I'm new to the list. I've been trying to build PD devel_0_39 on a linux box using scons and GCC without success.
I have been getting internal compiler floating point errors using both GCC 3.4.3 and GCC 4.0.0. at which point scons refuses to go any further.
can you post any details?
cheers ... tim
Tim, Other interested persons -
At 03:20 PM 11/27/2005, Tim Blechman wrote:
I'm new to the list. I've been trying to build PD devel_0_39 on a linux box using scons and GCC without success.
I have been getting internal compiler floating point errors using both GCC 3.4.3 and GCC 4.0.0. at which point scons refuses to go any further.
can you post any details?
cheers ... tim
GCC 3.4.3 error report:
http://www.dolphin-speech.net/mike/errors-gcc343.lst
GCC 4.0.0 error report:
http://www.dolphin-speech.net/mike/errors-gcc400.lst
I don't know of any reason why I should be getting internal compiler errors trying to build this codebase, it doesn't make sense to me at all.
Michael A. Hobson The Dolphin Speech Project [No, I don't work with dolphins. See my web site for info.] web: http://www.dolphin-speech.net email: mhobson@dolphin-speech.net icq: #2186709 yahoo: warrior_mike2001
I have been getting internal compiler floating point errors using both GCC 3.4.3 and GCC 4.0.0. at which point scons refuses to go any further.
can you post any details?
cheers ... tim
GCC 3.4.3 error report:
http://www.dolphin-speech.net/mike/errors-gcc343.lst
GCC 4.0.0 error report:
http://www.dolphin-speech.net/mike/errors-gcc400.lst
I don't know of any reason why I should be getting internal compiler errors trying to build this codebase, it doesn't make sense to me at all.
can you compile anything? this looks like a compiler error ... did you try gcc 3.3?
tim
On Mon, 28 Nov 2005, Tim Blechmann wrote:
GCC 3.4.3 error report: http://www.dolphin-speech.net/mike/errors-gcc343.lst GCC 4.0.0 error report: http://www.dolphin-speech.net/mike/errors-gcc400.lst I don't know of any reason why I should be getting internal compiler errors trying to build this codebase, it doesn't make sense to me at all.
can you compile anything? this looks like a compiler error ... did you try gcc 3.3?
I should've said this: just because something is a bug in the compiler doesn't mean we don't have to take it into account. Trying to compile devel_0_39 with simd=1 seems to be really, really troublesome with most versions of GCC I encounter. Most people who come to me with problems compiling devel_0_39 have that compiler error problem, so I have to tell them to do scons simd=0, except that sometimes they're trying devel_0_39 *because* of SIMD.
And then, I tried using GCC 4.0.2 for a while, but encountered programs that wouldn't compile anymore and that looked like real trouble to get to compile with GCC 4.x, so I reverted to GCC 3.4, and then encountered fundamental incompatibilities in libstdc++... and I don't know how to keep libstdc++'s from conflicting, short of static linking.
I'd recommend that simd=1 only enables SIMD asm code, and that a new option moresimd=1 would enable GCC options for SIMD generation, and would default to moresimd=0 until versions of GCC that people can actually use also can compile with SIMD enabled!
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Trying to compile devel_0_39 with simd=1 seems to be really, really troublesome with most versions of GCC I encounter.
definitely odd, ive been able to compile with simd using GCC 3.4.4, 4.0.2, 4.1.0-beta20051125
most who had the errors were using Fedora and various RedHat derivatives, right? i know one user was able to solve the errors by switching to Ubuntu...
And then, I tried using GCC 4.0.2 for a while, but encountered programs that wouldn't compile anymore and that looked like real trouble to get to compile with GCC 4.x, so I reverted to GCC 3.4, and then encountered fundamental incompatibilities in libstdc++... and I don't know how to keep libstdc++'s from conflicting, short of static linking.
gentoo does a great job of this ( i have no idea how, but it just always works and compilers and glibc upgrades dont break stuff..) to switch between gcc's you'd eselect compiler list, then set
if you convinced everyone in your building to install distccd, installs would be faster than SuSE
I'd recommend that simd=1 only enables SIMD asm code, and that a new option moresimd=1 would enable GCC options for SIMD generation, and would default to moresimd=0 until versions of GCC that people can actually use also can compile with SIMD enabled!
this sounds awfully convoluted... SCons has a TryBuild() and other methods which could recompile without the offensive SIMD code if the compiler crashed...
On Fri, 30 Dec 2005, c wrote:
Trying to compile devel_0_39 with simd=1 seems to be really, really troublesome with most versions of GCC I encounter.
definitely odd, ive been able to compile with simd using GCC 3.4.4, 4.0.2, 4.1.0-beta20051125
Those are all really recent versions of GCC. I think the problems are with late 3.3, early 3.4, early 4.0, all three being slightly older GCC's. The problem is that those versions of GCC are still very much in use and will continue to be so for over a year.
most who had the errors were using Fedora and various RedHat derivatives, right?
No, I don't really recall all the distros involved, but sure was SuSE involved several times: Normand, Alx and I are three SuSE users.
gentoo does a great job of this ( i have no idea how, but it just always works and compilers and glibc upgrades dont break stuff..) to switch between gcc's you'd eselect compiler list, then set
(unfinished sentence?)
if you convinced everyone in your building to install distccd, installs would be faster than SuSE
What's that? Something like pymake? Anyhow, you're joking, I've seen gentoo, and with the small number of linux comps in my home these days, I can't see Gentoo _not_ taking an awful lot of time to compile.
this sounds awfully convoluted... SCons has a TryBuild() and other methods which could recompile without the offensive SIMD code if the compiler crashed...
There's a _big_ problem with that solution: if the compiler crashes in some place, then most likely the same bug causes some memory corruption that doesn't make the compiler crash, but instead corrupts the *.o files, and then there's nothing scons can do about it because it doesn't know.
At least, if the compiler crashes, the _whole_ build should be retried, and there should be a scons option anyway so that the user can override it in case corruption happens without a crash for some reason.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hi Matju,
GCC 3.4.3 error report: http://www.dolphin-speech.net/mike/errors-gcc343.lst GCC 4.0.0 error report: http://www.dolphin-speech.net/mike/errors-gcc400.lst I don't know of any reason why I should be getting internal compiler errors trying to build this codebase, it doesn't make sense to me at all.
can you compile anything? this looks like a compiler error ... did you try gcc 3.3?
I should've said this: just because something is a bug in the compiler doesn't mean we don't have to take it into account. Trying to compile devel_0_39 with simd=1 seems to be really, really troublesome with most versions of GCC I encounter. Most people who come to me with problems compiling devel_0_39 have that compiler error problem, so I have to tell them to do scons simd=0, except that sometimes they're trying devel_0_39 *because* of SIMD.
What kind of problems are those? They can't be related to the mentioned ones in the error reports above.
greetings, Thomas
On Mon, 2 Jan 2006, Thomas Grill wrote:
I should've said this: just because something is a bug in the compiler doesn't mean we don't have to take it into account. Trying to compile devel_0_39 with simd=1 seems to be really, really troublesome with most versions of GCC I encounter. [...]
What kind of problems are those? They can't be related to the mentioned ones in the error reports above.
When in SIMD mode, and only in SIMD mode, each *.c file is compiled using those settings:
-mfpmath=sse -mmmx -msse
Which is broken in many currently used versions of GCC.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hi Matju,
When in SIMD mode, and only in SIMD mode, each *.c file is compiled using those settings:
-mfpmath=sse -mmmx -msse
Which is broken in many currently used versions of GCC.
broken in which way? I think only -msse is actually needed for the simd build - this could be easily adjusted in the scons script.
greetings, Thomas
On Mon, 2 Jan 2006, Thomas Grill wrote:
When in SIMD mode, and only in SIMD mode, each *.c file is compiled using those settings: -mfpmath=sse -mmmx -msse Which is broken in many currently used versions of GCC.
broken in which way? I think only -msse is actually needed for the simd build
- this could be easily adjusted in the scons script.
Broken as in throws a FloatingPointException (signal 6, core dumped) in your face while trying to compile boring C code.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard schrieb:
On Mon, 2 Jan 2006, Thomas Grill wrote:
When in SIMD mode, and only in SIMD mode, each *.c file is compiled using those settings: -mfpmath=sse -mmmx -msse Which is broken in many currently used versions of GCC.
broken in which way? I think only -msse is actually needed for the simd build
- this could be easily adjusted in the scons script.
Broken as in throws a FloatingPointException (signal 6, core dumped) in your face while trying to compile boring C code.
Well then i'd say people should either change the compiler or not use SIMD.
greetings, Thomas
-
c -
Mathieu Bouchard -
Michael A. Hobson -
Thomas Grill -
Tim Blechmann