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] |
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] |