llvm dev - Jan 2015 - [LLVMdev] [3.6 Release] RC1 has been tagged, Testing Phase I begins

On 15 January 2015 at 13:35, Renato Golin <renato.golin at linaro.org>
wrote:
> AArch64 tested and uploaded. ARMv7 in progress.
Hi Hans,

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. 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?

cheers,
--renato

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

> 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.

On 20 January 2015 at 18:55, Hans Wennborg <hans at chromium.org>
wrote:
> 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
None of that seems to be the culprit. I think the real problem here is
that the release scripts are building with autoconf and our buildbots
have migrated to CMake a few months ago.

I'll bootstrap it with CMake and see what I get. Shouldn't we be
moving to CMake based release anyway?

cheers,
--renato

On Wed, Jan 21, 2015 at 6:38 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 20 January 2015 at 18:55, Hans Wennborg <hans at chromium.org>
wrote:
>> 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?)
>
> None of that seems to be the culprit. I think the real problem here is
> that the release scripts are building with autoconf and our buildbots
> have migrated to CMake a few months ago.
>
> I'll bootstrap it with CMake and see what I get.
Thanks, let me know what you find out.
> Shouldn't we be
> moving to CMake based release anyway?
Oh, the joy of having two build systems. :-(

As long as we have  two, it doesn't really matter which one we use to
build the binaries, as users building from source will still rely on
both to be working.

 - Hans

> > Shouldn't we be
> > moving to CMake based release anyway?
> 
> Oh, the joy of having two build systems. :-(
> 
> As long as we have  two, it doesn't really matter which one we use to
> build the binaries, as users building from source will still rely on
> both to be working.
> 
>  - Hans
On that subject, are you aware that the release builds for linux don't build
compiler-rt for any target other than x86/x86_64? I noticed it today when I
tried the address sanitizer for Mips and found I didn't have the runtime.

It seems that targets have to be explicitly enabled in
tools/clang/runtime/compiler-rt/Makefile.

On 19 January 2015 at 10:25, Renato Golin <renato.golin at linaro.org>
wrote:
> Phase 1 passes check-all with flying colours, while Phase 2 fails *a
> lot* if C++ Clang tests with seg-faults in the parser. But this is
> something we're not seeing in the self-hosting buildbot for the same
> commit as 3.6 branched off of:
Sigh... Using CMake gets me the same problems. I have no idea what's
going on but that is not looking right.

I'll try to check out the first commit on 3.6.0 and see if that
builds. Then bisect.

cheers,
--renato