similar to: [LLVMdev] x86 long double coming

Thanks again, Dale. Hopefully, someone has the answer. Jose -----Original Message----- From: Dale Johannesen [mailto:dalej at apple.com] Sent: Friday, January 29, 2010 3:52 PM To: Jose Rangel Cc: Dale Johannesen Subject: Re: [LLVMdev] llvm-gcc 4.0 question On Jan 29, 2010, at 3:13 PMPST, Jose Rangel wrote: > Hi Dale, > > Is there a way to get llvm 4.2 and os x 10.4 to work

Hi, I think Dale meant to post this to ask the whole group, instead of just me. Basically, I'd like to build llvm-gcc 4.2 on host i686-apple-darwin9 for target powerpc-apple-darwin8. So far my efforts have failed. If you know the answer or can point me in the right direction, I'd be much obliged. Thx, Jose > Hi Dale, > > Is there a way to get llvm 4.2 and os x 10.4 to work

On Jun 6, 2008, at 8:51 AM, Jean-Daniel Dupas wrote: > Hello, > > > I'm playing with llvm/clang and I have a problem when I try to use > the -ast-print options for a file that uses long double. > > The Basic/Targets.cpp file defined the x86 (and x86_64) long double > type as APFloat::x87DoubleExtended. > Then, when the AST printer try to write a long double

Hello, I'm playing with llvm/clang and I have a problem when I try to use the -ast-print options for a file that uses long double. The Basic/Targets.cpp file defined the x86 (and x86_64) long double type as APFloat::x87DoubleExtended. Then, when the AST printer try to write a long double literal value (using VisitFloatingLiteral()), it call FloatingLiteral- >getValueAsDouble()

On Jan 29, 2010, at 2:55 PMPST, Jose Rangel wrote: > Hi Dale, > > Thanks for getting back. I may not be able to switch to llvm 4.2 at > this > time. I did try: > > llvm-gcc --emit-llvm -c sumarray.c -o sumarray.bc > llc -march=ppc32 sumarray.bc > gcc -arch ppc sumarray.s > > And this produced a ppc binary that worked (at least in this case). > > Do you

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

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

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

Hi Dale, Thanks for getting back. I may not be able to switch to llvm 4.2 at this time. I did try: llvm-gcc --emit-llvm -c sumarray.c -o sumarray.bc llc -march=ppc32 sumarray.bc gcc -arch ppc sumarray.s And this produced a ppc binary that worked (at least in this case). Do you know if this approach is worthwhile? Thx, Jose -----Original Message----- From: Dale Johannesen [mailto:dalej at

Actually the 2.8 fork is coming up tomorrow and I'm thinking maybe we should wait until after that. Is this something you really want to get in 2.8? On Sep 1, 2010, at 6:29 PMPDT, John Thompson wrote: > Dale, > > Thanks. It's not changed, but I've enclosed a fresh patch against > today's trunk. > However, I'm seeing 28 unexpected failing tests in

I'm using .Call() to call C code from R under Windows (on an Intel Core 2 duo). The C code involves some very small numbers, and I think I'm losing precision using doubles. I thought I might use long doubles to see if I can get that precision back. I have a few questions: 1. Does this affect the portability to other OSs or processors? 2. I'm returning the results in a matrix. Will

Assign the bug to me and I'll fix it in TOT next week! Thanks for narrowing it down! On Wednesday, September 22, 2010, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi all, > > I think I figured it out: > 112804 causes 64-bit UNPCKLBW to no longer be selected for certain cases. > 112805 is benign. > 112806 causes 64-bit UNPCKHBW to no longer be selected for

On Oct 11, 2008, at 12:49 AM, Duncan Sands wrote: > On Friday 10 October 2008 20:29:49 Michael wrote: >> What command and options should be used to convert C++ to C? > > Try this: > > llvm-gcc -c -O3 -emit-llvm file.cpp -o - | llc -march=c -o - > > It should spray C code to standard out. Bear in mind that if you use features from the C++ library, you are still going

Hi Dale, Thanks for replying. Concerning Darwin, I compiled this test on snow leopard and ran it using rosetta (that is, using -arch ppc -m32). I will try this later on leopard. Thanks, Jose ________________________________ From: Dale Johannesen [mailto:dalej at apple.com] Sent: Friday, January 22, 2010 3:10 PM To: Jose Rangel Cc: Dale Johannesen; llvmdev at cs.uiuc.edu

On Feb 23, 2009, at 10:30 AMPST, Aaron Gray wrote: > On Mon, Feb 23, 2009 at 6:22 PM, Aaron Gray <aaronngray.lists at googlemail.com > > wrote: > On Mon, Feb 23, 2009 at 6:09 PM, Dale Johannesen <dalej at apple.com> > wrote: > These benchmarks are not distributed with llvm (which doesn't have the > legal right to distribute Spec, for example). If you have

On Mon, Mar 1, 2010 at 6:00 PM, Dale Johannesen <dalej at apple.com> wrote: > No, C only requires support for objects up to 65535 bytes in size.  C99 5.2.4.1. 65535 bytes would be reasonably sufficient; what's the largest supported by the LLVM code generator?

On Sep 21, 2010, at 5:30 PMPDT, Bill Wendling wrote: > LLVM isn't going to stop generating MMX instructions all together. We can't do that. :-) If the user specifically wants MMX (by, say, using the builtins), we have to support that still. The plan to cease generating MMX for generic vectors is a work-in-progress right now. It's not in 2.8. > > -bw Right, early on there

Dale Johannesen wrote: > On Feb 23, 2009, at 10:30 AMPST, Aaron Gray wrote: > > On Mon, Feb 23, 2009 at 6:22 PM, Aaron Gray <aaronngray.lists at googlemail.com<mailto:aaronngray.lists at googlemail.com>> wrote: > On Mon, Feb 23, 2009 at 6:09 PM, Dale Johannesen <dalej at apple.com<mailto:dalej at apple.com>> wrote: > These benchmarks are not distributed with

Dale, Thanks. It's not changed, but I've enclosed a fresh patch against today's trunk. However, I'm seeing 28 unexpected failing tests in llvm/test on x86 Linux 64 today. But it's the same on an unmodified tree, so I guess I'm still okay. It passed at one point for me with these changes. -John On Wed, Sep 1, 2010 at 5:04 PM, Dale Johannesen <dalej at apple.com>