LLVM 3.2 failure

[Geoffrey Mainland]

Glad to know I'm not crazy...

There is already a ticket #7694 about the failure bootstrapping with
LLVM 3.2.

Also, Jan, could you send a fingerprint of your build tree? You can use
utils/fingerprint/fingerprint.py to generate one. If your tree works and
ours doesn't, that might help us narrow down the bug.

Thanks,
Geoff

On 03/14/2013 02:40 PM, Austin Seipp wrote:
> I was able to reproduce Geoffrey's failure on Mac OS X 10.8, with LLVM
> 3.2. The stage2 compiler eventually segfaults ("Segmentation Fault
> 11") during the build process after being compiled successfully with
> stage1.
>
> Something recently happened, because I was bootstrapping fine with
> LLVM 3.2 recently after David's fixes landed (I filed a small raft of
> tickets.) It's times like these I really wish we had a reliable 'git
> bisect'...
>
> I unfortunately haven't had time to dig into this, but I'll file a
> ticket to track it this morning. I can also reproduce this on my
> ARM/Linux machine. Previously, I got it to at least get done with
> stage2, and fail later in DPH. Now it seems to fail earlier in the
> same way the OS X build does.
>
> OS's:
>
> - 32bit ARM/Linux, Ubuntu 12.10 Linaro derivative; GCC 4.6.3.
> Bootstrapping compiler is GHC 7.4.1, LLVM 3.2.
> - 64bit OS X 10.8 Mountain Lion, llvm-gcc (XCode 4.6.) Bootstrapping
> compiler is GHC 7.6.2, LLVM 3.2.
>
> Also, @Jan: the warnings during the build process probably come from
> your bootstrap compiler. The built compiler (stage1/stage2) both
> support LLVM 3.2 directly and have correct version checks, but the
> bootstrap compiler you're using won't. In practice this mismatch never
> proved a problem in the past; just weeks ago the entire tree validated
> with the LLVM build on OS X with no failures and I was working on ARM
> things.
>
> I'll file a ticket and dig in soon when I get a chance.
>
> On Thu, Mar 14, 2013 at 9:29 AM, Geoffrey Mainland
<mainland at apeiron.net> wrote:
>> On 03/14/2013 02:15 PM, Jan Stolarek wrote:
>>>> Hm, you're sure that LLVM 3.2 is in your path when you configure GHC?
>>> I removed LLVM 3.0 from my system so there's no possibility of
>> mistaking 3.2 with 3.0. I'm also
>>> getting lots of compilation warnings about untested LLVM version -
>> this didn't happen with 3.0.
>>>
>>>> This is HEAD?
>>> Yes. Commit 56353e3da9d5718dfd25e25ccf61c78b25deefe8
>>>
>>>> Linux x64?
>>> Yes:
>>>
>>> [killy at xerxes : ~] uname -a
>>> Linux xerxes.discovery 2.6.37.6-24-desktop #1 SMP PREEMPT 2012-10-18
>> 22:36:08 +0200 x86_64 x86_64
>>> x86_64 GNU/Linux
>>>
>>>> What is in your build.mk file?
>>> The relevant parts are:
>>>
>>> BuildFlavour = quick-llvm
>>>
>>> ifeq "$(BuildFlavour)" "quick-llvm"
>>>
>>> SRC_HC_OPTS        = -H64m -O0 -fllvm
>>> GhcStage1HcOpts    = -O -fllvm
>>> GhcStage2HcOpts    = -O0 -fllvm
>>> GhcLibHcOpts       = -O -fllvm
>>> SplitObjs          = NO
>>> HADDOCK_DOCS       = NO
>>> BUILD_DOCBOOK_HTML = NO
>>> BUILD_DOCBOOK_PS   = NO
>>> BUILD_DOCBOOK_PDF  = NO
>>>
>>> endif
>>>
>>> As you can see I'm not building the documentation. It's because it
>> fails to build on my system and
>>> I don't care much about resolving that.
>>>
>>> Janek
>>
>> You don't have the following line?
>>
>> GhcLibWays = $(if $(filter $(DYNAMIC_BY_DEFAULT),YES),dyn,v)
>>
>> I ask because I am using a stock build.mk copied from build.mk.sample
>> with BuildFlavour = quick-llvm, GHC HEAD, and LLVM 3.2, and my stage2
>> compiler crashes. It would be good to know *exactly* what the contents
>> of your build.mk are.
>>
>> What version of GHC are you using to perform the build? Are you using
>> parallel make?
>>
>> Thanks,
>> Geoff