https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #11 from David Brown <david at westcontrol dot com> --- Reliance on -fcommon has not been correct or compatible with any C standard (I don't think it was even right for K&R C). If the code is written correctly (with at most one definition of all externally linked symbols) then -fcommon does not make it incorrect or conflict with the standards. But if your code requires -fcommon to compile correctly, it does not conform to C89 or anything newer. Personally, I'd like to see many old and dangerous C practices give errors by default. Along with common symbols, I'd include non-prototype function declarations and definitions, and calling functions without declaring them. These are the kind of thing you'd expect to see in pre-ANSI C - other than that, they are probably errors in the code. It is good that gcc still supports such code, but I think making them errors by default will reduce bugs in current code. And surely that is worth the cost of adding a "-fold-code" flag to ancient build recipes? (The "-fold-code" flag could probably also imply "-fno-strict-aliasing -fwrapv" to deal with other assumptions sometimes made in older code.) There is precedence for this. The default standard for gcc changed from "gnu89" to "gnu11". While most "gnu89" code will compile with the same semantics in "gnu11" mode, there are a fair number of incompatibilities. Changing the default to "-fno-common" (and ideally "-Werror=strict-prototypes -Werror=old-style-declaration -Werror=missing-parameter-type") would have a lot smaller impact than changing the default standard.
