similar to: [LLVMdev] APFloat::PPCDoubleDouble arithmetic

Hi Hal, On Sun, Oct 2, 2016 at 7:43 PM Hal Finkel <hfinkel at anl.gov> wrote: > Hi Tim, > > How, in general, are you thinking about doing this? I ask because, as you > clearly know, the double-double format is formed by the sum of two > double-precision numbers, and the various arithmetic operations are formed > mostly in terms of double-precision arithmetic on the

I have found some internal test failures due to the wrong constant folding on ppc_fp128. As documented in APFloat::PPCDoubleDouble, APFloat doesn't support PowerPC double-double correctly < https://github.com/llvm-mirror/llvm/blob/492acdd450bcdf9837494d6da029ed064f14fc33/lib/Support/APFloat.cpp#L74 >. To support this, we need to add a second tuple of (sign, exponent, significand) to

I am seeing failures in two tests after migrating to v5.0 final, these are: std/language.support/support.limits/limits/numeric.limits.members/quiet_NaN. pass.cpp and: std/language.support/support.limits/limits/numeric.limits.members/signaling_ NaN.pass.cpp However, these are new tests and it turns out that the underlying problem is that the builtin '__builtin_nanl("")' is

> I'd rather not. The functionality you want is there, feed another > APFloat type through APFloat::convert first. > > Using host FP is not something that should be encouraged; the main > point of APFloat is so people don't have to do that. Why do you want > to, btw? > Yes, i got it working using APFloat::convert. I need host float to output to my backend which

On Jul 9, 2010, at 1:20 PMPDT, Jochen Wilhelmy wrote: >> I'd rather not. The functionality you want is there, feed another >> APFloat type through APFloat::convert first. >> >> Using host FP is not something that should be encouraged; the main >> point of APFloat is so people don't have to do that. Why do you >> want to, btw? > > Yes, i got

On 9/25/2017 5:35 AM, Martin J. O'Riordan via llvm-dev wrote: > > I am seeing failures in two tests after migrating to v5.0 final, these > are: > > std/language.support/support.limits/limits/numeric.limits.members/quiet_NaN.pass.cpp > > and: > > std/language.support/support.limits/limits/numeric.limits.members/signaling_NaN.pass.cpp > > However, these are new

In r187314, APFloat multiplication by with NaNs was made to always yield a positive NaN. I am wondering whether that was the correct decision. It is of course true that the result of a multiplication is undefined in IEEE, however, we were using multiplication by -1.0 to implement IEEE negate, which is defined to preserve the sign bit. r210428 made 0-NaN have IEEE negate behavior, which is good

FYI, I was looking at the SSE/AVX codegen here: http://llvm.org/bugs/show_bug.cgi?id=20578 If LLVM starts caring about FP exceptions, even this won't be possible. Is there a way of doing an IEEE-754 fneg in C/C++? Ie, there's no fneg() in libm, so any C method we choose could cause an exception, and that's not allowed by the IEEE definition of fneg. On Fri, Aug 8, 2014 at 12:29 PM,

On 7 August 2014 20:52, Keno Fischer <kfischer at college.harvard.edu> wrote: > One more update: Since the code generated by the bitcast wasn't ideal > and we were afraid to loose vectorization, etc., we ended up going > with fsub -0.0, x, which for some reason unlike fsub 0.0, x, seems to > be have appropriately at all optimization levels. That's because "fsub 0.0,

Ok. That you for clarifying the point for me. I was primed for a regression because this behavior changed over llvm versions and was causing my tests to fail ;). I'm now doing bitcasting to int, xoring with the signbit and bitcasting back. On Thu, Aug 7, 2014 at 2:59 AM, Owen Anderson <resistor at mac.com> wrote: > Subtraction is also not a correct implementation of negation, for

Ok, I had forgotten about sNaNs. Doesn't the same caveat apply to 0-sNaN then though or does that not signal? Does that mean we need a separate way to handle negate in the IR? Funnily enough, historically I believe we were using the multiplication by -1.0 because it was a more reliable negation that 0-x (from 3.0 until 3.3 at least). Is there a good reason why multiplication by NaN should kill

Is there any intention of making floating absolute and negate primitive IR instructions? I ask because only a few days ago I was also faced with the task of implementing negate in my compiler, and finding no suitable IR instruction, simply subtracted from zero. But this is wrong. I could change my code to do the bit casting and fiddling, but I wonder: would that be lowered appropriately on all

Dear R users, I created a matrix that tells me the first day of use of a category by id. #Calculate time difference test$tdiff<-as.numeric(difftime(as.Date("2002-09-01"), test$ftime, units = "days")) # obtain the index date per person and dcategory index.date.test<-tapply(test$tdiff, list(test$id, test$rcat), max) Nonetheless, at the moment I think will be

APFloat is derived from C code using fixed width storage for the matntissa. When converting to C++ I changed it to variable- width storage for space efficiency and generality reasons. Unfortunately this leads to a complication during float->float conversions that I missed that isn't present when using fixed width storage. Dale - I think this solves the issue correctly whilst preserving

Dietmar, > this fixes single precision floating point but breaks double precision. > for arm-softfloat-linux-gnu, FLOAT_WORDS_BIG_ENDIAN is true while > WORDS_BIG_ENDIAN is false. as far as i've seen, there's only a single > flag for endianess in the llvm target description string, so i don't > really understand how this is supposed to work. Hrm, I think I even

On Dec 8, 2007, at 11:33 AM, Reid Spencer wrote: > Okay, but I imagine that leaves it still being used in APFloat.cpp > which > is also trying to be segregated to the support module. >> >> If this doesn't seem like a clean enough solution, there are other >> ways to potentially decouple APFloat more from the Serialization >> "library." The

Hello. When running clang in Debug mode, I am getting an assertion failure when parsing the following line: float ko = 0x1.1p0; Apparently, the recent changes in the use of StringRef haven't been propagated to all places. Please find attached the trivial patch. Cheers, Enea Zaffanella. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name:

Fixed in r79450, along with an additional one of the same nature. Thanks, - Daniel On Thu, Aug 20, 2009 at 7:42 AM, Enea Zaffanella<zaffanella at cs.unipr.it> wrote: > Hello. > > When running clang in Debug mode, I am getting an assertion failure when > parsing the following line: > > float ko = 0x1.1p0; > > Apparently, the recent changes in the use of StringRef

On Thu, Aug 20, 2009 at 10:13 AM, Daniel Dunbar<daniel at zuster.org> wrote: > Fixed in r79450, along with an additional one of the same nature. > > Thanks, >  - Daniel Thanks Daniel and Enea for finding this! I'm adding a lot more test cases like this to APFloat's unittests so hopefully we won't have any other bugs lying around.

On Mar 6, 2010, at 3:39 AM, Jochen Wilhelmy wrote: > Hi! > > I wonder if llvm::APFloat::toString() can be const since > it should not modify the APFloat. Done in r97883, thanks.