https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> ---
I've started looking at this again.
Norm's patch has a few problems:
* For one, it matches a couple of alias names for -std values, which
will never hit the specs machinery.
* Worse, though: since gcc 5 changed its default to -std=gnu11 it
doesn't work without an explicit -std=* option given. Instead, one
has to handle it the other way round: use values-xpg4.o only with an
explicit -std=c90 or -std=gnu90, and values-xpg6.o otherwise.
That default is also necessary because many runtime libraries
(libstdc++, libgfortran, libgo, probably others) depend on C99
semantics by default, and there's no way of determining in specs which
language is being linked for.
The attached patch does this, and includes a forward port of Jeff's
patch to escape special characters like `:' in %{S:X} expressions.
It also removes the xfail from the libstdc++ test that requires C99
semantics from libc to work.
There's still more investigation to be done on my part, like
* when exactly values-X[ac].o are appropriate,
* what Studio 15.c cc/c89/c99, CC, f77/f90/f95 do in this space
Also, there's the issue of copyright: I suspect Jeff's patch is large
enough to require an assignment (which may be hard to get after 8 years,
unless he has one in place already ;-). If this proves impossible, one
could omit the handling for -std=iso9899:199409 for now, which is only a
niche case (or introduce -std=c94 and make -std=iso9899:199409 an alias
for that, but that would be an ugly hack).
The same might be true for Norm's comment in his patch, though I suspect
Oracle has a corporate assignment on file.
Given how late in the GCC 7 cycle we are, I fear it's becoming too late
to get this in; however I still wanted to keep the ball rolling.
Rainer
