Antw.: 2.0 Pre-release tarballs online

Hi,

logs.zip (39.6 KB)

Hi,

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.

Good.

Results of "make check" (see ppc.log):

                === Summary ===

# of expected passes 1630
# of unexpected failures 21
# of expected failures 2

This doesn't look like there's enough tests. The total number should be
in the high 1900s. Did you configure with only the PPC target?

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.

This isn't the correct solution :slight_smile: We don't (or try not) to include
system headers anywhere except lib/System and a few spots in
include/llvm/Support. The case in point is
include/llvm/Support/DataTypes.h. Please adjust
include/llvm/Support/DataTypes.h to accommodate this operating system
and send the patch to llvm-commits mailing list. We'll include it so
that LLVM can compile on Slackware 10.2 with gcc 3.3.6.

... snip ...
Others have responded to the rest.

Reid.

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?

I'll mention this in the release notes. The darwin linker in 10.5 (not yet released) supports llvm, and there is an experimental patch for binutils, but I don't knows its current state.

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

This is all great information, I'm merging this into the release notes.

  * Type::IntTy, Type::UIntTy, Type::SByteTy, ... are replaced by Type::Int8Ty, ... How does one keep code portable with the various TypeIntXTy's?

LLVM integer types have always been fixed size. "long" didn't correspond to C's "long" type, it was always 64-bits.

* CastInst is now abstract and its functionality is split into several parts. What to choose when casting a pointer to a double pointer?

pointer to pointer casts are always bitcast.

Is it always clear which cast instruction is the right one (e.g. when exact Value is only known at run-time)?

Yep. :slight_smile:

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

Yes. The next/prev pointers have extra information encoded in them now, for efficiency. The iterator takes care of this for you, deferencing the raw pointer wouldn't work even if you could get to it.

* The same goes for BasicBlock::getNext()/Prev(). Is iterating through the parent Function's iterator the only solution?

Yep.

* CallInst's constructors do not accept vectors anymore, but a double pointer (!) instead. Why?

Most calls have been changed to take a range instead of a vector instead. This allows you to do things like this:

   Value *Ops = { Op1, Op2, Op3 };
   new Whatever(Ops, 3);

which avoids creating a temporary vector.

  * In my own code, I can't use cout anymore without the std:: prefix.

You should have always used std:: :slight_smile:

* ... (there is probably more, as my app compiles by now, but is still broken)

This is all very useful. If you have any more additions, please let me know. Thanks again,

-Chris

Hello, Reid.

This doesn't look like there's enough tests. The total number should
be
in the high 1900s. Did you configure with only the PPC target?

Yes. I've looked into logs. All "unexpected" are either due to lack of
targets (ppc only) or no llvm-gcc found.

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

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

Hi,

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!

The strange thing is that the configure process defines:

#define HAVE_STDINT_H 1

However, without literally including stdint.h (which should be avoided as Reid mentioned) the compilation of AsmWriter.cpp goes wrong, although stdint.h, llvm/Support/DataTypes.h and inttypes.h are all mentioned in AsmWriter.d:

if g++ -I/home/bram/workspace/svn/aspicere2/trunk/llvm-build/lib/VMCore -I/home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore -I/home/bram/workspace/svn/aspicere2/trunk/llvm-build/include -I/home/bram/workspace/svn/aspicere2/trunk/llvm/include -I/home/bram/workspace/svn/aspicere2/trunk/llvm-build/include -I/home/bram/workspace/svn/aspicere2/trunk/llvm/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -g -fno-exceptions -D_DEBUG -Woverloaded-virtual -pedantic -Wall -W -Wwrite-strings -Wno-long-long -Wunused -Wno-unused-parameter -c -MD -MT /home/bram/workspace/svn/aspicere2/trunk/llvm-build/lib/VMCore/Debug/AsmWriter.o -MP -MF /home/bram/workspace/svn/aspicere2/trunk/llvm-build/lib/VMCore/Debug/AsmWriter.LACXXd /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore/AsmWriter.cpp -o /home/bram/workspace/svn/aspicere2/trunk/llvm-build/lib/VMCore/Debug/AsmWriter.o ;\
   then /usr/bin/mv -f "/home/bram/workspace/svn/aspicere2/trunk/llvm-build/lib/VMCore/Debug/AsmWriter.LACXXd" "/home/bram/workspace/svn/aspicere2/trunk/llvm-build/lib/VMCore/Debug/AsmWriter.d"; \
   else /usr/bin/rm -f "/home/bram/workspace/svn/aspicere2/trunk/llvm-build/lib/VMCore/Debug/AsmWriter.LACXXd"; exit 1; fi
In file included from /home/bram/workspace/svn/aspicere2/trunk/llvm/include/llvm/Function.h:22,
                  from /home/bram/workspace/svn/aspicere2/trunk/llvm/include/llvm/Module.h:17,
                  from /home/bram/workspace/svn/aspicere2/trunk/llvm/include/llvm/Assembly/PrintModulePass.h:22,
                  from /home/bram/workspace/svn/aspicere2/trunk/llvm/lib/VMCore/AsmWriter.cpp:18:
/home/bram/workspace/svn/aspicere2/trunk/llvm/include/llvm/BasicBlock.h: In
    static member function `static unsigned int
    llvm::BasicBlock::getInstListOffset()':
/home/bram/workspace/svn/aspicere2/trunk/llvm/include/llvm/BasicBlock.h:197: error: syntax
    error before `;' token
...

Should -DHAVE_STDINT_H be passed to the above command?

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.

Problem solved: compiling the 2.0 frontend from source had resulted in gcc, g++, ... instead of llvm-gcc, llvm-g++, ... After manually renaming them, compilation of LLVM was a breeze and the tests did not yield any unexpected failures (see attachment).

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University (Belgium)

x86.log.zip (19.3 KB)

Hi Bram,

Hi,

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

The strange thing is that the configure process defines:

#define HAVE_STDINT_H 1

However, without literally including stdint.h (which should be
avoided as Reid mentioned) the compilation of AsmWriter.cpp goes
wrong,

What goes wrong?

although stdint.h, llvm/Support/DataTypes.h and inttypes.h are
all mentioned in AsmWriter.d:

.. snip ..

Should -DHAVE_STDINT_H be passed to the above command?

No, it is defined in include/llvm/Config/config.h which is an autoconf
generated file and included in all LLVM compilations.

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

Problem solved: compiling the 2.0 frontend from source had resulted
in gcc, g++, ... instead of llvm-gcc, llvm-g++, ... After manually
renaming them, compilation of LLVM was a breeze and the tests did not
yield any unexpected failures (see attachment).

Glad you figured that out. The build guidelines for llvm-gcc are in
README.LLVM at the top level of the llvm-gcc source tree. It recommends
making links. Some of us, however, also use the --program-prefix=llvm-
option when configuring llvm-gcc which causes all programs to have an
llvm- prefix.

Hi,

What goes wrong?

Everything’s fine now. Forgot to look at Tanya’s changes (#include “llvm/Support/DataTypes.h”) :-)…

Glad you figured that out. The build guidelines for llvm-gcc are in
README.LLVM at the top level of the llvm-gcc source tree. It recommends
making links. Some of us, however, also use the --program-prefix=llvm-
option when configuring llvm-gcc which causes all programs to have an
llvm- prefix.

OK, I’lll use the latter option from now on.

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University (Belgium)

Everything's fine now. Forgot to look at Tanya's changes (#include "llvm/Support/DataTypes.h") :-)...

Thats great news!

Glad you figured that out. The build guidelines for llvm-gcc are in
README.LLVM at the top level of the llvm-gcc source tree. It recommends
making links. Some of us, however, also use the --program-prefix=llvm-
option when configuring llvm-gcc which causes all programs to have an
llvm- prefix.

OK, I'lll use the latter option from now on.

I'm actually going to change the README.LLVM to suggest people use --program-prefix=llvm-. I have made the same mistake you did by using the wrong gcc. Its easy to do.

Thanks again!

-Tanya

Hi,

I'll mention this in the release notes. The darwin linker in 10.5 (not
yet released) supports llvm, and there is an experimental patch for
binutils, but I don't knows its current state.

OK, I'll try out the latter (and wait for Leopard in the meantime :-)).

This is all very useful. If you have any more additions, please let me
know. Thanks again,

You're welcome, here's some more:
  * The various IntXTy's are not considered primitive anymore by e.g. Type::isPrimitiveType().
  * It seems that a C-call like printf("---\n") is transformed to puts("---") in the LLVM IR instead of keeping it a printf. What are the circumstances in which this happens? Do other similar conversions occur? Can this be turned off (lower optimisation level?)? Manually replacing the puts-calls by a printf-call is not straightforward, as the argument should be appended a '\n' (implicit with puts).

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University (Belgium)

Hello, Bram

  * It seems that a C-call like printf("---\n") is transformed to puts
("---") in the LLVM IR instead of keeping it a printf. What are the
circumstances in which this happens? Do other similar conversions
occur? Can this be turned off (lower optimisation level?)? Manually
replacing the puts-calls by a printf-call is not straightforward, as
the argument should be appended a '\n' (implicit with puts).

This transformation is performed via simplify-libcalls optimization
pass. You can look into corresponding source to check for list of
xforms.

Anton is right. You should be able to use -fno-builtins to disable this.

-Chris

Hi,

Anton is right. You should be able to use -fno-builtins to disable this.

Thanks, that did the trick.

Some final remarks (my app works again :-)):
  * llvm.va_start and similar intrinsics now have an i8* arg instead of an sbyte**
  * For some reason the Arguments of a Function are now circularly linked, i.e. getPrev()/Next() does not yield 0 when the first Argument is reached, but jumps back to the last one. I experienced this with a loop I was using to find out the index of an Argument. It relied on the fact that getPrev() would eventually give 0, which worked in previous LLVM versions.

On a related note: while using llvmc I have some test cases where the following error now pops up on Linux X86 (not on OSX):

<premain>: CommandLine Error: Argument 'debug' defined more than once!
llvmc: CommandLine Error: Argument 'debug' defined more than once!

These are the arguments I provide to llvmc (I need the -disable-opt as some of the standard passes absolutely need to occur before my passes, and the rest must come afterwards):

llvmc --config-dir ${ASPICERE2_SRC}/config/ -Tlnk="-L${LLVM_FRONT}/lib" -Tlnk="-L${ASPICERE2_INSTALL}/lib" -Tlnk="-L${SWI_LIB}" -Tlnk="-load=${ASPICERE2_INSTALL}/lib/weaver" -Tlnk="-load=${ASPICERE2_INSTALL}/lib/native" -Tlnk="-disable-opt" -Tlnk="-constmerge" -Tlnk="-globalsmodref-aa" -Tlnk="-reify" -Tlnk="-match" -Tlnk="-weave" -Tlnk="-globalsmodref-aa" -Tlnk="-internalize" -Tlnk="-ipsccp" -Tlnk="-globalopt" -Tlnk="-constmerge" -Tlnk="-deadargelim" -Tlnk="-instcombine" -Tlnk="-inline" -Tlnk="-prune-eh" -Tlnk="-globalopt" -Tlnk="-globaldce" -Tlnk="-argpromotion" -Tlnk="-instcombine" -Tlnk="-scalarrepl" -Tlnk="-globalsmodref-aa" -Tlnk="-licm" -Tlnk="-load-vn" -Tlnk="-gcse" -Tlnk="-dse" -Tlnk="-instcombine" -Tlnk="-simplifycfg" -Tlnk="-globaldce" $FILTERED_ARGS $ASPECT_STRING_TO_C

Variable $FILTERED_ARGS contains some .c files and also the -o switch with the name of the resulting binary, while $ASPECT_STRING_TO_C contains another number of .c files.

The weird thing (besides that I only experience this error on Linux) is that although all my test cases use llvmc, only two fail with this error without a clear reason. Any ideas on this?

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University (Belgium)

Anton is right. You should be able to use -fno-builtins to disable
this.

Thanks, that did the trick.

Some final remarks (my app works again :-)):
* llvm.va_start and similar intrinsics now have an i8* arg instead
of an sbyte**

ok

* For some reason the Arguments of a Function are now circularly
linked, i.e. getPrev()/Next() does not yield 0 when the first
Argument is reached, but jumps back to the last one. I experienced
this with a loop I was using to find out the index of an Argument. It
relied on the fact that getPrev() would eventually give 0, which
worked in previous LLVM versions.

Ah, these should be private. Thanks for pointing this out, I'll fix ;-). You should use iterators.

On a related note: while using llvmc I have some test cases where the
following error now pops up on Linux X86 (not on OSX):

<premain>: CommandLine Error: Argument 'debug' defined more than once!
llvmc: CommandLine Error: Argument 'debug' defined more than once!

No idea. :slight_smile:

llvmc is a work in progress which has stagnated somewhat. I strongly recommend using llvm-gcc directly.

-Chris

On a related note: while using llvmc I have some test cases where the
following error now pops up on Linux X86 (not on OSX):

<premain>: CommandLine Error: Argument 'debug' defined more than once!
llvmc: CommandLine Error: Argument 'debug' defined more than once!

No idea. :slight_smile:

llvmc is a work in progress which has stagnated somewhat. I strongly
recommend using llvm-gcc directly.

Bram:
About the only way I know of to get that error is if you linked LLVM into a loadable module and loaded it with llvmc. Did you do that? If so, don't link any LLVM stuff into your module! See the Makefile in the "Hello" transform for an example of how to do this. If you need to use something in LLVM that is not linked into llvmc (so it can't be dynamically resolved at load time), then either a) find another way to do it (without using LLVM) or b) copy the code and link it statically into your loadable module making sure that you remove any static constructors/destructors for pass registration, statistics or command line options.

Reid.

Hi,

<premain>: CommandLine Error: Argument 'debug' defined more than once!
llvmc: CommandLine Error: Argument 'debug' defined more than once!

llvmc is a work in progress which has stagnated somewhat. I strongly
recommend using llvm-gcc directly.

That's my intention as soon as LTO works in the linker :-). I tried to download Chandler's patches following the links on http://www.nabble.com/LLVM’s-Link-Time-Optimizer-integrated-into-GNU-ld-t2935174.html, but his server is apparently down. Is there some mirror?

About the only way I know of to get that error is if you linked LLVM into a loadable module and loaded it with llvmc. Did you do that?

I did link a few files from the lib/Transforms/Utils-directory. When I remove them from my build my app still works (linking them with my build apparently is superfluous in 2.0), but the error still remains. However, I noticed the above messages also in the logs of the tests that succeeded, so this llvmc problem is apparently not the cause of the errors I experience.

This is the command I use:

llvmc --config-dir ${ASPICERE2_SRC}/config/ -Tlnk="-L${LLVM_FRONT}/lib" -Tlnk="-L${ASPICERE2_INSTALL}/lib" -Tlnk="-L${SWI_LIB}" -Tlnk="-load=${ASPICERE2_INSTALL}/lib/weaver" -Tlnk="-load=${ASPICERE2_INSTALL}/lib/native" -Tlnk="-disable-opt" -Tlnk="-constmerge" -Tlnk="-globalsmodref-aa" -Tlnk="-reify" -Tlnk="-match" -Tlnk="-weave" -Tlnk="-globalsmodref-aa" -Tlnk="-internalize" -Tlnk="-ipsccp" -Tlnk="-globalopt" -Tlnk="-constmerge" -Tlnk="-deadargelim" -Tlnk="-instcombine" -Tlnk="-inline" -Tlnk="-prune-eh" -Tlnk="-globalopt" -Tlnk="-globaldce" -Tlnk="-argpromotion" -Tlnk="-instcombine" -Tlnk="-scalarrepl" -Tlnk="-globalsmodref-aa" -Tlnk="-licm" -Tlnk="-load-vn" -Tlnk="-gcse" -Tlnk="-dse" -Tlnk="-instcombine" -Tlnk="-simplifycfg" -Tlnk="-globaldce" $FILTERED_ARGS $ASPECT_STRING_TO_C

There are two dynamic modules of mine which are explicitly loaded (they no longer use LLVM modules). Afterwards, some optimisation passes are listed, some more than once. However, even if I remove the optimisations the messages still appear (without harming anyone).

Kind regards,

Bram Adams
GH-SEL, INTEC, Ghent University (Belgium)