Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] Build error with gcc 4.1.1"
2006 Sep 06
3
[LLVMdev] Build error with gcc 4.1.1
I fixed my immediate problem by using a different version
of gcc.
Chris Lattner kirjoitti:
> The offending line of code looks fine on our side,
> but there could be something I'm missing.
For what it is worth, I've run into problems with boost_concept_check
before when using Boost.Python. Some versions of gcc worked fine,
while others gave error messages relating to
2006 Sep 06
0
[LLVMdev] Build error with gcc 4.1.1
On Fri, 1 Sep 2006, [ISO-8859-1] Kellom�ki Pertti wrote:
> I am trying to build llvm 1.8a with gcc 4.1.1 and I get the attached error.
> Are there any easy workarounds or should I just try another version of gcc?
I haven't seen this error, but I'm not using GCC 4.1.1. It would be good
to track this down and either file a bug with GCC or for us to get it
fixed in LLVM. The
2006 Sep 06
0
[LLVMdev] Build error with gcc 4.1.1
On Wed, 6 Sep 2006, [ISO-8859-1] Pertti Kellom�ki wrote:
> I fixed my immediate problem by using a different version
> of gcc.
ok.
> Chris Lattner kirjoitti:
>> The offending line of code looks fine on our side,
>> but there could be something I'm missing.
>
> For what it is worth, I've run into problems with boost_concept_check
> before when using
2006 Sep 07
1
[LLVMdev] Build error with gcc 4.1.1
Chris Lattner kirjoitti:
> Question: does GCC 4.1.2 (if it exists) or GCC mainline fix the
> problem? If so, we should document 4.1.1 as being buggy.
GCC 4.1.2 does not exist yet, but I grabbed the 4.2-20060906
snapshot of GCC and it compiled LLVM without problems. I verified
that the hello world example from Getting Started worked, but did
not test beyond that. This is on x86 Gentoo.
--
2007 Nov 09
2
[LLVMdev] Atomicity and synchronization
There was some discussion in the summer on the mailing list
about atomicity and synchronization primitives for LLVM. Is
there any progress being made in that department?
--
Pertti
2006 Nov 15
4
[LLVMdev] Byte code libraries and linking
As I have explained in another thread, I am in the process of
porting portions of newlib to LLVM. The target system has no
operating system and a custom processor which may be changed from
compilation to compilation.
We intend to use LLVM as the front end and generate target specific
code from LLVM byte code. For various reasons (whole program
optimization being one of them), it would seem to
2006 Nov 02
4
[LLVMdev] LLVM and libc
We are going to use LLVM in a compiler project for transport
triggered processors. See Wikipedia for more on transport triggering:
<http://en.wikipedia.org/wiki/Transport_Triggered_Architectures>.
One thing we need is some sort of libc. We are targeting embedded
systems, and I have been looking at things like newlib. Are there
people out there doing something similar? Or any advice or
2006 Nov 23
3
[LLVMdev] Byte code portability (was Re: libstdc++ as bytecode, and compiling C++ to C)
On Wed, 22 Nov 2006, [ISO-8859-1] Pertti Kellom�ki wrote:
> Aside from stuff that depends on system headers, are there any other
> dependencies on the host system? In other words, will llvm-gcc produce
> exactly the same byte code for a given set of source files regardless of
> where compilation takes place? This has obvious implications on
Yes. Many aspects of the target compiler
2006 Nov 09
9
[LLVMdev] LLVM and newlib progress
I managed to compile newlib with llvm-gcc yesterday. That
is, the machine independent part is now basically done, and
the syscall part contains no-op stubs provided by libgloss.
I haven't tested the port yet, but since newlib has already
been ported to many architectures, I would be pretty surprised
if there were any major problems.
A couple of things I noticed when configuring newlib for
2007 Apr 10
2
[LLVMdev] Using LLVM as a cross compiler without fully retargeting gcc?
We are using LLVM to target a customizable processor
architecture. One of the activities to be supported is
architecture exploration, where one explores the processor
design space (e.g. connectivity, number of FUs) and tries
to find a good match for the application at hand.
The exploration needs to be relatively rapid, so targeting
and compiling gcc for each of the processor variants is
not
2006 Nov 09
2
[LLVMdev] LLVM and newlib progress
Hi Reid,
I'll write a separate post about the intrinsics, but just
a quick note about the CFLAGS issue.
Reid Spencer kirjoitti:
> On Thu, 2006-11-09 at 15:29 +0200, Pertti Kellomäki wrote:
>> Another related thing is that even when I defined -emit-llvm in
>> what I thought would be a global CFLAGS for all of newlib, it did
>> not get propagated to all subdirectories.
2006 Nov 06
0
[LLVMdev] LLVM and libc
I have been browsing through the newlib documentation at
<http://sources.redhat.com/newlib/> and pondering about
how newlib relates to LLVM. Comments welcome, again.
As I see it, there are basically two parts of libc that need to be
considered. Much of libc is stuff like atoi(), isalpha(), etc. which are
just convenience routines written in ANSI C. For these, it should be
sufficient to
2006 Nov 09
0
[LLVMdev] LLVM and newlib progress
Chris Lattner kirjoitti:
> There isn't any really good reason to have an llvm intrinsic for write,
> just leave 'write' as an external function.
So is the opportunity for inlining the only reason for e.g. the
llvm.memcpy intrinsic?
--
Pertti
2006 Nov 15
0
[LLVMdev] Byte code libraries and linking
To follow up on my own post:
> The only concern here is that this brings in all of libc, but I
> suppose it should be easy enough to run dead code elimination on
> linked.bc to shake out the unused bits?
Cursory browsing of LLVM optimization passes did not turn up
anything directly applicable, at least "opt -adce" and "opt -globaldce"
did not reduce the size of the
2006 Nov 22
0
[LLVMdev] Byte code portability (was Re: libstdc++ as bytecode, and compiling C++ to C)
Chris Lattner wrote:
> On Tue, 21 Nov 2006, Emil Mikulic wrote:
>> LLVMers, given the same endianness and pointersize, can one mix and
>> match LLVM bytecode files produced on different platforms?
>
> No, not in general. For example, on the mac, printf it often #defined to
> printf$ldbl, which doesn't exist on linux. System headers generally foil
> the ability
2006 Nov 28
1
[LLVMdev] Type visitor?
Is there some fundamental reason why instructions have a
visitor interface but types do not? Or does the support
in fact exist and I am just blind?
--
Pertti
2006 Apr 20
2
[LLVMdev] 1.7 Pre-Release Ready for Testing
Hi Pertti,
The boost Python are not (yet) part of LLVM so I suppose it would
make most sense to try to makes fixes/changes so they would work for
1.7 and then try to get them into LLVM CVS. It would be good in such
a case to ask the author of the bindings again if he would allow
this, because basicaly I think he has to agree to the LLVM lincense.
cheers, Eric
On Apr 20, 2006, at 5:08
2007 Nov 09
0
[LLVMdev] Atomicity and synchronization
On Fri, 9 Nov 2007, [ISO-8859-1] Pertti Kellom�ki wrote:
> There was some discussion in the summer on the mailing list
> about atomicity and synchronization primitives for LLVM. Is
> there any progress being made in that department?
Nope, not that I know of.
-Chris
--
http://nondot.org/sabre/
http://llvm.org/
2006 Apr 20
1
[LLVMdev] 1.7 Pre-Release Ready for Testing
Pertti Kellomäki wrote:
> This came up when trying to compile the Python bindings
> against llvm 1.7. File include/llvm/Transforms/Scalar.h
> declares llvm::createPREPass(), which does not seem to
> be implemented anywhere. Should I report this in llvmbugs?
Just to clarify myself: this is an issue with the LLVM sources,
not with the Python bindings.
--
Pertti
2008 Oct 15
0
[LLVMdev] LLVM 2.4 problem? (resend)
Tatu Vaajalahti wrote:
> On 15.10.2008, at 14.01, Pertti Kellomäki wrote:
>> Seems to me that it is perfectly legitimate for the compiler to fold
>> the two char constants together.
> True, but note that it is the address of a variable that is used, not
> the value.
I don't have the C standard handy, but I would be somewhat
surprised if the standard would explicitly