similar to: [LLVMdev] wrong code bugs

Displaying 20 results from an estimated 40000 matches similar to: "[LLVMdev] wrong code bugs"

2009 Mar 30
0
[LLVMdev] wrong code bugs
Jay, On Mar 30, 2009, at 10:29 AM, Jay Foad wrote: > Hi, > > http://llvm.org/bugs/show_bug.cgi?id=3367 > http://llvm.org/bugs/show_bug.cgi?id=3831 > > These bugs are both cases where the optimizers are generating > incorrect code. They have simple test cases and reasonably > straightforward fixes. I've just done a successful test-suite run on > i686-pc-linux-gnu
2009 Mar 30
1
[LLVMdev] wrong code bugs
Jay, > On Mar 30, 2009, at 10:29 AM, Jay Foad wrote: > >> Hi, >> >> http://llvm.org/bugs/show_bug.cgi?id=3367 Do you have updated test case that fails with mainline? The current test case in bugzilla does not fail for me. Thanks, - Devang >> >> http://llvm.org/bugs/show_bug.cgi?id=3831 >> >> These bugs are both cases where the optimizers are
2008 Oct 21
4
[LLVMdev] endian independence
Hi, I'd like to use LLVM to compile and optimise code when I don't know whether the target CPU is big- or little-endian. This would allow me to create a single optimised LLVM bitcode binary of an application, and then run it through a JIT compiler on systems of differening endianness. I realise that in general the LLVM IR depends on various characteristics of the target; I'd just
2011 May 06
8
[LLVMdev] nightly test suite failure: ms_struct-bitfield-init-1.c
Hi, I've just tried to run the test-suite, for the first time in ages. It stops rather abruptly with: $ make TEST=nightly report report.html /home/jay/llvm/local/bin/llvm-gcc -I/home/jay/llvm/gitobjdir/projects/test-suite/SingleSource/UnitTests -I/home/jay/svn/llvm-project/test-suite/trunk/SingleSource/UnitTests -I/home/jay/git/llvm/projects/test-suite/include -I../../include
2011 May 07
2
[LLVMdev] nightly test suite failure: ms_struct-bitfield-init-1.c
On May 6, 2011, at 4:57 PM, Andrew Trick wrote: > On May 6, 2011, at 1:29 AM, Jay Foad wrote: > >> This seems wrong -- if a test fails, it shouldn't stop the whole >> "make", it should just get logged as a failure and continue. > > That's a frustrating aspect of the test-suite Makefiles. I don't know how to work around it without removing the test
2009 May 29
3
[LLVMdev] debug info for global variables when optimising
I see that llvm-gcc now has some support for generating debug info when optimising - thanks! However, it still doesn't generate debug info for global variables when optimising. Is there any reason for this? With the attached patch, the whole test suite passes for me with TEST=ipodbgopt. Thanks, Jay. -------------- next part -------------- A non-text attachment was scrubbed... Name:
2008 Oct 27
3
[LLVMdev] endian independence
>> I'm already working on this myself. Would you be interested in having >> this work contributed back to LLVM? > > If this were to better support target independent languages, it would > be very useful. If you're just trying to *reduce* the endianness > assumptions that leak through, I don't think it's a good approach. > There is just no way to solve
2008 Oct 27
0
[LLVMdev] endian independence
On Oct 21, 2008, at 2:27 AM, Jay Foad wrote: > Hi, > > I'd like to use LLVM to compile and optimise code when I don't know > whether the target CPU is big- or little-endian. This would allow me > to create a single optimised LLVM bitcode binary of an application, > and then run it through a JIT compiler on systems of differening > endianness. Ok. > I realise that
2009 Feb 02
1
[LLVMdev] bug 3367
Please can you consider fixing bug 3367 in the trunk and 2.5 branch? It's an assertion failure in an optimization pass that I hit when compiling a real C++ application. It's caused by -inline not updating the call graph when it replaces a call with an invoke. There's a very small test case attached to the bug, as well as a pretty obvious fix. http://llvm.org/bugs/show_bug.cgi?id=3367
2012 May 04
1
[LLVMdev] llvm-gcc bugs
Hi Jay, they all seem to work with dragonegg, so I closed them. Ciao, Duncan. On 04/05/12 13:37, Jay Foad wrote: > On 1 May 2012 12:34, Jay Foad<jay.foad at gmail.com> wrote: >> The following bugs look like they only relate to llvm-gcc. Can they be >> closed, as llvm-gcc is no longer supported? > > Also: > > http://llvm.org/bugs/show_bug.cgi?id=1375 >
2012 Feb 13
2
[LLVMdev] We need better hashing
On 13 February 2012 09:22, Jay Foad <jay.foad at gmail.com> wrote: > Would it be possible to use CityHash instead for strings? > > http://code.google.com/p/cityhash/ Incidentally there was talk of using CityHash for LLVM's StringMap last year, but I don't think it ever came to anything: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-April/014656.html Jay.
2009 Feb 27
3
[LLVMdev] warning from -instcombine
Hi, I noticed this code in lib/Transforms/Scalar/InstructionCombining.cpp: cerr << "WARNING: While resolving call to function '" << Callee->getName() << "' arguments were dropped!\n"; If you're using LLVM as a static compiler, this warning is a bit incongruous, because it's not formatted in the same way as warnings from
2011 May 06
0
[LLVMdev] nightly test suite failure: ms_struct-bitfield-init-1.c
On May 6, 2011, at 1:29 AM, Jay Foad wrote: > This seems wrong -- if a test fails, it shouldn't stop the whole > "make", it should just get logged as a failure and continue. That's a frustrating aspect of the test-suite Makefiles. I don't know how to work around it without removing the test from your tree. -Andy
2012 May 04
0
[LLVMdev] llvm-gcc bugs
On 1 May 2012 12:34, Jay Foad <jay.foad at gmail.com> wrote: > The following bugs look like they only relate to llvm-gcc. Can they be > closed, as llvm-gcc is no longer supported? Also: http://llvm.org/bugs/show_bug.cgi?id=1375 http://llvm.org/bugs/show_bug.cgi?id=2203 http://llvm.org/bugs/show_bug.cgi?id=2522 Duncan, do you think these should be moved to dragonegg? Thanks, Jay.
2009 Feb 27
0
[LLVMdev] warning from -instcombine
On Feb 27, 2009, at 1:47 AM, Jay Foad wrote: > Hi, > > I noticed this code in lib/Transforms/Scalar/InstructionCombining.cpp: > > cerr << "WARNING: While resolving call to function '" > << Callee->getName() << "' arguments were dropped!\n"; > > If you're using LLVM as a static compiler, this warning is a
2012 May 01
4
[LLVMdev] llvm-gcc bugs
The following bugs look like they only relate to llvm-gcc. Can they be closed, as llvm-gcc is no longer supported? http://llvm.org/bugs/show_bug.cgi?id=3636 http://llvm.org/bugs/show_bug.cgi?id=5011 http://llvm.org/bugs/show_bug.cgi?id=6764 http://llvm.org/bugs/show_bug.cgi?id=8451 http://llvm.org/bugs/show_bug.cgi?id=9310 http://llvm.org/bugs/show_bug.cgi?id=9311
2011 May 07
0
[LLVMdev] nightly test suite failure: ms_struct-bitfield-init-1.c
Fariborz, On May 6, 2011, at 5:07 PM, Fariborz Jahanian wrote: > > On May 6, 2011, at 4:57 PM, Andrew Trick wrote: > >> On May 6, 2011, at 1:29 AM, Jay Foad wrote: >> >>> This seems wrong -- if a test fails, it shouldn't stop the whole >>> "make", it should just get logged as a failure and continue. >> >> That's a
2012 Feb 14
0
[LLVMdev] We need better hashing
On Feb 13, 2012, at 1:27 AM, Jay Foad wrote: > On 13 February 2012 09:22, Jay Foad <jay.foad at gmail.com> wrote: >> Would it be possible to use CityHash instead for strings? >> >> http://code.google.com/p/cityhash/ > > Incidentally there was talk of using CityHash for LLVM's StringMap > last year, but I don't think it ever came to anything: >
2011 Jun 15
0
[LLVMdev] nightly test suite failure: ms_struct-bitfield-init-1.c
On 6 May 2011 09:29, Jay Foad <jay.foad at gmail.com> wrote: > I've just tried to run the test-suite, for the first time in ages. It > stops rather abruptly with: > > $ make TEST=nightly report report.html > > /home/jay/llvm/local/bin/llvm-gcc > -I/home/jay/llvm/gitobjdir/projects/test-suite/SingleSource/UnitTests >
2015 Nov 23
2
asan for allocas on powerpc64
In LowerGET_DYNAMIC_AREA_OFFSET() you're calling MFI->getMaxCallFrameSize(), but it looks like that doesn't return useful information until after the PrologEpilogInserter's PEI::calculateCallsInformation() has run. So maybe the lowering has to be done as part of frame index elimination? (I'm not too familiar with this code.) Jay. On 23 November 2015 at 13:07, Jay Foad