similar to: [LLVMdev] Floating point number format in .ll files changed?

On Oct 2, 2007, at 8:15 AM, Jan Rehders wrote: > Hi, > > after upgrading to 2.1 I noticed that the format for floating point > numbers in .ll files apparently changed. I now get errors like > > "llvm-as: var.ll:48,0: Floating point constant invalid for type" > > for such code: > > "@gmFloat = constant float 0.3". > > I checked with llvm-gcc

Le 2 juin 2010 à 12:21, Eli Friedman a écrit : > On Wed, Jun 2, 2010 at 2:59 AM, Stéphane Letz <letz at free.fr> wrote: >> Hi, >> >> We need to generate "Floating point constants" in our code. In http://llvm.org/docs/LangRef.html it is explained that FP has to follow special encoding rules to be handled by LLVM later one (hexadecimal coding...) >>

On Jun 2, 2010, at 3:28 AMPDT, Stéphane Letz wrote: > > Le 2 juin 2010 à 12:21, Eli Friedman a écrit : > >> On Wed, Jun 2, 2010 at 2:59 AM, Stéphane Letz <letz at free.fr> wrote: >>> Hi, >>> >>> We need to generate "Floating point constants" in our code. In http://llvm.org/docs/LangRef.html it is explained that FP has to follow special

Hi, We need to generate "Floating point constants" in our code. In http://llvm.org/docs/LangRef.html it is explained that FP has to follow special encoding rules to be handled by LLVM later one (hexadecimal coding...) Is there any code available in LLVM to handle this kind of "standard float to LLVM float" conversion? Thanks. Stéphane Letz

On Wed, Jun 2, 2010 at 2:59 AM, Stéphane Letz <letz at free.fr> wrote: > Hi, > > We need to generate "Floating point constants" in our code. In http://llvm.org/docs/LangRef.html it is explained that FP has to follow special encoding rules to be handled by LLVM later one (hexadecimal coding...) > > Is there any code available in LLVM  to handle this kind of

This patch supplies software IEEE floating point support. The comment from the patch reproduced below says all there is to say. This patch contains the prior "cleanup" patch; please don't apply that one. Please let me know of any bugs. It is tested reasonably well, but until I put together random tests it's hard to have 100% confidence. Neil. /* A self-contained host- and

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.

I'm breaking this out from LLVM asserts thread. Here are all the assertions in APInt I consider should be recoverable: APInt::APInt: bitwidth too small Null pointer detected! APInt::getBitsNeeded: Invalid string length string is only a minus! Invalid radix APInt::fromString: Radix should be 2, 8, 10, or 16! Invalid string length string is only a minus Insufficient bit width Invalid digit in

Hi, I am trying to print a hex value ( 4111999A for 9.1) for a corresponding floating point number. The routine convertToHexString in APFFloat class only prints in C99 Floating point hexagondecimal constant (eg 1.e00000p3). Without writing my own routine, how do I get to print the hexadecimal representation for a floating point value? Sirish -- Qualcomm Innovation Center, Inc is a member

Le 2 juin 2010 à 19:48, Dale Johannesen a écrit : > > On Jun 2, 2010, at 3:28 AMPDT, Stéphane Letz wrote: > >> >> Le 2 juin 2010 à 12:21, Eli Friedman a écrit : >> >>> On Wed, Jun 2, 2010 at 2:59 AM, Stéphane Letz <letz at free.fr> wrote: >>>> Hi, >>>> >>>> We need to generate "Floating point constants"

Ok, here is the patch again... I also included fixes for the bits that originally gave my mailer fits... Two votes for orange, so I went with orange... Doing diffs in .: --- ./lib/AsmParser/LLLexer.cpp.~1~ 2007-12-14 22:09:06.000000000 -0800 +++ ./lib/AsmParser/LLLexer.cpp 2007-12-15 13:02:47.000000000 -0800 @@ -54,7 +54,7 @@ static uint64_t HexIntToVal(const char * Result +=

Hi, > • Emit LLVM assembly from your compiler's native language. > for: very straightforward to get started > against: the .ll parser is slower than the bitcode reader when > interfacing to the middle end > against: you'll have to re-engineer the LLVM IR object model and asm > writer in your language > against: it may be harder to track changes to the IR One more

Hello All, the patch below adds a target lowering hook to state that the target supports (or not) floating point exception behavior. The patch is small and contains one possible use for the hook (folding potentially exception raising fp operations). Any comments? Thanks Pedro -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: opensource1.txt

I assume you meant to ask for ports that *don’t* support floating point exceptions. To my knowledge, neither R600 nor NVPTX support floating point exceptions. —Owen > On Aug 8, 2014, at 2:41 PM, Eric Christopher <echristo at gmail.com> wrote: > > There's a lot of cut and paste in those routines. Can you do something > to unify it a bit? Also, do we have any ports that

> ------------------------------ > > Message: 4 > Date: Wed, 2 Jun 2010 11:07:39 -0700 > From: Dale Johannesen <dalej at apple.com> > Subject: Re: [LLVMdev] Generating Floating point constants > To: St?phane Letz <letz at free.fr> > Cc: llvmdev at cs.uiuc.edu > Message-ID: <AEC895CC-E887-4329-8743-FA606BD401F6 at apple.com> > Content-Type:

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

>From the language guide: "The one non-intuitive notation for constants is the optional hexadecimal form of floating point constants. For example, the form 'double 0x432ff973cafa8000' is equivalent to (but harder to read than) 'double 4.5e+15'. The only time hexadecimal floating point constants are required (and the only time that they are generated by the disassembler) is

On Aug 19, 2009, at 9:36 PM, Erick Tryzelaar wrote: > I'm breaking this out from LLVM asserts thread. Here are all the > assertions in APInt I consider should be recoverable: > > APInt::APInt: > bitwidth too small > Null pointer detected! Hi Eric, As we discussed on IRC, I don't think there is any reason for the implementation of these methods to check these

Hi, I've been playing around with the APFloat class lately and I came across behavior I was not expecting based on reading the implementation comments and I'm wondering if it's a bug or intentional. The behavior concerns converting an APFloat to a string and back again. In the implementation of ``APFloat::toString(...)`` you can specify ``FormatPrecision`` as 0. The method comments

>> >> I wonder why APFloat::convertToDouble asserts if it is not an >> APFloat::IEEEdouble while the name "convertToDouble" suggests that it >> converts when it is not a double. > > The conversion is to (host) double, as the name implies. Among > APFloat types, that is only implemented for APFloat::IEEEdouble. > yes, it's to host double