issue with clang and CPUTYPE native

Alexander Best arundel at freebsd.org
Mon Jan 31 21:00:41 UTC 2011


On Mon Jan 31 11, Roman Divacky wrote:
> On Mon, Jan 31, 2011 at 04:27:55PM +0000, Alexander Best wrote:
> > On Sat Jan  1 11, Alexander Best wrote:
> > > On Sat Jan  1 11, Roman Divacky wrote:
> > > > > > clang -O2 -pipe -march=native -fpic -fvisibility=hidden -DVISIBILITY_HIDDEN -g -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c
> > > > > > detected CPU = core2
> > > > > > Assertion failed: (getMinSignedBits() <= 64 && "Too many bits for int64_t"), function getSExtValue, file /usr/subversion-src/lib/clang/libclangcodegen/../../../contrib/llvm/include/llvm/ADT/APInt.h, line 1149.
> > > > > > Stack dump:
> > > > > > 0.	Program arguments: /usr/obj/usr/subversion-src/tmp/usr/bin/clang -cc1 -triple x86_64-undermydesk-freebsd9.0 -S -disable-free -main-file-name mulvti3.c -pic-level 1 -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu core2 -g -resource-dir /usr/obj/usr/subversion-src/tmp/usr/lib/clang/2.8 -D VISIBILITY_HIDDEN -O2 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -std=gnu99 -ferror-limit 19 -fmessage-length 275 -fvisibility hidden -stack-protector 1 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-G6mPQL.s -x c /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c 
> > > > > > 1.	<eof> parser at end of file
> > > > > > 2.	Code generation
> > > > > > clang: error: clang frontend command failed due to signal 6 (use -v to see invocation)
> > > > > > *** Error code 250
> > > > 
> > > > 
> > > > this is a genuine llvm bug it may have been (or may have been not) fixed in recent llvm.
> > > > 
> > > > if you feel like it - install llvm/clang from subversion and check if it compiles this
> > > > ok. if it does not I think it's worth filing a bug in llvm bugzilla..
> > 
> > i just wanted to report that the latest clang version doesn't trigger the
> > assert any longer:
> > 
> > clang version 2.9 (trunk 124571)
> > Target: x86_64-unknown-freebsd9.0
> > Thread model: posix
> > 
> > is there a way to have the local "-fformat-extensions" clang additions pushed
> > upstream? maybe that mght be sufficient to compile the freebsd source with
> > clang 2.9+.
> 
> no, it makes no sense to push the printf patches upstream. it's freebsd kernel
> only.
> 
> for compiling freebsd kernel you are supposed to use /usr/bin/clang (or just
> ignore the warnings from upstream clang)

you should be able to reproduce the issue on arch=amd64 and the following in
/etc by doing 'make' in lib/libcompiler_rt:

otaku% cat /etc/make.conf /etc/src.conf
cat: /etc/make.conf: No such file or directory
# CLANG options
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
# Don't die on warnings
#NO_WERROR=
#WERROR=

# Enable debugging symbols for world
DEBUG_FLAGS = -g

... removing the "-g" switch from DEBUG_FLAGS solves the issue.

using the 2.9-development branch, lib/libcompiler_rt compiles fine even with
the -g switch.

cheers.
alex

> 
> 
> what are you trying to do anyway? :)

-- 
a13x


More information about the freebsd-toolchain mailing list