JuliaLang/openlibm — Issue #2: Definition of isinf
Author: ViralBShah
Created: 2012-01-06 03:32:18+00:00
State: open

After searching wikipedia more, I determined the last definition is only correct for programs compiled with gcc on x86 (and gcc-clang apparently on x86) and that it may be fragile for GCC > 4.3. There really doesn't seem to me to be a portable way of determining infinity for anything larger than float and double without including math.h.
-Jameson

On Thu, Jan 5, 2012 at 10:27 AM, Viral Shah wrote:
Ah - I just saw the bug report. Will try to get it to build on linux next.

-viral

On Jan 5, 2012, at 8:54 PM, Jameson Nash wrote:

> Actually, I think a better definition would be:
> #define __isinff(x) (x & ~(1<<31)) == 0x7f800000
> #define __isinfd(x) (x & ~(1<<63)) == 0x7ff0000000000000
> #define __isinfl(x) (x & ~(1<<79)) == 0x7fff8000000000000000
> Although that last one is not exactly correct and I'm not sure what happens with bit manipulations of floating point numbers. It may be necessary to cast them to a sufficiently large uint first.
>
> I don't consider inf_torture.c as much of a math test as I do of a way to break your compiler. Providing things like assert(isinf((double)1./0)) and assert(!isnan((double)1./0)) would make a better test suite.
>
> Openlibm currently doesn't build on linux (see Jeff's bug report) since it doesn't have the necessary BSD headers.
>
> -jameson
>
>
>
> On Thu, Jan 5, 2012 at 1:55 AM, Viral Shah wrote:
> We can get the inlining working later - seems unnecessary right now.
>
> Do you feel comfortable enough to make those the definitions for isinf* in openlibm for now? If so, can you create a merge request, or commit directly to the openlibm repo? You should be able to commit to it.
>
> Need to try openlibm on linux, which I haven't even tried.
>
> Would be nice to add the torture test to the repo as well. I am hoping that over time, we have a high quality test-suite in openlibm.
>
> -viral
>
>
>
> On Jan 5, 2012, at 11:51 AM, Jameson Nash wrote:
>
> > I think they inlined to get those last few extra percentage points of speed by eliminating the function call, which could presumably matter when putting this into some heavily optimized graphics loop.
> >
> > Replacing isinf with __isinf works fine on Apple, which is probably already using a derivative of FDLIBM underneath and happens to have the correct definitions in this case (it is a BSD port after all). Otherwise, this is a really bad idea since it disables all type-checking in potentially stack destroying ways (or subtle bug inducing ways) if the definitions used by the compiler are different. Remember the bug I tracked down with the 8 bit boxing of Julia types? It would be like that. I've attached some c code I wrote to delve into this on 64-bit Apple. Results on other compilers / computer not strictly guaranteed, although I've shown it to work on 32-bit Ubuntu also. See some of the different results you can get with gcc vs clang, with and without compiler optimizations (-ffast-math and -O3 for starters).
> >
> > It does however suggest a portable definition for isinf that seems sort-of likely to work of:
> > #define isinff(x) x == x && x > 0xff800000
> > #define isinfd(x) x == x && x > 0x7ff0000000000000
> > #define isinfl(x) x == x && x > 0x7fff8000000000000000
> > ---------------------------
> > 5. NOTES ON PORTING FDLIBM
> > ---------------------------
> > Care must be taken when installing FDLIBM over existing
> > libm.a.
> > All co-existing function prototypes must agree, otherwise
> > users will encounter mysterious failures.
> >
> > So far, the only known likely conflict is the declaration
> > of the IEEE recommended function scalb:
> >
> > double scalb(double,double) (1) SVID3 defined
> > double scalb(double,int) (2) IBM,DEC,...
> >
> > FDLIBM follows Sun definition and use (1) as default.
> > If one's existing libm.a uses (2), then one may raise
> > the flags _SCALB_INT during the compilation of FDLIBM
> > to get the correct function prototype.
> > (E.g., make "CFLAGS = -D_IEEE_LIBM -D_SCALB_INT".)
> > NOTE that if -D_SCALB_INT is raised, it won't be SVID3
> > conformant.
> >
> >
> > -Jameson
> >
> >
> >
> > On Jan 1, 2012, at 10:40 PM, Viral Shah wrote:
> >
> >> Yes, the whole inline thing is really confusing. I have got the whole thing building, and even loading in julia. See math_openlibm.j in examples.
> >>
> >> I will try out your inline branch. I don't want to include the system math.h, because that is exactly what I want to avoid with openlibm. I replaced isinf with __isinf and it worked.
> >>
> >> -viral
> >>
> >>
> >>
> >> On Jan 2, 2012, at 7:29 AM, Jameson Nash wrote:
> >>
> >>> That's odd, since on my Apple it worked.
> >>>
> >>> Anyways, I've forked your repo and created two branches. The first "inline" is simply getting it to build with inline support. The second "system_math_h_plus" is a (possibly foolish) attempt to include the system math.h header to pull in the proper compiler built in functions, macros, and constants (mostly for isinf and the sizes of a few other things). Both compile for me.
> >>>
> >>> To get it to work on linux (Ubuntu) for Jeff, I think you'll need to pull in the sys/cdefs.h file from the original BSD system to get the definitions of things like __pure2.
> >>>
> >>> More information on inline from the Apple man page for gcc (I just find all of it very confusing):
> >>> -fgnu89-inline
> >>> The option -fgnu89-inline tells GCC to use the traditional GNU
> >>> semantics for "inline" functions when in C99 mode.
> >>> Using this option is roughly equivalent to adding the
> >>> "gnu_inline" function attribute to all inline functions.
> >>>
> >>> This option is accepted by GCC versions 4.1.3 and up. In GCC
> >>> versions /* APPLE LOCAL extern inline */ prior to 4.3 (4.2 for
> >>> Apple's gcc), C99 inline semantics are not supported, and thus this
> >>> option is effectively assumed to be present regardless of whether
> >>> or not it is specified; the only effect of specifying it explicitly
> >>> is to disable warnings about using inline functions in C99 mode.
> >>> Likewise, the option -fno-gnu89-inline is not supported in versions
> >>> of /* APPLE LOCAL extern inline */ GCC before 4.3 (4.2 for Apple's
> >>> gcc). It is supported only in C99 or gnu99 mode, not in C89 or
> >>> gnu89 mode.
> >>>
> >>> The preprocesor macros "__GNUC_GNU_INLINE__" and
> >>> "__GNUC_STDC_INLINE__" may be used to check which semantics are in
> >>> effect for "inline" functions.
> >>>
> >>>
> >>>
> >>>
> >>> On Dec 31, 2011, at 11:08 PM, Viral Shah wrote:
> >>>
> >>>> I guess Apple's shipped gcc does not fully support this inline stuff?
> >>>>
> >>>> http://gcc.gnu.org/gcc-4.2/c99status.html
> >>>>
> >>>> -viral
> >>>>
> >>>>
> >>>>
> >>>> On Jan 1, 2012, at 1:47 AM, Jameson Nash wrote:
> >>>>
> >>>>> Here's an interesting resource on inline functions. http://www.greenend.org.uk/rjk/2003/03/inline.html It takes a bit of work to understand, but can help clear up the issue. In summary, it needs to be compiled with CFLAGS += -std=c99 (and revert your recent changes to the makefile and c files)
> >>>>> -Jameson
> >>>>>
> >>>>> On Dec 31, 2011, at 3:12 PM, Viral Shah wrote:
> >>>>>
> >>>>>> I got it to that stage too. Perhaps we can just try to build without the "long double" versions.
> >>>>>>
> >>>>>> -viral
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Jan 1, 2012, at 1:04 AM, Jameson Nash wrote:
> >>>>>>
> >>>>>>> I can get it to compile with a few fixes, however, I don't have a real definition for __isinfl (on Mac OS Lion / llvm-gcc), which is preventing linking.
> >>>>>>> -Jameson
> >>>>>>>
> >>>>>>>
> >>>>>>> On Dec 31, 2011, at 9:21 AM, Viral Shah wrote:
> >>>>>>>
> >>>>>>>> I have separated out the libm implementation from FreeBSD and am trying to build it standalone. I have it almost there, except a couple of long double things not building, and a couple of link time errors.
> >>>>>>>>
> >>>>>>>> https://github.com/JuliaLang/openlibm
> >>>>>>>>
> >>>>>>>> I have marked every change with VBS, where I had to make some small tweaks to get things to compile.
> >>>>>>>>
> >>>>>>>> I want to have all the libm functions then be prefixed with olm_ so that the library can be dropped in anywhere, and one can be absolutely sure of which functions are getting called etc. Next, I will plug it into julia, and it gives us many more complex functions. I then plan to start slowly writing tests for every function along the lines of Alan's numerical wiki, clean the style etc.
> >>>>>>>>
> >>>>>>>> Would be nice if anyone who is interested can take a look at my edits, and help get it going.
> >>>>>>>>
> >>>>>>>> -viral
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>