Displaying 4 results from an estimated 4 matches for "long_doubl".
Did you mean:
long_double
2011 Oct 05
2
[LLVMdev] LLVM IR is a compiler IR
All,
I should have chimed in earlier, but have been working on two more
side-channel variants of this conversation.
At the beginning the PNaCl team was strongly pushing for trying to keep
platform ABI compatibility on all
platforms while taking one portable bitcode stream as input. During the
discussions we've had over the past few
weeks it became obvious that that is simply not tractable,
2019 Dec 13
3
Build failure on powerpc64
...> double on ppc64.
> --- ./src/main/arithmetic.c.orig 2019-12-12 18:30:12.416334062 +0000
> +++ ./src/main/arithmetic.c 2019-12-12 18:30:44.966334062 +0000
> @@ -179,7 +179,10 @@ void attribute_hidden InitArithmetic()
> #endif
> }
> -#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
> +/* PowerPC 64 (when gcc has -mlong-double-128) breaks here because
> + * of issues constant folding 128bit IBM long doubles.
> + */
> +#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) &&...
2010 Oct 07
2
long double, C, fortran
I'm using .Call() to call C code from R under Windows (on an Intel
Core 2 duo). The C code involves some very small numbers, and I think
I'm losing precision using doubles. I thought I might use long doubles
to see if I can get that precision back. I have a few questions:
1. Does this affect the portability to other OSs or processors?
2. I'm returning the results in a matrix. Will
2019 Dec 13
0
Build failure on powerpc64
..../src/main/arithmetic.c.orig 2019-12-12
> 18:30:12.416334062 +0000
> > +++ ./src/main/arithmetic.c 2019-12-12 18:30:44.966334062 +0000
> > @@ -179,7 +179,10 @@ void attribute_hidden InitArithmetic()
> > #endif
> > }
>
> > -#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
> > +/* PowerPC 64 (when gcc has -mlong-double-128) breaks here because
> > + * of issues constant folding 128bit IBM long doubles.
> > + */
> > +#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZE...