[llvm-commits] [llvm-gcc-4.2] r49171 - in /llvm-gcc-4.2/trunk/gcc: llvm-convert.cpp llvm-types.cpp

Duncan Sands baldrick at free.fr
Sun Apr 6 01:32:11 PDT 2008


Hi Chris,

> > (2) function bodies [this is fine] and (3) function declarations  
> > [which
> > I disagree with].  The problematic example is:
> 
> Ok.  I'm not sure why #3 is bad.  If the external function ever did  
> throw, badness would clearly happen :)

No, it is only bad if it throws *when called from this module*.  That is
the point.  This is already handled by marking *all calls in this module*
nounwind.

> > My take is that compiling with !flag_exceptions tells you something
> > about the functions in this module but nothing about functions not
> > in this module, so marking external functions nounwind is wrong.
> > (The fact that calls to them from this module do not throw is taken
> > care of by marking *calls* nounwind, which we now do).
> 
> Right.  However, I think that this should be handled in the linker.   
> When llvm-link'ing together a function prototype with anything else (a  
> prototype or definition) the possibility of throwing should always win  
> (in other words "resultnothrow = proto1nothrow & proto2nothrow").  If  
> we did this, I don't think there would be a problem.

There indeed wouldn't be a problem.  But what I don't understand is why
you guys think it makes sense to mark declarations of external functions
nounwind (because of !flag_exceptions) in the first place.

> No, two conflicting prototypes mean the dest prototype should be  
> allowed to throw.

That is the safe thing to do, and I have nothing against it.  However
it seems to me that this is just masking the fact that we have taught
llvm-gcc to produce bogus declarations.

> I tend to think that this should be handled in the linker.  Is there  
> any reason we can't do that?

Of course we can do that (and probably should do that as a way of
being nice to users), but is it really the "right thing to do" (tm)?

Ciao,

Duncan.



More information about the llvm-commits mailing list