Tanya M. Lattner
2008-Oct-10 20:11 UTC
[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.