LLVM 3.2 failure
Geoffrey Mainland
mainland at apeiron.net
Thu Mar 14 18:00:16 CET 2013
At least they didn't re-roll the release tarball a second time :)
Would be good to confirm that we built from the same source tree. I am
building LLVM HEAD right now and will try that with GHC.
Geoff
On 03/14/2013 04:54 PM, Austin Seipp wrote:
> The LLVM 3.2 tarball has an annoying bug: it specifies the version as
> '3.2svn' and not 3.2. So it's kind of difficult to distinguish them.
> You can verify this by downloading the 3.2 tarball from their website
> and looking at autoconf's AC_INIT line:
>
> $ pwd
> /Users/a/Downloads/llvm-3.2.src
> $ grep 3.2svn autoconf/configure.ac
> AC_INIT([LLVM],[3.2svn],[http://llvm.org/bugs/])
>
> It's likely Jan is using the right version. It's annoying as hell this
> bug is there, though* and LLVM developers don't generally do
> point-releases or update the tarballs. It's probably stuck like this
> until LLVM 3.3.
>
> * Any interested parties can find a patch for the 3.2 tarball here,
> but you'll of course have to apply manually and rebuild:
>
https://github.com/thoughtpolice/homebrew/blob/35d39a504e619a3443abae0e249b366cc0ae4428/Library/Formula/llvm.rb#L108
>
>
> On Thu, Mar 14, 2013 at 11:47 AM, Geoffrey Mainland
> <mainland at apeiron.net> wrote:
>> On 03/14/2013 04:40 PM, Jan Stolarek wrote:
>>>> If you type llc -version at the command line, it really says it's 3.2?
>>> You don't seem to believe me :)
>>
>> Given that Austin and I have the stage 2 compiler failure and you don't,
>> I think it is reasonable do double check :)
>>
>>> [killy at xerxes : ~] llc --version
>>> LLVM (http://llvm.org/):
>>> LLVM version 3.2svn
>>> Optimized build with assertions.
>>> Built Mar 14 2013 (09:02:06).
>>> Default target: x86_64-unknown-linux-gnu
>>> Host CPU: corei7
>>>
>>> Registered Targets:
>>> arm - ARM
>>> cellspu - STI CBEA Cell SPU [experimental]
>>> cpp - C++ backend
>>> hexagon - Hexagon
>>> mblaze - MBlaze
>>> mips - Mips
>>> mips64 - Mips64 [experimental]
>>> mips64el - Mips64el [experimental]
>>> mipsel - Mipsel
>>> msp430 - MSP430 [experimental]
>>> nvptx - NVIDIA PTX 32-bit
>>> nvptx64 - NVIDIA PTX 64-bit
>>> ppc32 - PowerPC 32
>>> ppc64 - PowerPC 64
>>> sparc - Sparc
>>> sparcv9 - Sparc V9
>>> thumb - Thumb
>>> x86 - 32-bit X86: Pentium-Pro and above
>>> x86-64 - 64-bit X86: EM64T and AMD64
>>> xcore - XCore
>>> [killy at xerxes : ~] opt --version
>>> LLVM (http://llvm.org/):
>>> LLVM version 3.2svn
>>> Optimized build with assertions.
>>> Built Mar 14 2013 (09:02:06).
>>> Default target: x86_64-unknown-linux-gnu
>>> Host CPU: corei7
>>>
>>> So at this point we are clearly dealing with a system-specific
>> problem. The possible differences
>>> that come to my mind are:
>>> - I'm using LLVM 3.2 compiled from source, while you might be using a
>> pre-built version from the
>>> repository
>>> - And I'm also using GHC 7.6.2 that I compiled by myself, instead of
>> pre-built binaries available
>>> at GHC web site. Are you using the binaries or do you also compiled
>> your GHC from sources?
>>>
>>> Janek
>>
>> I built LLVM 3.2 from source, but from the release tarball, not
>> subversion. Does your svn checkout correspond exactly to the source in
>> the 3.2 release tarball?
>>
>> I also built both GHC 7.4.2 and 7.6.2 from source (release tarballs),
>> both using the native back end. Since it's the stage 2 compiler that is
>> failing, it's difficult to see why this would matter.
>>
>> Geoff
More information about the ghc-devs
mailing list