3.6.1 Release Update

Hi,

I am no longer accepting new patch nominations for the 3.6.1 branches.
There are a handful of outstanding patches waiting for approval from
code owners, I may still merge these if I get code owner approval before
the start of 'official' testing.

We had originally planed to start 'official' testing today, however a regression
was found in the 3.6 branch, so I would like to delay testing until this is fixed.

Here is the regression: 23407 – Tests failing with 3.6.1

It looks like this was caused by r236066-r236068.

-Tom

I am no longer accepting new patch nominations for the 3.6.1 branches.
There are a handful of outstanding patches waiting for approval from
code owners, I may still merge these if I get code owner approval before
the start of 'official' testing.

Hi Tom,

Where's the list? Is there any ARM left?

Here is the regression: https://llvm.org/bugs/show_bug.cgi?id=23407
It looks like this was caused by r236066-r236068.

Is anyone looking at this? The bug is unassigned... Ahmed, can you have a look?

LowerCallTo has a comment that worries me:

/// FIXME: When all targets are
/// migrated to using LowerCall, this hook should be integrated into SDISel.

Does that mean if LowerCall is called directly, it won't fix the tail
call reusing the stack pointer? Can they be called interchangeably by
the same back-end on different occasions?

This may well be a red herring, though...

cheers,
--renato

> I am no longer accepting new patch nominations for the 3.6.1 branches.
> There are a handful of outstanding patches waiting for approval from
> code owners, I may still merge these if I get code owner approval before
> the start of 'official' testing.

Hi Tom,

Where's the list? Is there any ARM left?

LLVM:

#r232449 Need approval
#r232794 Need approval
#r233312 Need approval
#r235699 Need approval

CLANG:

# r232579 Need help merging this one.
# r228118 Need approval

LIBCXX ABI (All need approval):

r231839
r231852
r233984
r234254
r236299

None of these appear to be related to ARM.

> Here is the regression: 23407 – Tests failing with 3.6.1
> It looks like this was caused by r236066-r236068.

Is anyone looking at this? The bug is unassigned... Ahmed, can you have a look?

Not yet, I will try to follow up on this tomorrow.

LowerCallTo has a comment that worries me:

/// FIXME: When all targets are
/// migrated to using LowerCall, this hook should be integrated into SDISel.

Does that mean if LowerCall is called directly, it won't fix the tail
call reusing the stack pointer? Can they be called interchangeably by
the same back-end on different occasions?

Not sure, the tests only fail on i386. I can't reproduce on amd64.

-Tom

> Here is the regression: https://llvm.org/bugs/show_bug.cgi?id=23407
> It looks like this was caused by r236066-r236068.

Is anyone looking at this? The bug is unassigned... Ahmed, can you have a look?

Not yet, I will try to follow up on this tomorrow.

I tried to reproduce this morning on i386 (I did), I vaguely remember
seeing a cast assertion failure; I'll have a closer look tomorrow.

Note that the failing tests were added by those commits, so if this is
urgent, we can just revert both of them and be done with it.

-Ahmed

Also, what about the other failures? Ignoring the XPASS', there's:

    LLVM :: ExecutionEngine/RuntimeDyld/X86/MachO_x86-64_PIC_relocations.s

which isn't related to sret (and for which I can't really help).

-Ahmed

No, I believe that's due to r236068.

Lang, can you have a look at the 3.6.1. failure with that patch?

cheers,
--renato

#r232449 Need approval

This seems to be adding asserts and a new test. LGTM.

#r232794 Need approval

This is less clear, as is fixing an assert by making SCEV a bit
smarter (thus, maybe not removing the underlying reason for the assert
completely).

I'd prefer some SCEV expert to opine, keeping in mind that we don't
want APIs or ABIs to change.

#r233312 Need approval
#r235699 Need approval

These are dodgy. It doesn't seem to fix any serious problem, it
changes the behaviour of APInt, and it seems to be having trouble
getting it right.

I really want to let this one pass.

CLANG:

# r232579 Need help merging this one.

Did you merge r232454? If so, we need to revert, and reapply this one.
If not, I'd guess only applying it would work.

# r228118 Need approval

This looks like a new feature. If self contained, seems innocuous
enough to pass.

I'd prefer some OpenCL expert to opine.

LIBCXX ABI (All need approval):

r231839
r231852

LGTM.

r234254
r236299

Fixes for the above. LGTM.

r233984

New feature, but self-contained. LGTM.

cheers,
--renato

I apologize for missing this message.
All of these libc++abi changes are good to merge.

-- Marshall

> > > I am no longer accepting new patch nominations for the 3.6.1 branches.
> > > There are a handful of outstanding patches waiting for approval from
> > > code owners, I may still merge these if I get code owner approval
> before
> > > the start of 'official' testing.
> >
> > Hi Tom,
> >
> > Where's the list? Is there any ARM left?
> >
> >
>
> LLVM:
>
> #r232449 Need approval
> #r232794 Need approval
> #r233312 Need approval
> #r235699 Need approval
>
> CLANG:
>
> # r232579 Need help merging this one.
> # r228118 Need approval
>
> LIBCXX ABI (All need approval):
>
> r231839
> r231852
> r233984
> r234254
> r236299
>
>
I apologize for missing this message.
All of these libc++abi changes are good to merge.

No problem, you already approved these commits in a different thread :slight_smile:

These patches were merged prior to tagging -rc1.

-Tom