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

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 21 January 2015 at 14:44, Renato Golin <renato.golin at linaro.org>
wrote:
> I'll bootstrap it with CMake and see what I get. Shouldn't we be
> moving to CMake based release anyway?
Hans,

CODE RED for ARMv7...

The buildbots are green on self-hosting because they're building with
-mfpu=vfpv3 and not NEON. When I bootstrapped the release, I was using
NEON and that's what killed it. We have a test-suite buildbot running
with NEON, but that wasn't enough to pick up the regression, as it
seemed only Clang was complex enough to show it.

Result: we have a serious code-generation problem with NEON and I have
no idea where it is... at least I know that it's after 3.5 and before
3.6 branch.

I'll start a bissect between 3.5 and 3.6, but given that this is a
self-hosting issue on an ARMv7 board, it could take days.

I don't want to delay the release even further, and I believe none of
the RC1 patches will make a difference, so Hans, please continue with
RC2 and I'll pick it up when I finish. Hopefully, I'll find the bug
before final.

Fingers crossed...

cheers,
--renato

PS: I'll add a slow self-hosting full buildbot with Thumb2+NEON to
cover the other bases we're not covering, and hopefully that'll help
with this issue in the future.

Hi,

On Mon, Jan 26, 2015 at 3:41 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 21 January 2015 at 14:44, Renato Golin <renato.golin at
linaro.org> wrote:
>> I'll bootstrap it with CMake and see what I get. Shouldn't we
be
>> moving to CMake based release anyway?
>
> Hans,
>
> CODE RED for ARMv7...
>
> The buildbots are green on self-hosting because they're building with
> -mfpu=vfpv3 and not NEON. When I bootstrapped the release, I was using
> NEON and that's what killed it. We have a test-suite buildbot running
> with NEON, but that wasn't enough to pick up the regression, as it
> seemed only Clang was complex enough to show it.
>
> Result: we have a serious code-generation problem with NEON and I have
> no idea where it is... at least I know that it's after 3.5 and before
> 3.6 branch.
I reported this some time ago, I guess you just missed it:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-December/079749.html

Regards,
ismail

On Mon, Jan 26, 2015 at 5:41 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 21 January 2015 at 14:44, Renato Golin <renato.golin at
linaro.org> wrote:
>> I'll bootstrap it with CMake and see what I get. Shouldn't we
be
>> moving to CMake based release anyway?
>
> Hans,
>
> CODE RED for ARMv7...
>
> The buildbots are green on self-hosting because they're building with
> -mfpu=vfpv3 and not NEON. When I bootstrapped the release, I was using
> NEON and that's what killed it. We have a test-suite buildbot running
> with NEON, but that wasn't enough to pick up the regression, as it
> seemed only Clang was complex enough to show it.
>
> Result: we have a serious code-generation problem with NEON and I have
> no idea where it is... at least I know that it's after 3.5 and before
> 3.6 branch.
>
> I'll start a bissect between 3.5 and 3.6, but given that this is a
> self-hosting issue on an ARMv7 board, it could take days.
>
> I don't want to delay the release even further, and I believe none of
> the RC1 patches will make a difference, so Hans, please continue with
> RC2 and I'll pick it up when I finish. Hopefully, I'll find the bug
> before final.
>
> Fingers crossed...
Huge thanks for figuring this out!

You're not delaying the release. Like you said, I plan to continue
with RC2 to get testing for the stuff we've merged (probably sometime
this week), and then we can hopefully get this fixed, do an RC3 and
then ship :)

Thanks,
Hans