similar to: [LLVMdev] Suggested change to docs re: double/float constant syntax.

>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

Hi, The optimizer folds "(unsigned int) -1.0f" to 0. As a result, the following routine foo returns 0 with optimization, and returns -1 (0xffffffff) without optimization. unsigned int foo() { float myfloat = -1.0f; unsigned int myint = (unsigned int) myfloat; return myint; } INSTCOMBINE ITERATION #0 on IC: ConstFold to: i32 0 from: %conv = fptoui float

Hi! is there an instruction or intrinsic that converts from float to integer with round to even? It should function like open cl-style convert_int_rte(myFloat) -Jochen

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.

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

I have what appears to be a bug in LLVM... I'm deeply hesitant to label it a bug, given my lack of experience with LLVM, but the behaviour of this fragment strongly suggests a bug. In particular, compiling and running this fragment using a fresh SVN build yields this stderr: uccello:/tmp clements$ lli a.out.bc 0 lli 0x005e72b6 char const* std::find<char const*,

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...) >>

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 and it now generates code for the hexadecimal floating point representation. The documentation at

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

hi folks, this is driving me up the wall. Apologies for posting twice in the same week, I'm writing up a thesis. I wish to color-code some dots in an xy plot. I've got a csv file with various elements, one of which is the color-key (with the header 'color'). If the color-key is decimal (eg. 1,2,3) then I can use plot (X ~ Y, col=data$color) The problem, however, is that using

Hi, do you know, a method to convert an decimal value (integer) to the corresponding hexadecimal value ? thinks for help. Romain -- Lorrilli?re Romain UMR 8079 Laboratoire Ecologie, Syst?matique et Evolution B?t. 362 Universit? Paris-Sud 91405 Orsay cedex France tel : 01 69 15 56 85 fax : 01 69 15 56 96 mobile : 06 81 70 90 70 email : romain.lorrilliere at ese.u-psud.fr

Hi, Andreas Neustifter wrote: > Hi Daniel! > > Daniel Dunbar wrote: >> Hi Andreas, >> >> I talked with Chris about this the morning, and I think we agreed that >> lli based tests for this stuff are ok, as long as we limit them to >> just a few. The main thing we basically need lli for is to test the >> generation of the profiling information;

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 Dieter, Sorry my mistake. I wanted to convert them into Decimal (not Hexadecimal). Given this string, the desired answer follows: > ascii_str <- "ORQ>IK" 79 82 81 62 73 75 > ascii_str2 <- "FDC" 70 68 67 - Gundala Viswanath Jakarta - Indonesia On Mon, Dec 22, 2008 at 5:49 PM, Dieter Menne <dieter.menne at menne-biomed.de> wrote: > Gundala

In short if suppose i have some expression as a=b+c-d*e, and with the help of LLVM pass i want to make a string like this:- "[Hexadecimal address of 'b'] [opcode of +] [Hexadecimal address of 'c'] [opcode of -] [Hexadecimal address of 'd'] [opcode of *] [Hexadecimal address of 'e']". Than how can i make it................ -- View this message in

Hi, The -dot-cfg option of opt will write a diagram of an analyzed function's CFG to DOT format. If you then open the DOT file, you will see that the BasicBlocks are uniquely identified with hexadecimal addresses. For example, an edge from one block to another may look like: Node0x10026b0:s0 -> Node0x1004c20; I've been trying to figure out where these hexadecimal addresses

Hi all, I have noticed incorrect parsing of very small hexadecimal numbers like "0x1.00000000d0000p-987". Such a hexadecimal representation can can be produced by sprintf() using the %a flag. The return value is incorrectly reported as 0 when coercing these numbers to double using as.double()/as.numeric(), as illustrated in the three examples below:

Hi all, I've written a patch to extend FileCheck to support matching arithmetic expressions involving variable [1] (eg. to match REG+1 where REG is a variable with a numeric value). It was suggested to me in the review to introduce the concept of numeric variable and to allow for specifying the base the value are written in. [1] https://reviews.llvm.org/D49084 I think the syntax should

On 01/05/2007 7:21 AM, Stephan wrote: > Hi, > >> 0x10L > returns: int 0 > > I would expect: int 16? > This happens with all integer constants given by hexadecimal notation. > It's a bug? Certainly looks like one; I've cc'd this to the bug list (but won't be able to look into fixing it). Duncan Murdoch > > >> sessionInfo() > R

I've been using the nifty: DEBUG(errs() << "Here is the state of things:\n"); style of optional logging, but ran into an issue where I want to dump a table of information. The problem is getting the columns to line up, since the raw_ostream methods write numbers as variable length. I've worked up a patch that adds two new methods to raw_ostream: /// write_hex -