[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