[LLVMdev] Antw.: 2.0 Pre-release tarballs online
Bram Adams
bram.adams at ugent.be
Thu May 17 14:07:28 PDT 2007
Hi,
Op 15-mei-07, om 10:23 heeft Tanya M. Lattner het volgende geschreven:
1) Download llvm-gcc4 binary and llvm. Compile and run make check.
I did a debug build on OSX 10.4.9 and everything went fine.
Results of "make check" (see ppc.log):
=== Summary ===
# of expected passes 1630
# of unexpected failures 21
# of expected failures 2
3) Compile llvm-gcc4 and llvm from source. Run 'make check'.
On Slackware 10.2 (GCC 3.3.6), I got an error during a debug build
with the header files using uintptr_t (not recognised as a type).
Putting "#include <stdint.h>" in include/llvm/BasicBlock.h (llvm) and
in "include/llvm/ValueSymbolTable.h" (frontend) resolved this.
Also, I got linking errors while linking tblgen (see error.txt). Any
ideas about this?
Results of "make check" (without tblgen; see x86.log):
=== Summary ===
# of expected passes 1423
# of unexpected failures 25
# of expected failures 3
It would also be helpful for someone to compile/test with objdir !=
srcdir.
Both builds above happened in a directory separate from the source
directory.
About LTO support: the new release documents don't mention anything
about this. Also, the relevant bugzilla entries I could find date
back to March 2007. Has any progress been made recently in adding LTO
to the Darwin linker and/or GNU binutils?
About porting from 1.9 to 2.0: it would be helpful to have some kind
of porting guide as I encountered a lot of API changes, e.g.:
* SymbolTable.h has vanished
* Type::IntTy, Type::UIntTy, Type::SByteTy, ... are replaced by
Type::Int8Ty, ... How does one keep code portable with the various
TypeIntXTy's?
* GetElementPtrInst's constructor doesn't accept an std::vector
anymore but requires explicit arguments.
* CastInst is now abstract and its functionality is split into
several parts. What to choose when casting a pointer to a double
pointer? Is it always clear which cast instruction is the right one
(e.g. when exact Value is only known at run-time)?
* Instruction::getNext()/Prev() have suddenly become private,
seemingly without fast, easy to use alternative. Is iterating through
the parent BasicBlock's iterator the only solution?
* The same goes for BasicBlock::getNext()/Prev(). Is iterating
through the parent Function's iterator the only solution?
* CallInst's constructors do not accept vectors anymore, but a
double pointer (!) instead. Why?
* Module::getNamedFunction() is now called Module::getFunction().
* llvm/Transforms/Utils/Cloning.h's CloneFunctionInto() needs a
DenseMap as its third argument instead of an STL map.
* Pass's constructor now needs an intptr_t as explained in the
updated "Write your first pass"-document.
* In my own code, I can't use cout anymore without the std:: prefix.
* ConstantBool/Integral/Int are merged into ConstantInt.
* %llvm.dbg.subprogram.type's line number is now the 7th element;
its compile unit is now the 6th element.
* Argument names have got their argument index appended to their
name in the LLVM bitcode (e.g. "define void @f(i32 %Arg1, i32 %
OtherArg2) {...}" instead of "define void @f(i32 %Arg, i32 %OtherArg)
{...}").
* ... (there is probably more, as my app compiles by now, but is
still broken)
Kind regards,
Bram Adams
GH-SEL, INTEC, Ghent University (Belgium)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070517/384cf38a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logs.zip
Type: application/zip
Size: 40502 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070517/384cf38a/attachment.zip>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070517/384cf38a/attachment-0001.html>
More information about the llvm-dev
mailing list