search for: frounding

I am trying to upgrade to the LLVM v4.0 branch, but I am seeing failures in my TableGen descriptions for conversion from FP32 to FP16 (scalar and vector). The patterns I have are along the lines of: [(set (f16 RF16:$dst), (fround (f32 RF32:$src)))] or: [(set (v2f16 VF16:$dst), (fround (v2f32 VF32:$src)))] and these now produce the errors: error: In CONV_f32_f16: Type inference

Hi, all, In PR#1138 and PR#1139, I pointed out that round() with digits<0 would not actually round to an integer. Brian D. Ripley (hereafter BDR) fixed it in R-1.4.0, but the fix introduced a new error, PR#1254 (caught by Ole Christensen). BDR (I'm guessing) fixed the fix; here's the relevant line from fround.c: if(dig <= 0 && fabs(res) < 1e9) res = (int)floor(res +

[ Email repost 3 of 3 ] From: Dirk Eddelbuettel <edd at debian.org> To: R-devel org <r-devel at r-project.org> Subject: [Patch] Minor glitch in 'Writing R Extensions' Date: Mon, 3 Sep 2012 10:58:32 -0500 The (marked up in info mode) manual Writing R Extensions says in 6.1.3 -- Function: double fprec (double X, double DIGITS) Returns the value of X

Hi, > 1e10+5i [1] 1e+10+0e+00i > Im(1e10+5i) [1] 5 maybe little better... --- R-3.5.1.orig/src/main/complex.c 2018-03-26 07:02:25.000000000 +0900 +++ R-3.5.1/src/main/complex.c 2018-07-10 12:50:42.523874767 +0900 @@ -381,6 +381,7 @@ r->i = fround(pow10 * x->i, digits)/pow10; } else { digits = (double)(dig); + if(digits < 1) digits=1; /* a little better */

R> round(100000/3, -2) - 33300 [1] -7.275958e-12 I would have hoped for 0. The problem seems to be specifically for negative "digits". This is in 1.3.1 on Solaris 2.6 (full description at bottom). [Apologies for making everyone read this 3 times; my bug.report() burped.] Peter Dalgaard <p.dalgaard@biostat.ku.dk> says the problem is in fround.c, which reads in part:

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

Hi, I am compiling R2.8.1 on a Sun M4000 machine with Solaris 10. I am using Sun Studio 12. I get the following error: cc -xtarget=native64 -G -L/usr/sfw/lib/sparcv9 -L/opt/csw/lib/sparcv9 -o grDevices.so chull.o devNull.o devPicTeX.o devPS.o devQuartz.o init.o mkdir ../../../../library/grDevices/libs Warning in solve.default(rgb) : unable to load shared library

Hi everyone, According to the current design an intrinsic call that depends on current floating point environment (for example, rounding mode) or change it (for example by raising FP exceptions) is represented by constrained intrinsics. The latter have attached metadata that provide info about current FP environment and have attribute `IntrInaccessibleMemOnly` that helps keeping order of

On a recent FreeBSD 8.0-CURRENT (i386) building R (any version) breaks with the following messages: ---------------------------------------------------------------------- [...snip...] gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c wilcox.c -o wilcox.o gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/usr/local/include

...u.org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html#Optimize-Options> > > -ffp-contract=style > -ffast-math > -fno-math-errno > -funsafe-math-optimizations > -fassociative-math > -freciprocal-math > -ffinite-math-only > -fno-signed-zeros > -fno-trapping-math > -frounding-math > -fsignaling-nans > -fsingle-precision-constant > > etc, and the relevant negations of these options. We can't predict how customers will choose to chain these together, so I think the LLVM optimizer and backend designs should accommodate all possibilities derived from those...

...ions are part of FENV_ACCESS regions and which are not. This takes into account both the semantics of the #pragma as defined by the standard, and the implementation-defined default rules that apply to code outside of any #pragma. GCC currently has the following two related command-line options: -frounding-math: Do not assume default rounding mode -ftrapping-math: Assume FP operations may trap clang accepts but (basically) ignores those options. As a first step, it might make sense to have the FENV_ACCESS default behavior triggered by these options, even while the front end does not yet support the...

...ault mode assumes that the current rounding mode is the > default rounding mode. But the same holds true for many other > intrinsics and even the arithmetic IR operations like add. > > If you want to stop clang from making the default rounding mode > assumption, you need to use the -frounding-math option (or one > of its equivalents), which will cause clang to emit the corresponding > constrained intrinsics instead, for those two as well all other > affected intrinsics. > > I don't see why it would make sense to add another special case > just for those two intrins...

>Date: Thu, 15 Oct 1998 15:30:22 +0200 >To: Guido Masarotto <guido at sirio.stat.unipd.it> >From: Andrea Rossetti <rossetti at stud.unipg.it> >Subject: probably "round()" bug > >Hi to all R people, >I'm using the Guido Masarotto's compiled R, version 0.62.3. >there is a probably bug in round function, in fact I've done: > >>

>Date: Thu, 15 Oct 1998 15:30:22 +0200 >To: Guido Masarotto <guido at sirio.stat.unipd.it> >From: Andrea Rossetti <rossetti at stud.unipg.it> >Subject: probably "round()" bug > >Hi to all R people, >I'm using the Guido Masarotto's compiled R, version 0.62.3. >there is a probably bug in round function, in fact I've done: > >>

I have included the full configure/make output: (the particular error regarding bessel_i.c is at the END of the report). -walter tautz cd build/R-1.4.0 \ && unset noclobber \ && CPPFLAGS=" " \ LDFLAGS="" \ ./configure --prefix=/software/r-1 \ --datadir=/software/r-1/data \ --libdir=/software/r-1/lib \

...S regions and which are not. This takes into account > both the semantics of the #pragma as defined by the standard, > and the implementation-defined default rules that apply to code > outside of any #pragma. GCC currently has the following two > related command-line options: > > -frounding-math: Do not assume default rounding mode > -ftrapping-math: Assume FP operations may trap > > clang accepts but (basically) ignores those options. As a first > step, it might make sense to have the FENV_ACCESS default > behavior triggered by these options, even while the front end &...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 While I'm not an R expert, I have used R on Windows XP. Now I've moved to Ubuntu (Intrepid), and I'm trying to configure R to work with the Gelman and Hill _Data Analysis Using Regression and Multilevel/Hierarchical Models_. So far, it's not working. I start by following the instructions for installing arm and BRugs at

....org/onlinedocs/gcc-6.2.0/gcc/Optimize-Options.html# > Optimize-Options > > -ffp-contract=style > -ffast-math > -fno-math-errno > -funsafe-math-optimizations > -fassociative-math > -freciprocal-math > -ffinite-math-only > -fno-signed-zeros > -fno-trapping-math > -frounding-math > -fsignaling-nans > -fsingle-precision-constant > > etc, and the relevant negations of these options. We can't predict how > customers will choose to chain these together, so I think the LLVM > optimizer and backend designs should accommodate all possibilities derived &g...

...are not. This takes into account > both the semantics of the #pragma as defined by the standard, > and the implementation-defined default rules that apply to code > outside of any #pragma. GCC currently has the following two > related command-line options: > > -frounding-math: Do not assume default rounding mode > -ftrapping-math: Assume FP operations may trap > > clang accepts but (basically) ignores those options. As a first > step, it might make sense to have the FENV_ACCESS default > behavior triggered by these options, even while...

I'm having trouble making todays development snapshot: -DHAVE_CONFIG_H -g -O2 -c stirlerr.c -o stirlerr.o stirlerr.c:34: conflicting types for `Rf_stirlerr' ../../src/include/R_ext/Mathlib.h:557: previous declaration of `Rf_stirlerr' make[3]: *** [stirlerr.o] Error 1 [20] /home/mfa5/gilp/R-versions/R-devel : uname -a SunOS mfa99579 5.6 Generic_105181-11 sun4u sparc SUNW,Ultra-5_10