Date: Sun, 22 May 2011 16:00:22 -0600 From: Warner Losh <imp@bsdimp.com> To: Roman Divacky <rdivacky@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Dimitry Andric <dim@FreeBSD.org> Subject: Re: svn commit: r222183 - head/lib/clang Message-ID: <9D5A92B1-7577-44CF-A7EB-E8E334411E6F@bsdimp.com> In-Reply-To: <20110522202256.GA43412@freebsd.org> References: <201105221632.p4MGWjUb081825@svn.freebsd.org> <20110522202256.GA43412@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=20 > 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=3Dx86_64 and leave MACHINE=3Damd64. 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 >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. :) >>=20 >> Modified: >> head/lib/clang/clang.build.mk >>=20 >> Modified: head/lib/clang/clang.build.mk >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- 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+=3D -O1 >>=20 >> TARGET_ARCH?=3D ${MACHINE_ARCH} >> # XXX: 8.0, to keep __FreeBSD_cc_version happy >> -CFLAGS+=3D-DLLVM_HOSTTRIPLE=3D\"${TARGET_ARCH}-undermydesk-freebsd9.0\= " >> = +CFLAGS+=3D-DLLVM_HOSTTRIPLE=3D\"${TARGET_ARCH:C/amd64/x86_64/}-unknown-fr= eebsd9.0\" >>=20 >> .ifndef LLVM_REQUIRES_EH >> CXXFLAGS+=3D-fno-exceptions >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9D5A92B1-7577-44CF-A7EB-E8E334411E6F>