This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: add _HAVE_LONG_DOUBLE flag, math.h update


Jeff:
     I don't know that infinities warnings will not be generated.  (GCC
4.3 warns for the manual infinities, but that point is moot because it
doesn't use that case since it uses it's builtins.  The older GCCs
I have--4.1 and older ones, that even have the builtins--do not warn.)
Let's put it in and see.  If people get warnings they'll complain and
I'll fix them, hopefully in a clean way for that other compiler.  I
added a note for people to email if they get warnings from the HUGE
lines.  (I've been wondering lately if anybody uses anything other than
GCC, anyway.)  An interesting irony is that doing HUGE_VAL in this way
is exactly what the standard orders when infinities are not supported--a
value that will overflow at translation time.
     I've changed it to the statics method, as you're right, it's best
to start out clean.  (By the way, I just did some quick testing with
GCC 3.2.3 on RHEL3, and it actually fails to raise FP exceptions in some
places where it should.  e.g.  NAN (as 0./0.) in an automatic variable
assignment does not give an exception--not following the rules in F.7.4
and F.7.5 in C99.  Same for the 1.0e999999999.  However, GCC 4.1.2
under RHEL5 does give the exception for automatic 0./0., although not
for 1.0e999999999.  Interesting.  If I were signed up, I suppose I'd
enter an MR against GCC.)
     About why not 'reusing'?  Two thoughts.  First, nobody thought
about
it before you did.  (#define HUGE_VALF ((float) HUGE_VAL) seems like
a simple, good idea.  The cast is not prohibited as it is for many of
the integer constants because the define is not required to be usable
in a preprocessor evaluation.)  Secondly, if I read F.7.5 correctly, the
cast would be required to be done at execution time, which would be
undesirable versus all being done at translation time.  It's an
interesting idea.
     An updated patch is attached, being the same as the first for
all files except math.h, which uses static locals in the defines.
(Hmm.  I just realized that I used "const" instead of "_CONST" when I
did it.  However, I propose that it be left that way, as there are
plenty of other files that do that, which demonstrate that all the
compilers have it.  e.g. libc/stdlib/a64l.c, dated 2005 and
argz/argz_replace.c, dated 2003.)
				Craig 

-----Original Message-----
From: Jeff Johnston [mailto:jjohnstn@redhat.com] 
Sent: Wednesday, May 06, 2009 4:51 PM
To: Howland Craig D (Craig)
Cc: Newlib
Subject: Re: add _HAVE_LONG_DOUBLE flag, math.h update

Howland Craig D (Craig) wrote:
> ...
Craig,

I don't have the 754 standard so thanks for the details.

I wasn't really interested in the SI stuff, but I mentioned it
nonetheless.

I'm not comfortable with the infinities logic due to the possibility of 
warnings.  I am not sure how you know that the infinities and hugevals 
won't generate warnings in any other embedded compilers using the logic 
per your comment.

Again, I would prefer to use the statics as I know they will work and 
avoid the runtime fp exception.  Special casing should be handled for a 
platform in machine/ieeefp.h (e.g. float not 32-bits). 

As an aside, I don't understand why the glibc non-GNUC logic doesn't 
simply reuse HUGE_VALF for HUGE_VAL and HUGE_VALL so one only cares 
about the float bytes and endianness, but I must be missing something.

-- Jeff J.

Attachment: math2.patch
Description: math2.patch


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]