Link with correct values-*.o files on Solaris (PR target/40411)

On Solaris, gcc has long failed to enable libc's C99 mode as documented
in PR target/40411.  To do so, one needs to link with a values-xpg6.o
file provided by the system.  That file defines a __xpg6 variable in a
way which lets libc (and in some cases libm) select between C99 and
non-C99 behaviour at runtime.

This failure causes lots of problems for users and has become worse
since GCC 5 which enables -std=gnu11 by default, requiring C99 behaviour
without any special options.  We also have two testcases that are
xfail'ed because of this issue.

The fix in itself is trivial, but has long been highly contentious
because it affects even shared libraries that are compiled as (and may
even require) C90 mode.  However, there's nothing to be done about that
since this is how Solaris' C99 mode selection works, and the alternative
(not enabling it all or leaving linking some weird object to the users)
are far worse.

At the same time, I had a new look at when values-Xc.o is used by the
Studio compilers.  It selects strict ISO C mode in a couple of cases,
and the latest Studio 12.6 cc, which is about to do away with the
previous -Xc option which enabled that mode in favour of gcc-compatible
-pedantic, uses the latter to control its use.  So I've changed gcc to
follow suit.

Given that only one instance of the __xpg6 etc. variables take effect
per process, I'm only linking the values-*.o files into executable
programs, not shared libraries.

Versions of this patch have long been in the Solaris userland and
OpenIndiana oi-userland repos with no ill effect, and the current one
has been bootstrapped on the whole range of Solaris targets
(*86*-pc-solaris2.1[01] and sparc*-sun-solaris2.1[01]) without
regressions.

The STARTFILE_ARCH_SPEC comment is losely based on one from the Solaris
userland repo patch, but heavily reworked, clarified and extended.
Also, to the best of my knowledge Oracle has a corporate copyright
assignment in place, so this shouldn't be a problem anyway.

Installed on mainline.

	Rainer

On Fri, 12 Jan 2018, Rainer Orth wrote:

> At the same time, I had a new look at when values-Xc.o is used by the
> Studio compilers.  It selects strict ISO C mode in a couple of cases,
> and the latest Studio 12.6 cc, which is about to do away with the
> previous -Xc option which enabled that mode in favour of gcc-compatible
> -pedantic, uses the latter to control its use.  So I've changed gcc to
> follow suit.

gcc -pedantic is only ever a diagnostic option, not a semantic one; it's 
incorrect to use it to change library semantics.  The relevant options for 
strict ISO C (and C++) modes are -ansi, -std=c*, -std=iso9899:199409 and 
aliases for those options.

-ansi is not defined as a .opt alias of -std=c90 (because the option it's 
an alias for depends on whether C or C++ is being compiled), so I'd expect 
the specs to need to handle it along with -std=c90.  I'd also expect 
-std=iso9899:199409 to need to be handled there, supposing handling it 
like -std=c90 is correct.  And what about C++ versions not based on C99 or 
later?

Hi Joseph,

> On Fri, 12 Jan 2018, Rainer Orth wrote:
>
>> At the same time, I had a new look at when values-Xc.o is used by the
>> Studio compilers.  It selects strict ISO C mode in a couple of cases,
>> and the latest Studio 12.6 cc, which is about to do away with the
>> previous -Xc option which enabled that mode in favour of gcc-compatible
>> -pedantic, uses the latter to control its use.  So I've changed gcc to
>> follow suit.
>
> gcc -pedantic is only ever a diagnostic option, not a semantic one; it's 
> incorrect to use it to change library semantics.  The relevant options for 
> strict ISO C (and C++) modes are -ansi, -std=c*, -std=iso9899:199409 and 
> aliases for those options.

that's what you get for changing your code at the eleventh hour ;-)
Before introducing -pedantic, I had

#define STARTFILE_ARCH_SPEC \
  "%{ansi|std=c90|std=iso9899\\:199409:values-Xc.o%s; :values-Xa.o%s} \

(which isn't correct either since it only handled C90 and C94).  I don't
think you need to handle the aliases explicitly: last time I checked
they never arrive in specs.

Prompted by the realization that -ansi applies to both C and C++ and I
only meant to affect C, I had a look at what the (then recently
released) Studio 12.6 compilers do, which strive for more GCC
compatibility.

I've now also checked the OpenSolaris libc and libm sources for uses of
_lib_version == strict_ansi (as is set in values-Xc.o).  libc has none,
and the uses in libm all follow this pattern (ignoring C Issue 4.2
compatibility mode handling no longer activated):

		if (lib_version == strict_ansi) {
			errno = EDOM;
		} else if (!matherr(&exc)) {
			errno = EDOM;
		}

The default implementation of matherr (overridable by the user) just returns 0.

So it seems the following snippet

#define STARTFILE_ARCH_SPEC \
[...]
     %{std=c9*|std=iso9899\\:199409|std=c1*:values-Xc.o%s; :values-Xa.o%s} \

seems like the right thing to do, as you said.

> -ansi is not defined as a .opt alias of -std=c90 (because the option it's 
> an alias for depends on whether C or C++ is being compiled), so I'd expect 
> the specs to need to handle it along with -std=c90.  I'd also expect 
> -std=iso9899:199409 to need to be handled there, supposing handling it 
> like -std=c90 is correct.  And what about C++ versions not based on C99 or 
> later?

I'm of mixed minds about whether or not to include -ansi in the above
list: for C it's correct, for C++ it's less clear.  AFAIK there's no way
to distinguish between different languages in specs (like via an -x
<lang> switch always passed in).  OTOH, it has always been there already.

The following patch implements the above with corresponding comment
adjustments.  I'm open to suggestions what to do about -ansi.

	Rainer

On Tue, 30 Jan 2018, Rainer Orth wrote:

> So it seems the following snippet
> 
> #define STARTFILE_ARCH_SPEC \
> [...]
>      %{std=c9*|std=iso9899\\:199409|std=c1*:values-Xc.o%s; :values-Xa.o%s} \
> 
> seems like the right thing to do, as you said.

That version would need updating when we add -std=c2x (once there's a C2x 
working draft with features being added to it).  If you use std=c* instead 
of separate std=c9* and std=c1* you'd avoid needing such a change - but 
then of course it would cover -std=c++* for C++.

Hi Joseph,

> On Tue, 30 Jan 2018, Rainer Orth wrote:
>
>> So it seems the following snippet
>> 
>> #define STARTFILE_ARCH_SPEC \
>> [...]
>>      %{std=c9*|std=iso9899\\:199409|std=c1*:values-Xc.o%s; :values-Xa.o%s} \
>> 
>> seems like the right thing to do, as you said.
>
> That version would need updating when we add -std=c2x (once there's a C2x 
> working draft with features being added to it).  If you use std=c* instead 
> of separate std=c9* and std=c1* you'd avoid needing such a change - but 
> then of course it would cover -std=c++* for C++.

I know, that why I used the current form.  Admittedly it's a maintenance
problem (likely to be forgotten in the future).  If we add in -ansi, we
can just as well add -std=c++* (thus -std=c*), too.

I guess that's the safest option overall, unless Jonathan has objections
from a C++ standards perspective.

	Rainer

On 30/01/18 15:51 +0100, Rainer Orth wrote:
>Hi Joseph,
>
>> On Tue, 30 Jan 2018, Rainer Orth wrote:
>>
>>> So it seems the following snippet
>>>
>>> #define STARTFILE_ARCH_SPEC \
>>> [...]
>>>      %{std=c9*|std=iso9899\\:199409|std=c1*:values-Xc.o%s; :values-Xa.o%s} \
>>>
>>> seems like the right thing to do, as you said.
>>
>> That version would need updating when we add -std=c2x (once there's a C2x
>> working draft with features being added to it).  If you use std=c* instead
>> of separate std=c9* and std=c1* you'd avoid needing such a change - but
>> then of course it would cover -std=c++* for C++.
>
>I know, that why I used the current form.  Admittedly it's a maintenance
>problem (likely to be forgotten in the future).  If we add in -ansi, we
>can just as well add -std=c++* (thus -std=c*), too.
>
>I guess that's the safest option overall, unless Jonathan has objections
>from a C++ standards perspective.

No objections from me, I'm happy either way.

Hi Jonathan,

> On 30/01/18 15:51 +0100, Rainer Orth wrote:
>>Hi Joseph,
>>
>>> On Tue, 30 Jan 2018, Rainer Orth wrote:
>>>
>>>> So it seems the following snippet
>>>>
>>>> #define STARTFILE_ARCH_SPEC \
>>>> [...]
>>>>      %{std=c9*|std=iso9899\\:199409|std=c1*:values-Xc.o%s; :values-Xa.o%s} \
>>>>
>>>> seems like the right thing to do, as you said.
>>>
>>> That version would need updating when we add -std=c2x (once there's a C2x
>>> working draft with features being added to it).  If you use std=c* instead
>>> of separate std=c9* and std=c1* you'd avoid needing such a change - but
>>> then of course it would cover -std=c++* for C++.
>>
>>I know, that why I used the current form.  Admittedly it's a maintenance
>>problem (likely to be forgotten in the future).  If we add in -ansi, we
>>can just as well add -std=c++* (thus -std=c*), too.
>>
>>I guess that's the safest option overall, unless Jonathan has objections
>>from a C++ standards perspective.
>
> No objections from me, I'm happy either way.

thanks.  So I've opted to include -ansi for C++ backwards compatibility
and thus -std=c* for ease of maintenance.

Here's what I've commited after another round of testing.

	Rainer