Issue with LTO/-fwhole-program

[Joseph S. Myers]

On Mon, 14 Jun 2010, Dave Korn wrote:

> On 13/06/2010 23:20, Joseph S. Myers wrote:
> > On Sun, 13 Jun 2010, Dave Korn wrote:
> > 
> >> On 13/06/2010 20:55, Ian Lance Taylor wrote:
> >>> David Brown <david@westcontrol.com> writes:
> >>>
> >>>> If -flto were to activate the -fno-common flag, would that then catch 
> >>>> these potential problems with a linker error?
> >>> We could perhaps do that for C/C++ code, but Fortran relies on common 
> >>> symbols.
> >> Well we shouldn't do it for plain C either, or at the very least should make
> >> it depend on the -std= option in effect, but since the code is entirely valid
> >> and legitimate C, I think we should acknowledge this is a weakness in our
> >> compiler. The original testcase is a perfectly straightforward bit of C89;
> >> there are two compatible tentative declarations of a variable of type int
> >> called "v". We don't want to have to argue that one is in fact a variable of
> > 
> > This is not valid standard C; 
> 
>   Not valid *which standard* C?

Any standard C.  It is not valid C90 or C99.

> > you can have two tentative definitions in 
> > the same translation unit, but not in different translation units.  
> > Allowing commons is listed as a common extension in C90 G.5.11.
> 
>   So your objection is that it *is* valid after all?  I'm not following.  As

It is a common extension, not ISO C.  LTO of course should handle 
-fcommon, -fno-common, mixtures of them and the "common" and "nocommon" 
attributes, as part of handling all of GNU C.

> far as I remember that sort of thing, ropey though it seems nowadays, was
> always an accepted part of K'n'R C, which I thought was what C89 aimed to
> formalize.

The C89 Rationale lists various models used by different implementation in 
this area, and the Unix model it describes as "Relaxed Ref/Def" is not the 
one adopted by C89.

-- 
Joseph S. Myers
joseph@codesourcery.com