OK, some investigation results from the always invigorating world of ABI configuration issues:
If you are producing an armv7l-unknown-linux-gnueabihf target then you NEED TO DEFINITELY NOT USE --abi=aapcs to avoid some FileCheck problems. However, if you are producing an armv7l-unknown-linux-gnueabi target then you NEED --abi=aapcs to avoid some problems. On a recent/future ubuntu ARM based system, it's correct to specify armv7l-unknown-linux-gnueabihf and so we should use that and drop the --abi=aapcs entry. (It's still an open question whether in other circumstances plain gnueabi remains an interesting target that ought to be tested, but on stock ubuntu gnueabihf is the way to go.) If I do that on my pandaboard I both get rid of some of the existing failures and I don't create any new ones. I've also tested clang and it produces runnable executables. So I think this change is what ought to be there. Could I ask you to try that configuration options on your buildslaves and see if that reproduces what I see? Once it's clear this is ok I'll try to do a formal patch to the ARM installation notes in LLVM. (I don't think aapcs causes "real-life" problems, it just changes function signatures which FileCheck regexps doesn't understand.) Many thanks, and sorry for the confusion. Cheers, David -----Original Message----- From: David Tweed [mailto:[email protected]] Sent: 27 September 2012 11:21 To: David Tweed; 'Galina Kistanova'; '[email protected]'; 'llvm cfe' Cc: Amara Emerson; Kristof Beyls Subject: RE: [cfe-commits] Update Cortex-A9 buildslaves Right, the situation is more complex than I thought. Using the same triple as the ubuntu gcc was compiled with fixes (in the "right" way) some of the regression test failures. However, a just completed run of the full regression tests has shown it causes about 50 new failures within clang. I need to look at these to see why this change has occurred, but I think it's probably best not to change the triple just yet. In general, while the interaction between the clang driver search mechanism and the pre-existing gcc installation is, I suspect, always going to be complex and ad-hoc, at the moment there's no integrated gives no feedback about how all these checks have influenced the paths it knows about, etc. I'm not sure if this is something worth trying to address. Thanks, David -----Original Message----- From: David Tweed [mailto:[email protected]] Sent: 27 September 2012 10:03 To: 'Galina Kistanova'; [email protected]; llvm cfe Cc: Amara Emerson; Kristof Beyls Subject: RE: [cfe-commits] Update Cortex-A9 buildslaves Hi, I haven't quite completed my internal testing yet, but since you're making modifications to the buildbots: according to http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/3118/ste ps/configure/logs/stdio you're configuring with armv7l-unknown-linux-gnueabi. Could you change that to armv7l-unknown-linux-gnueabihf please? I've been digging into some clang failures and I think that this configuration used to match the debian/ubuntu gcc configuration, then at some point debian/ubuntu changed their configuration, especially for gcc. clang particularly depends on extracting info from the gcc configuration, and with a mismatched triple it thinks there's not a working gcc installation so stops lots of stuff early. Tests are still running, but I think it solves some clang issues and doesn't introduce any new ones. Let me know if any of this is unclear Cheers -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Galina Kistanova Sent: 26 September 2012 19:36 To: [email protected]; llvm cfe Subject: [cfe-commits] Update Cortex-A9 buildslaves Hello everyone, We have updated both Cortex-A9 buildslaves to reduce the number of failing tests. Currently both Pandaboards run Ubuntu 12.10 and the following development toolchain: gcc (Ubuntu/Linaro 4.7.2-1ubuntu1) 4.7.2 g++ (Ubuntu/Linaro 4.7.2-1ubuntu1) 4.7.2 GNU ld (GNU Binutils for Ubuntu) 2.22.90.20120919 Python 2.7.3 Please note that the current expected number of failing tests on this builder is 17. We are working on fixing them, and as always, patches are welcome. Thanks Galina _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
