On Tue, 2006-03-28 at 14:47 +0100, Simon Marlow wrote: > Duncan Coutts wrote: > > With last night's ghc 6.4.2 snapshot I still need this patch applied to > > fix building with make -j2 > > > > http://www.haskell.org//pipermail/cvs-ghc/2006-March/028982.html > > "mkDerivedConstants.c depends on ghcplatform.h" > > > > I think it should go to the STABLE ghc branch as well as HEAD. > > oops, thanks for the reminder. Now merged.
Ta. I've been testing yesterday's snapshot, ghc-6.4.2.20060372. It's building fine on amd64 & sparc. I'm getting mangler problems on ia64 which are new since 6.4.1 but probably related to existing ia64 mangler problems it's just we're now hitting them when building ghc itself rather than things like darcs. If you're interested I can give you the details but I suspect you're not ;-). I'll see if Matthew Chapman comes up with anything. I found that -O2-for-C/-optc-O2 breaks on sparc (makes genprimop segfault immediately on startup). That's not a bug of course, though it happens to work on x86/amd64. People do do this kind of thing despite the warnings: http://haskell.org/haskellwiki/Performance/GHC see "Crank up the gcc flags", "-optc-O3 -optc-ffast-math" :-) I'm currently testing a system in the Gentoo ghc ebuilds to pass a highly filtered set of the users' CFLAGS through to gcc via -optc/-opta/-optl as appropriate. This was requested by the Gentoo people who support the less common arches like sparc,mips,alpha etc. Their point was that it's important for some abi flags to be passed through to gcc or we'll end up using a different abi from the rest of the system. This is particularly true with mips which seems to have about half a dozen different possible ABIs including 32/64bit instructions, 32/64bit pointers and big/little endian. Crazy. A more sensible example is sparc where if you don't specify and -march= flag then gcc will generate code for the sparc v7 cpu generation which did not have integer or floating point multiplication/division instructions. So pretty much all sparc users have something like "-march=ultrasparc" in their CFLAGS. If we pass that through then we do get gcc emiting the new assembler instructions. On some apps this can make a big performance difference. The one most often quoted is OpenSSL which runs several times faster for some operations when compiled for the appropriate sparc CPU generation. So we're testing this code in ghc-6.4.1-r3.ebuild and ghc-6.4.2_pre200603XX.ebuild, hence my noticing that -O2 breaks sparc. -O2 also breaks ia64 by changing the assembly and upsetting the mangler. Both are now filtered out. Duncan _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
