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

[Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>]

[-- 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