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