This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/16787] NAN constant "(0.0/0.0)" cannot be compiled by Tru64 cc
- From: "scott dot bailey at eds dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 29 Jul 2004 14:02:14 -0000
- Subject: [Bug bootstrap/16787] NAN constant "(0.0/0.0)" cannot be compiled by Tru64 cc
- References: <20040727192305.16787.scott.bailey@eds.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From scott dot bailey at eds dot com 2004-07-29 14:02 -------
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
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16787