[cfe-dev] Bug#704111: clang fails to correctly implement hard float ABI during default compiles due to rediculously low default CPU setting.

peter green plugwash at p10link.net
Wed Mar 27 18:06:27 PDT 2013

Package: clang
Version: 1:3.0-6.1
Severity: grave
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("armv4", "armv4t", 

    .Cases("armv5", "armv5t", 

    .Cases("armv5e", "armv5te", 


    .Cases("armv6", "armv6k", 


    .Cases("armv6z", "armv6zk", 


    .Cases("armv7", "armv7a", "armv7-a", 

    .Cases("armv7r", "armv7-r", 

    .Cases("armv7m", "armv7-m", 




    .Cases("armv6m", "armv6-m", 

    // 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...
Name: 29-set-default-cpu-for-armhf.diff
Type: text/x-diff
Size: 1494 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130328/258fbd70/attachment.diff>

More information about the cfe-dev mailing list