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

Message ID yddo9lzqtxy.fsf@CeBiTec.Uni-Bielefeld.DE
State New
Headers show
Series
  • Link with correct values-*.o files on Solaris (PR target/40411)
Related show

Commit Message

Rainer Orth Jan. 12, 2018, 9:59 a.m.
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

Comments

Joseph Myers Jan. 12, 2018, 5:46 p.m. | #1
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?
Rainer Orth Jan. 30, 2018, 2:02 p.m. | #2
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
Joseph Myers Jan. 30, 2018, 2:43 p.m. | #3
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++.
Rainer Orth Jan. 30, 2018, 2:51 p.m. | #4
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
Jonathan Wakely Jan. 30, 2018, 3:04 p.m. | #5
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.
Rainer Orth Jan. 30, 2018, 9:20 p.m. | #6
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

Patch

# 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