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

[Hans Wennborg]

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