[cfe-dev] last statement of a basic block
Rajendra
rks at cse.iitb.ac.in
Tue Jan 29 21:52:28 PST 2013
Hi,
How do we know last statement of a basic block both in case of
terminator and without terminator?
e.g.
int x, y, z;
x = 10;
y = 0;
if (x > 0)
z = 1;
else
z = 0;
I want to know if y = 0; is last statement in basic block (excluding
condition x > 0 in this block).
Also, z = 1; or z = 0; are last statements in their respective basic
blocks.
- Rajendra
On 30-01-2013 06:21 AM, cfe-dev-request at cs.uiuc.edu wrote:
> Send cfe-dev mailing list submissions to
> cfe-dev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> or, via email, send a message with subject or body 'help' to
> cfe-dev-request at cs.uiuc.edu
>
> You can reach the person managing the list at
> cfe-dev-owner at cs.uiuc.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cfe-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: BUG: VarDecl::getSourceRange() incorrect if CallInit
> style used for builtin type. (Richard Smith)
> 2. Re: BUG: VarDecl::getSourceRange() incorrect if CallInit
> style used for builtin type. (Will Wilson)
> 3. PR15105: __attribute__((noreturn)) and noreturn function
> types (Richard Smith)
> 4. Re: PR15105: __attribute__((noreturn)) and noreturn function
> types (Sean Silva)
> 5. Re: PR15105: __attribute__((noreturn)) and noreturn function
> types (Richard Smith)
> 6. Re: PR15105: __attribute__((noreturn)) and noreturn function
> types (John McCall)
>
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 29 Jan 2013 15:19:32 -0800
> From: Richard Smith <richard at metafoo.co.uk>
> To: Will Wilson <will at indefiant.com>
> Cc: cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] BUG: VarDecl::getSourceRange() incorrect if
> CallInit style used for builtin type.
> Message-ID:
> <CAOfiQqmAjUv4oBXMgx2t2+zskAKnyKNXekJvSerWmBuhNXftag at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> See this thread:
>
>
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120709/060344.html
>
> and particularly:
>
>
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120709/060465.html
>
> On Tue, Jan 29, 2013 at 2:53 PM, Will Wilson <will at indefiant.com>
> wrote:
>> Hi All,
>>
>> I've been digging into a bug that appears when call-style
>> initializers are
>> used for builtin types. For example:
>>
>> int g_foo(1);
>>
>> Results in an initializer that is solely an IntegerLiteral - the
>> ParenListExpr that originally surrounded it is lost during
>> Sema::AddInitializerToDecl(). This unfortunately also loses the end
>> location
>> for the final ')' and leads the VarDecl::getSourceRange() returning
>> the
>> location of the IntegerLiteral for the end location.
>>
>> What should be the correct approach here? Surely the ParenListExpr
>> should be
>> preserved in the AST? Or if it really is supposed to be folded away
>> at this
>> stage than how can we retain the end location for the expression?
>
> Using ParenListExpr is not appropriate -- that AST node is only
> intended for transient use, to represent a syntactic construct which
> we have not yet resolved to the right semantic node.
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 30 Jan 2013 00:40:51 +0100
> From: Will Wilson <will at indefiant.com>
> To: Richard Smith <richard at metafoo.co.uk>
> Cc: cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] BUG: VarDecl::getSourceRange() incorrect if
> CallInit style used for builtin type.
> Message-ID:
> <CAGdyRYqw+7v=vK0kFuJaBSULcggUH8LbfjiuGn_hdkQOKoY+Bw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On 30 January 2013 00:19, Richard Smith <richard at metafoo.co.uk>
> wrote:
>
>> See this thread:
>>
>>
>>
>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120709/060344.html
>>
>> and particularly:
>>
>>
>>
>> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120709/060465.html
>>
>>
> Thanks for the context on this Richard. It's a somewhat larger can of
> worms
> than I was expecting. I see you agreed with the CXXDirectInitExpr
> proposal
> from John McCall, but I have a suspicion it might be a fair bit of
> work to
> implement, integrate and test? That said, this is a fairly ugly
> problem for
> code refactoring currently - but not unsurmountable (I hope).
>
>
>> On Tue, Jan 29, 2013 at 2:53 PM, Will Wilson <will at indefiant.com>
>> wrote:
>> > Hi All,
>> >
>> > I've been digging into a bug that appears when call-style
>> initializers
>> are
>> > used for builtin types. For example:
>> >
>> > int g_foo(1);
>> >
>> > Results in an initializer that is solely an IntegerLiteral - the
>> > ParenListExpr that originally surrounded it is lost during
>> > Sema::AddInitializerToDecl(). This unfortunately also loses the
>> end
>> location
>> > for the final ')' and leads the VarDecl::getSourceRange()
>> returning the
>> > location of the IntegerLiteral for the end location.
>> >
>> > What should be the correct approach here? Surely the ParenListExpr
>> should be
>> > preserved in the AST? Or if it really is supposed to be folded
>> away at
>> this
>> > stage than how can we retain the end location for the expression?
>>
>> Using ParenListExpr is not appropriate -- that AST node is only
>> intended for transient use, to represent a syntactic construct which
>> we have not yet resolved to the right semantic node.
>>
>
> Fair enough. I think for now I'll attempt to hack around it but if
> that
> fails I may have to investigate doing it properly...
>
> - Will.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
> <http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20130130/da3e64d3/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 29 Jan 2013 15:41:34 -0800
> From: Richard Smith <richard at metafoo.co.uk>
> To: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>
> Subject: [cfe-dev] PR15105: __attribute__((noreturn)) and noreturn
> function types
> Message-ID:
> <CAOfiQqna3ymn-AbkLGLT6B9k6fhsFtxiji6Sq-_mCxxTdexMDw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> As PR15105 notes, our implementation of __attribute__((noreturn)) is
> not entirely GCC-compatible. As far as I can tell, the situation in
> GCC is:
>
> GCC does not have a plain 'noreturn function' type.
> __attribute__((noreturn)) on a function declaration makes that
> declaration declare a noreturn function. It does not affect the
> function's type.
> __attribute__((noreturn)) on a function pointer or function reference
> produces a 'pointer/reference to noreturn function' type.
> GCC allows implicit conversions in either direction between
> pointer-to-noreturn-function and pointer-to-function.
>
> In Clang:
>
> Clang *does* have a plain 'noreturn function' type.
> __attribute__((noreturn)) on a function declaration makes that
> declaration declare a noreturn function, and *adjusts the function
> type* to be a noreturn function.
> __attribute__((noreturn)) on a function pointer or function reference
> produces a 'pointer/reference to noreturn function' type.
> Clang allows a pointer-to-noreturn-function to implicitly convert to
> a
> pointer-to-function, but not vice versa.
>
> So... Clang's approach is more sound and type-safe, but it's not
> GCC-compatible. The difference reaches into the language semantics
> (C++ templates can tell the difference between noreturn and
> not-noreturn functions), and the ABI (GCC has a different mangling
> for
> pointer-to-noreturn-function which Clang does not implement).
>
> What do people think? Is our improved behavior here sufficient to
> justify the GCC incompatibility, or should we switch to being GCC
> compatible? Or pick some middle-ground -- perhaps we could continue
> to
> diagnose pointer-to-function to pointer-to-noreturn-function
> conversions, except where the source expression is directly taking
> the
> address of a noreturn function?
>
> Thanks!
> Richard
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 29 Jan 2013 19:13:15 -0500
> From: Sean Silva <silvas at purdue.edu>
> To: Richard Smith <richard at metafoo.co.uk>
> Cc: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>
> Subject: Re: [cfe-dev] PR15105: __attribute__((noreturn)) and
> noreturn
> function types
> Message-ID:
> <CAHnXoanBagg8e1xXpdzaofuVtgbT9z8g=mDmWzOoYCRCpJnE2w at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> How often does our "improved" behavior cause us to reject valid code?
>
> If this is causing problems for someone in the wild (the PR suggests
> that it is), IMO we should just be compatible with GCC.
>
> Since as you pointed out it has ABI and language semantics effects,
> incompatibility could have potentially serious consequences and the
> safest bet is to just be compatible.
>
> -- Sean Silva
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 29 Jan 2013 16:20:55 -0800
> From: Richard Smith <richard at metafoo.co.uk>
> To: Sean Silva <silvas at purdue.edu>
> Cc: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>
> Subject: Re: [cfe-dev] PR15105: __attribute__((noreturn)) and
> noreturn
> function types
> Message-ID:
> <CAOfiQq=mUBeo=0fNfJkh77OrAU=voW8M9CnXeNi9LtbmBs+jWw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Jan 29, 2013 at 4:13 PM, Sean Silva <silvas at purdue.edu>
> wrote:
>> How often does our "improved" behavior cause us to reject valid
>> code?
>
> That sounds very hard to quantify. But at least I don't believe
> anyone
> has ever encountered the name mangling issue in the wild and reported
> it as a bug.
>
>> If this is causing problems for someone in the wild (the PR suggests
>> that it is), IMO we should just be compatible with GCC.
>
> Well, there are a number of ways we could proceed. I'm currently
> swaying towards being largely GCC-compatible, but keeping our ban on
> implicitly converting pointer-to-function to
> pointer-to-noreturn-function (except in the cases where we can
> trivially see that the source is a noreturn function).
>
>> Since as you pointed out it has ABI and language semantics effects,
>> incompatibility could have potentially serious consequences and the
>> safest bet is to just be compatible.
>>
>> -- Sean Silva
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 29 Jan 2013 16:51:56 -0800
> From: John McCall <rjmccall at apple.com>
> To: Richard Smith <richard at metafoo.co.uk>
> Cc: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>
> Subject: Re: [cfe-dev] PR15105: __attribute__((noreturn)) and
> noreturn
> function types
> Message-ID: <033CF546-E1C6-4508-B63F-16F6B4DE8FEA at apple.com>
> Content-Type: text/plain; CHARSET=US-ASCII
>
> On Jan 29, 2013, at 3:41 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
>> As PR15105 notes, our implementation of __attribute__((noreturn)) is
>> not entirely GCC-compatible. As far as I can tell, the situation in
>> GCC is:
>>
>> GCC does not have a plain 'noreturn function' type.
>> __attribute__((noreturn)) on a function declaration makes that
>> declaration declare a noreturn function. It does not affect the
>> function's type.
>> __attribute__((noreturn)) on a function pointer or function
>> reference
>> produces a 'pointer/reference to noreturn function' type.
>> GCC allows implicit conversions in either direction between
>> pointer-to-noreturn-function and pointer-to-function.
>>
>> In Clang:
>>
>> Clang *does* have a plain 'noreturn function' type.
>> __attribute__((noreturn)) on a function declaration makes that
>> declaration declare a noreturn function, and *adjusts the function
>> type* to be a noreturn function.
>> __attribute__((noreturn)) on a function pointer or function
>> reference
>> produces a 'pointer/reference to noreturn function' type.
>> Clang allows a pointer-to-noreturn-function to implicitly convert to
>> a
>> pointer-to-function, but not vice versa.
>>
>> So... Clang's approach is more sound and type-safe, but it's not
>> GCC-compatible. The difference reaches into the language semantics
>> (C++ templates can tell the difference between noreturn and
>> not-noreturn functions), and the ABI (GCC has a different mangling
>> for
>> pointer-to-noreturn-function which Clang does not implement).
>>
>> What do people think? Is our improved behavior here sufficient to
>> justify the GCC incompatibility, or should we switch to being GCC
>> compatible? Or pick some middle-ground -- perhaps we could continue
>> to
>> diagnose pointer-to-function to pointer-to-noreturn-function
>> conversions, except where the source expression is directly taking
>> the
>> address of a noreturn function?
>
> We're not guided by language standards here, and GCC's model for this
> is quite bizarre, probably because of the internal representational
> issues.
> For example, they drop "noreturn" on member functions because
> volatile
> functions are valid there, and I assume they get the subtype
> relationship
> wrong because it's generally valid to add the volatile qualifier in
> a pointer conversion.
>
> If their model were any less broken, I might agree with the
> compatibility
> argument. As it is, it seems like a major drop in functionality for
> a pretty
> theoretical interoperation gain.
>
> That said, I see no reason not to adopt their mangling as a special
> case
> when mangling pointers and references to noreturn functions.
>
> John.
>
>
> ------------------------------
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> End of cfe-dev Digest, Vol 67, Issue 180
> ****************************************
More information about the cfe-dev
mailing list