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 <da...@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 jos...@codesourcery.com
