Displaying 20 results from an estimated 7000 matches similar to: "[LLVMdev] -Wl,native-cbe problem"
2005 Mar 02
0
[LLVMdev] -Wl,native-cbe problem
I will definately look into this tonight and see if it is a problem with my
recent patch.
On Wednesday 02 March 2005 3:39 am, Markus F.X.J. Oberhumer wrote:
> Reid Spencer wrote:
> > On Tue, 2005-03-01 at 22:07, Markus F.X.J. Oberhumer wrote:
> >>Follow up: After removing the dangling symlink the problem now looks:
> >>
> >>-march=c((anonymous
2005 Mar 02
0
[LLVMdev] -Wl,native-cbe problem
On Wed, 2 Mar 2005, Markus F.X.J. Oberhumer wrote:
> When running the current CVS version on an AMD64 (targeted at 64-bits) I hit
> the following when trying to link with -Wl,native-cbe:
>
> march=c((anonymous namespace)::PrintStackTrace()+0x1e)[0x847a17e]
> /lib/libc.so.6(abort+0xcc)[0x556abbbc]
> -march=c[0x8261958]
> [0x8afe738]
> gccld: /usr/lib/../lib64/X11:
2005 Mar 02
0
[LLVMdev] -Wl,native-cbe problem
Adam,
Looks like you have your first issue with the gccld patch. Could you
please look into this for us? Markus seems to have detected a situation
where -native-cbe is acting like -native ...
On Wed, 2005-03-02 at 00:39, Markus F.X.J. Oberhumer wrote:
> Short update: -native-cbe is currently broken as gccld/llc seems to generate
> assembler code instead of C. To easy debugging of such
2005 Apr 21
0
[LLVMdev] Need help with bugpoint for codegen problem
On Fri, Apr 22, 2005 at 01:46:53AM +0200, Markus F.X.J. Oberhumer wrote:
> Debugging code generator problem!
> <cbe><gcc><program>Warning: While generating reference output, program
> exited with
> non-zero exit code. This will NOT be treated as a failure.
>
> *** The C backend cannot match the reference diff, but it is used as the
> 'known good'
2005 Apr 10
1
[LLVMdev] sys::Program::ExecuteAndWait() caller problems
On Sun, 10 Apr 2005, Markus F.X.J. Oberhumer wrote:
> sys::Program::ExecuteAndWait() requires that the first element in "args"
> should be the name of the program, but (at least) llvm-ld.cpp and gccld.cpp
> fail to do so, thereby effectively swallowing the first parameter.
> This is the reason that -native-cbe has not working for some time - actually
> I wonder why no
2005 Apr 11
0
[LLVMdev] sys::Program::ExecuteAndWait() caller problems
It's correct; the win32 version also expects the first arg to be the
name of the program.
Markus F.X.J. Oberhumer wrote:
> Chris Lattner wrote:
>
>> On Sun, 10 Apr 2005, Markus F.X.J. Oberhumer wrote:
>>
>>> sys::Program::ExecuteAndWait() requires that the first element in
>>> "args" should be the name of the program, but (at least) llvm-ld.cpp
2004 Sep 11
0
[LLVMdev] POST MORTEM: llvm-test changes
For the heck of it I tried upgrading to gcc 3.4.2 (from 3.3.3). It
didn't make a difference. So here are the failures for llvm-test. All
diffs are against the "native" output.
===================== MultiSource/Applications/sgefa
cbe failed differently from jit/llc. First cbe:
84c84
< One-Norm(A) ---------- 8.879153e+02.
---
> One-Norm(A) ---------- 8.879156e+02.
2005 May 13
0
[LLVMdev] LongTy in LowerInvoke.cpp
On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote:
> Chris Lattner wrote:
>> On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote:
>>
>>> There is still one unneeded LongTy in LowerInvoke.cpp - something like
>>> this pseudo-diff should probably get applied.
>>
>>
>> What does this impact?
>
> This causes code like
>
> write(2,
2005 Apr 22
0
[LLVMdev] Need help with bugpoint for codegen problem
On Fri, Apr 22, 2005 at 03:13:44AM +0200, Markus F.X.J. Oberhumer wrote:
> Misha Brukman wrote:
> >On Fri, Apr 22, 2005 at 02:32:25AM +0200, Markus F.X.J. Oberhumer wrote:
> >>[...]
> >>bugpoint: Unknown command line argument '-instcombine-load-vn'. Try:
> >>'bugpoint --help'
> >
> >You need a space between -instcombine and
2005 Apr 20
3
[LLVMdev] misc CVS patches
On Tue, Apr 19, 2005 at 07:01:40AM +0200, Markus F.X.J. Oberhumer wrote:
> While trying to hunt down a codegen bug (not yet found) ...
Have you considered using bugpoint for your codegen debugging needs?
http://llvm.cs.uiuc.edu/docs/Bugpoint.html#codegendebug
> I've collected some small patches you might find useful.
Sweet!
> Please review and apply as you see fit.
I've
2006 Sep 18
2
[LLVMdev] llvm-g++: Internal error
Hi,
i used CVS to checkout the source of llvm and llvm-gcc, compiled and built
them on my machine successfully.
i tried a c-language hello program, it was OK.
But when i tried a c++-language hello program, i got:
~/project/llvm/examples$ llvm-g++ t3.cc -o t3
gccld:
/developer/zsth/project/llvm/src/llvm/lib/Analysis/IPA/CallGraph.cpp:277:
void
2006 Sep 14
1
[LLVMdev] use LLVM to convert C++ code to C code
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
I am newbie to llvm.<br>
<br>
I am unable to generate
2004 May 01
0
[LLVMdev] opt, llcc, ll++, -O1, -O2, -O3
On Sat, 1 May 2004, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote:
> there are two issues concerning invoking optimizations:
>
> 1.
> this document:
> http://llvm.cs.uiuc.edu/docs/GettingStarted.html
> is very nice, it would be good though to add in a section
>
> An Example Using the LLVM Tool Chain
>
> examples on optimization step.
That's an
2008 Jul 16
2
[LLVMdev] bugpoint / cbe Problems
I'm having some trouble using bugpoint with newer version of gcc (bugpoint
debug output below).
I looked into the "conflicting type for malloc" problem and it doesn't seem
easy to solve due to the unknown size of size_t (see LowerAllocations.cpp).
The "void main()" problem is probably a result of this test being converted
from Fortran. I'll have to dig into
2008 Jul 16
2
[LLVMdev] bugpoint / cbe Problems
On Wednesday 16 July 2008 10:31, David Greene wrote:
> On Wednesday 16 July 2008 10:12, David Greene wrote:
> > I'm having some trouble using bugpoint with newer version of gcc
> > (bugpoint debug output below).
>
> I was using gcc 4.1.2. When I try 3.2.3 I get:
>
> bugpoint-test-program.bc.cbe.c:237: warning: conflicting types for built-in
> function
2008 Nov 07
2
[LLVMdev] CBE errors
Hi,
I'm running into some strange errors with the CBE. I've narrowed the
problem down to a very simple CPP program:
main.cpp:
--------------------------------------------------------------------------------
#include <string>
static std::string hello("Hello world!");
int main() {
return 0;
}
2005 May 13
0
[LLVMdev] LongTy in LowerInvoke.cpp
On Fri, 13 May 2005, Markus F.X.J. Oberhumer wrote:
>> Ah ok, in that case, the CBE should be fixed. There are other cases that
>> could cause long arguments to exist on 32-bit systems. If the C compiler
>> takes issue with this, it would be best to tell the CBE to emit casts to C
>> (long) or something.
>
> Actually that's the only case I stumbled over this
2008 Jul 16
0
[LLVMdev] bugpoint / cbe Problems
On Wednesday 16 July 2008 10:12, David Greene wrote:
> I'm having some trouble using bugpoint with newer version of gcc (bugpoint
> debug output below).
I was using gcc 4.1.2. When I try 3.2.3 I get:
bugpoint-test-program.bc.cbe.c:237: warning: conflicting types for built-in
function `memcpy'
bugpoint-test-program.bc.cbe.c: In function `main':
2012 Oct 10
1
[LLVMdev] CBE progress and design
Hello all,
As some of you may remember, I am trying to get the C back-end back in
working condition. I have the old version up and running (including
most of it's pre-existing bugs), email me if you want a patch to the
current trunk.
=== Question 1: new design feedback ===
I am currently looking into moving the CBE to run after the initial
lowering and type legalization phases so that
2012 Oct 11
1
[LLVMdev] CBE progress and design
On 10/10/12 18:57, Nadav Rotem wrote:
> Hi Roel!
>
>
> On Oct 10, 2012, at 5:29 AM, Roel Jordans <r.jordans at tue.nl> wrote:
>
>> Hello all,
>>
>> As some of you may remember, I am trying to get the C back-end back in working condition. I have the old version up and running (including most of it's pre-existing bugs), email me if you want a patch to the