similar to: [LLVMdev] -g in data-only files

Not even for externally visible symbols? That sounds like a bug. Evan On Jul 8, 2008, at 1:01 PM, Dale Johannesen wrote: > I have just noticed that -g doesn't emit debug info for data-only > files. > Before I get deep into fixing this, let me make sure it isn't > intentional? > > _______________________________________________ > LLVM Developers mailing list >

Hello- Shouldn't this catch swapcontext as well? Alistair On 26 May 2010, at 22:14, Dale Johannesen wrote: > > On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: > >> vfork and getcontext have wildly platform-dependent semantics. >> Handling >> them conservatively is reasonable, even if some platforms don't need >> it. >> >> Dan >

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

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>

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

On Sep 2, 2010, at 2:44 PMPDT, Jeff Kunkel wrote: > I need to track which MachineBasicBlocks branch into other > MachineBasicBlocks. How do I do it? Look at the Predecessor/Successor lists, which are target-independent > I see a MachineOperand can hold a MachineBasicBlock*. Does this mean > the instruction may branch to the MachineBasicBlock, or can it be > something like an

It is at the end allowing for oddities like debug info and multiple branches. You might want to look at AnalyzeBranch. On Sep 2, 2010, at 4:19 PMPDT, Jeff Kunkel wrote: > Is there any way to tell where in the Instruction list, the branch > to the other MachineBasicBlock happens? I know in the BasicBlock had > a nice api for it. > > Thanks, > Jeff Kunkel > > On Thu,

On May 12, 2009, at 5:01 PMPDT, OvermindDL1 wrote: > 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:

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

Hi, I ran Spec2006 with -O4. All integer benchmarks passed, but only 8 out 17 of floating point benchmarks passed. Is this normal or I made a mistake in my build? Reza -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100722/4c4a81a9/attachment.html>

On Jul 22, 2010, at 4:18 PMPDT, Reza Yazdani wrote: > Hi, > > I ran Spec2006 with -O4. All integer benchmarks passed, but only 8 > out 17 of floating point benchmarks passed. Is this normal or I > made a mistake in my build? Hi Reza. Somebody on Linux should answer, but I don't think it's normal. You may have checked out the source at a moment when it had a bug

I'm close to confirming that I get the equivalent results from the test-suite with my changes, compared to a fresh tree, on a Linux x86 64 bit box. When that is the case, may I check in my current changes for the LLVM side? My preference is to develop the mult-alt support incrementally, rather than one big check-in, as I get nervous sitting on a lot of changes for a long time. I feel this

On Aug 10, 2010, at 1:47 PMPDT, Bueno, Denis wrote: > On 8/10/10 2:39 PM, "Dale Johannesen" <dalej at apple.com> wrote: > >> What environment is this? Some JITs work better than others. > > Ubuntu Lucid, x86_64. No idea then. It was surely tested on x86-64 Linux, if not that exact variant.

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

Thanks. I could take a look at the lines and all of them have smull instruction like 'smull r0, r1, r0, r1'. Won On Wed, Jul 8, 2009 at 2:54 PM, Dale Johannesen <dalej at apple.com> wrote: > > On Jul 8, 2009, at 12:52 PMPDT, Won J Jeon wrote: > > I tried a couple of options (-mcpu=arm1136j-s, -mcpu=arm1136jf-s, > -march=armv6, ...) to let the compile know the

I didn't see swapcontext in the list in gcc's special_function_p function... -bw On May 26, 2010, at 2:20 PM, Alistair Lynn wrote: > Hello- > > Shouldn't this catch swapcontext as well? > > Alistair > > On 26 May 2010, at 22:14, Dale Johannesen wrote: > >> >> On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: >> >>> vfork and

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

Following is the list of fp benchmarks that fail. They all pass with -O3, but some fail with -O4. I did the test run. Thanks, Reza Estimated Estimated Base Base Base Peak Peak Peak Benchmarks Ref. Run Time Ratio Ref. Run Time Ratio -------------- ------ --------- ---------

Is there any way to tell where in the Instruction list, the branch to the other MachineBasicBlock happens? I know in the BasicBlock had a nice api for it. Thanks, Jeff Kunkel On Thu, Sep 2, 2010 at 5:56 PM, Dale Johannesen <dalej at apple.com> wrote: > > On Sep 2, 2010, at 2:44 PMPDT, Jeff Kunkel wrote: > >> I need to track which MachineBasicBlocks branch into other