the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Dennis Clarke-2

This is a guess because I am not sure. However I did a quad[1] stage
bootstrap of 8.2.0 twice in the past week and saw reasonably good[2]
results. However I took the final result and dropped it on some
other machine and g++ stopped working with oddball messages thus:

/usr/include/math.h:45:12: error: 'std::float_t' has not been declared
  using std::float_t;
             ^~~~~~~

That caught me off guard entirely because the bootstrap4 host has
no problems at all.

So I then looked at my gcc 7.3.0 builds[3] and gave them a whirl on
these two host machines.  One of them was just fine and the other
had a similar issue :

/usr/local/gcc7/lib/gcc/sparc64-sun-solaris2.10/7.3.0/include-fixed/math.h:52:12:
error: 'std::float_t' has not been declared
  using std::float_t;
             ^~~~~~~

Strange. Even more strange the host that fails with 8.2.0 works just
fine with 7.3.0 however the other machine has opposite results.

I looked at my gcc 8.1.0 compiler[4] and saw this :

$ ls -l
/usr/local/gcc8/lib/gcc/sparc64-sun-solaris2.10/8.1.0/include-fixed/math.h
-rw-r--r--   1 root  bin  11133 May 11 09:04
/usr/local/gcc8/lib/gcc/sparc64-sun-solaris2.10/8.1.0/include-fixed/math.h


OKay ... however my 8.2.0 result has no such header file at all!

However it does exist in my previous 8.1.0 result as well as my 7.3.0
compiler :

$ ls -l
/usr/local/gcc7/lib/gcc/sparc64-sun-solaris2.10/7.3.0/include-fixed/math.h
-rw-r--r--   1 root bin 11133 Apr 16  2018
/usr/local/gcc7/lib/gcc/sparc64-sun-solaris2.10/7.3.0/include-fixed/math.h

However gcc 8.2.0 works fine on the host that did the bootstrap and
fails on some other machine.

The question has to be where do these "include-fixed" headers come
from? I am looking for an end point result that I know I can drop
on any similar machine and it will "just work"(tm).

Dennis

[1] seemed like a good idea to give a try ... bootstrap4

[2] https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg03050.html

[3] https://gcc.gnu.org/ml/gcc-testresults/2018-04/msg01455.html

[4] https://gcc.gnu.org/ml/gcc-testresults/2018-05/msg01368.html
Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Jonathan Wakely-4
On Wed, 24 Oct 2018 at 04:25, Dennis Clarke <[hidden email]> wrote:
> The question has to be where do these "include-fixed" headers come
> from?

The include-fixed headers are generated as part of the GCC build
process. The contents of the fixincludes dir in the GCC sources apply
a set of rules to fix known problems in the system headers (either
conformance bugs, or incompatibilities with GCC). That means the
include-fixed files are specific to the machine they were created for
(and any machines with the same set of headers).

> I am looking for an end point result that I know I can drop
> on any similar machine and it will "just work"(tm).

Generally "any similar machine" won't work, it needs to be exactly the
same, because otherwise differences in the libc headers cause this
kind of problem.
Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Jonathan Wakely-4
On Wed, 24 Oct 2018 at 09:53, Jonathan Wakely <[hidden email]> wrote:
>
> On Wed, 24 Oct 2018 at 04:25, Dennis Clarke <[hidden email]> wrote:
> > The question has to be where do these "include-fixed" headers come
> > from?
>
> The include-fixed headers are generated as part of the GCC build
> process. The contents of the fixincludes dir in the GCC sources apply
> a set of rules to fix known problems in the system headers (either
> conformance bugs, or incompatibilities with GCC).

This is (barely) documented at
https://gcc.gnu.org/onlinedocs/gccint/Headers.html
Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Marc Glisse-6
In reply to this post by Jonathan Wakely-4
On Wed, 24 Oct 2018, Jonathan Wakely wrote:

> On Wed, 24 Oct 2018 at 04:25, Dennis Clarke <[hidden email]> wrote:
>> The question has to be where do these "include-fixed" headers come
>> from?
>
> The include-fixed headers are generated as part of the GCC build
> process. The contents of the fixincludes dir in the GCC sources apply
> a set of rules to fix known problems in the system headers (either
> conformance bugs, or incompatibilities with GCC). That means the
> include-fixed files are specific to the machine they were created for
> (and any machines with the same set of headers).
>
>> I am looking for an end point result that I know I can drop
>> on any similar machine and it will "just work"(tm).
>
> Generally "any similar machine" won't work, it needs to be exactly the
> same, because otherwise differences in the libc headers cause this
> kind of problem.

I have old memories of people copying the compiler then rerunning just
fixincludes on the new machine. I see that we install fixincl and
fixinc.sh, possibly so we can rerun it when we update the system headers,
but it could also be used for the other machine.

--
Marc Glisse
Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Jonathan Wakely-4
On Wed, 24 Oct 2018 at 13:50, Marc Glisse wrote:

>
> On Wed, 24 Oct 2018, Jonathan Wakely wrote:
>
> > On Wed, 24 Oct 2018 at 04:25, Dennis Clarke <[hidden email]> wrote:
> >> The question has to be where do these "include-fixed" headers come
> >> from?
> >
> > The include-fixed headers are generated as part of the GCC build
> > process. The contents of the fixincludes dir in the GCC sources apply
> > a set of rules to fix known problems in the system headers (either
> > conformance bugs, or incompatibilities with GCC). That means the
> > include-fixed files are specific to the machine they were created for
> > (and any machines with the same set of headers).
> >
> >> I am looking for an end point result that I know I can drop
> >> on any similar machine and it will "just work"(tm).
> >
> > Generally "any similar machine" won't work, it needs to be exactly the
> > same, because otherwise differences in the libc headers cause this
> > kind of problem.
>
> I have old memories of people copying the compiler then rerunning just
> fixincludes on the new machine. I see that we install fixincl and
> fixinc.sh, possibly so we can rerun it when we update the system headers,
> but it could also be used for the other machine.

Ah yes, that sounds familiar to me too.

If the machines are hugely different things still won't work. For
example libstdc++ makes some decisions at build time and relies on
those still being available on the host machine later. Specifically,
if ::float_t is defined during the build libstdc++ will use it
unconditionally, so if it isn't present on the host machine later
(either in the host <math.h> or the include-fixed <math.h>) you'll
still get errors.
Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Dennis Clarke-2
In reply to this post by Jonathan Wakely-4
On 10/24/2018 05:04 AM, Jonathan Wakely wrote:

> On Wed, 24 Oct 2018 at 09:53, Jonathan Wakely <[hidden email]> wrote:
>>
>> On Wed, 24 Oct 2018 at 04:25, Dennis Clarke <[hidden email]> wrote:
>>> The question has to be where do these "include-fixed" headers come
>>> from?
>>
>> The include-fixed headers are generated as part of the GCC build
>> process. The contents of the fixincludes dir in the GCC sources apply
>> a set of rules to fix known problems in the system headers (either
>> conformance bugs, or incompatibilities with GCC).
>
> This is (barely) documented at
> https://gcc.gnu.org/onlinedocs/gccint/Headers.html
>

OKay .. maybe I can write something ( anything ) with examples but my
test case examples are Debian on ppc64 and Solaris on sparc as well as
FreeBSD on x86_64.  Something somewhere that says certain C++ standards
are expected ... or not ... I have yet to figure it out here.

Long email ... on the way  :-\

Dennis Clarke
Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Dennis Clarke-2
In reply to this post by Jonathan Wakely-4
On 10/24/2018 04:53 AM, Jonathan Wakely wrote:

> On Wed, 24 Oct 2018 at 04:25, Dennis Clarke <[hidden email]> wrote:
>> The question has to be where do these "include-fixed" headers come
>> from?
>
> The include-fixed headers are generated as part of the GCC build
> process. The contents of the fixincludes dir in the GCC sources apply
> a set of rules to fix known problems in the system headers (either
> conformance bugs, or incompatibilities with GCC). That means the
> include-fixed files are specific to the machine they were created for
> (and any machines with the same set of headers).
>
>> I am looking for an end point result that I know I can drop
>> on any similar machine and it will "just work"(tm).
>
> Generally "any similar machine" won't work, it needs to be exactly the
> same, because otherwise differences in the libc headers cause this
> kind of problem.
>

[I will cc Rainer Orth who may know of such things.]

SUMMARY : patch 119966-02 on Solaris is a math.h game changer

I did some digging on three nearly identical machines named "n", "b",
and "c".  Single letter hostnames will work for now.  All three have
the exact same hardware. Precisely. Same firmware. Also the exact same
operating system and revision with the exception of a particular patch
released 21 May 2016 :

119966-02 sparc SUNWlibm SunOS 5.10: Math Libraries (libm+libmvec)

Oracle made significant changes to a collection of headers under
/usr/include :

-rwxr-xr-x 1 root root    4264 Mar  7  2016 ./complex.h
-rwxr-xr-x 1 root root    4996 Mar  7  2016 ./fenv.h
-rwxr-xr-x 1 root root    6208 Mar  7  2016 ./floatingpoint.h
-rwxr-xr-x 1 root root   42707 Mar  7  2016 ./iso/math_c99.h
-rwxr-xr-x 1 root root    3209 Mar  7  2016 ./iso/math_impl.h
-rwxr-xr-x 1 root root    7831 Mar  7  2016 ./iso/math_iso.h
-rwxr-xr-x 1 root root   10977 Mar  7  2016 ./math.h
-rwxr-xr-x 1 root root   26920 Mar  7  2016 ./sunmath.h
-rwxr-xr-x 1 root root    1864 Mar  7  2016 ./sys/ieeefp.h
-rwxr-xr-x 1 root root    3433 Mar  7  2016 ./tgmath.h

Well there we see /usr/include/math.h is 10977 bytes in size and it just
so happens to be 396 lines long.  The system math.h that has been around
for quite a while is smaller by a whopping 64 lines :

jupiter # ls -lap /usr/include/math.h
-rw-r--r-- 1 root bin     9694 Aug  7  2009 /usr/include/math.h

I looked over the diff and it seems to all be related to C++ and glibc
related stuff[1]. The patch has a bucket load of shared objects also.
Here is the bugid list and that tells us a lot :

15007277 SUNBT4293101 libsunmath.so should be a part of Solaris (/usr/lib)
15506837 SUNBT6746001 15165237 SUNBT4882158 also affects C99 scalbln
functions
15706370 SUNBT7032798 cacosl(-1) returns 0 in error
15739597 SUNBT7086487 changes to pow function in <math.h> for C++ 2011
16220045 floatingpoint.h and iso/math_c99.h need patches for C++2011
16393089 /usr/include/complex.h is not usable with GCC
16562616 math headers still use #pragma ident; complex.h should allow
use by g++
16563240 C11 CMPLX* macros needed in <complex.h>
17031074 tgammal(-1.L) raises spurious inexact exception
17032772 erfl(LDBL_MIN) & erfcl(LDBL_MIN) raise spurious underflow exception
19073967 gcc version of signbit in <iso/math_c99.h> broken with -O2
-Wall -Werror
19337921 C99 math needs to be in namespace std for C++11 and later
19652435 scalb() declaration in <math.h> causes failures in the UNIX V7
(XPG7) test suite
20655863 bracket deprecated sunmath.h interfaces with __SUNMATH_DEPRECATED
21185492 cacosh(0. + NAN*I) gives incorrect result
21202051 ctan(INFINITY + 0*I) gives incorrect result
21828659 lgammal(nextafterl(0.5L, 0.0L)) does not always return correct
result
22170821 C++11 <cmath> must handle integral arguments to C99 math functions
22212928 <math.h> can fail to interact properly with glibc++ <cmath>
22388801 Studio 12.4 -std=c++11 does not recognize __builtin_signbit{f,l}


Well gee ... we have a new /usr/include/math.h and sure enough the
builds of gcc on any host with this new and shiney and improved math.h
do NOT have a math.h in the "include-fixed" directory. Seems to make
sense right?

No need to "fix" it I guess because patch 119966-02 took care of that
for the gcc build process.

Nifty.

Recall those three hosts I mentioned? The most trivial C++ will cause
g++ to throw a hissy fit on a machine that does not have the new and
improved math.h anywhere in the "include-fixed" :


trivial test code :

n$ cat foo.cpp

#include <iostream>
int main()
{
    std::cout << "foo\n";
}


hostname n :  has shiney new math.h in gcc include-fixed ?   YES
               patch 119966-02 and new /usr/include/math.h ?  YES

n$ ls -1d /usr/local/gcc[7-8]
/usr/local/gcc7
/usr/local/gcc8

n$ ls -1
/usr/local/gcc[7-8]/lib/gcc/sparc64-sun-solaris2.10/*/include-fixed/math.h
/usr/local/gcc7/lib/gcc/sparc64-sun-solaris2.10/7.3.0/include-fixed/math.h
/usr/local/gcc8/lib/gcc/sparc64-sun-solaris2.10/8.1.0/include-fixed/math.h
n$
n$ /usr/local/gcc7/bin/g++ -o foo foo.cpp
n$ /usr/local/gcc8/bin/g++ -o foo foo.cpp

works just fine.


hostname b :  has shiney new math.h in gcc include-fixed ?   YES and NO
               patch 119966-02 and new /usr/include/math.h ?  NO

b$ ls -1d /usr/local/gcc[7-8]
/usr/local/gcc7
/usr/local/gcc8

b$ ls -1
/usr/local/gcc[7-8]/lib/gcc/sparc64-sun-solaris2.10/*/include-fixed/math.h
/usr/local/gcc7/lib/gcc/sparc64-sun-solaris2.10/7.3.0/include-fixed/math.h
b$

gcc 7.3.0 with the new math.h in include-fixed blows up.

b$ /usr/local/gcc7/bin/g++ -o foo foo.cpp
   * * *  fail with plenty of noises about math.h * * *

However gcc 8.2.0 works just fine here :

b$ /usr/local/gcc8/bin/g++ -m64 -Wl,-rpath=/usr/local/lib/\$ISALIST -o
foo foo.cpp
b$ ./foo
foo
b$



hostname c :  has shiney new math.h in gcc include-fixed ?   YES and NO
               patch 119966-02 and new /usr/include/math.h ?  NO


c$ ls -lapb /usr/include/math.h
-rw-r--r-- 1 root bin    10977 Mar  7  2016 /usr/include/math.h

c$ ls -1d /usr/local/gcc[7-8]
/usr/local/gcc7
/usr/local/gcc8

c$ ls -1
/usr/local/gcc[7-8]/lib/gcc/sparc64-sun-solaris2.10/*/include-fixed/math.h
/usr/local/gcc7/lib/gcc/sparc64-sun-solaris2.10/7.3.0/include-fixed/math.h
c$

c$
c$ /usr/local/gcc8/bin/g++ --version
g++ (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

c$ ls -lapb /usr/include/math.h
-rw-r--r--   1 root     bin        10977 Mar  7  2016 /usr/include/math.h
c$ /usr/local/gcc7/bin/g++ -m64 -Wl,-rpath=/usr/local/lib/\$ISALIST -o
foo foo.cpp
c$ /usr/local/gcc8/bin/g++ -m64 -Wl,-rpath=/usr/local/lib/\$ISALIST -o
foo foo.cpp
In file included from /usr/local/gcc8/include/c++/8.2.0/bits/std_abs.h:40,
                  from /usr/local/gcc8/include/c++/8.2.0/cstdlib:77,
                  from
/usr/local/gcc8/include/c++/8.2.0/ext/string_conversions.h:41,
                  from
/usr/local/gcc8/include/c++/8.2.0/bits/basic_string.h:639,
                  from /usr/local/gcc8/include/c++/8.2.0/string:52,
                  from
/usr/local/gcc8/include/c++/8.2.0/bits/locale_classes.h:4,
                  from /usr/local/gcc8/include/c++/8.2.0/bits/ios_base.h:41,
                  from /usr/local/gcc8/include/c++/8.2.0/ios:42,
                  from /usr/local/gcc8/include/c++/8.2.0/ostream:38,
                  from /usr/local/gcc8/include/c++/8.2.0/iostream:39,
                  from foo.cpp:2:
/usr/include/math.h:45:12: error: 'std::float_t' has not been declared
  using std::float_t;
             ^~~~~~~
.
.
.
.
/usr/include/math.h:98:12: error: 'std::trunc' has not been declared
  using std::trunc;
             ^~~~~
c$


So the mess seems to be that one must have these include-fixed headers
in place OR not.   I  do recall a fix includes script .. from ... way
back in the gcc 3.x days.  Seems familiar.   Also Jonathan wakely just
pointed out ye sparse https://gcc.gnu.org/onlinedocs/gccint/Headers.html


Dennis Clarke



[1] diff of new shiney math.h from ye older math.h

jupiter # diff -c /usr/include/math.h math.h
*** /usr/include/math.h Fri Aug  7 21:20:41 2009
--- math.h      Mon Mar  7 18:11:34 2016
***************
*** 1,12 ****
   /*
!  * Copyright 2009 Sun Microsystems, Inc.  All rights reserved.
!  * Use is subject to license terms.
    */

   #ifndef _MATH_H
   #define       _MATH_H

! #pragma ident "@(#)math.h     2.25    09/05/19 SMI"

   #include <iso/math_iso.h>
   #include <iso/math_c99.h>
--- 1,16 ----
   /*
!  * Copyright (c) 1993, 2015, Oracle and/or its affiliates. All rights
reserved.
    */

+ #if __cplusplus >= 201103L
+ #undef        _GLIBCXX_USE_C99_MATH
+ #undef        _GLIBCXX_USE_C99_MATH_TR1
+ #endif
+
   #ifndef _MATH_H
   #define       _MATH_H

! /* @(#)math.h 2.26    16/02/27 */

   #include <iso/math_iso.h>
   #include <iso/math_c99.h>
***************
*** 37,42 ****
--- 41,103 ----
   using std::tanh;
   #endif

+ #if __cplusplus >= 201103L
+ using std::float_t;
+ using std::double_t;
+
+ using std::fpclassify;
+ using std::isfinite;
+ using std::isinf;
+ using std::isnan;
+ using std::isnormal;
+ using std::signbit;
+
+ using std::isgreater;
+ using std::isgreaterequal;
+ using std::isless;
+ using std::islessequal;
+ using std::islessgreater;
+ using std::isunordered;
+
+ using std::acosh;
+ using std::asinh;
+ using std::atanh;
+ using std::cbrt;
+ using std::copysign;
+ using std::erf;
+ using std::erfc;
+ using std::exp2;
+ using std::expm1;
+ using std::fdim;
+ using std::fma;
+ using std::fmax;
+ using std::fmin;
+ using std::hypot;
+ using std::ilogb;
+ using std::lgamma;
+ using std::llrint;
+ using std::llround;
+ using std::log1p;
+ using std::log2;
+ using std::logb;
+ using std::lrint;
+ using std::lround;
+ using std::nan;
+ using std::nanf;
+ using std::nanl;
+ using std::nearbyint;
+ using std::nextafter;
+ using std::nexttoward;
+ using std::remainder;
+ using std::remquo;
+ using std::rint;
+ using std::round;
+ using std::scalbln;
+ using std::scalbn;
+ using std::tgamma;
+ using std::trunc;
+ #endif        /* __cplusplus >= 201103L */
+
   #ifdef __cplusplus
   extern "C" {
   #endif
***************
*** 132,144 ****
   extern double hypot __P((double, double));
   extern double lgamma __P((double));

! #if defined(__MATHERR_ERRNO_DONTCARE)
   #pragma does_not_read_global_data(erf, erfc, hypot)
   #pragma does_not_write_global_data(erf, erfc, hypot)
   #pragma no_side_effect(erf, erfc, hypot)
   #endif

! #if !defined(_STDC_C99) && _XOPEN_SOURCE - 0 < 600 &&
!defined(__C99FEATURES__)
   extern int isnan __P((double));

   #pragma does_not_read_global_data(isnan)
--- 193,206 ----
   extern double hypot __P((double, double));
   extern double lgamma __P((double));

! #if !defined(__cplusplus) && defined(__MATHERR_ERRNO_DONTCARE)
   #pragma does_not_read_global_data(erf, erfc, hypot)
   #pragma does_not_write_global_data(erf, erfc, hypot)
   #pragma no_side_effect(erf, erfc, hypot)
   #endif

! #if !defined(_STDC_C99) && _XOPEN_SOURCE - 0 < 600 && \
!       !defined(__C99FEATURES__) && __cplusplus - 0 < 201103L
   extern int isnan __P((double));

   #pragma does_not_read_global_data(isnan)
***************
*** 165,170 ****
--- 227,233 ----
   #if defined(__EXTENSIONS__) || !defined(_XOPEN_SOURCE) || \
         _XOPEN_SOURCE - 0 >= 500 || \
         defined(_XOPEN_SOURCE) && _XOPEN_SOURCE_EXTENDED - 0 == 1
+ #if defined(__EXTENSIONS__) || _XOPEN_SOURCE - 0 < 700
   /*
    * SVID & XPG 4.2/5
    */
***************
*** 175,180 ****
--- 238,244 ----
   #pragma does_not_write_global_data(scalb)
   #pragma no_side_effect(scalb)
   #endif
+ #endif

   /* BEGIN adopted by C99 */
   extern double acosh __P((double));
***************
*** 193,199 ****
   extern double log1p __P((double));
   extern double rint __P((double));

! #if defined(__MATHERR_ERRNO_DONTCARE)
   #pragma does_not_read_global_data(acosh, asinh, atanh, cbrt)
   #pragma does_not_read_global_data(logb, nextafter, remainder)
   #pragma does_not_read_global_data(expm1, ilogb, log1p, rint)
--- 257,263 ----
   extern double log1p __P((double));
   extern double rint __P((double));

! #if !defined(__cplusplus) && defined(__MATHERR_ERRNO_DONTCARE)
   #pragma does_not_read_global_data(acosh, asinh, atanh, cbrt)
   #pragma does_not_read_global_data(logb, nextafter, remainder)
   #pragma does_not_read_global_data(expm1, ilogb, log1p, rint)
***************
*** 288,294 ****
   extern double copysign __P((double, double));
   extern double scalbn __P((double, int));

! #if defined(__MATHERR_ERRNO_DONTCARE)
   #pragma does_not_read_global_data(copysign, scalbn)
   #pragma does_not_write_global_data(copysign, scalbn)
   #pragma no_side_effect(copysign, scalbn)
--- 352,358 ----
   extern double copysign __P((double, double));
   extern double scalbn __P((double, int));

! #if !defined(__cplusplus) && defined(__MATHERR_ERRNO_DONTCARE)
   #pragma does_not_read_global_data(copysign, scalbn)
   #pragma does_not_write_global_data(copysign, scalbn)
   #pragma no_side_effect(copysign, scalbn)
jupiter #












Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Jonathan Wakely-4
In reply to this post by Dennis Clarke-2
On Wed, 24 Oct 2018 at 16:02, Dennis Clarke <[hidden email]> wrote:

>
> On 10/24/2018 05:04 AM, Jonathan Wakely wrote:
> > On Wed, 24 Oct 2018 at 09:53, Jonathan Wakely <[hidden email]> wrote:
> >>
> >> On Wed, 24 Oct 2018 at 04:25, Dennis Clarke <[hidden email]> wrote:
> >>> The question has to be where do these "include-fixed" headers come
> >>> from?
> >>
> >> The include-fixed headers are generated as part of the GCC build
> >> process. The contents of the fixincludes dir in the GCC sources apply
> >> a set of rules to fix known problems in the system headers (either
> >> conformance bugs, or incompatibilities with GCC).
> >
> > This is (barely) documented at
> > https://gcc.gnu.org/onlinedocs/gccint/Headers.html
> >
>
> OKay .. maybe I can write something ( anything ) with examples but my
> test case examples are Debian on ppc64 and Solaris on sparc as well as
> FreeBSD on x86_64.  Something somewhere that says certain C++ standards
> are expected ... or not ... I have yet to figure it out here.

I don't understand what you're saying. Are you asking for something?
Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Dennis Clarke-2
On 10/24/2018 11:05 AM, Jonathan Wakely wrote:

> On Wed, 24 Oct 2018 at 16:02, Dennis Clarke <[hidden email]> wrote:
>>
>> On 10/24/2018 05:04 AM, Jonathan Wakely wrote:
>>> On Wed, 24 Oct 2018 at 09:53, Jonathan Wakely <[hidden email]> wrote:
>>>>
>>>> On Wed, 24 Oct 2018 at 04:25, Dennis Clarke <[hidden email]> wrote:
>>>>> The question has to be where do these "include-fixed" headers come
>>>>> from?
>>>>
>>>> The include-fixed headers are generated as part of the GCC build
>>>> process. The contents of the fixincludes dir in the GCC sources apply
>>>> a set of rules to fix known problems in the system headers (either
>>>> conformance bugs, or incompatibilities with GCC).
>>>
>>> This is (barely) documented at
>>> https://gcc.gnu.org/onlinedocs/gccint/Headers.html
>>>
>>
>> OKay .. maybe I can write something ( anything ) with examples but my
>> test case examples are Debian on ppc64 and Solaris on sparc as well as
>> FreeBSD on x86_64.  Something somewhere that says certain C++ standards
>> are expected ... or not ... I have yet to figure it out here.
>
> I don't understand what you're saying. Are you asking for something?
>

I am saying that page can be updated a bit with some more explanation
  and examples and such and I could write up something.

Dennis
Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Jonathan Wakely-4
In reply to this post by Dennis Clarke-2
On Wed, 24 Oct 2018 at 16:05, Dennis Clarke wrote:
> So the mess seems to be that one must have these include-fixed headers
> in place OR not.

As I said earlier, when libstdc++ is built it looks at the target
headers and checks which features are present in the libc headers. It
then assumes that doesn't change. If the host machine's headers change
significantly, that can invalidate the configuration that libstdc++
decided on at build time.

Due to the significant changes to the libc <math.h> as part of patch
119966-02, I expect you cannot take a libstdc++ built on an unpatched
system and run it on a patched system.


Rainer should be able to confirm it, but I think this is related to
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00330.html -- that patch
is present in all versions of GCC 7 and 8, so if you're seeing
problems with those versions then I suspect it's due to differences
between <math.h> when libstdc++ was configured and when you're trying
to use it.

What's not clear from your email is whether you built those versions
of GCC on the host machines where you're testing them (and if so,
whether it was before or after installing patch 119966-02) or whether
you built them on one machine and then copied them to the other hosts.
Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Jonathan Wakely-4
On Wed, 24 Oct 2018 at 16:23, Jonathan Wakely wrote:

>
> On Wed, 24 Oct 2018 at 16:05, Dennis Clarke wrote:
> > So the mess seems to be that one must have these include-fixed headers
> > in place OR not.
>
> As I said earlier, when libstdc++ is built it looks at the target
> headers and checks which features are present in the libc headers. It
> then assumes that doesn't change. If the host machine's headers change
> significantly, that can invalidate the configuration that libstdc++
> decided on at build time.
>
> Due to the significant changes to the libc <math.h> as part of patch
> 119966-02, I expect you cannot take a libstdc++ built on an unpatched
> system and run it on a patched system.
>
>
> Rainer should be able to confirm it, but I think this is related to
> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00330.html -- that patch

Ah yes, Rainer said there:

"They were introduced in Solaris 10 Patch 11996[67]-02"


> is present in all versions of GCC 7 and 8, so if you're seeing
> problems with those versions then I suspect it's due to differences
> between <math.h> when libstdc++ was configured and when you're trying
> to use it.
>
> What's not clear from your email is whether you built those versions
> of GCC on the host machines where you're testing them (and if so,
> whether it was before or after installing patch 119966-02) or whether
> you built them on one machine and then copied them to the other hosts.
Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Dennis Clarke-2
On 10/24/2018 11:24 AM, Jonathan Wakely wrote:

> On Wed, 24 Oct 2018 at 16:23, Jonathan Wakely wrote:
>>
>> On Wed, 24 Oct 2018 at 16:05, Dennis Clarke wrote:
>>> So the mess seems to be that one must have these include-fixed headers
>>> in place OR not.
>>
>> As I said earlier, when libstdc++ is built it looks at the target
>> headers and checks which features are present in the libc headers. It
>> then assumes that doesn't change. If the host machine's headers change
>> significantly, that can invalidate the configuration that libstdc++
>> decided on at build time.
>>
>> Due to the significant changes to the libc <math.h> as part of patch
>> 119966-02, I expect you cannot take a libstdc++ built on an unpatched
>> system and run it on a patched system.
>>
>>
>> Rainer should be able to confirm it, but I think this is related to
>> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00330.html -- that patch
>
> Ah yes, Rainer said there:
>
> "They were introduced in Solaris 10 Patch 11996[67]-02"
>

yeah .. the schmucks at Oracle broke it ... nicely done.

Dennis

Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Dennis Clarke-2
In reply to this post by Jonathan Wakely-4
On 10/24/2018 11:23 AM, Jonathan Wakely wrote:

> On Wed, 24 Oct 2018 at 16:05, Dennis Clarke wrote:
>> So the mess seems to be that one must have these include-fixed headers
>> in place OR not.
>
> As I said earlier, when libstdc++ is built it looks at the target
> headers and checks which features are present in the libc headers. It
> then assumes that doesn't change. If the host machine's headers change
> significantly, that can invalidate the configuration that libstdc++
> decided on at build time.
>
> Due to the significant changes to the libc <math.h> as part of patch
> 119966-02, I expect you cannot take a libstdc++ built on an unpatched
> system and run it on a patched system.
>
>
> Rainer should be able to confirm it, but I think this is related to
> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00330.html -- that patch
> is present in all versions of GCC 7 and 8, so if you're seeing
> problems with those versions then I suspect it's due to differences
> between <math.h> when libstdc++ was configured and when you're trying
> to use it.
>
> What's not clear from your email is whether you built those versions
> of GCC on the host machines where you're testing them (and if so,
> whether it was before or after installing patch 119966-02) or whether
> you built them on one machine and then copied them to the other hosts.
>

Thank you Jonathan.  This had me up late last night looking over three
different builds of gcc that go back at least two years.  Clearly two
years.  A few machines have those dastdardly libm patches and other
machines do not.  The gcc builds that were wonderfully bootstrapped on
systems without that libm patches are of course borked on any system
that has them. I suspect the reverse is also true.

So machine "b" did the bootstrap4 of 8.2.0 and the libm patches are NOT
there on that machine. I also have gcc 7.3.0 on machine "b" which was
built elsewhere :

Machine "b" has the unborked math.h :

b$ ls -lapb /usr/include/math.h
-rw-r--r--   1 root     bin         9694 Aug  7  2009 /usr/include/math.h
b$

gcc 7.3.0 fails here :

b$ /usr/local/gcc7/bin/g++ -m64 -Wl,-rpath=/usr/local/lib/\$ISALIST -o
foo foo.cpp > /dev/null 2>&1
b$ echo $?
1
b$

gcc 8.2.0 works fine as it was bootstrapped here :

b$ /usr/local/gcc8/bin/g++ --version | head -1
g++ (GCC) 8.2.0
b$

b$ /usr/local/gcc8/bin/g++ -m64 -Wl,-rpath=/usr/local/lib/\$ISALIST -o
foo foo.cpp > /dev/null 2>&1
b$ echo $?
0
b$
b$ ls -ladb /usr/local/gcc8/bin/g++ /usr/local/gcc7/bin/g++
-rwxr-xr-x   4 root     root     6286112 Apr 18  2018
/usr/local/gcc7/bin/g++
-rwxr-xr-x   4 root     root     6673584 Oct 23 15:59
/usr/local/gcc8/bin/g++

However the 7.3.0 has math.h in the include-fixed and that doesn't matter:

/usr/local/gcc7/lib/gcc/sparc64-sun-solaris2.10/7.3.0/include-fixed/math.h


What a mess.

Dennis
Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Jonathan Wakely-4
On Wed, 24 Oct 2018 at 17:16, Dennis Clarke wrote:

>
> On 10/24/2018 11:23 AM, Jonathan Wakely wrote:
> > What's not clear from your email is whether you built those versions
> > of GCC on the host machines where you're testing them (and if so,
> > whether it was before or after installing patch 119966-02) or whether
> > you built them on one machine and then copied them to the other hosts.
> >
>
> Thank you Jonathan.  This had me up late last night looking over three
> different builds of gcc that go back at least two years.  Clearly two
> years.  A few machines have those dastdardly libm patches and other
> machines do not.  The gcc builds that were wonderfully bootstrapped on
> systems without that libm patches are of course borked on any system
> that has them. I suspect the reverse is also true.

Then that's the cause of the problem.

> However the 7.3.0 has math.h in the include-fixed and that doesn't matter:
>
> /usr/local/gcc7/lib/gcc/sparc64-sun-solaris2.10/7.3.0/include-fixed/math.h

Because what matters is not whether that file is present or not, but
whether what gets included by <math.h> on the host machine *now*
matches what got included by <math.h> on the build machine *then*. It
doesn't matter whether what gets included is /usr/include/math.h or
GCC's include-fixed/math.h or something else, as long as it matches
what libstdc++ was configured against.
Reply | Threaded
Open this post in threaded view
|

Re: the mystery of math.h in lib/gcc/%triple-name%/%gcc-version%/include-fixed

Dennis Clarke-2
On 10/24/2018 12:22 PM, Jonathan Wakely wrote:

> On Wed, 24 Oct 2018 at 17:16, Dennis Clarke wrote:
>>
>> On 10/24/2018 11:23 AM, Jonathan Wakely wrote:
>>> What's not clear from your email is whether you built those versions
>>> of GCC on the host machines where you're testing them (and if so,
>>> whether it was before or after installing patch 119966-02) or whether
>>> you built them on one machine and then copied them to the other hosts.
>>>
>>
>> Thank you Jonathan.  This had me up late last night looking over three
>> different builds of gcc that go back at least two years.  Clearly two
>> years.  A few machines have those dastdardly libm patches and other
>> machines do not.  The gcc builds that were wonderfully bootstrapped on
>> systems without that libm patches are of course borked on any system
>> that has them. I suspect the reverse is also true.
>
> Then that's the cause of the problem.
>
>> However the 7.3.0 has math.h in the include-fixed and that doesn't matter:
>>
>> /usr/local/gcc7/lib/gcc/sparc64-sun-solaris2.10/7.3.0/include-fixed/math.h
>
> Because what matters is not whether that file is present or not, but
> whether what gets included by <math.h> on the host machine *now*
> matches what got included by <math.h> on the build machine *then*. It
> doesn't matter whether what gets included is /usr/include/math.h or
> GCC's include-fixed/math.h or something else, as long as it matches
> what libstdc++ was configured against.
>



That damn patch should come with a warning : software from the past that
was working is about to fail.  Good luck.


Dennis