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

[Tanya M. Lattner]

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

Ok. This is now fixed on the release branch. Thanks!

> Also, I got linking errors while linking tblgen (see error.txt). Any ideas 
> about this?

I'm not really sure whats going on here and I can't reproduce this since I 
don't have your setup. Its probably either an issue with gcc or ld (try 
upgrading to 2.17.X if possible). If you can try to investigate it 
further, that would be great. Then file a bug for it.

Otherwise, I think the make check errors are ok given it can't find 
llvm-gcc.

Thanks!
-Tanya

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