similar to: [LLVMdev] String format

On Mon, Feb 2, 2015 at 9:51 AM, Robin Eklind <carl.eklind at myport.ac.uk> wrote: > (forgot to cc the list) > > Answers, questions and assumptions are inlined in the response. > > If someone with knowledge of the LLVM IR type system could take a look at > my assumptions below I'd be very happy. > > On 01/30/2015 02:24 AM, Sean Silva wrote: > >> On Thu,

>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

Hello Sean, Thank you for your reply. I'll give your suggestion to item 6 and 7 a try tonight. I'll start a compilation and let it run throughout the night. My laptop (x61s) is 8 years old by know, so compiling LLVM takes a little time :) Regarding item 8. I don't know if anyone is using "": in the wild so fixing the implementation might make sense. If not the

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

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

Alexander, On Darwin the "__cstring" section (really section with type S_CSTRING_LITERAL) is defined to contain zero terminate strings of bytes that the linker can merge and re-order. If you want pad bytes before and after the string, you need to put the strings in a different section (e.g. __TEXT, __const). But, CF/NSString literals will be problematic. The compiler emits a static

On Sun, 15 Jul 2007, Ben Chambers wrote: > ... > store float 0x4016A3D700000000, float* %f > ... > > Which is correct, but is a pain to have to parse. Ideally, floating > point would be printed like it says in the language guide, only using > the hexadecimal representation when decimal representation is > impossible. In this case, however, 5.66e+00 seems pretty

It appears to me based on my experiments with llvm-as that literal floating-point constants may be specified in the 64-bit IEEE hexadecimal format, but not in the 32-bit format. For instance, this file: target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32- i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64- f80:128:128" target triple =

(forgot to CC llvmdev) On Thu, Mar 21, 2013 at 5:54 PM, Alexander Potapenko <glider at google.com> wrote: > Hey Anna, Nick, Ted, > > We've the following problem with string literals under ASan on Mac. > Some global string constants end up being put into the .cstring > section, for which the following rules apply: > - the strings can't contain zeroes in their

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 +=

Gabor Csardi writes: > Btw. for some motivation, here is a (surely incomplete) list of > languages with '+' as the string concatenation operator: > > ALGOL 68, BASIC, C++, C#, Cobra, Pascal, Object Pascal, Eiffel, Go, > JavaScript, Java, Python, Turing, Ruby, Windows Powers hell, > Objective-C, F#, Sc-ala, Ya. The situation for R is rather different from that of a

Hi James, I like that suggestion very much but I think keeping the order of the two sides as initially proposed makes more sense. In printf/scanf the string is first because the primary use of these functions is to do I/O and so you first specify what you are going to output/input and then where to capture variables. The primary objective of FileCheck variables and expressions is to capture/print

I don't think it is reasonable to change the parser this way. This is currently valid R code: a <- "foo" "bar" and with the new syntax, it is also valid, but with a different meaning. Or you can even consider a <- "foo" bar %>% func() %>% print() etc. I like the idea of string literals, but the C/C++ way clearly does not work. The Python/Julia way

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

Am 28.08.2011 20:02, schrieb geovanisouza92 at gmail.com: > Hi, Jo! > > I'm trying create a new programming language, and I want that it have > Unicode support (support for read and manipulate rightly the source-code and > string literals). > > But, in addition, my programming language supports "string interpolation" > string, and in these interpolations, tiny

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 Wed, 14 Jun 2017, G?bor Cs?rdi wrote: > > > I like the idea of string literals, but the C/C++ way clearly does not > > work. The Python/Julia way might, i.e.: > > > > """this is a > > multi-line > > lineral""" > > luke-tierney at uiowa.edu: > This does look like a promising option; some more careful checking

To be clear, I do not intend to add support for hex specifier in the current patch, I just want to make sure the syntax we choose is going to allow it later. My immediate use case is decimal integer and I intend to write the code so that it's easy to extend to more type of numeric variables and expressions later. This way we'll only add specifier that are actually required by actual

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