Bug 19933 - Problem with define of HUGE_VAL in math_c99.
Summary: Problem with define of HUGE_VAL in math_c99.
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.4.4
: P2 normal
Target Milestone: 3.4.5
Assignee: Eric Botcazou
URL:
Keywords: patch
: 20317 (view as bug list)
Depends on:
Blocks: 21315
  Show dependency treegraph
 
Reported: 2005-02-13 05:49 UTC by Case Van Horsen
Modified: 2005-05-29 20:52 UTC (History)
4 users (show)

See Also:
Host: *-*-solaris2.10
Target:
Build:
Known to work: 4.0.1 4.1.0
Known to fail: 3.4.4
Last reconfirmed: 2005-03-04 18:11:59


Attachments
Fixed version of math_c99.h. (647 bytes, text/plain)
2005-05-03 10:00 UTC, Eric Botcazou
Details
Fixed version of math_c99.h. (657 bytes, text/plain)
2005-05-03 11:37 UTC, Eric Botcazou
Details
Fixed version of math_c99.h. (723 bytes, text/plain)
2005-05-09 07:56 UTC, Eric Botcazou
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Case Van Horsen 2005-02-13 05:49:00 UTC
Python does not compile on Solaris 10 x86 GA. The problem exists with gcc-3.4.3
shipped by Sun with Solaris and with a 3.4.4 snapshot I compiled.

I reproduced the problem with the following code fragment: 

#define _XOPEN_SOURCE 1000
#include <math.h>
int main()
{
  double f=HUGE_VAL;
}

Compiler output is:

$ gcc hv.c
hv.c: In function `main':
hv.c:5: error: incompatible types in initialization
$

Python defines _XOPEN_SOURCE to be greater than 600 so it triggers the inclusion
of math_c99.h.

The fix is editing <iso/math_c99.h>. If I copy /usr/include/iso/math_c99.h to
<gcc-install-dir>/include/iso/math_c99.h and change the line

#define HUGE_VAL        __builtin_huge_val

to

#define HUGE_VAL        __builtin_huge_val().

With this change to math_c99.h, Python compiles properly. Should
mkheaders/fixincludes deal with this?
Comment 1 Eric Botcazou 2005-03-04 18:10:40 UTC
*** Bug 20317 has been marked as a duplicate of this bug. ***
Comment 2 Eric Botcazou 2005-03-04 18:11:59 UTC
Confirmed by duplicate.
Comment 3 Case Van Horsen 2005-03-07 06:15:05 UTC
I downloaded and tried the Sun Studio 10 compiler. It does require math_c99.h as
distributed by Sun. So I'd say gcc will need to work around this header file.
Comment 4 Joseph S. Myers 2005-03-22 20:52:53 UTC
The following definitions should replace the Solaris ones outright for GCC.
This has been reported to Sun, so fixes for these should be disabled for
any future header mentioning __GNUC__.

#define HUGE_VAL       (__builtin_huge_val())
#define HUGE_VALF      (__builtin_huge_valf())
#define HUGE_VALL      (__builtin_huge_vall())
#define INFINITY       (__builtin_inff())
#define NAN            (__builtin_nanf(""))

#define isgreater(x, y)        __builtin_isgreater(x, y)
#define isgreaterequal(x, y)   __builtin_isgreaterequal(x, y)
#define isless(x, y)           __builtin_isless(x, y)
#define islessequal(x, y)      __builtin_islessequal(x, y)
#define islessgreater(x, y)    __builtin_islessgreater(x, y)
#define isunordered(u, v)      __builtin_isunordered(u, v)

__builtin_isinf and __builtin_signbit are not currently entirely suited
to the uses to which they are being put.  For __builtin_isinf this is bug 20558.
For __builtin_signbit, it ought to be type-generic but avoid falling back to
the wrong function or a function the library does not have.  (The Solaris
libc doesn't seem to have isinf or signbit library functions.)  GCC does
not yet have __builtin_isfinite or __builtin_isnormal functions; they would
be generically useful additions if they always avoided falling back to
a library function.  __builtin_fpclassify would also be useful but would
only be usable where GCC is configured to know the FP_* values used on
a given target.

In principle all the macros can be defined along the lines of   
the isnan/isfinite/isinf definitions in libgcc2.c, with GNU extensions to
avoid multiple evaluation, but this is not very efficient.
Comment 5 Eric Botcazou 2005-04-30 17:10:49 UTC
Fixing.
Comment 6 Eric Botcazou 2005-05-01 12:21:13 UTC
> GCC does not yet have __builtin_isfinite or __builtin_isnormal functions; they 
> would be generically useful additions if they always avoided falling back to
> a library function.  __builtin_fpclassify would also be useful but would
> only be usable where GCC is configured to know the FP_* values used on
> a given target.
> 
> In principle all the macros can be defined along the lines of   
> the isnan/isfinite/isinf definitions in libgcc2.c, with GNU extensions to
> avoid multiple evaluation, but this is not very efficient.

Joseph, we are severely bitten by the __builtin_isfinite problem for the Fortran
compiler (this is PR target/21315).  What do you suggest?  Fixincluding to GCC
__builtin_* functions when possible and fixincluding away in the other cases?
Comment 7 joseph@codesourcery.com 2005-05-01 14:24:35 UTC
Subject: Re:  Problem with define of HUGE_VAL in math_c99.

On Sun, 1 May 2005, ebotcazou at gcc dot gnu dot org wrote:

> > In principle all the macros can be defined along the lines of   
> > the isnan/isfinite/isinf definitions in libgcc2.c, with GNU extensions to
> > avoid multiple evaluation, but this is not very efficient.
> 
> Joseph, we are severely bitten by the __builtin_isfinite problem for the Fortran
> compiler (this is PR target/21315).  What do you suggest?  Fixincluding to GCC
> __builtin_* functions when possible and fixincluding away in the other cases?

Fixincluding everything to working definitions if possible, even if 
cumbersome, with all the fixes disabled conditional on __GNUC__ being 
mentioned in the header.  (If support for some of these built-in functions 
is then added to GCC, remove the relevant fixes, but I suppose you want to 
fix things on 4.0 branch as well as mainline for now.)  I'm not sure what 
is best done with the signbit definition (maybe nothing if it will never 
call a library function at present, even though it isn't properly 
type-generic); but the others can be done, e.g.

#define isfinite(x) __extension__ ({ __typeof (x) __x = (x); __builtin_expect (!isnan(__x - __x), 1); })

following libgcc2.c but using statement expressions and __typeof to avoid 
multiple evaluation.  (This includes fixincluding isinf, per bug 20558.)

I'd recommend making each fixed definition a separate fixinclude (so they 
still work if e.g. the header gets reordered; and so if Sun produce a 
partially fixed header version then the disabling on __GNUC__ only needs 
changing for those definitions which remain problematic).

Comment 8 Eric Botcazou 2005-05-03 09:48:54 UTC
> I'm not sure what is best done with the signbit definition (maybe nothing if
> it will never call a library function at present, even though it isn't
> properly type-generic);

We can discriminate using sizeof, like in glibc.

> but the others can be done, e.g.
> 
> #define isfinite(x) __extension__ ({ __typeof (x) __x = (x); __builtin_expect
(!isnan(__x - __x), 1); })

This works fine for "big" numbers, but are there similar tricks to distinguish
denormals from normals?  If no, we'll have to resort to FLT_MIN and the like or
to bitwise-testing the exponent against 0.

I'm going to attach a first version of math_c99.h.
Comment 9 Eric Botcazou 2005-05-03 10:00:05 UTC
Created attachment 8803 [details]
Fixed version of math_c99.h.
Comment 10 joseph@codesourcery.com 2005-05-03 10:54:20 UTC
Subject: Re:  Problem with define of HUGE_VAL in math_c99.

On Tue, 3 May 2005, ebotcazou at gcc dot gnu dot org wrote:

> This works fine for "big" numbers, but are there similar tricks to distinguish
> denormals from normals?  If no, we'll have to resort to FLT_MIN and the like or
> to bitwise-testing the exponent against 0.

Use __FLT_MIN__ etc. since <float.h> may not be included.

For a good fix we'll want to add built-in functions compatible with the 
Solaris header and remove the relevant fixes, and those would test the 
bits of the representation appropriately, but for now I think __FLT_MIN__ 
is the right approach and the fixes could more suitably go on 4.0 branch 
than new built-in functions.

We have a functional __builtin_isnan, there is no need to fix that 
particular definition.

Comment 11 Eric Botcazou 2005-05-03 11:35:53 UTC
> Use __FLT_MIN__ etc. since <float.h> may not be included.

Of course.

> For a good fix we'll want to add built-in functions compatible with the 
> Solaris header and remove the relevant fixes, and those would test the 
> bits of the representation appropriately, but for now I think __FLT_MIN__ 
> is the right approach and the fixes could more suitably go on 4.0 branch 
> than new built-in functions.

Agreed.  I'll open an enhancement PR for the missing builtins.

> We have a functional __builtin_isnan, there is no need to fix that 
> particular definition.

Right, but it is type-dependent so I guess we have to play the sizeof game.

I'm going to attach a revised version.  Does it look OK to you?  If so, I'll
write tests and run them on SPARC (I don't have access to i386-pc-solaris2.10)
before translating it into a fixinclude patch.

Note that I'd like to have a fix for the 3.4 branch too, and we have neither
__builtin_isnan nor __builtin_signbit on that branch.
Comment 12 Eric Botcazou 2005-05-03 11:37:35 UTC
Created attachment 8804 [details]
Fixed version of math_c99.h.
Comment 13 joseph@codesourcery.com 2005-05-03 12:59:26 UTC
Subject: Re:  Problem with define of HUGE_VAL in math_c99.

On Tue, 3 May 2005, ebotcazou at gcc dot gnu dot org wrote:

> > We have a functional __builtin_isnan, there is no need to fix that 
> > particular definition.
> 
> Right, but it is type-dependent so I guess we have to play the sizeof game.

__builtin_isnan is type-generic and functionally so, unlike 
__builtin_signbit which isn't although it should be and __builtin_isinf 
which tries to be type-generic and is broken in doing so (bug 20558).  
The __builtin_isnanf and __builtin_isnanl functions can be ignored.

Comment 14 Eric Botcazou 2005-05-03 14:39:02 UTC
> __builtin_isnan is type-generic and functionally so, unlike 
> __builtin_signbit which isn't although it should be and __builtin_isinf 
> which tries to be type-generic and is broken in doing so (bug 20558).

2 more questions:
  1. Can we work around bug 20558 by using the sizeof trick for isinf?
  2. Can we use __builtin_finite for isfinite?
Comment 15 joseph@codesourcery.com 2005-05-03 16:21:59 UTC
Subject: Re:  Problem with define of HUGE_VAL in math_c99.

On Tue, 3 May 2005, ebotcazou at gcc dot gnu dot org wrote:

>   1. Can we work around bug 20558 by using the sizeof trick for isinf?

No, because all of __builtin_isinf, __builtin_isinff, __builtin_isinfl may 
fall back to library functions isinf, isinff, isinfl and Solaris libc/libm 
doesn't have those functions.

>   2. Can we use __builtin_finite for isfinite?

No, because again all the __builtin_finite* functions may fall back to 
library functions and the only one of those Solaris has is plain "finite".

Comment 16 Eric Botcazou 2005-05-09 07:56:28 UTC
Created attachment 8844 [details]
Fixed version of math_c99.h.

This one has successfully passed sanity checks and makes it possible to build a
working libgfortran.
Comment 17 CVS Commits 2005-05-19 07:06:00 UTC
Subject: Bug 19933

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	ebotcazou@gcc.gnu.org	2005-05-19 07:05:46

Modified files:
	gcc/testsuite  : ChangeLog 
	fixincludes    : ChangeLog fixincl.x inclhack.def 
Added files:
	gcc/testsuite/gcc.dg: c99-math-double-1.c c99-math-float-1.c 
	                      c99-math.h c99-math-long-double-1.c 
	fixincludes/tests/base/iso: math_c99.h 

Log message:
	fixincludes/
	PR target/19933
	PR target/21315
	* inclhack.def: New fixes solaris_math_[1-9].
	* fixincl.x: Regenerate.
	* tests/base/iso/math_c99.h: New.
	
	gcc/testsuite/
	* gcc.dg/c99-math.h: New
	* gcc.dg/c99-math-float-1.c: New test.
	* gcc.dg/c99-math-double-1.c: Likewise.
	* gcc.dg/c99-math-long-double-1.c: Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5495&r2=1.5496
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-double-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-float-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math.h.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-long-double-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/ChangeLog.diff?cvsroot=gcc&r1=1.41&r2=1.42
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/fixincl.x.diff?cvsroot=gcc&r1=1.20&r2=1.21
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/inclhack.def.diff?cvsroot=gcc&r1=1.20&r2=1.21
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/tests/base/iso/math_c99.h.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 18 CVS Commits 2005-05-19 07:11:43 UTC
Subject: Bug 19933

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	ebotcazou@gcc.gnu.org	2005-05-19 07:11:26

Modified files:
	gcc/testsuite  : ChangeLog 
	fixincludes    : ChangeLog fixincl.x inclhack.def 
Added files:
	gcc/testsuite/gcc.dg: c99-math-double-1.c c99-math-float-1.c 
	                      c99-math.h c99-math-long-double-1.c 
	fixincludes/tests/base/iso: math_c99.h 

Log message:
	fixincludes/
	PR target/19933
	PR target/21315
	* inclhack.def: New fixes solaris_math_[1-9].
	* fixincl.x: Regenerate.
	* tests/base/iso/math_c99.h: New.
	
	gcc/testsuite/
	* gcc.dg/c99-math.h: New
	* gcc.dg/c99-math-float-1.c: New test.
	* gcc.dg/c99-math-double-1.c: Likewise.
	* gcc.dg/c99-math-long-double-1.c: Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.186&r2=1.5084.2.187
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-double-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-float-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-long-double-1.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.32.2.5&r2=1.32.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/fixincl.x.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.16.14.3&r2=1.16.14.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/inclhack.def.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.16.14.3&r2=1.16.14.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/fixincludes/tests/base/iso/math_c99.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1

Comment 19 Eric Botcazou 2005-05-19 07:16:08 UTC
Fixed in 4.0.1 and later.  Backporting to 3.4.x.
Comment 20 Eric Botcazou 2005-05-24 13:36:59 UTC
Patch for 3.4.x: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02123.html
Comment 21 CVS Commits 2005-05-29 20:45:49 UTC
Subject: Bug 19933

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	ebotcazou@gcc.gnu.org	2005-05-29 20:45:44

Modified files:
	gcc            : ChangeLog 
	gcc/testsuite  : ChangeLog 
	gcc/fixinc     : fixincl.x inclhack.def 
Added files:
	gcc/testsuite/gcc.dg: c99-math-double-1.c c99-math-float-1.c 
	                      c99-math.h c99-math-long-double-1.c 
	gcc/fixinc/tests/base/iso: math_c99.h 

Log message:
	PR target/19933
	* fixinc/inclhack.def (solaris_math_6_1): New fix.
	(solaris_math_9): Rewrite and guard with #ifdef __sparc__.
	* fixinc/fixincl.x: Regenerate.
	* fixinc/tests/base/iso/math_c99.h: Adjust for above changes.
	
	Backport from mainline:
	2005-05-19  Eric Botcazou  <ebotcazou@libertysurf.fr>
	Joseph S. Myers  <joseph@codesourcery.com>
	
	* fixinc/inclhack.def: New fixes solaris_math_[1-9].
	* fixinc/fixincl.x: Regenerate.
	* fixinc/tests/base/iso/math_c99.h: New.
	
	Backport from mainline:
	2005-05-10  Joseph S. Myers  <joseph@codesourcery.com>
	
	* fixinc/inclhack.def (stdio_stdarg_h, stdio_va_list): Bypass on
	*-*-solaris2.1[0-9]*, not just *-*-solaris2.1[0-9].
	* fixinc/fixincl.x: Regenerate.
	
	Backport from mainline:
	2004-11-26  Mark Mitchell  <mark@codesourcery.com>
	
	* fixinc/inclhack.def (gnu_types): Do not use on Solaris 2.1x.
	(stdio_va_list): Likewise.
	(stdio_stdarg.h): Likewise.
	(solaris_stdio_tag): Add bypass.
	* fixinc/fixincl.x: Regenerated.
	
	testsuite/
	* gcc.dg/c99-math.h: New
	* gcc.dg/c99-math-float-1.c: New test.
	* gcc.dg/c99-math-double-1.c: Likewise.
	* gcc.dg/c99-math-long-double-1.c: Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.872&r2=2.2326.2.873
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.398&r2=1.3389.2.399
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-double-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-float-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/c99-math-long-double-1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.8.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/fixincl.x.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.177.4.10&r2=1.177.4.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/inclhack.def.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.190.4.10&r2=1.190.4.11
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fixinc/tests/base/iso/math_c99.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1

Comment 22 Eric Botcazou 2005-05-29 20:52:59 UTC
Patch backported to 3.4 branch.