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

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

[Rainer Orth]

[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]

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

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


2017-01-10  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	gcc/testsuite:
	PR libfortran/67412
	* gfortran.dg/execute_command_line_2.f90: Remove dg-xfail-run-if
	on *-*-solaris2.10.

	libstdc++-v3:
	PR libstdc++/64054
	* testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc:
	Remove dg-xfail-run-if.

	gcc:
	PR target/40411
	* config/sol2.h (STARTFILE_ARCH_SPEC): Don't use with -shared or
	-symbolic.
	Use values-Xc.o for -pedantic.
	Link with values-xpg4.o for C90, values-xpg6.o otherwise.


[-- Attachment #2: sol2-values.patch --]
[-- Type: text/x-patch, Size: 3145 bytes --]

# HG changeset patch
# Parent  6c02c349f11cdd56ccf4666e36295538969b37d2
Link with correct values-xpg[46].o file on Solaris (PR target/40411)

diff --git a/gcc/config/sol2.h b/gcc/config/sol2.h
--- a/gcc/config/sol2.h
+++ b/gcc/config/sol2.h
@@ -169,9 +169,34 @@ along with GCC; see the file COPYING3.  
 #undef SUPPORTS_INIT_PRIORITY
 #define SUPPORTS_INIT_PRIORITY HAVE_INITFINI_ARRAY_SUPPORT
 
+/* Solaris libc and libm implement multiple behaviours for various
+   interfaces that have changed over the years in different versions of the
+   C standard.  The behaviour is controlled by linking corresponding
+   values-*.o objects.  Each of these objects contain alternate definitions
+   of one or more variables that the libraries use to select which
+   conflicting behaviour they should exhibit.  There are two sets of these
+   objects, values-X*.o and values-xpg*.o.
+
+   The values-X[ac].o objects set the variable _lib_version.  The Studio C
+   compilers use values-Xc.o with either -Xc or (since Studio 12.6)
+   -pedantic to select strictly conformant ISO C behaviour, otherwise
+   values-Xa.o.
+
+   The values-xpg[46].o objects define either or both __xpg[46] variables,
+   selecting XPG4 mode (__xpg4) and conforming C99/SUSv3 behavior (__xpg6).
+
+   Since GCC 5, gcc defaults to -std=gnu11 or higher, so we link
+   values-xpg6.o to get C99 semantics.  Besides, most of the runtime
+   libraries always require C99 semantics.
+
+   Since only one instance of _lib_version and __xpg[46] takes effekt (the
+   first in ld.so.1's search path), we only link the values-*.o files into
+   executable programs.  */
 #undef STARTFILE_ARCH_SPEC
-#define STARTFILE_ARCH_SPEC "%{ansi:values-Xc.o%s} \
-			    %{!ansi:values-Xa.o%s}"
+#define STARTFILE_ARCH_SPEC \
+  "%{!shared:%{!symbolic: \
+     %{pedantic:values-Xc.o%s; :values-Xa.o%s} \
+     %{std=c90|std=gnu90:values-xpg4.o%s; :values-xpg6.o%s}}}"
 
 #if defined(HAVE_LD_PIE) && defined(HAVE_SOLARIS_CRTS)
 #define STARTFILE_CRTBEGIN_SPEC "%{static:crtbegin.o%s; \
diff --git a/gcc/testsuite/gfortran.dg/execute_command_line_2.f90 b/gcc/testsuite/gfortran.dg/execute_command_line_2.f90
--- a/gcc/testsuite/gfortran.dg/execute_command_line_2.f90
+++ b/gcc/testsuite/gfortran.dg/execute_command_line_2.f90
@@ -1,5 +1,4 @@
 ! { dg-do run }
-! { dg-xfail-run-if "PR libfortran/67412" { *-*-solaris2.10 } }
 !
 ! Check that EXECUTE_COMMAND_LINE handles invalid command lines appropriately
 !
diff --git a/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
--- a/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/hexfloat.cc
@@ -1,6 +1,5 @@
 // { dg-do run { target c++11 } }
 // { dg-require-string-conversions "" }
-// { dg-xfail-run-if "PR libstdc++/64054" { *-*-solaris* } }
 // { dg-xfail-run-if "broken long double IO" { newlib_broken_long_double_io  } }
 
 // 2014-03-27 Rüdiger Sonderfeld

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

[Joseph Myers]

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?

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Rainer Orth]

[-- Attachment #1: Type: text/plain, Size: 3099 bytes --]

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

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


2018-01-29  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	PR target/40411
	* config/sol2.h (STARTFILE_ARCH_SPEC): Use -std=c9*,
	-std=iso9899:199409, -std=c1* instead of -pedantic to select
	values-Xc.o.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sol2-values-Xc.patch --]
[-- Type: text/x-patch, Size: 1271 bytes --]

# HG changeset patch
# Parent  85f8b72d36b77c99997c044e6383f825596017ad
Fix use of Solaris values-Xc.o (PR target/40411)

diff --git a/gcc/config/sol2.h b/gcc/config/sol2.h
--- a/gcc/config/sol2.h
+++ b/gcc/config/sol2.h
@@ -180,7 +180,9 @@ along with GCC; see the file COPYING3.  
    The values-X[ac].o objects set the variable _lib_version.  The Studio C
    compilers use values-Xc.o with either -Xc or (since Studio 12.6)
    -pedantic to select strictly conformant ISO C behaviour, otherwise
-   values-Xa.o.
+   values-Xa.o.  Since -pedantic is a diagnostic option only in GCC, we
+   need to specifiy the -std=c* options and -std=iso9899:199409.  -ansi is
+   omitted from that list to avoid influencing C++.
 
    The values-xpg[46].o objects define either or both __xpg[46] variables,
    selecting XPG4 mode (__xpg4) and conforming C99/SUSv3 behavior (__xpg6).
@@ -195,7 +197,7 @@ along with GCC; see the file COPYING3.  
 #undef STARTFILE_ARCH_SPEC
 #define STARTFILE_ARCH_SPEC \
   "%{!shared:%{!symbolic: \
-     %{pedantic:values-Xc.o%s; :values-Xa.o%s} \
+     %{std=c9*|std=iso9899\\:199409|std=c1*:values-Xc.o%s; :values-Xa.o%s} \
      %{std=c90|std=gnu90:values-xpg4.o%s; :values-xpg6.o%s}}}"
 
 #if defined(HAVE_LD_PIE) && defined(HAVE_SOLARIS_CRTS)

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

[Joseph Myers]

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++.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Rainer Orth]

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

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

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

[Jonathan Wakely]

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.

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

[Rainer Orth]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

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

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


2018-01-29  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	PR target/40411
	* config/sol2.h (STARTFILE_ARCH_SPEC): Use -std=c*,
	-std=iso9899:199409 instead of -pedantic to select values-Xc.o.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sol2-values-Xc.patch --]
[-- Type: text/x-patch, Size: 1307 bytes --]

# HG changeset patch
# Parent  53e957fef7f285d1a5bb84f370d5158d238b2ceb
Fix use of Solaris values-Xc.o (PR target/40411)

diff --git a/gcc/config/sol2.h b/gcc/config/sol2.h
--- a/gcc/config/sol2.h
+++ b/gcc/config/sol2.h
@@ -180,7 +180,10 @@ along with GCC; see the file COPYING3.  
    The values-X[ac].o objects set the variable _lib_version.  The Studio C
    compilers use values-Xc.o with either -Xc or (since Studio 12.6)
    -pedantic to select strictly conformant ISO C behaviour, otherwise
-   values-Xa.o.
+   values-Xa.o.  Since -pedantic is a diagnostic option only in GCC, we
+   need to specifiy the -std=c* options and -std=iso9899:199409.  We
+   traditionally include -ansi, which affects C and C++, and also -std=c++*
+   for consistency.
 
    The values-xpg[46].o objects define either or both __xpg[46] variables,
    selecting XPG4 mode (__xpg4) and conforming C99/SUSv3 behavior (__xpg6).
@@ -195,7 +198,7 @@ along with GCC; see the file COPYING3.  
 #undef STARTFILE_ARCH_SPEC
 #define STARTFILE_ARCH_SPEC \
   "%{!shared:%{!symbolic: \
-     %{pedantic:values-Xc.o%s; :values-Xa.o%s} \
+     %{ansi|std=c*|std=iso9899\\:199409:values-Xc.o%s; :values-Xa.o%s} \
      %{std=c90|std=gnu90:values-xpg4.o%s; :values-xpg6.o%s}}}"
 
 #if defined(HAVE_LD_PIE) && defined(HAVE_SOLARIS_CRTS)