llvm dev - Oct 2008 - [LLVMdev] 2.4 Pre-release (v1) Available for Testing

LLVMers,

The 2.4 pre-release is available for testing:
http://llvm.org/prereleases/2.4/

If you have time, I'd appreciate anyone who can help test the release. 
Please do the following:

1) Download/compile llvm source, and either compile llvm-gcc source or use
    llvm-gcc binary.
2) Run make check, send me the testrun.log
3) Run "make TEST=nightly report" and send me the report.nightly.txt
4) Please provide details on what platform you compiled LLVM on and how
    you built LLMV (src == obj, or src != obj)

Please COMPLETE ALL TESTING BY the end of the day on Oct. 19th!

Thanks,
Tanya

On Fri, Oct 10, 2008 at 2:11 PM, Tanya M. Lattner <tonic at nondot.org>
wrote:
>
> LLVMers,
>
> The 2.4 pre-release is available for testing:
> http://llvm.org/prereleases/2.4/
>
> If you have time, I'd appreciate anyone who can help test the release.
> Please do the following:
>
> 1) Download/compile llvm source, and either compile llvm-gcc source or use
>    llvm-gcc binary.
> 2) Run make check, send me the testrun.log
> 3) Run "make TEST=nightly report" and send me the
report.nightly.txt
> 4) Please provide details on what platform you compiled LLVM on and how
>    you built LLMV (src == obj, or src != obj)
Downloaded the 2.4pr source code.
Compiling on Windows XP SP2 using Visual Studio 2005/VC8 with current patches.

Initial notice while it is compiling, lots of warning that look valid, such as:
1) "The POSIX name for this item is deprecated. Instead, use the ISO
C++ conformant name: someFuncName"
2) "...not all control paths return a value"
3) "type name first seen using 'class' now seen using
'struct'"
4) Lots of conversion/truncation warning, this one does not need to be
a big focus, but explicit conversion/truncations would silence these
and make the compiler happy.
5) "destructor could not be generated because a base class destructor
is inaccessible"
6) " check operator precedence for possible error; use parentheses to
clarify precedence"
7) "switch statement contains 'default' but no 'case'
labels"
8) etc...
9) And of course a few VC++ specific ones that can be ignored, but the
above are valid.

The full build log is at:
http://overminddl1.com/stuff/llvm/First_Full_Build.txt
On this first compile everything compiled except for llc and lli,
which did not link due to:
 unresolved external symbol "class llvm::FunctionPass * __cdecl
llvm::createPBQPRegisterAllocator(void)"

I told it to compile again (hopefully just missed a link due to a bad
project build order I hope, from looking at it though that does not
appear to be the case, it looks like that symbol is not externally
visible...).
Second attempt to link the llc and lli projects again also failed,
some error, looks like that symbol needs to be fixed.

Other then the one link error due to the missing external symbol, the
windows build seems to build.  Fibonacci also works fine (tested both
the debug and release builds with numbers from 1 to 45 each, I assume
the results are the correct numbers, did not check, it all looked fine
though).  Lots of warnings, most of which look like they can be safely
ignored, a few should be handled.  Are there any Windows tests you
want run?


On Fri, Oct 10, 2008 at 2:11 PM, Tanya M. Lattner <tonic at nondot.org>
wrote:
> Please COMPLETE ALL TESTING BY the end of the day on Oct. 19th!
Speaking of, we really need a test suite to test llvm itself, and not
llvm-gcc (to make sure llvm is correct on platforms without a gcc
build system).  The closest we have is the Fibinocci project and that
is anything but conclusive.

OvermindDL1 <overminddl1 at gmail.com> writes:

[snip]
> On this first compile everything compiled except for llc and lli,
> which did not link due to:
>  unresolved external symbol "class llvm::FunctionPass * __cdecl
> llvm::createPBQPRegisterAllocator(void)"
That is because the lib/CodeGen project file is missing PBQP.cpp.

[snip]
> On Fri, Oct 10, 2008 at 2:11 PM, Tanya M. Lattner <tonic at
nondot.org> wrote:
>> Please COMPLETE ALL TESTING BY the end of the day on Oct. 19th!
> Speaking of, we really need a test suite to test llvm itself, and not
> llvm-gcc (to make sure llvm is correct on platforms without a gcc
> build system).  The closest we have is the Fibinocci project and that
> is anything but conclusive.
I could add that to my CMake build system TODO, but so far I'm a bit
skeptic about LLVM relevance on the non-Unix world. The Windows build
can be broken for a long period before anyone notices. The VS2003
support is broken since a long time ago and, apart from myself, no other
user cares. Seems that LLVM penetration on Windows, for instance, is
almost nil. Is it really worth the trouble to support things like
testing on systems that almost nobody (wants to) use?.

-- 
Oscar

Hi Tanya, I get these warnings when building llvm with gcc-4.3
on x86-64-linux:

llvm[1]: Compiling Path.cpp for Release build
In file included from Path.cpp:270:
Unix/Path.inc: In member function ‘bool llvm::sys::Path::eraseFromDisk(bool,
std::string*) const’:
Unix/Path.inc:661: warning: ignoring return value of ‘int system(const char*)’,
declared with attribute warn_unused_result

llvm[1]: Compiling raw_ostream.cpp for Release build
raw_ostream.cpp: In member function ‘virtual void
llvm::raw_fd_ostream::flush_impl()’:
raw_ostream.cpp:227: warning: ignoring return value of ‘ssize_t write(int, const
void*, size_t)’, declared with attribute warn_unused_result

llvm[3]: Compiling InstructionCombining.cpp for Release build
InstructionCombining.cpp: In function ‘bool CollectBSwapParts(llvm::Value*, int,
uint32_t, llvm::SmallVector<llvm::Value*, 8u>&)’:
InstructionCombining.cpp:3942: warning: suggest parentheses around + or - inside
shift

llvm[3]: Compiling PPCISelDAGToDAG.cpp for Release build
PPCGenDAGISel.inc: In member function
‘llvm::SDNode*<unnamed>::PPCDAGToDAGISel::Emit_14(const
llvm::SDValue&, unsigned int, llvm::MVT)’:
PPCGenDAGISel.inc:58: warning: ‘mb’ may be used uninitialized in this function
PPCGenDAGISel.inc:58: note: ‘mb’ was declared here
PPCGenDAGISel.inc:67: warning: ‘me’ may be used uninitialized in this function
PPCGenDAGISel.inc:67: note: ‘me’ was declared here

(I've fixed, hopefully correctly, the PPC warnings in svn with commit 57635.
I don't see the InstructionCombining warning with svn so perhaps it has
already
been fixed there).

Also, in llvm-gcc4.2-2.4.source/README.LLVM it says:

$ ../llvm-gcc4-x.y.source/configure --prefix=`pwd`/../install
--program-prefix=llvm- \
    --enable-llvm=$LLVMOBJDIR --enable-languages=c,c++$EXTRALANGS $TARGETOPTIONS

That should be llvm-gcc4.2-x.y.source (gcc4 -> gcc4.2).  And since this is
the
release of 2.4, could change x->2 and y->4:

$ ../llvm-gcc4.2-2.4.source/configure --prefix=`pwd`/../install
--program-prefix=llvm- \
    --enable-llvm=$LLVMOBJDIR --enable-languages=c,c++$EXTRALANGS $TARGETOPTIONS

When building llvm-gcc from source I get:
obj/./gcc/xgcc -Bobj/./gcc/ -Bobj/../install/x86_64-unknown-linux-gnu/bin/
-Bobj/../install/x86_64-unknown-linux-gnu/lib/ -isystem
obj/../install/x86_64-unknown-linux-gnu/include -isystem
obj/../install/x86_64-unknown-linux-gnu/sys-include -O2  -O2 -g -O2  -DIN_GCC   
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared -nodefaultlibs
-Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/32/libgcc.map -o
32/libgcc_s.so.1.tmp  -m32 libgcc/32/_muldi3_s.o libgcc/32/_negdi2_s.o
libgcc/32/_lshrdi3_s.o libgcc/32/_ashldi3_s.o libgcc/32/_ashrdi3_s.o
libgcc/32/_cmpdi2_s.o libgcc/32/_ucmpdi2_s.o libgcc/32/_clear_cache_s.o
libgcc/32/_enable_execute_stack_s.o libgcc/32/_trampoline_s.o
libgcc/32/__main_s.o libgcc/32/_absvsi2_s.o libgcc/32/_absvdi2_s.o
libgcc/32/_addvsi3_s.o libgcc/32/_addvdi3_s.o libgcc/32/_subvsi3_s.o
libgcc/32/_subvdi3_s.o libgcc/32/_mulvsi3_s.o libgcc/32/_mulvdi3_s.o
libgcc/32/_negvsi2_s.o libgcc/32/_negvdi2_s.o libgcc/32/_ctors_s.o
libgcc/32/_ffssi2_s.o libgcc/32/_ffsdi2_s.o libgcc/32/_clz_s.o
libgcc/32/_clzsi2_s.o libgcc/32/_clzdi2_s.o libgcc/32/_ctzsi2_s.o
libgcc/32/_ctzdi2_s.o libgcc/32/_popcount_tab_s.o libgcc/32/_popcountsi2_s.o
libgcc/32/_popcountdi2_s.o libgcc/32/_paritysi2_s.o libgcc/32/_paritydi2_s.o
libgcc/32/_powisf2_s.o libgcc/32/_powidf2_s.o
libgcc/32/_powixf2_s.olibgcc/32/_powitf2_s.o libgcc/32/_mulsc3_s.o
libgcc/32/_muldc3_s.o libgcc/32/_mulxc3_s.o libgcc/32/_multc3_s.o
libgcc/32/_divsc3_s.olibgcc/32/_divdc3_s.o libgcc/32/_divxc3_s.o
libgcc/32/_divtc3_s.o libgcc/32/_bswapsi2_s.o libgcc/32/_bswapdi2_s.o
libgcc/32/_fixunssfsi_s.o libgcc/32/_fixunsdfsi_s.o libgcc/32/_fixunsxfsi_s.o
libgcc/32/_fixsfdi_s.o libgcc/32/_fixunssfdi_s.o
libgcc/32/_floatdisf_s.olibgcc/32/_floatundisf_s.o libgcc/32/_fixdfdi_s.o
libgcc/32/_fixunsdfdi_s.o libgcc/32/_floatdidf_s.o libgcc/32/_floatundidf_s.o
libgcc/32/_fixxfdi_s.o libgcc/32/_fixunsxfdi_s.o libgcc/32/_floatdixf_s.o
libgcc/32/
_floatundixf_s.o libgcc/32/_fixtfdi_s.o libgcc/32/_fixunstfdi_s.o
libgcc/32/_floatditf_s.o libgcc/32/_floatunditf_s.o libgcc/32/_divdi3_s.o
libgcc/32/_moddi3_s.o libgcc/32/_udivdi3_s.o libgcc/32/_umoddi3_s.o
libgcc/32/_udiv_w_sdiv_s.o libgcc/32/_udivmoddi4_s.o libgcc/32/unwind-dw2_s.o
libgcc/32/unwind-dw2-fde-glibc_s.o libgcc/32/unwind-sjlj_s.o
libgcc/32/gthr-gnat_s.o libgcc/32/unwind-c_s.o -lc && rm -f
32/libgcc_s.so && if [ -f 32/libgcc_s.so.1 ];then mv -f 32/libgcc_s.so.1
32/libgcc_s.so.1.backup; else true; fi && mv 32/libgcc_s.so.1.tmp
32/libgcc_s.so.1 && ln -s libgcc_s.so.1 32/libgcc_s.so
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
/usr/X11R6/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when searching
for -lc
/usr/X11R6/bin/ld: skipping incompatible /usr/lib/../lib/libc.a when searching
for -lc
/usr/X11R6/bin/ld: i386:x86-64 architecture of input file
`/usr/lib/../lib/crti.o' is incompatible with i386 output
/usr/X11R6/bin/ld: i386:x86-64 architecture of input file
`/usr/lib/../lib/crtn.o' is incompatible with i386 output
make[4]: *** [32/libgcc_s.so] Error 1

i.e. the build fails.  Investigating.

Ciao,

Duncan.