[cfe-dev] Bug#704111: clang fails to correctly implement hard float ABI during default compiles due to rediculously low default CPU setting.
plugwash at p10link.net
Wed Mar 27 18:06:27 PDT 2013
x-debbugs-cc: debian-arm at lists.debian.org; cfe-dev at cs.uiuc.edu
(note for non-debian people reading this, the version of clang in debian
wheezy is a 3.0 based version which already has patches to make it
invoke the linker with appropriate arguments. The llvm version also
appears to be 3.0 again somewhat patched by debian)
I recently discovered that the version of clang in debian wheezy and
raspbian wheezy does not work correctly on either debian armhf or
raspbian. It seems the problem is that clang can't work out what CPU
type it should be using and defaults to something very low (specifically
arm7tdmi). With this CPU selected clang silently fails to properly use
the hard float ABI and as such any armhf code it generates is broken and
won't call floating point routines correctly. It also causes an
assertion failure in the bfd linker (but links successfully with the
gold linker). Setting the CPU type to something sensible makes it
implement the hard float ABI correctly and also stops the assertion
failure in the bfd linker.
I have managed to figure out how to patch clang to change the default
CPU for armhf (patch attatched). However i'm not sure what it is best to
set it to for debian armhf*. In particular this block of code from just
below where my patch is applied seems to map all armv7 variants to a CPU
type of "coretex-a8".
return llvm::StringSwitch<const char
.Cases("armv7", "armv7a", "armv7-a",
// If all else failed, return the most base CPU LLVM
Now it is my understanding that "traditional cortex a8" includes CPU
features not required by debian armhf. Specifically neon and the extra
vfp registers. The questions I have are
1: What does the "coretex-a8" CPU setting imply for clang/llvm? in
particular does it imply neon and the extra vfp registers?
2: If noone can provide an answer to the above question then taking into
the account how late we are in the freeze should we play it safe and
specify a lower (armv6) CPU version to make sure that neon and the extra
vfp registers don't get accidently used. I personally think that the
answer is yes but I'm open to arguments.
If I get no response to this within about a weak I intend to attach a
nmu diff containing a version of the patch that sets the default set to
armv6. Then file a pre-approval request with the release team. Finally
if the release team approves and noone objects I intend to upload the NMU.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1494 bytes
Desc: not available
More information about the cfe-dev