similar to: [LLVMdev] x86_fp80, f80, and -m96bit-long-double

Displaying 20 results from an estimated 6000 matches similar to: "[LLVMdev] x86_fp80, f80, and -m96bit-long-double"

2010 Nov 01
0
[LLVMdev] x86_fp80, f80, and -m96bit-long-double
Hi Joel, > I am working on x86-64 and am working with a C frontend that folds > sizeof(long double) into 12. For now, I am trying to avoid modifying that > part of the frontend by finding a way 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
2010 Nov 02
2
[LLVMdev] x86_fp80, f80, and -m96bit-long-double
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
2010 Nov 03
0
[LLVMdev] x86_fp80, f80, and -m96bit-long-double
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
2010 Nov 01
0
[LLVMdev] x86_fp80, f80, and -m96bit-long-double
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
2010 Nov 01
4
[LLVMdev] x86_fp80, f80, and -m96bit-long-double
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 > command line option (i.e. -m96bit-long-double). Is there no different way to go about
2010 Nov 02
0
[LLVMdev] x86_fp80, f80, and -m96bit-long-double
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.
2008 Mar 27
2
[LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64
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
2009 Sep 30
0
[LLVMdev] long double type on ARM
Hi Jin-Gu Kang! It are possible that the problem you are experiencing have already been solved in the current llvm 2.6 release tree and the current svn trunk. So try using llc from llvm 2.6 release branch or llvm pre2.7 svn trunk! It would be helpful if you could open a bugreport for this issue and attach the problematic od.bc since we need a testcase from the bitcode that exposes the bug inorder
2009 Sep 30
0
[LLVMdev] long double type on ARM
Unlike llvm itself, llvm-gcc needs to be configured for a particular target architecture. It looks like you're using a copy of llvm-gcc that was built to generate x86 code. On Sep 30, 2009, at 6:27 AM, Jin Gu Kang wrote: > Dear LLVM members. > > I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 > version. > > When i compiled 'od' program in
2009 Sep 30
0
[LLVMdev] long double type on ARM
That is from 2.5, and just because there is nothing special listed in config.gcc does not mean it doesn't work. For 2.5, the ARM port of llvm-gcc did not require a separate llvm-arm.cpp source file, so nothing needed to be added to config.gcc. It worked fine as far as I know. For 2.6, you will see that there are some ARM-related changes to config.gcc in llvm-gcc. On Sep 30, 2009,
2009 Sep 30
2
[LLVMdev] long double type on ARM
Hi Bob! I could not find llvm file for ARM target in llvm-gcc 4.2 front end source code. $llvm-gcc-src/gcc/config.gcc file alpha*-*-*) cpu_type=alpha need_64bit_hwint=yes # LLVM LOCAL begin out_cxx_file=alpha/llvm-alpha.cpp # LLVM LOCAL end ;; ... arm*-*-*) cpu_type=arm extra_headers="mmintrin.h" ;; ... i[34567]86-*-*) cpu_type=i386 # LLVM LOCAL begin
2015 Nov 01
4
Representing X86 long double in Debug Info
I'm in the process of teaching the Verifier to validate that the size of debug info variable and the described value matches (already caught a couple of bugs, both in my frontend and in LLVM itself). However, I've run into the following: size of passed value (80) does not match size of declared variable (128) call void @llvm.dbg.declare(metadata x86_fp80* %x, metadata !11, metadata
2009 Sep 30
5
[LLVMdev] long double type on ARM
Dear LLVM members. I am compiling coreutils-7.4 package for ARM linux using LLVM 2.5 version. When i compiled 'od' program in coreutils package using LLVM 2.5, i could see the error message on llc processing. > llvm-gcc -emit-llvm ./od.c -c -o ./od.bc -other-options... > llc -march=arm ./od.bc -f -o ./od.s llc:
2015 Nov 02
2
Representing X86 long double in Debug Info
On Mon, Nov 2, 2015 at 8:38 AM, Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Looking at the code in clang CGDebugInfo just passes through the width of > the type as it is described by the TypeInfo, which in turn is defined by > the Target. At the moment I do not understand why an x86_fp80 is reported > to be 128 bits wide. (Since it’s a type natively
2015 Nov 03
2
Representing X86 long double in Debug Info
Looking into this more, what happens at the LLVM level is that we declare the size to be 80 bits and to find the storage size, we round up that size to the ABI alignment, so I could change the verifier check to do the same, which would solve the immediate issue for me. However, I would still like to figure out the DWARF question, esp. because it will be applicable to `i1`. On Mon, Nov 2, 2015 at
2008 Mar 27
0
[LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64
Does this fix it? Index: lib/Target/X86/X86Subtarget.h =================================================================== --- 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"; -
2008 Mar 27
1
[LLVMdev] llvm-gcc 4.2 assertion failed on linux x86_64
Probably better to move the discussion to a bug? Evan On Mar 27, 2008, at 9:04 AM, Duncan Sands wrote: > Does this fix it? > > Index: lib/Target/X86/X86Subtarget.h > =================================================================== > --- lib/Target/X86/X86Subtarget.h (revision 48879) > +++ lib/Target/X86/X86Subtarget.h (working copy) > @@ -144,9 +144,12 @@ > >
2013 Apr 15
1
[LLVMdev] Contradiction in DataLayout string
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
2015 Nov 03
2
Representing X86 long double in Debug Info
Adrian Prantl via llvm-dev wrote on Mon, 02 Nov 2015: > Looking at the code in clang CGDebugInfo just passes through the > width of the type as it is described by the TypeInfo, which in turn > is defined by the Target. At the moment I do not understand why an > x86_fp80 is reported to be 128 bits wide. The x86-64 and Darwin/i386 ABI define the size of the 80 bits extended
2009 Feb 11
1
[LLVMdev] Suggested change to docs re: double/float constant syntax.
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 =