[LLVMdev] [3.6 Release] RC1 has been tagged, Testing Phase I begins

[Duncan P. N. Exon Smith]

> On 2015 Jan 20, at 10:55, Hans Wennborg <hans at chromium.org> wrote:
> 
> On Mon, Jan 19, 2015 at 2:25 AM, Renato Golin <renato.golin at linaro.org> wrote:
>> ARMv7 is giving me a bit of a headache... I've tried building on two
>> different machines and I get the same error... Phase 2 completes
>> successfully, but while building Phase 3, I get the error on *every*
>> file:
>> 
>> 1.      /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c++/4.9/bits/ptr_traits.h:77:25:
>> at annotation token
>> 2.      /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c++/4.9/bits/ptr_traits.h:37:1:
>> parsing namespace 'std'
>> 3.      /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c++/4.9/bits/ptr_traits.h:73:5:
>> parsing struct/union/class body '__ptrtr_rebind_helper'
>> clang: error: unable to execute command: Bus error
>> clang: error: clang frontend command failed due to signal (use -v to
>> see invocation)
>> 
>> Phase 1 passes check-all with flying colours, while Phase 2 fails *a
>> lot* if C++ Clang tests with seg-faults in the parser.
> 
> At least having tests failing makes this easier.
> 
>> But this is
>> something we're not seeing in the self-hosting buildbot for the same
>> commit as 3.6 branched off of:
>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/2343
>> 
>> Could it be some of the merges later?
> 
> There weren't many merges between the branch point and the rc1 tag. They were:
> 
>  r226023 InstCombine: Don't take A-B<0 into A<B if A-B has other uses
>  r226029 IR: Fix a use-after-free in RAUW
>  r226044 IR: Drop metadata references more aggressively during teardown
>  r226046 IR: Always print MDLocation line
>  r226049 IR: Move MDLocation into place (clang testcases)
>  r226048 IR: Move MDLocation into place
>  r226058 IR: Fix comment spelling, NFC
> 
> Everything except the InstCombine one is Duncan's debug info/metadata
> stuff. Since this bootstrap build isn't using debug info, that just
> leaves the InstCombine change, which looks innocent in itself but
> maybe it is triggering some other problem (like PR22222?)
> 
> Would it be possible to revert that change locally, do the bootstrap
> and try some of the failing tests?
> 
> If that doesn't work, maybe revert the other chunk of patches and see
> if that helps. Or cherry-picking r226075 which is in the branch, but
> landed after rc1 was tagged. I don't have any ARM hardware to test on,
> so I'm afraid I can't help out much here myself :-/
> 
> Thanks,
> Hans

I agree with Hans that my changes seem somewhat unlikely to be the cause,
but if reverting them fixes it, please pull me in and I'll do what I can
to help.