[Bug c/46155] New: Bug with generation of float.h header file on AIX

[Bug c/46155] New: Bug with generation of float.h header file on AIX

[david.kirkby at onetel dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

           Summary: Bug with generation of float.h header file on AIX
           Product: gcc
           Version: 4.2.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: david.kirkby@onetel.net


Hi, 
I first posted this on the gcc-help mailing list, and was advised by  Ian Lance
Taylor to post this as a bug. 

On an IBM server running AIX 5.3, 'fprnd_t' is clearly defined in the IBM
system header file /usr/include/float.h

-bash-4.1$ grep fprnd_t  /usr/include/float.h
typedef unsigned short fprnd_t;
fprnd_t fp_read_rnd();
fprnd_t fp_swap_rnd();
fprnd_t fp_read_rnd(void);
fprnd_t fp_swap_rnd(fprnd_t rnd);

as an unsigned short. 

But when gcc is built, it creates several files called 'float.h', but all of
these lack any references at all to fprnd_t 

-bash-4.1$ find /opt/pware -name float.h
/opt/pware/include/c++/4.2.4/tr1/float.h
/opt/pware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.4/include/float.h
/opt/pware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.4/install-tools/include/float.h
-bash-4.1$ grep fprnd_t /opt/pware/include/c++/4.2.4/tr1/float.h
-bash-4.1$ grep fprnd_t
/opt/pware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.4/include/float.h
-bash-4.1$ grep fprnd_t
/opt/pware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.4/install-tools/include/float.h

This is from a gcc 4.2.4 binary downloaded from pware. I've run the 'mkheaders'
file, but that does not solve the problem.

Clearly this problem has existed for some time, as it has caused problems with
the GNU Scientific library for years. (just Google gsl aix). I found a
reference going back as far as 2002, but here's a more recent (and hopefully
useful) post on the matter. 

http://www.mail-archive.com/bug-gsl@gnu.org/msg01301.html

As  you can see, I'm trying to work around this in gsl with autoconf in GSL,
but ultimately it seems to be a GCC bug and not a GSL bug, so should be fixed
in GCC and not in GSL.

I'm attaching a copy of the IBM system header file:

/usr/include/float.h

as well as the float.h from 

/opt/pware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.4/include/float.h

If gcc developers do not have easy access to an AIX system, I can provide
access to AIX hardware.  

Dave

[Bug c/46155] Bug with generation of float.h header file on AIX

[david.kirkby at onetel dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

--- Comment #1 from Dr. David Kirkby <david.kirkby at onetel dot net> 2010-10-24 03:51:23 UTC ---
Created attachment 22138
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22138
This is the IBM header file (/usr/include/float.h) from an AIX 5.3 system

Clearly this shows that fprnd_t is defined as an unsigned short. So this
definition should appear in any gcc patched header files.

[Bug c/46155] Bug with generation of float.h header file on AIX

[david.kirkby at onetel dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

--- Comment #2 from Dr. David Kirkby <david.kirkby at onetel dot net> 2010-10-24 03:54:48 UTC ---
Created attachment 22139
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22139
Header file created by gcc. Stored at
/opt/pware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.4/include/float.h

Note how this file contains no reference to fprnd_t. The causes the GNU
Scientific library (GSL) to fail to compile unless one hacks a file in the GNU
Scientific library.

[Bug c/46155] Bug with generation of float.h header file on AIX

[david.kirkby at onetel dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

--- Comment #3 from Dr. David Kirkby <david.kirkby at onetel dot net> 2010-10-24 04:17:44 UTC ---
It looks to me that the GCC header file lacks several definitions that are in
the IBM header file (DEC128_EPSILON is another example). The size of the IBM
header is around twice that of the one in gcc. However, it is only fprnd_t, and
a few things that depend on that, which cause the compilation of the GNU
Scientific library to fail. 

This is the failure to build the GNU Scientific library, but I believe this is
a bug in GCC and not in the GNU Scientific library

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -g -O2 -MT make_rep.lo -MD
-MP -MF .deps/make_rep.Tpo -c make_rep.c  -DPIC -o .libs/make_rep.o
mv -f .deps/make_rep.Tpo .deps/make_rep.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I.. 
  -g -O2 -MT env.lo -MD -MP -MF .deps/env.Tpo -c -o env.lo env.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -g -O2 -MT env.lo -MD -MP
-MF .deps/env.Tpo -c env.c  -DPIC -o .libs/env.o
mv -f .deps/env.Tpo .deps/env.Plo
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I.. 
  -g -O2 -MT fp.lo -MD -MP -MF .deps/fp.Tpo -c -o fp.lo fp.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -g -O2 -MT fp.lo -MD -MP
-MF .deps/fp.Tpo -c fp.c  -DPIC -o .libs/fp.o
In file included from fp.c:22:
fp-aix.c: In function 'gsl_ieee_set_mode':
fp-aix.c:30: error: 'fprnd_t' undeclared (first use in this function)
fp-aix.c:30: error: (Each undeclared identifier is reported only once
fp-aix.c:30: error: for each function it appears in.)
fp-aix.c:30: error: expected ';' before 'rnd'
fp-aix.c:55: error: 'rnd' undeclared (first use in this function)
fp-aix.c:55: error: 'FP_RND_RN' undeclared (first use in this function)
fp-aix.c:59: error: 'FP_RND_RM' undeclared (first use in this function)
fp-aix.c:63: error: 'FP_RND_RP' undeclared (first use in this function)
fp-aix.c:67: error: 'FP_RND_RZ' undeclared (first use in this function)
make[2]: *** [fp.lo] Error 1
make[2]: Leaving directory
`/home/users/drkirkby/sage-4.6.alpha1/spkg/build/gsl-1.14/src/ieee-utils'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/home/users/drkirkby/sage-4.6.alpha1/spkg/build/gsl-1.14/src'
make: *** [all] Error 2

[Bug c/46155] Bug with generation of float.h header file on AIX

[david.kirkby at onetel dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

--- Comment #4 from Dr. David Kirkby <david.kirkby at onetel dot net> 2010-10-24 04:24:58 UTC ---
I forgot to say, this is with the latest version of the GNU Scientific library
(gsl-1.14). 

The hardware used is

 * IBM  RS/6000 7025 F50
 * 4 x 332 MHz 32-bit PowerPC CPUs
 * 3 GB RAM 

There's a full build log of the failed build of GSL at
http://trac.sagemath.org/sage_trac/ticket/10000 but I believe the problem can
be seen clearly from just using grep on the header files.

[Bug c/46155] Bug with generation of float.h header file on AIX

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-10-24 14:07:25 UTC ---
On Sun, 24 Oct 2010, david.kirkby at onetel dot net wrote:

> On an IBM server running AIX 5.3, 'fprnd_t' is clearly defined in the IBM
> system header file /usr/include/float.h
> 
> -bash-4.1$ grep fprnd_t  /usr/include/float.h
> typedef unsigned short fprnd_t;
> fprnd_t fp_read_rnd();
> fprnd_t fp_swap_rnd();
> fprnd_t fp_read_rnd(void);
> fprnd_t fp_swap_rnd(fprnd_t rnd);
> 
> as an unsigned short. 
> 
> But when gcc is built, it creates several files called 'float.h', but all of
> these lack any references at all to fprnd_t 

Indeed, fprnd_t is not a type that ISO C permits to be declared in 
float.h, and nor are the other identifiers in a reserved namespace.  So 
certainly in ISO C mode GCC's float.h must not include those declarations.

I haven't seen documentation for those functions and types, but they sound 
rather like they should be obsoleted by the standard <fenv.h> facilities 
such as fegetround and fesetround.

[Bug c/46155] Bug with generation of float.h header file on AIX

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-10-24 14:12:05 UTC ---
On Sun, 24 Oct 2010, david.kirkby at onetel dot net wrote:

> It looks to me that the GCC header file lacks several definitions that are in
> the IBM header file (DEC128_EPSILON is another example). The size of the IBM

GCC does define DEC128_EPSILON if __STDC_WANT_DEC_FP__ is defined by the 
user.  This conditional on  __STDC_WANT_DEC_FP__ is what TR 24732 
specifies (at least, in the last draft I have; I don't have the final TR).

Note that GCC does not support DFP on AIX, however, only on 
powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux* | s390*-*-linux* | 
i?86*-*-mingw* | x86_64*-*-mingw* | i?86*-*-cygwin*.

[Bug c/46155] Bug with generation of float.h header file on AIX

[david.kirkby at onetel dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

--- Comment #7 from Dr. David Kirkby <david.kirkby at onetel dot net> 2010-10-24 15:05:50 UTC ---
(In reply to comment #5)
> On Sun, 24 Oct 2010, david.kirkby at onetel dot net wrote:
> 
> > On an IBM server running AIX 5.3, 'fprnd_t' is clearly defined in the IBM
> > system header file /usr/include/float.h
> > 
> > -bash-4.1$ grep fprnd_t  /usr/include/float.h
> > typedef unsigned short fprnd_t;
> > fprnd_t fp_read_rnd();
> > fprnd_t fp_swap_rnd();
> > fprnd_t fp_read_rnd(void);
> > fprnd_t fp_swap_rnd(fprnd_t rnd);
> > 
> > as an unsigned short. 
> > 
> > But when gcc is built, it creates several files called 'float.h', but all of
> > these lack any references at all to fprnd_t 
> 
> Indeed, fprnd_t is not a type that ISO C permits to be declared in 
> float.h, and nor are the other identifiers in a reserved namespace.  So 
> certainly in ISO C mode GCC's float.h must not include those declarations.

I don't have a copy of the C standard. Is there one publicly available? In your
opinion, are IBM wrong to define fprnd_t in /usr/include/float.h? AIX 5.3 is a
POSIX certified operating system.

Clearly if the C standard says X,  Y and Z, and only X, Y and Z should be
defined in float.h, then I can see your point. Conversely, if the standard says
X, Y and Z must be defined, but other things can be defined, then I would
suggest it's a gcc bug. Without knowing the details of the standard, its
difficult for me to comment further. 

I'm sure if I asked IBM they would say it is a gcc bug!

> I haven't seen documentation for those functions and types, but they sound 
> rather like they should be obsoleted by the standard <fenv.h> facilities 
> such as fegetround and fesetround.

According to 

http://www.gnu.org/software/gnulib/manual/html_node/fesetround.html

fegetround() is not very portable, so I doubt the GSL developers would want to
use that. I've found GSL to be very portable. It seems to build on just about
anything - except AIX, unless one makes a few changes to a source file. 

Other than manually defining these, do you have a better solution on how to 
resolve this issue? 

Dave

[Bug c/46155] Bug with generation of float.h header file on AIX

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-10-24 15:21:44 UTC ---
On Sun, 24 Oct 2010, david.kirkby at onetel dot net wrote:

> I don't have a copy of the C standard. Is there one publicly available? In your
> opinion, are IBM wrong to define fprnd_t in /usr/include/float.h? AIX 5.3 is a
> POSIX certified operating system.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

(the standard as consolidated with subsequent TCs)

POSIX reserves *_t.  ISO C does not.  An ISO C program may do:

#define fprnd_t something random
#include <float.h>

(A POSIX program would need to define a feature test macro such as 
_POSIX_C_SOURCE, at which point fprnd_t becomes reserved, although the 
function names you listed still aren't reserved.)

> > I haven't seen documentation for those functions and types, but they sound 
> > rather like they should be obsoleted by the standard <fenv.h> facilities 
> > such as fegetround and fesetround.
> 
> According to 
> 
> http://www.gnu.org/software/gnulib/manual/html_node/fesetround.html
> 
> fegetround() is not very portable, so I doubt the GSL developers would want to
> use that. I've found GSL to be very portable. It seems to build on just about
> anything - except AIX, unless one makes a few changes to a source file. 

All the systems listed there are old systems.  ISO C99 was published on 1 
December 1999 - nearly 11 years ago.

It appears that GSL has code that uses the C99 interfaces (fp-gnuc99.c).  
I'd advise using that in preference to all the other pre-C99 OS-specific 
interfaces, whenever the C99 interfaces are available, rather than as the 
very last alternative.  If AIX supports the C99 interfaces, that solves 
your problem.

[Bug c/46155] Bug with generation of float.h header file on AIX

[david.kirkby at onetel dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

--- Comment #9 from Dr. David Kirkby <david.kirkby at onetel dot net> 2010-10-24 16:10:30 UTC ---
(In reply to comment #8)
> On Sun, 24 Oct 2010, david.kirkby at onetel dot net wrote:
> 
> > I don't have a copy of the C standard. Is there one publicly available? In your
> > opinion, are IBM wrong to define fprnd_t in /usr/include/float.h? AIX 5.3 is a
> > POSIX certified operating system.
> 
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

Thank you. Do you happen to have one for the C++ standards too? 

> > According to 
> > 
> > http://www.gnu.org/software/gnulib/manual/html_node/fesetround.html
> > 
> > fegetround() is not very portable, so I doubt the GSL developers would want to
> > use that. I've found GSL to be very portable. It seems to build on just about
> > anything - except AIX, unless one makes a few changes to a source file. 
> 
> All the systems listed there are old systems.  ISO C99 was published on 1 
> December 1999 - nearly 11 years ago.

Solaris 10 was only introduced in 2005, so Solaris 9 is not that old. To my
knowledge Cygwin does not support C99, though I know the GSL builds on Cygwin. 

It should also be noted that gcc is still not fully C99 compliant! 

http://gcc.gnu.org/c99status.html

11 years after the standard! 

> It appears that GSL has code that uses the C99 interfaces (fp-gnuc99.c).  

I'm a bit puzzled by that. Perhaps it only uses that when it knows the compiler
supports C99. 

> I'd advise using that in preference to all the other pre-C99 OS-specific 
> interfaces, whenever the C99 interfaces are available, rather than as the 
> very last alternative.  If AIX supports the C99 interfaces, that solves 
> your problem.

AIX 5.3 (released in 2004) fully supports the C99 standard, but earlier AIX
versions do not. However, I believe 5.2 supported most of it, so there may be
some argument here for using C99 code on AIX. 

I'm not a GSL developer, so the GSL developers would have to make the final
decision on that. But given GSL is very portable, I can imagine the developers
might be reluctant to change that. 

Dave

[Bug c/46155] Bug with generation of float.h header file on AIX

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-10-24 17:50:44 UTC ---
On Sun, 24 Oct 2010, david.kirkby at onetel dot net wrote:

> > > I don't have a copy of the C standard. Is there one publicly available? In your
> > > opinion, are IBM wrong to define fprnd_t in /usr/include/float.h? AIX 5.3 is a
> > > POSIX certified operating system.
> > 
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
> 
> Thank you. Do you happen to have one for the C++ standards too? 

No.

> Solaris 10 was only introduced in 2005, so Solaris 9 is not that old. To my
> knowledge Cygwin does not support C99, though I know the GSL builds on Cygwin. 

I think cygwin does have the fenv.h interfaces.

What is meant by "supporting" C99 is very complicated and it is likely to 
involve (if conscientious) complicated lists of caveats about the state of 
support of optional features, issues of interpretation of the standard, 
and what depends on different parts of the implementation (compiler, 
library, OS).  In this case you just need library interfaces that are easy 
to implement for any OS that has any of the alternative interfaces GSL 
sometimes uses.

> > It appears that GSL has code that uses the C99 interfaces (fp-gnuc99.c).  
> 
> I'm a bit puzzled by that. Perhaps it only uses that when it knows the compiler
> supports C99. 

That would be very silly, given that "supports C99" is a very complicated 
matter not a binary yes/no configure test.  For use of a particular 
library feature it should test for that library feature.  Not for support 
of \uNNNNNNNN extended characters in identifiers or any other random 
compiler feature.  And there's no reason for it to compare about other 
details of compiler Annex F support any more for using the C99 interfaces 
than for any of the other interfaces it uses.

What doesn't make sense to me is that GSL has the C99 interfaces as the 
*last* of a series of alternatives, so always preferring pre-standard 
OS-specific interfaces where both are available.  The sensible thing to do 
would be to prefer standard interfaces where available.

[Bug c/46155] Bug with generation of float.h header file on AIX

[kon at iki dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

--- Comment #11 from Kalle Olavi Niemitalo <kon at iki dot fi> 2010-10-24 19:47:27 UTC ---
(In reply to comment #7)
> In your opinion, are IBM wrong to define fprnd_t in /usr/include/float.h?

IBM's definition of fprnd_t in <float.h> is within #ifdef _ALL_SOURCE.  I
presume _ALL_SOURCE is not defined when IBM's compiler is used in ISO C
conforming mode.  AFAIK, adding non-standard definitions to standard header
files in non-conforming modes is a common practice.

The <float.h> that GCC installed on AIX is identical to gcc/ginclude/float.h in
the GCC 4.2.4 sources.  I can understand if GCC developers don't want to
introduce OS-specific sections in it.

[Bug c/46155] Bug with generation of float.h header file on AIX

[david.kirkby at onetel dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

--- Comment #12 from Dr. David Kirkby <david.kirkby at onetel dot net> 2010-10-26 17:59:38 UTC ---
(In reply to comment #11)
> (In reply to comment #7)
> > In your opinion, are IBM wrong to define fprnd_t in /usr/include/float.h?
> 
> IBM's definition of fprnd_t in <float.h> is within #ifdef _ALL_SOURCE.  I
> presume _ALL_SOURCE is not defined when IBM's compiler is used in ISO C
> conforming mode.  AFAIK, adding non-standard definitions to standard header
> files in non-conforming modes is a common practice.
> 
> The <float.h> that GCC installed on AIX is identical to gcc/ginclude/float.h in
> the GCC 4.2.4 sources.  I can understand if GCC developers don't want to
> introduce OS-specific sections in it.

Whist you can understand the developers not wanting to introduce OS-specific
sections to the library, it should be realised it breaks code which will
compile with the IBM compiler. IMHO, it would be sensible to preserve the IBM
definitions in the file. 

The 'mkheaders' script is I believe written to work around what gcc considers
buggy header files, yet by doing this you remove definitions that can be 
important on AIX systems. 

I can see your point about perhaps the GSL developers should use the C99
features in preference to other ones, but the GSL code is very portable, so I
suspect will work with pre-C99 systems. I know GSL builds on AIX, HP-UX,
FreeBSD and Cygwin - 4 less common operating systems. 

Anyway, I can work around this, but my own feeling is the IBM definitions
should be preserved. 

Dave

[Bug c/46155] Bug with generation of float.h header file on AIX

[kon at iki dot fi]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

--- Comment #13 from Kalle Olavi Niemitalo <kon at iki dot fi> 2010-11-18 08:10:20 UTC ---
Earlier, I thought GCC would eventually have to add some libc-specific
definitions to <float.h> anyway, in order to make FLT_ROUNDS call a function in
the C library and map the results correctly, and the IBM fprnd_t and function
declarations could then be added at the same time; but according to bug 30569,
FLT_ROUNDS is supposed to call a built-in function instead.

FLT_EVAL_METHOD has a similar "???" comment above it, but C99 says it shall be
a "constant expression[s] suitable for use in #if preprocessing directives", so
cannot expand to a function call.

[Bug c/46155] Bug with generation of float.h header file on AIX

[dje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46155

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-02-06
                 CC|                            |dje at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #14 from David Edelsohn <dje at gcc dot gnu.org> ---
This seems to be an AIXism.