I hit the -fno-common issue all the time with my own compiler, so I am happy to see gcc make this change; I’ll have a better argument to use when sending patches.

-fno-common has also revealed some hidden bugs in projects, where a define like PACKED is used after a struct specifier (intended to expand to __attribute__((packed))), but it never actually got defined. In addition to creating spurious global variables named PACKED, the structure does not end up getting packed as intended!

I have encountered people who think the change is bad since it breaks existing programs, so I want to point out that relying on this -fcommon behavior to merge definitions is not valid in any C standard. Each translation unit that includes a file with a declaration like int x; results in an external definition for that identifier, and identifiers with external linkage must have exactly one external definition (provided it is used somewhere in the program).

I wonder if sort’s version sort (e.g. sort -V) would be a better fix than the normalization of gcc versions in gcc-config. Also haven’t tried it, so no idea if it would work better.

This is the kind of prosaic scut work that never gets the glory, but is vital to keep things up to date and working smoothly. Excellent.

changing software version from 9 to 10 (…) [was] severe enough

Lol! From this wisdom, a less painful transition might be to first simulate gcc10 as a wrapper around gcc9, so to weed out any silly bugs first, before taking on the actual compiler bugs.

#!/bin/sh
if test "$1" = -dumpmachine; then
    exec echo 10
fi
exec gcc9 "$@"