[llvm-dev] returns_twice / noreturn

Johannes Doerfert via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 6 11:30:32 PST 2017


On 11/05, Sanjoy Das via llvm-dev wrote:
> On Fri, Nov 3, 2017 at 6:06 PM, Hal Finkel via llvm-dev
> > That's correct. The relevant semantics here come from C's setjmp/longjmp,
> > and there's an exception in that language to deal with this situation:
> >
> > 7.13.2.1p3: "All accessible objects have values, and all other components of
> > the abstract machine have state, as of the time the longjmp function was
> > called, except that the values of objects of automatic storage duration that
> > are local to the function containing the invocation of the corresponding
> > setjmp macro that do not have volatile-qualified type and have been changed
> > between the setjmp invocation and longjmp call are indeterminate."
> >
> > We should probably import some version of this into the LangRef to
> > more-accurately describe returns_twice/noreturn (because that's what we
> > actually implement in this regard).
> 
> We do not implement that restricted semantics correctly either -- see
> https://bugs.llvm.org/show_bug.cgi?id=27190
> 
> IMO the Right(TM) fix is to add a CFG edge from all possibly
> longjmp'ing function calls to all setjmps in a function.  We can
> probably do this by modeling the possibly longjmp'ing calls as invokes
> that unwind to a special "setjmp" landingpad.

Is the idea to encode all dynamic execution traces statically in the
CFG?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: Digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171106/b48fc4c8/attachment.sig>


More information about the llvm-dev mailing list