[LLVMdev] Antw.: 2.0 Pre-release tarballs online

[Tanya M. Lattner]

> 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?

I'll look into these two in a bit. Thanks!

> Results of "make check" (without tblgen; see x86.log):
>
>                ===  Summary ===
> #  of expected passes            1423
> #  of unexpected failures        25
> #  of expected failures            3

Can you verify that you have llvm-gcc in your path and that its the 2.0 
llvm-gcc? The errors are mostly saying the tests couldnt find llvm-gcc and 
also the path looked like a 1.9 one.

Thanks,
Tanya

>
> 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)
> 
>