Hello, I asked here for kind of reference GCC version which LLVM development team is using for *native* testing on ARM hardware. (no cross compilation!) last week or so. I've been curious myself how the situation looks and so I tested LLVM 2.9 as a reference point and LLVM HEAD as of June 29 on ARMv7 (two boards with two different Ubuntu versions) compiled by GCC 4.3.4, 4.4.1, 4.4.5, 4.5.2, 4.6.1 Linaro 2011.05 and 4.6.1 Linaro 2011.06. It looks like LLVM HEAD does have about 28 regressions in comparison with LLVM 2.9. If you are curious to know more or to get actual `make check' logs for all the combinations please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/ Is there anything other I might do for you to get those regressions fixed? Thanks, Karel
On Sun, Jul 3, 2011 at 1:32 PM, Karel Gardas <karel.gardas at centrum.cz> wrote:> Hello, > > I asked here for kind of reference GCC version which LLVM development > team is using for *native* testing on ARM hardware. (no cross > compilation!) last week or so. I've been curious myself how the > situation looks and so I tested LLVM 2.9 as a reference point and LLVM > HEAD as of June 29 on ARMv7 (two boards with two different Ubuntu > versions) compiled by GCC 4.3.4, 4.4.1, 4.4.5, 4.5.2, 4.6.1 Linaro > 2011.05 and 4.6.1 Linaro 2011.06. It looks like LLVM HEAD does have > about 28 regressions in comparison with LLVM 2.9. If you are curious to > know more or to get actual `make check' logs for all the combinations > please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/ > > Is there anything other I might do for you to get those regressions fixed?I just filed http://llvm.org/bugs/show_bug.cgi?id=10258 for the 2009-06-05-VariableIndexInsert.ll failure. For the JIT failures, it would be nice if you could track down the SVN revision when it started failing. (We have an ARM buildbot at http://google1.osuosl.org:8011/builders/clang-native-arm-cortex-a9 , but the JIT was already broken when it was set up.) -Eli
Hi, Karel Do you have any plan on figuring out since what svn version the ARM JIT had been broken? Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667
On 07/ 4/11 01:39 AM, Eli Friedman wrote:> For the JIT failures, it would be nice if you could track down the SVN > revision when it started failing. (We have an ARM buildbot at > http://google1.osuosl.org:8011/builders/clang-native-arm-cortex-a9 , > but the JIT was already broken when it was set up.)I'll try binary search between May 26 (1st build of buildbot) and April 6 (2.9 release) and will see if I get to something. Thanks, Karel
On 3 July 2011 21:32, Karel Gardas <karel.gardas at centrum.cz> wrote:> please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/ > > Is there anything other I might do for you to get those regressions fixed?Hi Karel, This is great! I can see there's only a handful of errors. All JIT errors seem to be the same (MC). All O2 errors, too (MIPS). The select.ll error was fixed by Eli last month, so not to worry. Do we have a similar thing for x86? Just to make sure the Mips errors are not ARM specific. About your configure options, I have some questions: - You use "--with-arch=armv6 --with-tune=cortex-a8", shouldn't it be armv7? - You're using softfp on Cortex-A8, have you tried with VFPv3/NEON? - On GCC 4.4.5 you're using "--with-float=softfp --with-fpu=vfpv3-d16" and (correctly) "--with-arch=armv7-a", which mode prevails? Soft or hard? - You're using Thumb on 4.4.5 and 4.5.2 only, any special reason not to use Thumb on previous GCCs? cheers, --renato
On 07/ 4/11 01:39 AM, Eli Friedman wrote:> For the JIT failures, it would be nice if you could track down the SVN > revision when it started failing. (We have an ARM buildbot at > http://google1.osuosl.org:8011/builders/clang-native-arm-cortex-a9 , > but the JIT was already broken when it was set up.)I've used my i.MX53 board to get this, but I'm returning it today back to Freescale and my pandaboard is testing GHC performance so I'll not be able to get to this again earlier than next week. Anyway, JIT failures happens somewhere between 131458 (which is OK) and 131466 (where JIT tests fail). Let me know if this is enough or I shall continue to point to the culprit revision directly. Thanks, Karel
Hi Renato, On 07/ 5/11 12:20 PM, Renato Golin wrote:> On 3 July 2011 21:32, Karel Gardas<karel.gardas at centrum.cz> wrote: >> please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/ >> >> Is there anything other I might do for you to get those regressions fixed? > > Hi Karel, > > This is great! > > I can see there's only a handful of errors. All JIT errors seem to be > the same (MC). All O2 errors, too (MIPS). The select.ll error was > fixed by Eli last month, so not to worry.W.r.t select.ll error, I'm not sure it is really fixed. I'll need to retest I'm using here few days old HEAD so it'll be quick.> Do we have a similar thing for x86? Just to make sure the Mips errors > are not ARM specific.I'm not sure, I don't test on x86, but my general feeling about LLVM-2.9 on x86 and ARM, was that x86 was in better shape -- that was a time I tested on x86...> About your configure options, I have some questions: > > - You use "--with-arch=armv6 --with-tune=cortex-a8", shouldn't it be armv7? > > - You're using softfp on Cortex-A8, have you tried with VFPv3/NEON? > > - On GCC 4.4.5 you're using "--with-float=softfp --with-fpu=vfpv3-d16" > and (correctly) "--with-arch=armv7-a", which mode prevails? Soft or > hard? > > - You're using Thumb on 4.4.5 and 4.5.2 only, any special reason not > to use Thumb on previous GCCs?All the questions above are answered with simple answer: I'm using system (i.e. ubuntu) provided GCC (except linaro) and so the params are those Ubuntu package maintaners used. On linaro I'm using ARM mode based on the experience with 4.4.1 which also uses ARM mode and looks better than 4.4.3/4.5.2 which are using thumb by default. No, I've not tried to use VFPv3/NEON yet. Cheers, Karel
On Sun, Jul 3, 2011 at 11:32 PM, Karel Gardas <karel.gardas at centrum.cz> wrote:> Hello, > > I asked here for kind of reference GCC version which LLVM development > team is using for *native* testing on ARM hardware. (no cross > compilation!) last week or so. I've been curious myself how the > situation looks and so I tested LLVM 2.9 as a reference point and LLVM > HEAD as of June 29 on ARMv7 (two boards with two different Ubuntu > versions) compiled by GCC 4.3.4, 4.4.1, 4.4.5, 4.5.2, 4.6.1 Linaro > 2011.05 and 4.6.1 Linaro 2011.06. It looks like LLVM HEAD does have > about 28 regressions in comparison with LLVM 2.9. If you are curious to > know more or to get actual `make check' logs for all the combinations > please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/ > > Is there anything other I might do for you to get those regressions fixed?I'm curious if anybody is still tracking the status of ARM support in LLVM. Right now I'm getting the following errors for llvm-3.0rc4 test suite on arm linux system: ******************** Testing Time: 2136.45s ******************** Failing Tests (7): LLVM :: ExecutionEngine/2002-12-16-ArgTest.ll LLVM :: ExecutionEngine/test-fp.ll LLVM :: Object/objdump-disassembly-inline-relocations.test LLVM :: Object/objdump-trivial-object.test LLVM-Unit :: ExecutionEngine/JIT/Release/JITTests/JIT.GlobalInFunction LLVM-Unit :: ExecutionEngine/JIT/Release/JITTests/JITTest.AvailableExternallyGlobalIsntEmitted LLVM-Unit :: ExecutionEngine/JIT/Release/JITTests/JITTest.FunctionPointersOutliveTheirCreator Expected Passes : 3239 Expected Failures : 46 Unsupported Tests : 2352 Unexpected Failures: 7 $ gcc -v Using built-in specs. COLLECT_GCC=/usr/armv7a-unknown-linux-gnueabi/gcc-bin/4.5.3/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7a-unknown-linux-gnueabi/4.5.3/lto-wrapper Target: armv7a-unknown-linux-gnueabi Configured with: /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/configure --prefix=/usr --bindir=/usr/armv7a-unknown-linux-gnueabi/gcc-bin/4.5.3 --includedir=/usr/lib/gcc/armv7a-unknown-linux-gnueabi/4.5.3/include --datadir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabi/4.5.3 --mandir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabi/4.5.3/man --infodir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabi/4.5.3/info --with-gxx-include-dir=/usr/lib/gcc/armv7a-unknown-linux-gnueabi/4.5.3/include/g++-v4 --host=armv7a-unknown-linux-gnueabi --build=armv7a-unknown-linux-gnueabi --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/armv7a-unknown-linux-gnueabi/4.5.3/python --enable-checking=release --disable-libgcj --with-arch=armv7-a --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.3-r1 p1.0, pie-0.4.5' Thread model: posix gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) And the failures are the same if using gcc 4.4.5 instead. -- Best regards, Siarhei Siamashka
Hi, Most of those test failures are due to the JIT, which is unmaintained for ARM and known to be dead. The only ones that worry me are the objdump ones, but llvm-objdump is still under development so it's not so surprising. Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Siarhei Siamashka Sent: 29 November 2011 08:40 To: Karel Gardas Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] LLVM on ARM testing. On Sun, Jul 3, 2011 at 11:32 PM, Karel Gardas <karel.gardas at centrum.cz> wrote:> Hello, > > I asked here for kind of reference GCC version which LLVM development > team is using for *native* testing on ARM hardware. (no cross > compilation!) last week or so. I've been curious myself how the > situation looks and so I tested LLVM 2.9 as a reference point and LLVM > HEAD as of June 29 on ARMv7 (two boards with two different Ubuntu > versions) compiled by GCC 4.3.4, 4.4.1, 4.4.5, 4.5.2, 4.6.1 Linaro > 2011.05 and 4.6.1 Linaro 2011.06. It looks like LLVM HEAD does have > about 28 regressions in comparison with LLVM 2.9. If you are curious to > know more or to get actual `make check' logs for all the combinations > please see http://ghcarm.wordpress.com/2011/07/03/llvm-on-arm-testing/ > > Is there anything other I might do for you to get those regressions fixed?I'm curious if anybody is still tracking the status of ARM support in LLVM. Right now I'm getting the following errors for llvm-3.0rc4 test suite on arm linux system: ******************** Testing Time: 2136.45s ******************** Failing Tests (7): LLVM :: ExecutionEngine/2002-12-16-ArgTest.ll LLVM :: ExecutionEngine/test-fp.ll LLVM :: Object/objdump-disassembly-inline-relocations.test LLVM :: Object/objdump-trivial-object.test LLVM-Unit :: ExecutionEngine/JIT/Release/JITTests/JIT.GlobalInFunction LLVM-Unit :: ExecutionEngine/JIT/Release/JITTests/JITTest.AvailableExternallyGlobalIsntEm itted LLVM-Unit :: ExecutionEngine/JIT/Release/JITTests/JITTest.FunctionPointersOutliveTheirCre ator Expected Passes : 3239 Expected Failures : 46 Unsupported Tests : 2352 Unexpected Failures: 7 $ gcc -v Using built-in specs. COLLECT_GCC=/usr/armv7a-unknown-linux-gnueabi/gcc-bin/4.5.3/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7a-unknown-linux-gnueabi/4.5.3/lto- wrapper Target: armv7a-unknown-linux-gnueabi Configured with: /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/configure --prefix=/usr --bindir=/usr/armv7a-unknown-linux-gnueabi/gcc-bin/4.5.3 --includedir=/usr/lib/gcc/armv7a-unknown-linux-gnueabi/4.5.3/include --datadir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabi/4.5.3 --mandir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabi/4.5.3/man --infodir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabi/4.5.3/info --with-gxx-include-dir=/usr/lib/gcc/armv7a-unknown-linux-gnueabi/4.5.3/inclu de/g++-v4 --host=armv7a-unknown-linux-gnueabi --build=armv7a-unknown-linux-gnueabi --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/armv7a-unknown-linux-gnueabi/4.5.3/python --enable-checking=release --disable-libgcj --with-arch=armv7-a --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.3-r1 p1.0, pie-0.4.5' Thread model: posix gcc version 4.5.3 (Gentoo 4.5.3-r1 p1.0, pie-0.4.5) And the failures are the same if using gcc 4.4.5 instead. -- Best regards, Siarhei Siamashka _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> I'm curious if anybody is still tracking the status of ARM support in > LLVM. Right now I'm getting the following errors for llvm-3.0rc4 test > suite on arm linux system:I tracked the status of ARM support few months age. There is a discussion thread before. ARM Qualification http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044026.html I think it just needs someone to organize how the ARM testing is done and how to track where the bug is. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667 Homepage: http://people.cs.nctu.edu.tw/~chenwj