On Tue, May 05, 2015 at 01:02:57PM +0100, Renato Golin wrote:> On 4 May 2015 at 21:55, Tom Stellard <tom at stellard.net> wrote: > > 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: 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.> 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> This may well be a red herring, though... > > cheers, > --renato
On Tue, May 5, 2015 at 6:21 PM, Tom Stellard <tom at stellard.net> wrote:>> > 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>> 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 > >> This may well be a red herring, though... >> >> cheers, >> --renato
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
On Tue, May 5, 2015 at 7:54 PM, Ahmed Bougacha <ahmed.bougacha at
gmail.com> wrote:> On Tue, May 5, 2015 at 6:21 PM, Tom Stellard <tom at stellard.net>
wrote:
>>> > 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
>
>>> 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
>>
>>> This may well be a red herring, though...
>>>
>>> cheers,
>>> --renato
On 6 May 2015 at 02:21, Tom Stellard <tom at stellard.net> wrote:> #r232449 Need approvalThis seems to be adding asserts and a new test. LGTM.> #r232794 Need approvalThis 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 approvalThese 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 approvalThis 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 > r231852LGTM.> r234254 > r236299Fixes for the above. LGTM.> r233984New feature, but self-contained. LGTM. cheers, --renato
On Tue, May 5, 2015 at 8:21 PM, Tom Stellard <tom at stellard.net> wrote:> On Tue, May 05, 2015 at 01:02:57PM +0100, Renato Golin wrote: > > On 4 May 2015 at 21:55, Tom Stellard <tom at stellard.net> wrote: > > > 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. -- Marshall -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150512/8cb9a4cd/attachment.html>
On Tue, May 12, 2015 at 09:47:47PM -0600, Marshall Clow wrote:> On Tue, May 5, 2015 at 8:21 PM, Tom Stellard <tom at stellard.net> wrote: > > > On Tue, May 05, 2015 at 01:02:57PM +0100, Renato Golin wrote: > > > On 4 May 2015 at 21:55, Tom Stellard <tom at stellard.net> wrote: > > > > 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 :) These patches were merged prior to tagging -rc1. -Tom> -- Marshall