From owner-freebsd-toolchain@FreeBSD.ORG Sun Dec 26 21:00:11 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id D01BA1065672; Sun, 26 Dec 2010 21:00:10 +0000 (UTC) Date: Sun, 26 Dec 2010 21:00:10 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20101226210010.GA72359@freebsd.org> References: <20101211114707.GA60390@freebsd.org> <4D051FD1.7070100@FreeBSD.org> <20101214204006.GA81772@freebsd.org> <4D0B8178.9010609@FreeBSD.org> <20101218154845.GA36640@freebsd.org> <20101218172130.GA49738@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101218172130.GA49738@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: clang and -mfpmath=387 on ARCH=amd64 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Dec 2010 21:00:11 -0000 On Sat Dec 18 10, Alexander Best wrote: > [snip] > > maybe sorting the options just like in the i386 section is a better to have > more consistency. it seems this issue is one of the cases where everybody is too afraid to make the actual commit. :( cheers. alex [snip] -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Mon Dec 27 09:26:16 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F31AF106566B for ; Mon, 27 Dec 2010 09:26:16 +0000 (UTC) (envelope-from ade@FreeBSD.org) Received: from panix.lovett.com (panix.lovett.com [166.84.7.128]) by mx1.freebsd.org (Postfix) with ESMTP id CB1508FC08 for ; Mon, 27 Dec 2010 09:26:16 +0000 (UTC) Received: from cpe-66-68-128-204.austin.res.rr.com ([66.68.128.204] helo=[172.16.32.150]) by panix.lovett.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PX96c-000A2D-Hw for freebsd-toolchain@freebsd.org; Mon, 27 Dec 2010 09:11:02 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: Ade Lovett In-Reply-To: <20101226210010.GA72359@freebsd.org> Date: Mon, 27 Dec 2010 03:10:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <44DC7721-D935-4957-AB1F-8D4776D3A2C2@FreeBSD.org> References: <20101211114707.GA60390@freebsd.org> <4D051FD1.7070100@FreeBSD.org> <20101214204006.GA81772@freebsd.org> <4D0B8178.9010609@FreeBSD.org> <20101218154845.GA36640@freebsd.org> <20101218172130.GA49738@freebsd.org> <20101226210010.GA72359@freebsd.org> To: freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.1082) Subject: Re: clang and -mfpmath=387 on ARCH=amd64 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 09:26:17 -0000 On Dec 26, 2010, at 15:00 , Alexander Best wrote: > it seems this issue is one of the cases where everybody is too afraid = to make > the actual commit. :( More likely, it's a case of let's get 7.4/8.2 out the door, with the = usual rush of MFCs. I have a feeling that 9.0 (perhaps the entire 9.x tree) is going to be = pretty brutal. Whether it's with gcc and clang side by side, or just = clang. A change of this magnitude is going to _hurt_. -aDe From owner-freebsd-toolchain@FreeBSD.ORG Mon Dec 27 21:35:59 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id D84731065674; Mon, 27 Dec 2010 21:35:59 +0000 (UTC) Date: Mon, 27 Dec 2010 21:35:59 +0000 From: Alexander Best To: freebsd-toolchain@freebsd.org Message-ID: <20101227213559.GA53178@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: issue with clang and CPUTYPE native X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 21:35:59 -0000 hi there, i've been experiencing the following problems with clang during TARGET buildworld for quite a while now: **** CODE **** clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -std=gnu99 -fstack-protector -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c building static supc++ library ranlib libsupc++.a ===> gnu/lib/libobjc (all) gcc -O2 -pipe -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/usr/subversion-src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -std=gnu99 -fstack-protector -c /usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c *** Signal 11 Stop in /usr/subversion-src/gnu/lib/libobjc. *** Error code 1 Stop in /usr/subversion-src/gnu/lib. *** Error code 1 Stop in /usr/subversion-src. *** Error code 1 Stop in /usr/subversion-src. *** Error code 1 Stop in /usr/subversion-src. *** Error code 1 Stop in /usr/subversion-src. **** CODE **** i've finally figured out that the following line in make.conf is causing the problem: CPUTYPE ?= native if i remove it or change it to CPUTYPE ?= nocona everything works fine. if i'm using gcc as compiler, having CPUTYPE ?= native in my make.conf causes no harm. this is on amd64 and a very recent HEAD snapshot. can somebody verify this issue? cheers. alex -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Mon Dec 27 22:10:50 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id DF103106566B; Mon, 27 Dec 2010 22:10:50 +0000 (UTC) Date: Mon, 27 Dec 2010 22:10:50 +0000 From: Alexander Best To: Ade Lovett Message-ID: <20101227221050.GA54914@freebsd.org> References: <20101211114707.GA60390@freebsd.org> <4D051FD1.7070100@FreeBSD.org> <20101214204006.GA81772@freebsd.org> <4D0B8178.9010609@FreeBSD.org> <20101218154845.GA36640@freebsd.org> <20101218172130.GA49738@freebsd.org> <20101226210010.GA72359@freebsd.org> <44DC7721-D935-4957-AB1F-8D4776D3A2C2@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44DC7721-D935-4957-AB1F-8D4776D3A2C2@FreeBSD.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: clang and -mfpmath=387 on ARCH=amd64 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2010 22:10:51 -0000 On Mon Dec 27 10, Ade Lovett wrote: > > On Dec 26, 2010, at 15:00 , Alexander Best wrote: > > it seems this issue is one of the cases where everybody is too afraid to make > > the actual commit. :( > > More likely, it's a case of let's get 7.4/8.2 out the door, with the usual rush of MFCs. > > I have a feeling that 9.0 (perhaps the entire 9.x tree) is going to be pretty brutal. Whether it's with gcc and clang side by side, or just clang. A change of this magnitude is going to _hurt_. if i understood the previous comments correctly this change will have *no* impact whatsoever appart from keeping stdout/stderr a bit cleaner. well...of course rushing changes is not a good idea but the opposide is just as bad. there are hundreds of very techie discussions where developers aggree on a certain item, but after the discussions ends nothing happens. e.g.: - switching the source for pciconf - mfc'ing the latest awk release to stable/7 - fixing some serious data corruption in the mailinglist archives - revising BDECFLAGS - ... plus numerous PRs which contain *correct* patches, now outdated due to their age. also this is very discouraging. a lot of people stop their community support, since their work (e.g. patches) dye of old age in some problem report. personally i write far less patches than i used too, simply because most of the time nobody will help you get the patches committed, even if they fix trivial spelling mistakes in manual pages. just my 0.02$. cheers. alex > > -aDe > -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Tue Dec 28 14:22:07 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC3BF1065675 for ; Tue, 28 Dec 2010 14:22:07 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0A7208FC12 for ; Tue, 28 Dec 2010 14:22:06 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id B0C679CB0DB; Tue, 28 Dec 2010 15:22:04 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzTwBVixCMiU; Tue, 28 Dec 2010 15:22:03 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 9A8589CB0F6; Tue, 28 Dec 2010 15:22:03 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id oBSEM3eQ070927; Tue, 28 Dec 2010 15:22:03 +0100 (CET) (envelope-from rdivacky) Date: Tue, 28 Dec 2010 15:22:03 +0100 From: Roman Divacky To: Alexander Best Message-ID: <20101228142203.GA69674@freebsd.org> References: <20101227213559.GA53178@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101227213559.GA53178@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-toolchain@freebsd.org Subject: Re: issue with clang and CPUTYPE native X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Dec 2010 14:22:07 -0000 -march=native in clang works by detecting CPU name and passing it (if found) to llvm. if the CPU is not detected nothing is passed. nocona is supported ie. leaving the CPUNAME empty or specifying it to "nocona" should be equivalent to setting it to "native". can you apply this patch: Index: Driver/Tools.cpp =================================================================== --- Driver/Tools.cpp (revision 122591) +++ Driver/Tools.cpp (working copy) @@ -684,6 +684,7 @@ // FIXME: We should also incorporate the detected target features for use // with -native. std::string CPU = llvm::sys::getHostCPUName(); + llvm::outs() << "detected CPU = " << CPU << "\n"; if (!CPU.empty()) CPUName = Args.MakeArgString(CPU); } else and try to clang -march=native hello_world.c ? I wonder what cpu (if any) is detected. On Mon, Dec 27, 2010 at 09:35:59PM +0000, Alexander Best wrote: > hi there, > > i've been experiencing the following problems with clang during TARGET > buildworld for quite a while now: > > **** CODE **** > clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > clang -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -std=gnu99 -fstack-protector -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c > building static supc++ library > ranlib libsupc++.a > ===> gnu/lib/libobjc (all) > gcc -O2 -pipe -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/usr/subversion-src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -std=gnu99 -fstack-protector -c /usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c > *** Signal 11 > > Stop in /usr/subversion-src/gnu/lib/libobjc. > *** Error code 1 > > Stop in /usr/subversion-src/gnu/lib. > *** Error code 1 > > Stop in /usr/subversion-src. > *** Error code 1 > > Stop in /usr/subversion-src. > *** Error code 1 > > Stop in /usr/subversion-src. > *** Error code 1 > > Stop in /usr/subversion-src. > **** CODE **** > > i've finally figured out that the following line in make.conf is causing the > problem: > > CPUTYPE ?= native > > if i remove it or change it to CPUTYPE ?= nocona everything works fine. if i'm > using gcc as compiler, having CPUTYPE ?= native in my make.conf causes no harm. > > this is on amd64 and a very recent HEAD snapshot. > > can somebody verify this issue? > > cheers. > alex > > -- > a13x > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@FreeBSD.ORG Thu Dec 30 00:20:33 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 24C891065673; Thu, 30 Dec 2010 00:20:33 +0000 (UTC) Date: Thu, 30 Dec 2010 00:20:33 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20101230002033.GA23583@freebsd.org> References: <20101227213559.GA53178@freebsd.org> <20101228142203.GA69674@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101228142203.GA69674@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: issue with clang and CPUTYPE native X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 00:20:33 -0000 On Tue Dec 28 10, Roman Divacky wrote: > -march=native in clang works by detecting CPU name > and passing it (if found) to llvm. if the CPU is not > detected nothing is passed. > > nocona is supported > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > be equivalent to setting it to "native". > > > can you apply this patch: > > Index: Driver/Tools.cpp > =================================================================== > --- Driver/Tools.cpp (revision 122591) > +++ Driver/Tools.cpp (working copy) > @@ -684,6 +684,7 @@ > // FIXME: We should also incorporate the detected target features for use > // with -native. > std::string CPU = llvm::sys::getHostCPUName(); > + llvm::outs() << "detected CPU = " << CPU << "\n"; > if (!CPU.empty()) > CPUName = Args.MakeArgString(CPU); > } else thanks a lot for the patch. i've applied it, but am not sure how to only compile clang. 'make' in usr.bin/clang fails. do i have to run target buildworld or is there a way to only build clang? cheers. alex > > > and try to > > clang -march=native hello_world.c > > ? I wonder what cpu (if any) is detected. > > > On Mon, Dec 27, 2010 at 09:35:59PM +0000, Alexander Best wrote: > > hi there, > > > > i've been experiencing the following problems with clang during TARGET > > buildworld for quite a while now: > > > > **** CODE **** > > clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc > > clang++: warning: argument unused during compilation: '-fno-implicit-templates' > > clang -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -std=gnu99 -fstack-protector -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c > > building static supc++ library > > ranlib libsupc++.a > > ===> gnu/lib/libobjc (all) > > gcc -O2 -pipe -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/usr/subversion-src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -std=gnu99 -fstack-protector -c /usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c > > *** Signal 11 > > > > Stop in /usr/subversion-src/gnu/lib/libobjc. > > *** Error code 1 > > > > Stop in /usr/subversion-src/gnu/lib. > > *** Error code 1 > > > > Stop in /usr/subversion-src. > > *** Error code 1 > > > > Stop in /usr/subversion-src. > > *** Error code 1 > > > > Stop in /usr/subversion-src. > > *** Error code 1 > > > > Stop in /usr/subversion-src. > > **** CODE **** > > > > i've finally figured out that the following line in make.conf is causing the > > problem: > > > > CPUTYPE ?= native > > > > if i remove it or change it to CPUTYPE ?= nocona everything works fine. if i'm > > using gcc as compiler, having CPUTYPE ?= native in my make.conf causes no harm. > > > > this is on amd64 and a very recent HEAD snapshot. > > > > can somebody verify this issue? > > > > cheers. > > alex > > > > -- > > a13x > > _______________________________________________ > > freebsd-toolchain@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Thu Dec 30 08:14:48 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBFAD1065696; Thu, 30 Dec 2010 08:14:48 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 983608FC1A; Thu, 30 Dec 2010 08:14:48 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 909999CB273; Thu, 30 Dec 2010 09:14:46 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5a88KrDlZH9; Thu, 30 Dec 2010 09:14:45 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id C2ABF9CB5DA; Thu, 30 Dec 2010 09:14:45 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id oBU8Ejbb099558; Thu, 30 Dec 2010 09:14:45 +0100 (CET) (envelope-from rdivacky) Date: Thu, 30 Dec 2010 09:14:45 +0100 From: Roman Divacky To: Alexander Best Message-ID: <20101230081445.GA99446@freebsd.org> References: <20101227213559.GA53178@freebsd.org> <20101228142203.GA69674@freebsd.org> <20101230002033.GA23583@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101230002033.GA23583@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-toolchain@freebsd.org Subject: Re: issue with clang and CPUTYPE native X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 08:14:48 -0000 On Thu, Dec 30, 2010 at 12:20:33AM +0000, Alexander Best wrote: > On Tue Dec 28 10, Roman Divacky wrote: > > -march=native in clang works by detecting CPU name > > and passing it (if found) to llvm. if the CPU is not > > detected nothing is passed. > > > > nocona is supported > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > > be equivalent to setting it to "native". > > > > > > can you apply this patch: > > > > Index: Driver/Tools.cpp > > =================================================================== > > --- Driver/Tools.cpp (revision 122591) > > +++ Driver/Tools.cpp (working copy) > > @@ -684,6 +684,7 @@ > > // FIXME: We should also incorporate the detected target features for use > > // with -native. > > std::string CPU = llvm::sys::getHostCPUName(); > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > if (!CPU.empty()) > > CPUName = Args.MakeArgString(CPU); > > } else > > thanks a lot for the patch. i've applied it, but am not sure how to only > compile clang. 'make' in usr.bin/clang fails. do i have to run target > buildworld or is there a way to only build clang? I would guess that cd lib/clang && make && cd ../../usr.bin/clang && make should work, if not - full buildworld is necessary I guess From owner-freebsd-toolchain@FreeBSD.ORG Thu Dec 30 18:40:48 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7E5061065670; Thu, 30 Dec 2010 18:40:48 +0000 (UTC) Date: Thu, 30 Dec 2010 18:40:48 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20101230184048.GA34628@freebsd.org> References: <20101227213559.GA53178@freebsd.org> <20101228142203.GA69674@freebsd.org> <20101230002033.GA23583@freebsd.org> <20101230081445.GA99446@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101230081445.GA99446@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: issue with clang and CPUTYPE native X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 18:40:48 -0000 On Thu Dec 30 10, Roman Divacky wrote: > On Thu, Dec 30, 2010 at 12:20:33AM +0000, Alexander Best wrote: > > On Tue Dec 28 10, Roman Divacky wrote: > > > -march=native in clang works by detecting CPU name > > > and passing it (if found) to llvm. if the CPU is not > > > detected nothing is passed. > > > > > > nocona is supported > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > > > be equivalent to setting it to "native". > > > > > > > > > can you apply this patch: > > > > > > Index: Driver/Tools.cpp > > > =================================================================== > > > --- Driver/Tools.cpp (revision 122591) > > > +++ Driver/Tools.cpp (working copy) > > > @@ -684,6 +684,7 @@ > > > // FIXME: We should also incorporate the detected target features for use > > > // with -native. > > > std::string CPU = llvm::sys::getHostCPUName(); > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > if (!CPU.empty()) > > > CPUName = Args.MakeArgString(CPU); > > > } else > > > > thanks a lot for the patch. i've applied it, but am not sure how to only > > compile clang. 'make' in usr.bin/clang fails. do i have to run target > > buildworld or is there a way to only build clang? > > I would guess that cd lib/clang && make && cd ../../usr.bin/clang && make > should work, if not - full buildworld is necessary I guess thanks. that worked. this is what clang detects as my cpu: -march=native this the dmesg output: CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (2394.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant cheers. alex -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Thu Dec 30 18:44:45 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 382941065679; Thu, 30 Dec 2010 18:44:45 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id E81F38FC17; Thu, 30 Dec 2010 18:44:44 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id D632F9CB0FB; Thu, 30 Dec 2010 19:44:42 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNpA-z0Szhyk; Thu, 30 Dec 2010 19:44:42 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 427849CB167; Thu, 30 Dec 2010 19:44:42 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id oBUIigYv079933; Thu, 30 Dec 2010 19:44:42 +0100 (CET) (envelope-from rdivacky) Date: Thu, 30 Dec 2010 19:44:42 +0100 From: Roman Divacky To: Alexander Best Message-ID: <20101230184442.GA79735@freebsd.org> References: <20101227213559.GA53178@freebsd.org> <20101228142203.GA69674@freebsd.org> <20101230002033.GA23583@freebsd.org> <20101230081445.GA99446@freebsd.org> <20101230184048.GA34628@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101230184048.GA34628@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-toolchain@freebsd.org Subject: Re: issue with clang and CPUTYPE native X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 18:44:45 -0000 On Thu, Dec 30, 2010 at 06:40:48PM +0000, Alexander Best wrote: > On Thu Dec 30 10, Roman Divacky wrote: > > On Thu, Dec 30, 2010 at 12:20:33AM +0000, Alexander Best wrote: > > > On Tue Dec 28 10, Roman Divacky wrote: > > > > -march=native in clang works by detecting CPU name > > > > and passing it (if found) to llvm. if the CPU is not > > > > detected nothing is passed. > > > > > > > > nocona is supported > > > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > > > > be equivalent to setting it to "native". > > > > > > > > > > > > can you apply this patch: > > > > > > > > Index: Driver/Tools.cpp > > > > =================================================================== > > > > --- Driver/Tools.cpp (revision 122591) > > > > +++ Driver/Tools.cpp (working copy) > > > > @@ -684,6 +684,7 @@ > > > > // FIXME: We should also incorporate the detected target features for use > > > > // with -native. > > > > std::string CPU = llvm::sys::getHostCPUName(); > > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > > if (!CPU.empty()) > > > > CPUName = Args.MakeArgString(CPU); > > > > } else > > > > > > thanks a lot for the patch. i've applied it, but am not sure how to only > > > compile clang. 'make' in usr.bin/clang fails. do i have to run target > > > buildworld or is there a way to only build clang? > > > > I would guess that cd lib/clang && make && cd ../../usr.bin/clang && make > > should work, if not - full buildworld is necessary I guess > > thanks. that worked. this is what clang detects as my cpu: > > -march=native hm? are you sure it wrote -march=native? it should have written "detected CPU = something" From owner-freebsd-toolchain@FreeBSD.ORG Thu Dec 30 18:46:16 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id E3AF81065672; Thu, 30 Dec 2010 18:46:16 +0000 (UTC) Date: Thu, 30 Dec 2010 18:46:16 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20101230184616.GA35433@freebsd.org> References: <20101227213559.GA53178@freebsd.org> <20101228142203.GA69674@freebsd.org> <20101230002033.GA23583@freebsd.org> <20101230081445.GA99446@freebsd.org> <20101230184048.GA34628@freebsd.org> <20101230184442.GA79735@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101230184442.GA79735@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: issue with clang and CPUTYPE native X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 18:46:17 -0000 On Thu Dec 30 10, Roman Divacky wrote: > On Thu, Dec 30, 2010 at 06:40:48PM +0000, Alexander Best wrote: > > On Thu Dec 30 10, Roman Divacky wrote: > > > On Thu, Dec 30, 2010 at 12:20:33AM +0000, Alexander Best wrote: > > > > On Tue Dec 28 10, Roman Divacky wrote: > > > > > -march=native in clang works by detecting CPU name > > > > > and passing it (if found) to llvm. if the CPU is not > > > > > detected nothing is passed. > > > > > > > > > > nocona is supported > > > > > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > > > > > be equivalent to setting it to "native". > > > > > > > > > > > > > > > can you apply this patch: > > > > > > > > > > Index: Driver/Tools.cpp > > > > > =================================================================== > > > > > --- Driver/Tools.cpp (revision 122591) > > > > > +++ Driver/Tools.cpp (working copy) > > > > > @@ -684,6 +684,7 @@ > > > > > // FIXME: We should also incorporate the detected target features for use > > > > > // with -native. > > > > > std::string CPU = llvm::sys::getHostCPUName(); > > > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > > > if (!CPU.empty()) > > > > > CPUName = Args.MakeArgString(CPU); > > > > > } else > > > > > > > > thanks a lot for the patch. i've applied it, but am not sure how to only > > > > compile clang. 'make' in usr.bin/clang fails. do i have to run target > > > > buildworld or is there a way to only build clang? > > > > > > I would guess that cd lib/clang && make && cd ../../usr.bin/clang && make > > > should work, if not - full buildworld is necessary I guess > > > > thanks. that worked. this is what clang detects as my cpu: > > > > -march=native > > hm? are you sure it wrote -march=native? it should have written oh sorry. i copy&pasted the wrong line. :( detected CPU = core2 > > "detected CPU = something" -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Thu Dec 30 20:18:51 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7EBC1065673; Thu, 30 Dec 2010 20:18:51 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 61C9B8FC0A; Thu, 30 Dec 2010 20:18:50 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 810F69CB0C3; Thu, 30 Dec 2010 21:18:49 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8feTYAnBgvXq; Thu, 30 Dec 2010 21:18:49 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id CCB419CB188; Thu, 30 Dec 2010 21:18:48 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id oBUKImFa092666; Thu, 30 Dec 2010 21:18:48 +0100 (CET) (envelope-from rdivacky) Date: Thu, 30 Dec 2010 21:18:48 +0100 From: Roman Divacky To: Alexander Best Message-ID: <20101230201848.GA92145@freebsd.org> References: <20101227213559.GA53178@freebsd.org> <20101228142203.GA69674@freebsd.org> <20101230002033.GA23583@freebsd.org> <20101230081445.GA99446@freebsd.org> <20101230184048.GA34628@freebsd.org> <20101230184442.GA79735@freebsd.org> <20101230184616.GA35433@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101230184616.GA35433@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-toolchain@freebsd.org Subject: Re: issue with clang and CPUTYPE native X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Dec 2010 20:18:51 -0000 On Thu, Dec 30, 2010 at 06:46:16PM +0000, Alexander Best wrote: > On Thu Dec 30 10, Roman Divacky wrote: > > On Thu, Dec 30, 2010 at 06:40:48PM +0000, Alexander Best wrote: > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > On Thu, Dec 30, 2010 at 12:20:33AM +0000, Alexander Best wrote: > > > > > On Tue Dec 28 10, Roman Divacky wrote: > > > > > > -march=native in clang works by detecting CPU name > > > > > > and passing it (if found) to llvm. if the CPU is not > > > > > > detected nothing is passed. > > > > > > > > > > > > nocona is supported > > > > > > > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > > > > > > be equivalent to setting it to "native". > > > > > > > > > > > > > > > > > > can you apply this patch: > > > > > > > > > > > > Index: Driver/Tools.cpp > > > > > > =================================================================== > > > > > > --- Driver/Tools.cpp (revision 122591) > > > > > > +++ Driver/Tools.cpp (working copy) > > > > > > @@ -684,6 +684,7 @@ > > > > > > // FIXME: We should also incorporate the detected target features for use > > > > > > // with -native. > > > > > > std::string CPU = llvm::sys::getHostCPUName(); > > > > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > > > > if (!CPU.empty()) > > > > > > CPUName = Args.MakeArgString(CPU); > > > > > > } else > > > > > > > > > > thanks a lot for the patch. i've applied it, but am not sure how to only > > > > > compile clang. 'make' in usr.bin/clang fails. do i have to run target > > > > > buildworld or is there a way to only build clang? > > > > > > > > I would guess that cd lib/clang && make && cd ../../usr.bin/clang && make > > > > should work, if not - full buildworld is necessary I guess > > > > > > thanks. that worked. this is what clang detects as my cpu: > > > > > > -march=native > > > > hm? are you sure it wrote -march=native? it should have written > > oh sorry. i copy&pasted the wrong line. :( > > detected CPU = core2 yes, you have core2, maybe thats why using CPU=nocona is causing you problems? From owner-freebsd-toolchain@FreeBSD.ORG Fri Dec 31 01:20:02 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id BA5CA1065672; Fri, 31 Dec 2010 01:20:02 +0000 (UTC) Date: Fri, 31 Dec 2010 01:20:02 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20101231012002.GA73736@freebsd.org> References: <20101227213559.GA53178@freebsd.org> <20101228142203.GA69674@freebsd.org> <20101230002033.GA23583@freebsd.org> <20101230081445.GA99446@freebsd.org> <20101230184048.GA34628@freebsd.org> <20101230184442.GA79735@freebsd.org> <20101230184616.GA35433@freebsd.org> <20101230201848.GA92145@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101230201848.GA92145@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: issue with clang and CPUTYPE native X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 01:20:02 -0000 On Thu Dec 30 10, Roman Divacky wrote: > On Thu, Dec 30, 2010 at 06:46:16PM +0000, Alexander Best wrote: > > On Thu Dec 30 10, Roman Divacky wrote: > > > On Thu, Dec 30, 2010 at 06:40:48PM +0000, Alexander Best wrote: > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > On Thu, Dec 30, 2010 at 12:20:33AM +0000, Alexander Best wrote: > > > > > > On Tue Dec 28 10, Roman Divacky wrote: > > > > > > > -march=native in clang works by detecting CPU name > > > > > > > and passing it (if found) to llvm. if the CPU is not > > > > > > > detected nothing is passed. > > > > > > > > > > > > > > nocona is supported > > > > > > > > > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > > > > > > > be equivalent to setting it to "native". > > > > > > > > > > > > > > > > > > > > > can you apply this patch: > > > > > > > > > > > > > > Index: Driver/Tools.cpp > > > > > > > =================================================================== > > > > > > > --- Driver/Tools.cpp (revision 122591) > > > > > > > +++ Driver/Tools.cpp (working copy) > > > > > > > @@ -684,6 +684,7 @@ > > > > > > > // FIXME: We should also incorporate the detected target features for use > > > > > > > // with -native. > > > > > > > std::string CPU = llvm::sys::getHostCPUName(); > > > > > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > > > > > if (!CPU.empty()) > > > > > > > CPUName = Args.MakeArgString(CPU); > > > > > > > } else > > > > > > > > > > > > thanks a lot for the patch. i've applied it, but am not sure how to only > > > > > > compile clang. 'make' in usr.bin/clang fails. do i have to run target > > > > > > buildworld or is there a way to only build clang? > > > > > > > > > > I would guess that cd lib/clang && make && cd ../../usr.bin/clang && make > > > > > should work, if not - full buildworld is necessary I guess > > > > > > > > thanks. that worked. this is what clang detects as my cpu: > > > > > > > > -march=native > > > > > > hm? are you sure it wrote -march=native? it should have written > > > > oh sorry. i copy&pasted the wrong line. :( > > > > detected CPU = core2 > > yes, you have core2, maybe thats why using CPU=nocona is causing you problems? CPU=nocona *isn't* causing problems. CPU=native is causing the problems. core2 is wrong imo. have a look at share/mk/bsd.cpu.mk for amd64. it sets core2 to nocona. so clang should detect nocona for CPU=native and *not* core2. however i'll try to run buildworld again with the patched clang to completely pinpoint the problem. cheers. alex -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Fri Dec 31 15:15:58 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8168B106566C; Fri, 31 Dec 2010 15:15:58 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 0E42B8FC12; Fri, 31 Dec 2010 15:15:57 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 9E7249CB065; Fri, 31 Dec 2010 16:15:55 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by lev.vlakno.cz (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAqiF10K1ILj; Fri, 31 Dec 2010 16:15:55 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id E8BBC9CB252; Fri, 31 Dec 2010 16:15:54 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id oBVFFsjJ030354; Fri, 31 Dec 2010 16:15:54 +0100 (CET) (envelope-from rdivacky) Date: Fri, 31 Dec 2010 16:15:54 +0100 From: Roman Divacky To: Alexander Best Message-ID: <20101231151554.GA29782@freebsd.org> References: <20101227213559.GA53178@freebsd.org> <20101228142203.GA69674@freebsd.org> <20101230002033.GA23583@freebsd.org> <20101230081445.GA99446@freebsd.org> <20101230184048.GA34628@freebsd.org> <20101230184442.GA79735@freebsd.org> <20101230184616.GA35433@freebsd.org> <20101230201848.GA92145@freebsd.org> <20101231012002.GA73736@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101231012002.GA73736@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-toolchain@freebsd.org Subject: Re: issue with clang and CPUTYPE native X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 15:15:58 -0000 On Fri, Dec 31, 2010 at 01:20:02AM +0000, Alexander Best wrote: > On Thu Dec 30 10, Roman Divacky wrote: > > On Thu, Dec 30, 2010 at 06:46:16PM +0000, Alexander Best wrote: > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > On Thu, Dec 30, 2010 at 06:40:48PM +0000, Alexander Best wrote: > > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > > On Thu, Dec 30, 2010 at 12:20:33AM +0000, Alexander Best wrote: > > > > > > > On Tue Dec 28 10, Roman Divacky wrote: > > > > > > > > -march=native in clang works by detecting CPU name > > > > > > > > and passing it (if found) to llvm. if the CPU is not > > > > > > > > detected nothing is passed. > > > > > > > > > > > > > > > > nocona is supported > > > > > > > > > > > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > > > > > > > > be equivalent to setting it to "native". > > > > > > > > > > > > > > > > > > > > > > > > can you apply this patch: > > > > > > > > > > > > > > > > Index: Driver/Tools.cpp > > > > > > > > =================================================================== > > > > > > > > --- Driver/Tools.cpp (revision 122591) > > > > > > > > +++ Driver/Tools.cpp (working copy) > > > > > > > > @@ -684,6 +684,7 @@ > > > > > > > > // FIXME: We should also incorporate the detected target features for use > > > > > > > > // with -native. > > > > > > > > std::string CPU = llvm::sys::getHostCPUName(); > > > > > > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > > > > > > if (!CPU.empty()) > > > > > > > > CPUName = Args.MakeArgString(CPU); > > > > > > > > } else > > > > > > > > > > > > > > thanks a lot for the patch. i've applied it, but am not sure how to only > > > > > > > compile clang. 'make' in usr.bin/clang fails. do i have to run target > > > > > > > buildworld or is there a way to only build clang? > > > > > > > > > > > > I would guess that cd lib/clang && make && cd ../../usr.bin/clang && make > > > > > > should work, if not - full buildworld is necessary I guess > > > > > > > > > > thanks. that worked. this is what clang detects as my cpu: > > > > > > > > > > -march=native > > > > > > > > hm? are you sure it wrote -march=native? it should have written > > > > > > oh sorry. i copy&pasted the wrong line. :( > > > > > > detected CPU = core2 > > > > yes, you have core2, maybe thats why using CPU=nocona is causing you problems? > > CPU=nocona *isn't* causing problems. CPU=native is causing the problems. > > core2 is wrong imo. have a look at share/mk/bsd.cpu.mk for amd64. it sets core2 > to nocona. so clang should detect nocona for CPU=native and *not* core2. no, your cpu is core2 so clang is correct to detect is as such. it's imho irrelevant that we (freebsd mk framework) reset core2 to nocona. the reason for that is imho that gcc 4.2.1 does not support core2 so we "downgrade" that to nocona. > however i'll try to run buildworld again with the patched clang to completely > pinpoint the problem. yes please, it's going to be interesting to see what is the exact problem From owner-freebsd-toolchain@FreeBSD.ORG Fri Dec 31 18:00:54 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id AFB90106566B; Fri, 31 Dec 2010 18:00:54 +0000 (UTC) Date: Fri, 31 Dec 2010 18:00:54 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20101231180054.GA77781@freebsd.org> References: <20101227213559.GA53178@freebsd.org> <20101228142203.GA69674@freebsd.org> <20101230002033.GA23583@freebsd.org> <20101230081445.GA99446@freebsd.org> <20101230184048.GA34628@freebsd.org> <20101230184442.GA79735@freebsd.org> <20101230184616.GA35433@freebsd.org> <20101230201848.GA92145@freebsd.org> <20101231012002.GA73736@freebsd.org> <20101231151554.GA29782@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <20101231151554.GA29782@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: issue with clang and CPUTYPE native X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 18:00:54 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri Dec 31 10, Roman Divacky wrote: > On Fri, Dec 31, 2010 at 01:20:02AM +0000, Alexander Best wrote: > > On Thu Dec 30 10, Roman Divacky wrote: > > > On Thu, Dec 30, 2010 at 06:46:16PM +0000, Alexander Best wrote: > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > On Thu, Dec 30, 2010 at 06:40:48PM +0000, Alexander Best wrote: > > > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > > > On Thu, Dec 30, 2010 at 12:20:33AM +0000, Alexander Best wrote: > > > > > > > > On Tue Dec 28 10, Roman Divacky wrote: > > > > > > > > > -march=native in clang works by detecting CPU name > > > > > > > > > and passing it (if found) to llvm. if the CPU is not > > > > > > > > > detected nothing is passed. > > > > > > > > > > > > > > > > > > nocona is supported > > > > > > > > > > > > > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > > > > > > > > > be equivalent to setting it to "native". > > > > > > > > > > > > > > > > > > > > > > > > > > > can you apply this patch: > > > > > > > > > > > > > > > > > > Index: Driver/Tools.cpp > > > > > > > > > =================================================================== > > > > > > > > > --- Driver/Tools.cpp (revision 122591) > > > > > > > > > +++ Driver/Tools.cpp (working copy) > > > > > > > > > @@ -684,6 +684,7 @@ > > > > > > > > > // FIXME: We should also incorporate the detected target features for use > > > > > > > > > // with -native. > > > > > > > > > std::string CPU = llvm::sys::getHostCPUName(); > > > > > > > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > > > > > > > if (!CPU.empty()) > > > > > > > > > CPUName = Args.MakeArgString(CPU); > > > > > > > > > } else > > > > > > > > > > > > > > > > thanks a lot for the patch. i've applied it, but am not sure how to only > > > > > > > > compile clang. 'make' in usr.bin/clang fails. do i have to run target > > > > > > > > buildworld or is there a way to only build clang? > > > > > > > > > > > > > > I would guess that cd lib/clang && make && cd ../../usr.bin/clang && make > > > > > > > should work, if not - full buildworld is necessary I guess > > > > > > > > > > > > thanks. that worked. this is what clang detects as my cpu: > > > > > > > > > > > > -march=native > > > > > > > > > > hm? are you sure it wrote -march=native? it should have written > > > > > > > > oh sorry. i copy&pasted the wrong line. :( > > > > > > > > detected CPU = core2 > > > > > > yes, you have core2, maybe thats why using CPU=nocona is causing you problems? > > > > CPU=nocona *isn't* causing problems. CPU=native is causing the problems. > > > > core2 is wrong imo. have a look at share/mk/bsd.cpu.mk for amd64. it sets core2 > > to nocona. so clang should detect nocona for CPU=native and *not* core2. > > no, your cpu is core2 so clang is correct to detect is as such. it's imho irrelevant > that we (freebsd mk framework) reset core2 to nocona. i'm sorry. you're of course right. looking at the manual page of a newer gcc release reveals that core2 is in fact the correct cpu. what i did now was to clean out my src.conf and make.conf and run buildworld with gcc and with clang. you can see the results in the attached file in addition to the contents of my src.conf and make.conf right now i'm trying to repeat the tests with cpu set to core2 and nocona. cheers. alex > > the reason for that is imho that gcc 4.2.1 does not support core2 so we "downgrade" > that to nocona. > > > > however i'll try to run buildworld again with the patched clang to completely > > pinpoint the problem. > > yes please, it's going to be interesting to see what is the exact problem -- a13x --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=BUILDWORLD grep -v "^#" /etc/make.conf /etc/src.conf: /etc/make.conf:KERNCONF = ARUNDEL /etc/make.conf:MODULES_OVERRIDE = \ /etc/make.conf:netgraph/netgraph \ /etc/make.conf:netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci \ /etc/make.conf:netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt \ /etc/make.conf:linux tmpfs sound/sound sound/driver/hda usb/uhid \ /etc/make.conf:procfs pseudofs linprocfs linsysfs lindev usb/quirk geom /etc/make.conf: /etc/make.conf: /etc/make.conf:CPUTYPE ?= native /etc/make.conf: /etc/make.conf:SENDMAIL_MC = /etc/mail/freebsd.mc /etc/make.conf:SENDMAIL_SUBMIT_MC = /etc/mail/freebsd.submit.mc /etc/make.conf: /etc/make.conf:OVERRIDE_LINUX_BASE_PORT = f10 /etc/make.conf:OVERRIDE_LINUX_NONBASE_PORTS = f10 /etc/make.conf:DA4 = yes /etc/make.conf:WITH_BSDEL = yes /etc/make.conf:WITH_256_COLOR = yes /etc/make.conf: /etc/make.conf:PERL_VERSION=5.12.2 /etc/src.conf: /etc/src.conf:DEBUG_FLAGS = -g /etc/src.conf: /etc/src.conf:WITHOUT_PROFILE=true /etc/src.conf:WITHOUT_CDDL=true /etc/src.conf:WITHOUT_ATM=true make buildworld: ==> SUCCEEDS! grep -v "^#" /etc/make.conf /etc/src.conf: /etc/make.conf:KERNCONF = ARUNDEL /etc/make.conf:MODULES_OVERRIDE = \ /etc/make.conf:netgraph/netgraph \ /etc/make.conf:netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci \ /etc/make.conf:netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt \ /etc/make.conf:linux tmpfs sound/sound sound/driver/hda usb/uhid \ /etc/make.conf:procfs pseudofs linprocfs linsysfs lindev usb/quirk geom /etc/make.conf: /etc/make.conf: /etc/make.conf:CPUTYPE ?= native /etc/make.conf: /etc/make.conf:SENDMAIL_MC = /etc/mail/freebsd.mc /etc/make.conf:SENDMAIL_SUBMIT_MC = /etc/mail/freebsd.submit.mc /etc/make.conf: /etc/make.conf:OVERRIDE_LINUX_BASE_PORT = f10 /etc/make.conf:OVERRIDE_LINUX_NONBASE_PORTS = f10 /etc/make.conf:DA4 = yes /etc/make.conf:WITH_BSDEL = yes /etc/make.conf:WITH_256_COLOR = yes /etc/make.conf: /etc/make.conf:PERL_VERSION=5.12.2 /etc/src.conf:.if !defined(CC) || ${CC} == "cc" /etc/src.conf:CC=clang /etc/src.conf:.endif /etc/src.conf:.if !defined(CXX) || ${CXX} == "c++" /etc/src.conf:CXX=clang++ /etc/src.conf:.endif /etc/src.conf:NO_WERROR= /etc/src.conf:WERROR= /etc/src.conf: /etc/src.conf:DEBUG_FLAGS = -g /etc/src.conf: /etc/src.conf:WITHOUT_PROFILE=true /etc/src.conf:WITHOUT_CDDL=true /etc/src.conf:WITHOUT_ATM=true make buildworld: ==> FAILS! 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. 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 Stop in /usr/subversion-src/lib/libcompiler_rt. *** Error code 1 Stop in /usr/subversion-src. *** Error code 1 Stop in /usr/subversion-src. *** Error code 1 Stop in /usr/subversion-src. *** Error code 1 Stop in /usr/subversion-src. --nFreZHaLTZJo0R7j-- From owner-freebsd-toolchain@FreeBSD.ORG Fri Dec 31 19:08:38 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id CF5B91065670; Fri, 31 Dec 2010 19:08:38 +0000 (UTC) Date: Fri, 31 Dec 2010 19:08:38 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20101231190838.GA85678@freebsd.org> References: <20101228142203.GA69674@freebsd.org> <20101230002033.GA23583@freebsd.org> <20101230081445.GA99446@freebsd.org> <20101230184048.GA34628@freebsd.org> <20101230184442.GA79735@freebsd.org> <20101230184616.GA35433@freebsd.org> <20101230201848.GA92145@freebsd.org> <20101231012002.GA73736@freebsd.org> <20101231151554.GA29782@freebsd.org> <20101231180054.GA77781@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101231180054.GA77781@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: issue with clang and CPUTYPE native X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 19:08:38 -0000 On Fri Dec 31 10, Alexander Best wrote: > On Fri Dec 31 10, Roman Divacky wrote: > > On Fri, Dec 31, 2010 at 01:20:02AM +0000, Alexander Best wrote: > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > On Thu, Dec 30, 2010 at 06:46:16PM +0000, Alexander Best wrote: > > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > > On Thu, Dec 30, 2010 at 06:40:48PM +0000, Alexander Best wrote: > > > > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > > > > On Thu, Dec 30, 2010 at 12:20:33AM +0000, Alexander Best wrote: > > > > > > > > > On Tue Dec 28 10, Roman Divacky wrote: > > > > > > > > > > -march=native in clang works by detecting CPU name > > > > > > > > > > and passing it (if found) to llvm. if the CPU is not > > > > > > > > > > detected nothing is passed. > > > > > > > > > > > > > > > > > > > > nocona is supported > > > > > > > > > > > > > > > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > > > > > > > > > > be equivalent to setting it to "native". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > can you apply this patch: > > > > > > > > > > > > > > > > > > > > Index: Driver/Tools.cpp > > > > > > > > > > =================================================================== > > > > > > > > > > --- Driver/Tools.cpp (revision 122591) > > > > > > > > > > +++ Driver/Tools.cpp (working copy) > > > > > > > > > > @@ -684,6 +684,7 @@ > > > > > > > > > > // FIXME: We should also incorporate the detected target features for use > > > > > > > > > > // with -native. > > > > > > > > > > std::string CPU = llvm::sys::getHostCPUName(); > > > > > > > > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > > > > > > > > if (!CPU.empty()) > > > > > > > > > > CPUName = Args.MakeArgString(CPU); > > > > > > > > > > } else > > > > > > > > > > > > > > > > > > thanks a lot for the patch. i've applied it, but am not sure how to only > > > > > > > > > compile clang. 'make' in usr.bin/clang fails. do i have to run target > > > > > > > > > buildworld or is there a way to only build clang? > > > > > > > > > > > > > > > > I would guess that cd lib/clang && make && cd ../../usr.bin/clang && make > > > > > > > > should work, if not - full buildworld is necessary I guess > > > > > > > > > > > > > > thanks. that worked. this is what clang detects as my cpu: > > > > > > > > > > > > > > -march=native > > > > > > > > > > > > hm? are you sure it wrote -march=native? it should have written > > > > > > > > > > oh sorry. i copy&pasted the wrong line. :( > > > > > > > > > > detected CPU = core2 > > > > > > > > yes, you have core2, maybe thats why using CPU=nocona is causing you problems? > > > > > > CPU=nocona *isn't* causing problems. CPU=native is causing the problems. > > > > > > core2 is wrong imo. have a look at share/mk/bsd.cpu.mk for amd64. it sets core2 > > > to nocona. so clang should detect nocona for CPU=native and *not* core2. > > > > no, your cpu is core2 so clang is correct to detect is as such. it's imho irrelevant > > that we (freebsd mk framework) reset core2 to nocona. > > i'm sorry. you're of course right. looking at the manual page of a newer gcc > release reveals that core2 is in fact the correct cpu. > > what i did now was to clean out my src.conf and make.conf and run buildworld > with gcc and with clang. > > you can see the results in the attached file in addition to the contents of my > src.conf and make.conf > > right now i'm trying to repeat the tests with cpu set to core2 and nocona. > > cheers. > alex > > > > > the reason for that is imho that gcc 4.2.1 does not support core2 so we "downgrade" > > that to nocona. > > > > > > > however i'll try to run buildworld again with the patched clang to completely > > > pinpoint the problem. > > > > yes please, it's going to be interesting to see what is the exact problem i've just tried building world with CUPTYPE ?= nocona and got the same result: gcc succeeds; clang fails. the error message however is not the one i was refering to earlier. the reason i get a different error message seems to be the fact that i got rid of most of the WITHOUT_* optins in src.conf. so there are at least two issues with clang, where it fails in cases gcc succeeds. i'm doing another final buildworld with CPUTYPE ?= core2, but i suspect the result will be the same. cheers. alex > > -- > a13x > grep -v "^#" /etc/make.conf /etc/src.conf: > > /etc/make.conf:KERNCONF = ARUNDEL > /etc/make.conf:MODULES_OVERRIDE = \ > /etc/make.conf:netgraph/netgraph \ > /etc/make.conf:netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci \ > /etc/make.conf:netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt \ > /etc/make.conf:linux tmpfs sound/sound sound/driver/hda usb/uhid \ > /etc/make.conf:procfs pseudofs linprocfs linsysfs lindev usb/quirk geom > /etc/make.conf: > /etc/make.conf: > /etc/make.conf:CPUTYPE ?= native > /etc/make.conf: > /etc/make.conf:SENDMAIL_MC = /etc/mail/freebsd.mc > /etc/make.conf:SENDMAIL_SUBMIT_MC = /etc/mail/freebsd.submit.mc > /etc/make.conf: > /etc/make.conf:OVERRIDE_LINUX_BASE_PORT = f10 > /etc/make.conf:OVERRIDE_LINUX_NONBASE_PORTS = f10 > /etc/make.conf:DA4 = yes > /etc/make.conf:WITH_BSDEL = yes > /etc/make.conf:WITH_256_COLOR = yes > /etc/make.conf: > /etc/make.conf:PERL_VERSION=5.12.2 > /etc/src.conf: > /etc/src.conf:DEBUG_FLAGS = -g > /etc/src.conf: > /etc/src.conf:WITHOUT_PROFILE=true > /etc/src.conf:WITHOUT_CDDL=true > /etc/src.conf:WITHOUT_ATM=true > > make buildworld: > > ==> SUCCEEDS! > > grep -v "^#" /etc/make.conf /etc/src.conf: > > /etc/make.conf:KERNCONF = ARUNDEL > /etc/make.conf:MODULES_OVERRIDE = \ > /etc/make.conf:netgraph/netgraph \ > /etc/make.conf:netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci \ > /etc/make.conf:netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt \ > /etc/make.conf:linux tmpfs sound/sound sound/driver/hda usb/uhid \ > /etc/make.conf:procfs pseudofs linprocfs linsysfs lindev usb/quirk geom > /etc/make.conf: > /etc/make.conf: > /etc/make.conf:CPUTYPE ?= native > /etc/make.conf: > /etc/make.conf:SENDMAIL_MC = /etc/mail/freebsd.mc > /etc/make.conf:SENDMAIL_SUBMIT_MC = /etc/mail/freebsd.submit.mc > /etc/make.conf: > /etc/make.conf:OVERRIDE_LINUX_BASE_PORT = f10 > /etc/make.conf:OVERRIDE_LINUX_NONBASE_PORTS = f10 > /etc/make.conf:DA4 = yes > /etc/make.conf:WITH_BSDEL = yes > /etc/make.conf:WITH_256_COLOR = yes > /etc/make.conf: > /etc/make.conf:PERL_VERSION=5.12.2 > /etc/src.conf:.if !defined(CC) || ${CC} == "cc" > /etc/src.conf:CC=clang > /etc/src.conf:.endif > /etc/src.conf:.if !defined(CXX) || ${CXX} == "c++" > /etc/src.conf:CXX=clang++ > /etc/src.conf:.endif > /etc/src.conf:NO_WERROR= > /etc/src.conf:WERROR= > /etc/src.conf: > /etc/src.conf:DEBUG_FLAGS = -g > /etc/src.conf: > /etc/src.conf:WITHOUT_PROFILE=true > /etc/src.conf:WITHOUT_CDDL=true > /etc/src.conf:WITHOUT_ATM=true > > make buildworld: > > ==> FAILS! > > 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. 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 > > Stop in /usr/subversion-src/lib/libcompiler_rt. > *** Error code 1 > > Stop in /usr/subversion-src. > *** Error code 1 > > Stop in /usr/subversion-src. > *** Error code 1 > > Stop in /usr/subversion-src. > *** Error code 1 > > Stop in /usr/subversion-src. -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Fri Dec 31 23:17:20 2010 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 57DCD1065672; Fri, 31 Dec 2010 23:17:20 +0000 (UTC) Date: Fri, 31 Dec 2010 23:17:20 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20101231231720.GA10589@freebsd.org> References: <20101230002033.GA23583@freebsd.org> <20101230081445.GA99446@freebsd.org> <20101230184048.GA34628@freebsd.org> <20101230184442.GA79735@freebsd.org> <20101230184616.GA35433@freebsd.org> <20101230201848.GA92145@freebsd.org> <20101231012002.GA73736@freebsd.org> <20101231151554.GA29782@freebsd.org> <20101231180054.GA77781@freebsd.org> <20101231190838.GA85678@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101231190838.GA85678@freebsd.org> Cc: freebsd-toolchain@freebsd.org Subject: Re: issue with clang and CPUTYPE native X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Dec 2010 23:17:20 -0000 On Fri Dec 31 10, Alexander Best wrote: > On Fri Dec 31 10, Alexander Best wrote: > > On Fri Dec 31 10, Roman Divacky wrote: > > > On Fri, Dec 31, 2010 at 01:20:02AM +0000, Alexander Best wrote: > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > On Thu, Dec 30, 2010 at 06:46:16PM +0000, Alexander Best wrote: > > > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > > > On Thu, Dec 30, 2010 at 06:40:48PM +0000, Alexander Best wrote: > > > > > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > > > > > On Thu, Dec 30, 2010 at 12:20:33AM +0000, Alexander Best wrote: > > > > > > > > > > On Tue Dec 28 10, Roman Divacky wrote: > > > > > > > > > > > -march=native in clang works by detecting CPU name > > > > > > > > > > > and passing it (if found) to llvm. if the CPU is not > > > > > > > > > > > detected nothing is passed. > > > > > > > > > > > > > > > > > > > > > > nocona is supported > > > > > > > > > > > > > > > > > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > > > > > > > > > > > be equivalent to setting it to "native". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > can you apply this patch: > > > > > > > > > > > > > > > > > > > > > > Index: Driver/Tools.cpp > > > > > > > > > > > =================================================================== > > > > > > > > > > > --- Driver/Tools.cpp (revision 122591) > > > > > > > > > > > +++ Driver/Tools.cpp (working copy) > > > > > > > > > > > @@ -684,6 +684,7 @@ > > > > > > > > > > > // FIXME: We should also incorporate the detected target features for use > > > > > > > > > > > // with -native. > > > > > > > > > > > std::string CPU = llvm::sys::getHostCPUName(); > > > > > > > > > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > > > > > > > > > if (!CPU.empty()) > > > > > > > > > > > CPUName = Args.MakeArgString(CPU); > > > > > > > > > > > } else > > > > > > > > > > > > > > > > > > > > thanks a lot for the patch. i've applied it, but am not sure how to only > > > > > > > > > > compile clang. 'make' in usr.bin/clang fails. do i have to run target > > > > > > > > > > buildworld or is there a way to only build clang? > > > > > > > > > > > > > > > > > > I would guess that cd lib/clang && make && cd ../../usr.bin/clang && make > > > > > > > > > should work, if not - full buildworld is necessary I guess > > > > > > > > > > > > > > > > thanks. that worked. this is what clang detects as my cpu: > > > > > > > > > > > > > > > > -march=native > > > > > > > > > > > > > > hm? are you sure it wrote -march=native? it should have written > > > > > > > > > > > > oh sorry. i copy&pasted the wrong line. :( > > > > > > > > > > > > detected CPU = core2 > > > > > > > > > > yes, you have core2, maybe thats why using CPU=nocona is causing you problems? > > > > > > > > CPU=nocona *isn't* causing problems. CPU=native is causing the problems. > > > > > > > > core2 is wrong imo. have a look at share/mk/bsd.cpu.mk for amd64. it sets core2 > > > > to nocona. so clang should detect nocona for CPU=native and *not* core2. > > > > > > no, your cpu is core2 so clang is correct to detect is as such. it's imho irrelevant > > > that we (freebsd mk framework) reset core2 to nocona. > > > > i'm sorry. you're of course right. looking at the manual page of a newer gcc > > release reveals that core2 is in fact the correct cpu. > > > > what i did now was to clean out my src.conf and make.conf and run buildworld > > with gcc and with clang. > > > > you can see the results in the attached file in addition to the contents of my > > src.conf and make.conf > > > > right now i'm trying to repeat the tests with cpu set to core2 and nocona. > > > > cheers. > > alex > > > > > > > > the reason for that is imho that gcc 4.2.1 does not support core2 so we "downgrade" > > > that to nocona. > > > > > > > > > > however i'll try to run buildworld again with the patched clang to completely > > > > pinpoint the problem. > > > > > > yes please, it's going to be interesting to see what is the exact problem > > i've just tried building world with CUPTYPE ?= nocona and got the same result: > gcc succeeds; clang fails. > > the error message however is not the one i was refering to earlier. the reason > i get a different error message seems to be the fact that i got rid of most of > the WITHOUT_* optins in src.conf. so there are at least two issues with clang, > where it fails in cases gcc succeeds. > > i'm doing another final buildworld with CPUTYPE ?= core2, but i suspect the > result will be the same. i think i found the problem. please take a look at the thread on freebsd-current named "userland weirdness between r216351 and r216738". Alexander Kabaev mentions a problem with rtld and this is exactly where the assert i reported gets hit. hopefully this issue will be solved soon. then i can continue looking into the other issue i experienced, where gcc compiled by clang would segfault with signal 11 during buildworld. maybe this also gets caused by the rtld issue. cheers. alex > > cheers. > alex > > > > > -- > > a13x > > > grep -v "^#" /etc/make.conf /etc/src.conf: > > > > /etc/make.conf:KERNCONF = ARUNDEL > > /etc/make.conf:MODULES_OVERRIDE = \ > > /etc/make.conf:netgraph/netgraph \ > > /etc/make.conf:netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci \ > > /etc/make.conf:netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt \ > > /etc/make.conf:linux tmpfs sound/sound sound/driver/hda usb/uhid \ > > /etc/make.conf:procfs pseudofs linprocfs linsysfs lindev usb/quirk geom > > /etc/make.conf: > > /etc/make.conf: > > /etc/make.conf:CPUTYPE ?= native > > /etc/make.conf: > > /etc/make.conf:SENDMAIL_MC = /etc/mail/freebsd.mc > > /etc/make.conf:SENDMAIL_SUBMIT_MC = /etc/mail/freebsd.submit.mc > > /etc/make.conf: > > /etc/make.conf:OVERRIDE_LINUX_BASE_PORT = f10 > > /etc/make.conf:OVERRIDE_LINUX_NONBASE_PORTS = f10 > > /etc/make.conf:DA4 = yes > > /etc/make.conf:WITH_BSDEL = yes > > /etc/make.conf:WITH_256_COLOR = yes > > /etc/make.conf: > > /etc/make.conf:PERL_VERSION=5.12.2 > > /etc/src.conf: > > /etc/src.conf:DEBUG_FLAGS = -g > > /etc/src.conf: > > /etc/src.conf:WITHOUT_PROFILE=true > > /etc/src.conf:WITHOUT_CDDL=true > > /etc/src.conf:WITHOUT_ATM=true > > > > make buildworld: > > > > ==> SUCCEEDS! > > > > grep -v "^#" /etc/make.conf /etc/src.conf: > > > > /etc/make.conf:KERNCONF = ARUNDEL > > /etc/make.conf:MODULES_OVERRIDE = \ > > /etc/make.conf:netgraph/netgraph \ > > /etc/make.conf:netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci \ > > /etc/make.conf:netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt \ > > /etc/make.conf:linux tmpfs sound/sound sound/driver/hda usb/uhid \ > > /etc/make.conf:procfs pseudofs linprocfs linsysfs lindev usb/quirk geom > > /etc/make.conf: > > /etc/make.conf: > > /etc/make.conf:CPUTYPE ?= native > > /etc/make.conf: > > /etc/make.conf:SENDMAIL_MC = /etc/mail/freebsd.mc > > /etc/make.conf:SENDMAIL_SUBMIT_MC = /etc/mail/freebsd.submit.mc > > /etc/make.conf: > > /etc/make.conf:OVERRIDE_LINUX_BASE_PORT = f10 > > /etc/make.conf:OVERRIDE_LINUX_NONBASE_PORTS = f10 > > /etc/make.conf:DA4 = yes > > /etc/make.conf:WITH_BSDEL = yes > > /etc/make.conf:WITH_256_COLOR = yes > > /etc/make.conf: > > /etc/make.conf:PERL_VERSION=5.12.2 > > /etc/src.conf:.if !defined(CC) || ${CC} == "cc" > > /etc/src.conf:CC=clang > > /etc/src.conf:.endif > > /etc/src.conf:.if !defined(CXX) || ${CXX} == "c++" > > /etc/src.conf:CXX=clang++ > > /etc/src.conf:.endif > > /etc/src.conf:NO_WERROR= > > /etc/src.conf:WERROR= > > /etc/src.conf: > > /etc/src.conf:DEBUG_FLAGS = -g > > /etc/src.conf: > > /etc/src.conf:WITHOUT_PROFILE=true > > /etc/src.conf:WITHOUT_CDDL=true > > /etc/src.conf:WITHOUT_ATM=true > > > > make buildworld: > > > > ==> FAILS! > > > > 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. 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 > > > > Stop in /usr/subversion-src/lib/libcompiler_rt. > > *** Error code 1 > > > > Stop in /usr/subversion-src. > > *** Error code 1 > > > > Stop in /usr/subversion-src. > > *** Error code 1 > > > > Stop in /usr/subversion-src. > > *** Error code 1 > > > > Stop in /usr/subversion-src. > > > -- > a13x -- a13x