search for: f80

...return 0; } % llvm-gcc -std=c99 -m96bit-long-double -emit-llvm -S -o test.ll test.c % llvmc test.ll % valgrind ./a.out |& grep Invalid ==3882== Invalid write of size 4 ==3882== Invalid write of size 2 ==3882== Invalid read of size 4 ==3882== Invalid read of size 2 Looking inside test.ll, I see f80:128:128, but I also see sizeof(long double)*5 folded into 60. Changing f80:128:128 to f80:96:96 does not fix the errors reported by valgrind. If I instead fix the folded constant, the errors go away, of course. Does llvm-gcc not intend to support -m96bit-long-double? Is there any way to inst...

...to tell LLVM that 12 bytes are > allocated for x86_fp80. I think the "fact" that x86 long double is 16 byte aligned on x86-64 is hard-wired in. I'm not sure how hard this would be to control via a command line option (i.e. -m96bit-long-double). > Looking inside test.ll, I see f80:128:128, but I also see sizeof(long > double)*5 folded into 60. Changing f80:128:128 to f80:96:96 does not fix > the errors reported by valgrind. If I instead fix the folded constant, > the errors go away, of course. If you had built llvm-gcc with checking enabled it would have aborted....

Hello, I have the following DataLayout string: e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32 Note that it has f80:128:128 followed by f80:32:32. This is an output from clang on Windows (clang -m32 -emit-llvm). Triple is i686-pc-win32. Documentation doesn't specify the interpretation of such cases. So I have two questions: 1...

...============================================= --- lib/Target/X86/X86Subtarget.h (revision 48879) +++ lib/Target/X86/X86Subtarget.h (working copy) @@ -144,9 +144,12 @@ std::string getDataLayout() const { const char *p; - if (is64Bit()) - p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128"; - else { + if (is64Bit()) { + if (isTargetDarwin()) + p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128"; + else + p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:32:32"; + } else { if (isTargetDarwin()) p = "e-p...

...========= > --- lib/Target/X86/X86Subtarget.h (revision 48879) > +++ lib/Target/X86/X86Subtarget.h (working copy) > @@ -144,9 +144,12 @@ > > std::string getDataLayout() const { > const char *p; > - if (is64Bit()) > - p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128"; > - else { > + if (is64Bit()) { > + if (isTargetDarwin()) > + p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:128:128"; > + else > + p = "e-p:64:64-s:64-f64:64:64-i64:64:64-f80:32:32"; > + } else { > if (i...

Here you go: Starting program: /home/chandlerc/code/compilers/build/llvm-gcc/gcc/cc1 -fpreprocessed -march=k8 testcase.i -o /dev/null warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff0d5fe000 [Thread debugging using libthread_db enabled] foocc1: /home/chandlerc/code/compilers/llvm-gcc/gcc/llvm-types.cpp:81: const llvm::Type* llvm_set_type(tree_node*, const

...ooking for find out how to assign a constant integer value to the variable in llvm ir. The following returns 12, and %var2 = 12. ; ModuleID = 't.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple = "x86_64-pc-linux-gnu" define i32 @test() nounwind readnone { %var1 = xor i32 0, 0 %var2 = add i32 %var1, 12 ret i32 %var2 } Why can't I do?: ; ModuleID = 't.c' target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16...

On Nov 1, 2010, at 12:03 PM, Jonas Maebe wrote: > > On 01 Nov 2010, at 18:37, Duncan Sands wrote: > >> I think the "fact" that x86 long double is 16 byte aligned on x86-64 is >> hard-wired in. > > Note that it's not just about alignment, but mainly about the reserved storage size. > >> I'm not sure how hard this would be to control via a

Hi Duncan, On Mon, 1 Nov 2010, Duncan Sands wrote: > > Does llvm-gcc not intend to support -m96bit-long-double? > > Please open a bug report asking for support for -m96bit-long-double, > to ensure this issue is not forgotten. Given the thread that followed this post, I'm not sure whether you still want a bug report. Is the plan to fix -m96bit-long-double or just remove it

Hi Joel, >>> Does llvm-gcc not intend to support -m96bit-long-double? >> >> Please open a bug report asking for support for -m96bit-long-double, >> to ensure this issue is not forgotten. > > Given the thread that followed this post, I'm not sure whether you still > want a bug report. Is the plan to fix -m96bit-long-double or just remove > it and expect

...rt while on vacation, and ran into a major issue. Given the following llvm-ir: $ clang++ -S -emit-llvm -O3 mangling.cpp -o - -Xclang -cxx-abi -Xclang microsoft ; ModuleID = 'mangling.cpp' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64- v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32" target triple = "i686-pc-win32" define i32 @"?heyimacxxfunction@@YAHXZ"() nounwind readnone { entry: ret i32 42 } Note the ?heyimacxxfunction@@YAHXZ. Now if I generate assembly (using clang or llc) I get:...

Hi Jonas, >> I think the "fact" that x86 long double is 16 byte aligned on x86-64 is >> hard-wired in. > > Note that it's not just about alignment, but mainly about the reserved storage size. actually it is about the alignment, since the reserved storage size is (in LLVM) the number of bytes needed to store the type (i.e. 10 bytes) rounded up by the alignment.

...sue. Given the following llvm-ir: >> >> $ clang++ -S -emit-llvm -O3 mangling.cpp -o - -Xclang -cxx-abi -Xclang microsoft >> ; ModuleID = 'mangling.cpp' >> target datalayout = >> "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64- >> v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32" >> target triple = "i686-pc-win32" >> >> define i32 @"?heyimacxxfunction@@YAHXZ"() nounwind readnone { >> entry: >> ret i32 42 >> } >> >> Note the ?hey...

...an example .ll where we have an alloca that can potentially be scalarized where the index into the vector is a function argument and could be set to any value. (scalar_repl_store_delete.ll): target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v16:16:16-v24:32:32-v32:32:32-v48:64:64-v64:64:64-v96:128:128-v128:128:128-v192:256:256-v256:256:256-v512:512:512-v1024:1024:1024--a64:64:64-f80:128:128-n8:16:32:64" define void @test_fn(<2 x i32>* %src, <2 x i32>* %results, i32 %alignmentOffsets) nounwind alwaysinline {...

...9;ve pretty much got everything else working for my front end which all runs fin in the Jit but I can't get global arrays to work. ; ModuleID = 'test' 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:32:32" target triple = "i686-pc-linux-gnu" @MyArray = external global [1000 x i32] define i32 @foo(i32 %a, i32 %b) { Entry: %mul = mul i32 %b, %a %ptr = getelementptr inbounds [1000 x i32]* @MyArray, i32 0, i32 %a store i32 %mul, i32* %ptr, align 4 ret i32 %a } Comparing i...

...emit-llvm* and there respective file are $ cat enum.c int main() { enum type{one=1,two,three} s; s = one; return s; } $ cat enum.s ; ModuleID = 'enum.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32" target triple = "i386-pc-cygwin" define i32 @main() nounwind { %1 = alloca i32, align 4 %s = alloca i32, align 4 store i32 0, i32* %1 store i32 1, i32* %s, align 4 %2 = load i32* %s, align 4 ret i32 %2 } *Question :* Why there is extra 4 bytes on st...

...ran into a major issue. Given the following llvm-ir: > > $ clang++ -S -emit-llvm -O3 mangling.cpp -o - -Xclang -cxx-abi -Xclang microsoft > ; ModuleID = 'mangling.cpp' > target datalayout = > "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64- > v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32" > target triple = "i686-pc-win32" > > define i32 @"?heyimacxxfunction@@YAHXZ"() nounwind readnone { > entry: > ret i32 42 > } > > Note the ?heyimacxxfunction@@YAHXZ. Now if I gen...

...x = * ((double *) a); *(x+1) = * ((double *) &a[a[0]-2]); } I use generate LLVM code using my own front-end that looks like: ; ModuleID = 'jb.c' 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:32:32-n8:16:32" target triple = "i386-pc-linux-gnu" define void @t2(double* %x) { L.entry: %a = alloca [2 x i64], align 4 %x.addr = alloca double* store double* %x, double** %x.addr %0 = bitcast [2 x i64]* %a to i64* store i64 3, i64* %0 %1 = getelementptr [2...

...> int main() > { >  enum type{one=1,two,three} s; >  s = one; >  return s; > } > > $ cat enum.s > ; ModuleID = 'enum.c' > target datalayout = > "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32" > target triple = "i386-pc-cygwin" > > define i32 @main() nounwind { >   %1 = alloca i32, align 4 >   %s = alloca i32, align 4 >   store i32 0, i32* %1 >   store i32 1, i32* %s, align 4 >   %2 = load i32* %s, align 4 >   ret i32 %2 >...

...OSX via the GDB JIT Interface, I switched the format of the in-memory object files to ELF. I thought this target triple should do:   Triple TT;   TT.setTriple(sys::getProcessTriple());   TT.setObjectFormat(llvm::Triple::ELF); But Clang exits with an error:   backend data layout 'e-m:e-i64:64-f80:128-n8:16:32:64-S128'   does not match expectedtarget description   'e-m:o-i64:64-f80:128-n8:16:32:64-S128'   1 error generated. The target selection is a little tricky here and I wonder if it's on purpose or not. One solution is to add another line:   TT.setOS(llvm::Triple::Unkno...