[Bug middle-end/15486] [3.3/3.4/3.5] -fdata-sections moves common vars to .bss

[jifl-bugzilla at jifvik dot org]

------- Additional Comments From jifl-bugzilla at jifvik dot org  2004-08-18 01:39 -------
Richard Earnshaw gave a most helpful analysis describing the various linkage
models mentioned in 6.22 of the C99 standard rationale. I quote from there about
the relaxed ref/def model that GCC previously implemented: "The UNIX operating
system C compiler and linker implement this model, which is recognized as a
common extension to the C language (see §K.5.11). UNIX C programs which take
advantage of this model are standard conforming in their environment, but are
not maximally portable (not strictly conforming)."

In other words, the programs are indeed standard conforming, not "invalid".
Strict conformance is akin to -pedantic - preventing an extension.

Are you perhaps saying that 6.9 para 5 of C99 mandates only one definition?
Actually that does not follow, as that only applies if the object is declared
with an external definition. It does not apply, as in the "legacy" code in
question, if the object is always defined (therefore becomes common), and never
declared with extern. The standard does not mandate breaking such code.

The code I have isn't really legacy code - it's only a few years old and was
taken from BSD post-1999 even. At the very least to be completely pedantic about
standards conformance, and break compilation of such code which has been
deliberately been maintained to work to date goes against the GNU spirit of
making things work. Especially when the change is clearly unintentional. I've
even suggested what I believe to be a simple fix.

Breaking a large body of past code should not be something done lightly,
certainly not in a patch that doesn't mention it and was intended to fix other
issues; and it isn't a decision that should be taken by one person just in this
bug. At the very least there are other ramifications:

I suggest if Andrew wants this change to be permanent, he needs to submit a
change to the -fno-common, and __attribute__((nocommon)),
__attribute__((section(...))) documentation which are all clearly wrong if
common data is eliminated. There are also quite a few comments in GCC that need
to be fixed to reflect this proposed new reality; and some code that could
probably now be removed.

I've reopened this bug to indicate that either this issue is still live as gcc
should not be suddenly (and without warning or prior deprecation) breaking
common Unix code; or that someone needs to fix the documentation and other bits
as above. At least that way with a proposed doc patch, the removal of common
variable support can be brought to a wider audience than this bug report.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15486