Bug 16787 - NAN constant "(0.0/0.0)" cannot be compiled by Tru64 cc
Summary: NAN constant "(0.0/0.0)" cannot be compiled by Tru64 cc
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 3.4.1
: P3 minor
Target Milestone: 3.4.6
Assignee: Not yet assigned to anyone
URL:
Keywords: build, documentation
: 17281 25002 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-07-27 19:23 UTC by R. Scott Bailey
Modified: 2006-02-17 01:21 UTC (History)
3 users (show)

See Also:
Host: alphaev56-dec-osf5.1
Target: alphaev56-dec-osf5.1
Build: alphaev56-dec-osf5.1
Known to work: 4.0.3 4.1.0 4.2.0 3.4.6
Known to fail:
Last reconfirmed: 2005-09-25 22:24:32


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description R. Scott Bailey 2004-07-27 19:23:05 UTC
Bootstrap of gcc-3.4.1 fails using cc compiler under Tru64 V5.1B, trying to 
compile libiberty/floatformat.c. The macro NAN is defined as the constant 
expression "(0.0 / 0.0)", which is not compilable by HP's cc compiler.

The following kludgy patch was sufficient to get me past the problem, but is 
totally inappropriate "as-is" for a generic fix. :-)

*** libiberty/floatformat.c	Wed Dec  3 13:36:50 2003
--- libiberty/floatformat.c	Tue Jul 27 15:09:15 2004
***************
*** 43,49 ****
  #endif
  
  #ifndef NAN
! #define NAN (0.0 / 0.0)
  #endif
  
  static unsigned long get_field PARAMS ((const unsigned char *,
--- 43,50 ----
  #endif
  
  #ifndef NAN
! #include "float.h"
! #define NAN DBL_QNAN
  #endif
  
  static unsigned long get_field PARAMS ((const unsigned char *,
Comment 1 Andrew Pinski 2004-07-28 06:07:15 UTC
Looks like another bug in a DEC's (Compaq/HP's) compiler.
Comment 2 R. Scott Bailey 2004-07-28 14:12:07 UTC
Subject: RE:  NAN constant "(0.0/0.0)" cannot be comp
	iled by Tru64 cc

>Looks like another bug in a DEC's (Compaq/HP's) compiler.

Yeah, what a pain. It turns out my suggested patch isn't quite good enough,
as much later on in the bootstrap process (I think during the build of the
C++ stuff) the (re-)build of floatformat.c dies again with "DBL_QNAN not
defined"... It appears that Tru64's /usr/include/float.h may be getting
occluded by one or another of the gcc float.h files. (I know I was up past
at least stage 2 of the bootstrap when I went home last night.)

I had earlier tried bootstrapping with my installed gcc 3.3.3 compiler, but
that failed early on with an apparent error in one of the generated
Makefiles and I couldn't even be sure which was at fault, much less what was
triggering the error. So I thought fudging the NAN definition might be
easier... Ha ha ha...

I will try replacing the '#include "float.h"' in my fix with an inline
definition of the two lines or so from float.h that appear to be required to
define DBL_QNAN and report back on my success or lack thereof. It probably
will be tomorrow, my system doesn't exactly build like lightning. :-)

Cheers,

	Scott Bailey
Comment 3 R. Scott Bailey 2004-07-28 19:30:06 UTC
Subject: RE:  NAN constant "(0.0/0.0)" cannot be comp
	iled by Tru64 cc

Well, I found that by preparing a patch that extracts two lines from
/usr/include/float.h and includes them in libiberty/floatformat.c for the
purpose of defining NAN, I was able to bootstrap from Tru64's cc and
complete the gcc build successfully.

However, my fear is that this patch isn't distributable since the header
file I'm borrowing the definitions from bears a Compaq Information
Technologies Group, L.P. copyright notice. :-( There actually are a number
of copyright statements, but the stuff I'm taking is from the "non POSIX"
section.

I'm open to more knowledgeable suggestions, but this may need to end up
getting listed as a known feature and I will open a problem report to HP and
see if it does any good.

Thanks anyway,

	Scott Bailey
Comment 4 Falk Hueffner 2004-07-29 11:44:30 UTC
(In reply to comment #3)

> However, my fear is that this patch isn't distributable since the header
> file I'm borrowing the definitions from bears a Compaq Information
> Technologies Group, L.P. copyright notice. :-(

I do not think that matters. I mean, even if Compaq's math.h contains
#define M_PI 3.14159265358979
I am still allowed to use the same definition in my program.

Comment 5 R. Scott Bailey 2004-07-29 14:02:07 UTC
Subject: RE:  NAN constant "(0.0/0.0)" cannot be comp
	iled by Tru64 cc

>> However, my fear is that this patch isn't distributable since the header
>> file I'm borrowing the definitions from bears a Compaq Information
>> Technologies Group, L.P. copyright notice. :-(
>
>I do not think that matters. I mean, even if Compaq's math.h contains
>#define M_PI 3.14159265358979
>I am still allowed to use the same definition in my program.

I agree it's a fuzzy situation. They aren't actually defining a numerical
constant; instead they define DBL_QNAN in terms of a value referenced by an
external pointer that presumably is pointing to some hand-crafted "magic
bytes" :-) in their library. I had just literally copied the two lines
without thinking about it too much.

However, we may have a better answer at hand. I talked to their support team
this morning (case 3207169315) and they suggested adding "-ieee" to CFLAGS
for the bootstrap. On my little test program (abstracted from floatformat.c)
this works -- you get a warning about overflow (just like previous versions
of Tru64) instead of an error -- and the compile succeeds.

I am trying another rebuild to see if this approach works for the whole
compiler.

Fingers crossed,

	Scott
Comment 6 R. Scott Bailey 2004-07-30 14:54:06 UTC
Subject: RE:  NAN constant "(0.0/0.0)" cannot be comp
	iled by Tru64 cc

Okay, I was able to get a good bootstrap doing this:

CC="cc -ieee" CFLAGS=-O2 /usr/local/bin/make bootstrap

The semi-obvious alternative, 'CC=cc CFLAGS="-O2 -ieee" ...' does not work
because after the compiler build succeeds, the make process then attempts to
build the c++ libraries using gcc with the supplied CFLAGS and then dies
because "-ieee" is not a valid gcc argument. Trying STAGE1_CFLAGS didn't
seem to do the right thing either, and I didn't have any other decent
guesses. :-)

Is it possible to teach configure that -ieee is needed when using the native
Tru64 cc compiler? (Well, "needed" for 5.1 and, it appears, "harmless" for
earlier versions.)

I have a couple more observations that I will open separate reports on.

Cheers,

	Scott
Comment 7 Andrew Pinski 2004-09-02 13:54:42 UTC
*** Bug 17281 has been marked as a duplicate of this bug. ***
Comment 8 Bill Northcott 2005-02-13 22:55:45 UTC
This is a documentation problem.    The current host specific docs at http://gcc.gnu.org/install/
specific.html#alpha*-*-* read:
*****************************
In Tru64 UNIX V5.1, Compaq introduced a new assembler that does not currently (2001-06-13) work 
with mips-tfile. As a workaround, we need to use the old assembler, invoked via the barely documented 
-oldas option. To bootstrap GCC, you either need to use the Compaq C Compiler:
        % CC=cc srcdir/configure [options] [target]
or you can use a copy of GCC 2.95.3 or higher built on Tru64 UNIX V4.0:
        % CC=gcc -Wa,-oldas srcdir/configure [options] [target]
*****************************
This is misleading and unhelpful:
1.  The only effect most people will observe from the assembler change is that gcc binaries built on 
older (pre 5.1) versions of Tru64 will not run on 5.1.
2.  The -oldas seems to be unecessary.
3.  The -ieee flag is vital to bootstrap using the DEC compiler.  So the configure suggestion should 
read: 'To bootstrap GCC, you either need to use the Compaq C Compiler:
        % CC="cc -ieee" srcdir/configure [options] [target]'

Could someone please please fix the documentation.
Bill Northcott
Comment 9 Andrew Pinski 2005-11-23 15:04:22 UTC
*** Bug 25002 has been marked as a duplicate of this bug. ***
Comment 10 Roger Sayle 2006-02-11 16:50:44 UTC
Subject: Bug 16787

Author: sayle
Date: Sat Feb 11 16:50:41 2006
New Revision: 110873

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110873
Log:
2006-02-11  Roger Sayle  <roger@eyesopen.com>
	    R. Scott Bailey  <scott.bailey@eds.com>
	    Bill Northcott  <w.northcott@unsw.edu.au>

	PR bootstrap/16787
	* floatformat.c: Include <float.h> where available.
	(NAN): Use value of DBL_QNAN if defined, and NAN isn't.


Modified:
    trunk/libiberty/ChangeLog
    trunk/libiberty/floatformat.c

Comment 11 Roger Sayle 2006-02-16 16:45:56 UTC
Subject: Bug 16787

Author: sayle
Date: Thu Feb 16 16:45:49 2006
New Revision: 111145

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111145
Log:
2006-02-16  Roger Sayle  <roger@eyesopen.com>
	    R. Scott Bailey  <scott.bailey@eds.com>
	    Bill Northcott  <w.northcott@unsw.edu.au>

	PR bootstrap/16787
	* floatformat.c: Include <float.h> where available.
	(NAN): Use value of DBL_QNAN if defined, and NAN isn't.


Modified:
    branches/gcc-4_1-branch/libiberty/ChangeLog
    branches/gcc-4_1-branch/libiberty/floatformat.c

Comment 12 Andrew Pinski 2006-02-16 17:43:47 UTC
Fixed.
Comment 13 Roger Sayle 2006-02-16 20:15:17 UTC
Subject: Bug 16787

Author: sayle
Date: Thu Feb 16 20:15:10 2006
New Revision: 111147

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111147
Log:
2006-02-16  Roger Sayle  <roger@eyesopen.com>
	    R. Scott Bailey  <scott.bailey@eds.com>
	    Bill Northcott  <w.northcott@unsw.edu.au>

	PR bootstrap/16787
	* floatformat.c: Include <float.h> where available.
	(NAN): Use value of DBL_QNAN if defined, and NAN isn't.


Modified:
    branches/gcc-4_0-branch/libiberty/ChangeLog
    branches/gcc-4_0-branch/libiberty/floatformat.c

Comment 14 Andrew Pinski 2006-02-16 20:17:08 UTC
And for 4.0.3 now.
Comment 15 Roger Sayle 2006-02-17 01:13:40 UTC
Subject: Bug 16787

Author: sayle
Date: Fri Feb 17 01:13:38 2006
New Revision: 111172

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111172
Log:
2006-02-16  Roger Sayle  <roger@eyesopen.com>
	    R. Scott Bailey  <scott.bailey@eds.com>
	    Bill Northcott  <w.northcott@unsw.edu.au>

	PR bootstrap/16787
	* floatformat.c: Include <float.h> where available.
	(NAN): Use value of DBL_QNAN if defined, and NAN isn't.


Modified:
    branches/gcc-3_4-branch/libiberty/ChangeLog
    branches/gcc-3_4-branch/libiberty/floatformat.c