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