svn commit: r222183 - head/lib/clang

[Warner Losh]

On May 22, 2011, at 2:22 PM, Roman Divacky wrote:
> The problem here is deeper in my opinion. What FreeBSD calls
> amd64 the rest of the world (ie. linux) calls x86_64, I think
> that instead of this we should teach llvm/clang about "amd64".
> Maybe as a FreeBSD-only diff.
> 
> The machine part of the triple is used in more places and this
> hack only is not the complete solution imho.

Personally, I think we should be migrating to the more widely accepted MACHINE_ARCH=x86_64 and leave MACHINE=amd64.  This would be the least disruptive, although there is going to be disruption no matter what we do.  Either we mess with old users or we keep fighting this uphill battle with external software.

My fear is that this ship has sailed, and we can't change globally.  In that case, we'll just need to configure the CPU for clang to be x86_64 and have the s/amd64/x86_64/ thing in the Makefiles to cope.  The architecture was originally called amd64, but the name was changed after we added support for it :(

I'd rather not have a bunch of freebsd-specifc clang hacks if we can avoid it.

Warner

> On Sun, May 22, 2011 at 04:32:45PM +0000, Dimitry Andric wrote:
>> Author: dim
>> Date: Sun May 22 16:32:44 2011
>> New Revision: 222183
>> URL: http://svn.freebsd.org/changeset/base/222183
>> 
>> Log:
>>  On amd64, change clang's default triple to 'x86_64-unknown-freebsd9.0',
>>  similar to what we do for binutils.  When clang's default triple starts
>>  with 'amd64-', it does not pass a proper -target-cpu option to its
>>  first stage.
>> 
>>  This can lead to problems, for example when structs are memcpy'd, and
>>  clang erroneously assumes they are 16-byte aligned.  It will then use
>>  the 'movaps' SSE instruction to implement the copy, which results in a
>>  bus error if the struct is really 8-byte aligned.
>> 
>>  I encountered this issue when gcc's /usr/libexec/cc1 started crashing
>>  with SIGBUS, after rebuilding world with clang ToT, but it also affects
>>  the version of clang that we have in the tree.  We were just lucky until
>>  now, apparently. :)
>> 
>> Modified:
>>  head/lib/clang/clang.build.mk
>> 
>> Modified: head/lib/clang/clang.build.mk
>> ==============================================================================
>> --- head/lib/clang/clang.build.mk	Sun May 22 15:24:56 2011	(r222182)
>> +++ head/lib/clang/clang.build.mk	Sun May 22 16:32:44 2011	(r222183)
>> @@ -15,7 +15,7 @@ CFLAGS+= -O1
>> 
>> TARGET_ARCH?=	${MACHINE_ARCH}
>> # XXX: 8.0, to keep __FreeBSD_cc_version happy
>> -CFLAGS+=-DLLVM_HOSTTRIPLE=\"${TARGET_ARCH}-undermydesk-freebsd9.0\"
>> +CFLAGS+=-DLLVM_HOSTTRIPLE=\"${TARGET_ARCH:C/amd64/x86_64/}-unknown-freebsd9.0\"
>> 
>> .ifndef LLVM_REQUIRES_EH
>> CXXFLAGS+=-fno-exceptions
> 
>