last statement of a basic block

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

last statement of a basic block

Rajendra
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, [hidden email] wrote:

> Send cfe-dev mailing list submissions to
> [hidden email]
>
> 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
> [hidden email]
>
> You can reach the person managing the list at
> [hidden email]
>
> 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 <[hidden email]>
> To: Will Wilson <[hidden email]>
> Cc: [hidden email]
> Subject: Re: [cfe-dev] BUG: VarDecl::getSourceRange() incorrect if
> CallInit style used for builtin type.
> Message-ID:
> <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> To: Richard Smith <[hidden email]>
> Cc: [hidden email]
> Subject: Re: [cfe-dev] BUG: VarDecl::getSourceRange() incorrect if
> CallInit style used for builtin type.
> Message-ID:
> <CAGdyRYqw+7v=[hidden email]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On 30 January 2013 00:19, Richard Smith <[hidden email]>
> 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 <[hidden email]>
>> 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 <[hidden email]>
> To: "[hidden email] Developers" <[hidden email]>
> Subject: [cfe-dev] PR15105: __attribute__((noreturn)) and noreturn
> function types
> Message-ID:
> <[hidden email]>
> 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 <[hidden email]>
> To: Richard Smith <[hidden email]>
> Cc: "[hidden email] Developers" <[hidden email]>
> Subject: Re: [cfe-dev] PR15105: __attribute__((noreturn)) and
> noreturn
> function types
> Message-ID:
> <CAHnXoanBagg8e1xXpdzaofuVtgbT9z8g=[hidden email]>
> 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 <[hidden email]>
> To: Sean Silva <[hidden email]>
> Cc: "[hidden email] Developers" <[hidden email]>
> Subject: Re: [cfe-dev] PR15105: __attribute__((noreturn)) and
> noreturn
> function types
> Message-ID:
> <CAOfiQq=mUBeo=0fNfJkh77OrAU=[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Jan 29, 2013 at 4:13 PM, Sean Silva <[hidden email]>
> 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 <[hidden email]>
> To: Richard Smith <[hidden email]>
> Cc: "[hidden email] Developers" <[hidden email]>
> Subject: Re: [cfe-dev] PR15105: __attribute__((noreturn)) and
> noreturn
> function types
> Message-ID: <[hidden email]>
> Content-Type: text/plain; CHARSET=US-ASCII
>
> On Jan 29, 2013, at 3:41 PM, Richard Smith <[hidden email]>
> 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
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> End of cfe-dev Digest, Vol 67, Issue 180
> ****************************************
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev