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

[Duncan Sands]

Hi,

> > Marking function prototypes as nothrow and then fixing it up in the  
> > linker is more complicated and doesn't provide any value.  Dale,  
> > what do you think?
> 
> I think a point I made earlier has gotten lost:  it is not possible to  
> handle this without changing the linker.

I agree that the linker should also be changed to
(1) have definitions override declarations.  This is really important.
(2) "and" attributes together when merging two declarations.  This is
less important, but is more friendly towards users.

> No matter what you do in the compiler, you can create cases where a  
> function is marked unwind in some
> files and nounwind in other files.  The linker must know how to deal  
> with that.

Sure.

> The sensible way to deal with it, IMO, is for the   
> definition to win, which means the setting on the declarations is  
> irrelevant (unless you want to warn when they don't match, and  
> apparently you don't.)

I already gave an example that shows you have to be careful when
merging two declarations also.

> To me it does not make sense for the setting   
> on the calls and the declarations not to match, so I'd leave it this  
> way.

I gave an example showing why it can make perfect sense.  Being able
to mark a call nounwind is useful because it means: in this context
it is known that the call cannot unwind (due to special knowledge
coming from the front-end, or whatever; for example we used to do
this for calls in no-throw regions).  This seems a perfect match
with the -fexceptions case: in the context of this module we know
the call cannot unwind.  I find it very strange that you want to
mark declarations nounwind when in fact you don't know whether that
function can unwind in general or not (see example).  Maybe this is
the influence of Ada, where you can't have multiple declarations of
a function - there is only one, and it is accurate - while in C people
are more used to having bogus declarations and fixing them up.

> Also I am not interpreting -fno-exceptions the same way he is (much of  
> the difficulty here is the vague descriptions provided in the gcc  
> docs).   I think it means "this file does not have to deal with the  
> possibility that exceptions get thrown".

Since there is no difficulty in doing the slightly more general "this
file does not have to deal with the possibility that exceptions get
thrown or unwound *in this file*", why not do so?

Ciao,

Duncan.