similar to: [LLVMdev] [LLVMbugs] [Bug 1896] New: Global Variable Optimizer fails assertion in OptimizeAwayTrappingUsesOfLoads

On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com> wrote: > > On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: > >> So I (think I) found a bug in the JIT: >> http://llvm.org/bugs/show_bug.cgi?id=4483 >> >> Basically, globals used by a function are allocated in the same buffer >> as the first code that uses it.  However, when you

On Jun 30, 2009, at 11:18 AMPDT, Jeffrey Yasskin wrote: > On Mon, Jun 29, 2009 at 5:50 PM, Dale Johannesen<dalej at apple.com> > wrote: >> >> On Jun 29, 2009, at 5:41 PMPDT, Reid Kleckner wrote: >> >>> So I (think I) found a bug in the JIT: >>> http://llvm.org/bugs/show_bug.cgi?id=4483 >>> >>> Basically, globals used by a

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

Anton, I didn't know that EQUIVALENCE is the only unsupported major Fortran feature, as this bug says. Can you give me an update on the status of the Fortran front-end and what the near-term goals are? I am getting more requests from academics doing HPC compilers and it would be useful to know where Fortran support stands. Other llvmdev'ers may be interested too. Thanks,

Currently the LLVMbugs list only receives emails when a new bug is filed or an existing bug gets finally resolved. The gcc-bugs list on the other hand receives an email for every new comment in bugzilla. This leads to much better transparency, because you can easily see which bugs are currently being worked on; while the current LLVMbugs setup left you totally in the dark. So my suggestion would

I'm forwarding this bug resolution because it has a pretty wide impact on LLVM developers. This bug (451) has been resolved (well, works for me anyway). If you have reconfigured your build tree since October 4th, you need to reconfigure again. The bug produced shared objects that don't have a .so extension. Reconfiguring will fix this problem. The notes below show what was needed to

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

> Anyone seeing this failure? > > FAIL: /Volumes/Gir/devel/llvm/llvm.src/test/CodeGen/Generic/2007-04-14-EHSelectorCrash.ll > for PR1326 Seems it was due to my changes. Investigating. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, Tom > * Intel and AMD machines running on Win32 using MinGW libraries > (native) As you can see here, LLVM is happy on win32. > without installing third-party libraries? Do these libraries need to > be distributed along with the generated executables? It depends on, how exactly you're compiling LLVM. If you'll go with Cygwin-generated binaries, then yes

Vikram, > I didn't know that EQUIVALENCE is the only unsupported major Fortran > feature, as this bug says. Can you give me an update on the status of > the Fortran front-end and what the near-term goals are? Ok. I was going to post something soon after 2.2 release, but let's do it now. LLVM 2.2 will contain (as a part of llvm-gcc 4.2) a port of gfortran compiler to the LLVM

Hi All, I did something dumb and bugzilla is sending out a ton of spam. We're working on it, I apologize for the email! -Chris

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

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

You may have noticed I added an "inlinehint" attribute to the IR yesterday, to represent user declarations that hint inlining would be a good idea ("inline" keyword). Chris and I have been discussing how to hook it up to the C++ FE. Consider: class X { int A(int x) {....} inline int B(int x); }; inline int X::B(int x) {...} Per the language standard, A and B

On Tue, May 12, 2009 at 5:01 PM, Dale Johannesen <dalej at apple.com> wrote: > > On May 12, 2009, at 3:09 PMPDT, OvermindDL1 wrote: > >> The error given: >> >> ..\..\..\..\trunk\lib\Transforms\Scalar\LoopStrengthReduce.cpp(1016) : >> error C2668: 'abs' : ambiguous call to overloaded function >> >> It should be rather obvious from the

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?

What environment is this? Some JITs work better than others. On Aug 10, 2010, at 1:35 PMPDT, Eric Christopher wrote: > On Aug 10, 2010, at 1:30 PM, Bueno, Denis wrote: > >> Running lli under gdb gives >> >> Program received signal SIGSEGV, Segmentation fault. >> [address] in ?? () >> (gdb) bt >> #0 [address] in ?? () >> Cannot access memory at

I tried a couple of options (-mcpu=arm1136j-s, -mcpu=arm1136jf-s, -march=armv6, ...) to let the compile know the specific ARM processor, but the same issue is still there. I tried to take a look at .s file in /tmp directory, but it's already cleaned up. Is it because I enabled the optimization option when I compiled llvm? Regards, Won On Wed, Jul 8, 2009 at 1:28 PM, Dale Johannesen <dalej

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