[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] [LLVMdev] !!! 3.2 Release RC2 deadline November 29th
From:       John McCall <rjmccall () apple ! com>
Date:       2012-11-28 23:09:23
Message-ID: AE3D30CB-416E-45DA-B594-AB372ECCF6A1 () apple ! com
[Download RAW message or body]

On Nov 28, 2012, at 11:49 AM, David Chisnall <David.Chisnall@cl.cam.ac.uk> =
wrote:
> On 28 Nov 2012, at 19:41, Tanya Lattner wrote:
> =

>> So why isn't this caught by any of the regression testing (testsuite) if=
 it nothing above -O1 can be compiled? I assume you mean for your project?
> =

> Any Objective-C on non-Apple platforms that uses cleanups (including thos=
e Clang inserts for blocks) breaks in certain cases with inlining.  There a=
re also some cases in C++, and cases in LTO (or using C headers in C++) whe=
n C++ code and C code using __attribute__((cleanup)) are mixed.  We have an=
 ugly hack in clang that avoids it in the most common case, but there are a=
lmost certainly cases that we are not catching.  =

> =

>> I'm trying to understand how large of a problem this is. Ideally, we wan=
t everything we can to get fixed.. but since there is some confusion and de=
bate on this bug, I'm thinking its not a quick or easy fix.
> =

> There is no debate in the bug.  The consensus (both in the bug report and=
 in-person discussions at the DevMeeting) is that the inliner is doing an o=
bviously wrong thing when it takes a function containing a catchall and one=
 containing a cleanup, inlines one into the other, and ends up with one wit=
h just a cleanup.  The discussion in the bug report is due to the fact that=
 there are probably also some corner cases where the wrong thing happens, b=
ut the inliner bug is the serious one.

I absolutely agree that the inliner seems to be doing the wrong thing on yo=
ur testcases, but IIRC, your testcases were all hand-written IR, and the in=
liner seemed to be doing the right thing for your original source-code test=
case.  I don't know of a reason why that should matter, but I'm hesitant to=
 call this a release blocker if you can't duplicate this starting from sour=
ce code, because it's possible that the inliner is only broken on "unrealis=
tic" IR =97 which would still definitely be a bug, but not one that should =
hold up the release.

Just to be clear, anything that a major frontend like clang would emit for =
actual source code is ipso facto "realistic".  I'm just asking that you fin=
d a way to duplicate with ObjC source, not with hand-written IR.

John.
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]