From owner-freebsd-toolchain@FreeBSD.ORG Sun Jan 30 22:17:59 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7C48C1065670; Sun, 30 Jan 2011 22:17:59 +0000 (UTC) Date: Sun, 30 Jan 2011 22:17:59 +0000 From: Alexander Best To: freebsd-toolchain@freebsd.org Message-ID: <20110130221759.GA38095@freebsd.org> References: <20110123130705.GA21973@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110123130705.GA21973@freebsd.org> Subject: Re: ${CC} in share/mk/bsd.cpu.mk 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, 30 Jan 2011 22:17:59 -0000 On Sun Jan 23 11, Alexander Best wrote: > hi there, i might have described things a bit too complicated. basically i want to have CPUTYPE ?= core2 in my make.conf. clang is capable of producing core2 specific code, however core2 always gets downgraded by share/mk/bsd.cpu.mk to nocona in order not to confuse gcc. any chance of fixing this? cheers. alex > > i was fiddling with share/mk/bsd.cpu.mk in order to add some clang specific > conditions. however it seems ${CC} is always set to "cc" no matter what's in > src.conf. this is odd, since there's already some code in bsd.cpu.mk which > checks ${CC} == icc. right now this code is a noop, since ${CC} can't be > anything else than "cc". is it possible to somehow fix this? > > e.g. there's no reason to set CPUTYPE to nocona, when > ${CC} == clang && ${CPUTYPE} == core2. > > cheers. > alex > > -- > a13x -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Sun Jan 30 23:38:10 2011 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 EFA041065672 for ; Sun, 30 Jan 2011 23:38:10 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id 8BC538FC0A for ; Sun, 30 Jan 2011 23:38:10 +0000 (UTC) Received: (qmail 19795 invoked from network); 30 Jan 2011 23:11:27 -0000 Received: from 188.118.200.192 (HELO ?192.168.0.129?) (188.118.200.192) by relay00.pair.com with SMTP; 30 Jan 2011 23:11:27 -0000 X-pair-Authenticated: 188.118.200.192 Date: Mon, 31 Jan 2011 00:11:33 +0100 (CET) From: Gerald Pfeifer To: Alexander Best In-Reply-To: <20110130221759.GA38095@freebsd.org> Message-ID: References: <20110123130705.GA21973@freebsd.org> <20110130221759.GA38095@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-toolchain@freebsd.org Subject: Re: [toolchain] ${CC} in share/mk/bsd.cpu.mk 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, 30 Jan 2011 23:38:11 -0000 On Sun, 30 Jan 2011, Alexander Best wrote: > i might have described things a bit too complicated. basically i want to > have CPUTYPE ?= core2 in my make.conf. clang is capable of producing > core2 specific code, however core2 always gets downgraded by > share/mk/bsd.cpu.mk to nocona in order not to confuse gcc. > > any chance of fixing this? I guess one of those extern compilers Robert has in mind should be lang/gcc46 from the Ports Collection which is perfectly happy to generate core2 code. I agree we need good infrastructure to support such cases. Gerald From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 31 09:50:58 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 1EDE51065672; Mon, 31 Jan 2011 09:50:58 +0000 (UTC) Date: Mon, 31 Jan 2011 09:50:58 +0000 From: Alexander Best To: Gerald Pfeifer Message-ID: <20110131095058.GB98011@freebsd.org> References: <20110123130705.GA21973@freebsd.org> <20110130221759.GA38095@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-toolchain@freebsd.org Subject: Re: [toolchain] ${CC} in share/mk/bsd.cpu.mk 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, 31 Jan 2011 09:50:58 -0000 On Mon Jan 31 11, Gerald Pfeifer wrote: > On Sun, 30 Jan 2011, Alexander Best wrote: > > i might have described things a bit too complicated. basically i want to > > have CPUTYPE ?= core2 in my make.conf. clang is capable of producing > > core2 specific code, however core2 always gets downgraded by > > share/mk/bsd.cpu.mk to nocona in order not to confuse gcc. > > > > any chance of fixing this? > > I guess one of those extern compilers Robert has in mind should > be lang/gcc46 from the Ports Collection which is perfectly happy > to generate core2 code. I agree we need good infrastructure to > support such cases. i just thought we could make the instructions in share/mk/bsd.cpu.mk which downgrades the CPUTYPE to nocona gcc specific. but for some reason that doesn't seem to work. :( Index: bsd.cpu.mk =================================================================== --- bsd.cpu.mk (revision 218104) +++ bsd.cpu.mk (working copy) @@ -55,7 +55,7 @@ . elif ${CPUTYPE} == "k7" CPUTYPE = athlon . endif -. elif ${MACHINE_CPUARCH} == "amd64" +. elif ${MACHINE_CPUARCH} == "amd64" && ${CC} != "clang" . if ${CPUTYPE} == "prescott" || ${CPUTYPE} == "core2" CPUTYPE = nocona . endif ...and still with clang as compiler CPUYTEP gets reset to nocona. cheers. alex > > Gerald -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 31 16:27:55 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id BE8D4106566B; Mon, 31 Jan 2011 16:27:55 +0000 (UTC) Date: Mon, 31 Jan 2011 16:27:55 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20110131162755.GA54255@freebsd.org> References: <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> <20110101153430.GA98411@freebsd.org> <20110101195823.GA41161@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110101195823.GA41161@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: Mon, 31 Jan 2011 16:27:55 -0000 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. 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+. cheers. alex > > same assert gets hit with svn clang/llvm: > > /usr/local/bin/clang -v -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/gitorious-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c > clang version 2.9 (trunk 122653) > Target: x86_64-unknown-freebsd9.0 > Thread model: posix > "/usr/local/bin/clang" -cc1 -triple x86_64-unknown-freebsd9.0 -emit-obj -disable-free -main-file-name mulvti3.c -pic-level 1 -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu core2 -target-linker-version 2.21 -v -g -resource-dir /usr/local/bin/../lib/clang/2.9 -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 mulvti3.o -x c /usr/gitorious-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c > clang -cc1 version 2.9 based upon llvm 2.9svn hosted on x86_64-unknown-freebsd9.0 > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > /usr/local/bin/../lib/clang/2.9/include > /usr/include > End of search list. > Assertion failed: (getMinSignedBits() <= 64 && "Too many bits for int64_t"), function getSExtValue, file /usr/local/src/llvm/include/llvm/ADT/APInt.h, line 1158. > Stack dump: > 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-freebsd9.0 -emit-obj -disable-free -main-file-name mulvti3.c -pic-level 1 -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu core2 -target-linker-version 2.21 -v -g -resource-dir /usr/local/bin/../lib/clang/2.9 -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 mulvti3.o -x c /usr/gitorious-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c > 1. parser at end of file > 2. Code generation > 3. Running pass 'Function Pass Manager' on module '/usr/gitorious-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c'. > clang: error: unable to execute command: Abort trap: 6 (core dumped) > clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) > *** Error code 255 > > Stop in /usr/gitorious-src/lib/libcompiler_rt. > > cheers. > alex > > > > > thank you! > > -- > a13x -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 31 20:24:29 2011 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 48623106564A; Mon, 31 Jan 2011 20:24:29 +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 024468FC0A; Mon, 31 Jan 2011 20:24:28 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id C22C59CB0C3; Mon, 31 Jan 2011 21:24:26 +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 C6BpbJlGUj0y; Mon, 31 Jan 2011 21:24:26 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 223C29CB882; Mon, 31 Jan 2011 21:24:26 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id p0VKOQuR064720; Mon, 31 Jan 2011 21:24:26 +0100 (CET) (envelope-from rdivacky) Date: Mon, 31 Jan 2011 21:24:26 +0100 From: Roman Divacky To: Alexander Best Message-ID: <20110131202426.GA64245@freebsd.org> References: <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> <20110101153430.GA98411@freebsd.org> <20110101195823.GA41161@freebsd.org> <20110131162755.GA54255@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110131162755.GA54255@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: Mon, 31 Jan 2011 20:24:29 -0000 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. 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) what are you trying to do anyway? :) From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 31 20:35:43 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 4D2CB1065670; Mon, 31 Jan 2011 20:35:43 +0000 (UTC) Date: Mon, 31 Jan 2011 20:35:43 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20110131203543.GA86795@freebsd.org> References: <20101230184616.GA35433@freebsd.org> <20101230201848.GA92145@freebsd.org> <20101231012002.GA73736@freebsd.org> <20101231151554.GA29782@freebsd.org> <20101231180054.GA77781@freebsd.org> <20101231190838.GA85678@freebsd.org> <20110101153430.GA98411@freebsd.org> <20110101195823.GA41161@freebsd.org> <20110131162755.GA54255@freebsd.org> <20110131202426.GA64245@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110131202426.GA64245@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: Mon, 31 Jan 2011 20:35:43 -0000 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. 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) > > > what are you trying to do anyway? :) compile world without /usr/bin/clang dumping core due to an assert being hit in lib/libcompiler_rt. ;) right now i can only use clang to compile the kernel, but not world. cheers. alex -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 31 21:00:41 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id BF0341065695; Mon, 31 Jan 2011 21:00:41 +0000 (UTC) Date: Mon, 31 Jan 2011 21:00:41 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20110131210041.GA89926@freebsd.org> References: <20101230184616.GA35433@freebsd.org> <20101230201848.GA92145@freebsd.org> <20101231012002.GA73736@freebsd.org> <20101231151554.GA29782@freebsd.org> <20101231180054.GA77781@freebsd.org> <20101231190838.GA85678@freebsd.org> <20110101153430.GA98411@freebsd.org> <20110101195823.GA41161@freebsd.org> <20110131162755.GA54255@freebsd.org> <20110131202426.GA64245@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110131202426.GA64245@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: Mon, 31 Jan 2011 21:00:41 -0000 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. 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 From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 31 21:02:53 2011 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 7802B106564A; Mon, 31 Jan 2011 21:02:53 +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 03D698FC15; Mon, 31 Jan 2011 21:02:52 +0000 (UTC) Received: from lev.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 16DDA9CB0C3; Mon, 31 Jan 2011 22:02:52 +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 FK2HeXZ37UCC; Mon, 31 Jan 2011 22:02:51 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 18CCC9CB883; Mon, 31 Jan 2011 22:02:51 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.4/8.14.4/Submit) id p0VL2p1e070290; Mon, 31 Jan 2011 22:02:51 +0100 (CET) (envelope-from rdivacky) Date: Mon, 31 Jan 2011 22:02:51 +0100 From: Roman Divacky To: Alexander Best Message-ID: <20110131210251.GA70081@freebsd.org> References: <20101230201848.GA92145@freebsd.org> <20101231012002.GA73736@freebsd.org> <20101231151554.GA29782@freebsd.org> <20101231180054.GA77781@freebsd.org> <20101231190838.GA85678@freebsd.org> <20110101153430.GA98411@freebsd.org> <20110101195823.GA41161@freebsd.org> <20110131162755.GA54255@freebsd.org> <20110131202426.GA64245@freebsd.org> <20110131210041.GA89926@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110131210041.GA89926@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: Mon, 31 Jan 2011 21:02:53 -0000 On Mon, Jan 31, 2011 at 09:00:41PM +0000, Alexander Best wrote: > 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. 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. new import of clang/llvm will happen really soon now, bringing quite a few improvements (mature integrated asm, some fbsd specific fixes etc.) roman From owner-freebsd-toolchain@FreeBSD.ORG Mon Jan 31 21:16:38 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 8A01D1065675; Mon, 31 Jan 2011 21:16:38 +0000 (UTC) Date: Mon, 31 Jan 2011 21:16:38 +0000 From: Alexander Best To: Roman Divacky Message-ID: <20110131211638.GA93805@freebsd.org> References: <20101231012002.GA73736@freebsd.org> <20101231151554.GA29782@freebsd.org> <20101231180054.GA77781@freebsd.org> <20101231190838.GA85678@freebsd.org> <20110101153430.GA98411@freebsd.org> <20110101195823.GA41161@freebsd.org> <20110131162755.GA54255@freebsd.org> <20110131202426.GA64245@freebsd.org> <20110131210041.GA89926@freebsd.org> <20110131210251.GA70081@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110131210251.GA70081@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: Mon, 31 Jan 2011 21:16:38 -0000 On Mon Jan 31 11, Roman Divacky wrote: > On Mon, Jan 31, 2011 at 09:00:41PM +0000, Alexander Best wrote: > > 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. 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. > > new import of clang/llvm will happen really soon now, bringing quite a few > improvements (mature integrated asm, some fbsd specific fixes etc.) very nice. looking forward to it. any chance we can get "CPUTYPE = core2" being propagated to clang, instead of reset to nocona in the near future? cheers. alex > > roman -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Tue Feb 1 11:54:04 2011 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 1E3391065670 for ; Tue, 1 Feb 2011 11:54:04 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id CFDDB8FC1E for ; Tue, 1 Feb 2011 11:54:03 +0000 (UTC) Received: by gyf3 with SMTP id 3so2575720gyf.13 for ; Tue, 01 Feb 2011 03:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:cc:content-type; bh=6+KFclmodUfcKGPB2M5fkXuEfzpgHyFFVzAb2rCKc1I=; b=tZnAf/VH/2odycwUHvm8ecuGA6dmbhDQBrKeHF7EmtPTXRzopSIXhhvbpB8vGMz463 LCAhMztmG80BahzSVQKKMb3rg9fZUrJySXKHH6AQFYI+4JP+TNfJHH+Wm4ZnWq46irwv uBHMI1uuLLoIqLLEIqN6v3ETWzjHIv55X1G/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=TL0uN8kc7nnFWibviHBUmUXVxchw4Bl4TIQP2Ssv1L0uZ6PiPY0dpauZDKtE0NgCGs KVwCzFZBmfAaAKBgbPPTDzGtQBSLDK8o+ugzbhO4CKxqHbZVwMzdt69xgoWFAFqduCb5 lXCfmGOwyu+h4WT7uUZngduFMfQm34DzXTe6I= MIME-Version: 1.0 Received: by 10.236.108.167 with SMTP id q27mr15378960yhg.36.1296559646940; Tue, 01 Feb 2011 03:27:26 -0800 (PST) Received: by 10.236.105.197 with HTTP; Tue, 1 Feb 2011 03:27:26 -0800 (PST) Date: Tue, 1 Feb 2011 06:27:26 -0500 Message-ID: From: "b. f." To: Gerald Pfeifer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-toolchain@FreeBSD.org Subject: Re: [toolchain] ${CC} in share/mk/bsd.cpu.mk X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 11:54:04 -0000 Gerald Pfeifer wrote: > On Sun, 30 Jan 2011, Alexander Best wrote: > > i might have described things a bit too complicated. basically i want to > > have CPUTYPE ?= core2 in my make.conf. clang is capable of producing > > core2 specific code, however core2 always gets downgraded by > > share/mk/bsd.cpu.mk to nocona in order not to confuse gcc. > > > > any chance of fixing this? > > I guess one of those extern compilers Robert has in mind should > be lang/gcc46 from the Ports Collection which is perfectly happy > to generate core2 code. I agree we need good infrastructure to > support such cases. Related: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=conf/84800 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=conf/112997 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=conf/30399 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=i386/122623 The longevity of some of these is remarkable. b. From owner-freebsd-toolchain@FreeBSD.ORG Tue Feb 1 17:10:18 2011 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 63EDA10656A8 for ; Tue, 1 Feb 2011 17:10:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 22D9F8FC22 for ; Tue, 1 Feb 2011 17:10:17 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p11H7F4N050453 for ; Tue, 1 Feb 2011 10:07:15 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4D483DC3.9000506@bsdimp.com> Date: Tue, 01 Feb 2011 10:07:15 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-toolchain@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [toolchain] ${CC} in share/mk/bsd.cpu.mk 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, 01 Feb 2011 17:10:18 -0000 On 02/01/2011 04:27, b. f. wrote: > Gerald Pfeifer wrote: >> On Sun, 30 Jan 2011, Alexander Best wrote: >>> i might have described things a bit too complicated. basically i want to >>> have CPUTYPE ?= core2 in my make.conf. clang is capable of producing >>> core2 specific code, however core2 always gets downgraded by >>> share/mk/bsd.cpu.mk to nocona in order not to confuse gcc. >>> >>> any chance of fixing this? >> I guess one of those extern compilers Robert has in mind should >> be lang/gcc46 from the Ports Collection which is perfectly happy >> to generate core2 code. I agree we need good infrastructure to >> support such cases. > > Related: > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=conf/84800 > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=conf/112997 > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=conf/30399 > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=i386/122623 > > The longevity of some of these is remarkable. Wow! I think the fortran one takes the cake for ancientness :) When applying it, keep in mind that we do things a little differently... Maybe I'll take a look at it/them :) Warner From owner-freebsd-toolchain@FreeBSD.ORG Tue Feb 1 19:25:56 2011 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 485A11065673; Tue, 1 Feb 2011 19:25:56 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id E63168FC17; Tue, 1 Feb 2011 19:25:55 +0000 (UTC) Received: by yxh35 with SMTP id 35so2790139yxh.13 for ; Tue, 01 Feb 2011 11:25:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:cc:content-type; bh=raZsO2bCE6fwjeQiBzGJCcb8VF/GxUFwrJghOeyHZvI=; b=c/wmLI8duFvotSM284gEMmqr3DFElv5LnLVKGMPDNp3I7BBkdRnwnhXH5xwUN+clGD N8T9guRIv1Ek+UxI1wtU+qR5Q0SUavmK0/r8gq8qRB+IXGl87YoCuCvq+z6L8xnITZt/ svWn3lEx1hYN5VFwEcJ40iteYyXumMJRGeuvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; b=JtczVZdoyTn9u7B1UkgGJpxC6sm4lK6AI6Dw4Ky5ccqioY138H+pdbX6l4tTiNPjSV YJUKwHJoV/1I7hzbn/gv6WbHvhqNlGUvO9jeX4tvfWGb2m8w2FAM70hrW/Bxkz24r4xW JT2i6q0ZSzL3IX9yuGtpwkNoDHiyn3MAhF7Lw= MIME-Version: 1.0 Received: by 10.236.111.43 with SMTP id v31mr16750903yhg.23.1296588348730; Tue, 01 Feb 2011 11:25:48 -0800 (PST) Received: by 10.236.105.197 with HTTP; Tue, 1 Feb 2011 11:25:48 -0800 (PST) Date: Tue, 1 Feb 2011 14:25:48 -0500 Message-ID: From: "b. f." To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-toolchain@FreeBSD.org, gerald@FreeBSD.org Subject: Re: [toolchain] ${CC} in share/mk/bsd.cpu.mk X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:25:56 -0000 Warner Losh wrote: > On 02/01/2011 04:27, b. f. wrote: > > Gerald Pfeifer wrote: > >> On Sun, 30 Jan 2011, Alexander Best wrote: > >>> i might have described things a bit too complicated. basically i want to > >>> have CPUTYPE ?= core2 in my make.conf. clang is capable of producing > >>> core2 specific code, however core2 always gets downgraded by > >>> share/mk/bsd.cpu.mk to nocona in order not to confuse gcc. > >>> > >>> any chance of fixing this? > >> I guess one of those extern compilers Robert has in mind should > >> be lang/gcc46 from the Ports Collection which is perfectly happy > >> to generate core2 code. I agree we need good infrastructure to > >> support such cases. > > > > Related: > > > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=conf/84800 > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=conf/112997 > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=conf/30399 > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=i386/122623 > > > > The longevity of some of these is remarkable. > > Wow! I think the fortran one takes the cake for ancientness :) When > applying it, keep in mind that we do things a little differently... > Maybe I'll take a look at it/them :) I didn't mean to suggest that the proposals of the original submitters be adopted in each case above, just that the PRs ought to be resolved, as they have practical consequences for users. I had mentioned the Fortran PR earlier to the GCC ports maintainer, and he saw no reason why the default Fortran bits (default targets, compiler and flag definitions) couldn't be shifted from src/share/mk/sys.mk and src/share/mk/bsd.lib.mk to ports/Mk/bsd.gcc.mk and placed under the USE_FORTRAN knob, as they are no longer used in the base system, and applicable standards like: http://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html state that " Implementations that do not support FORTRAN may omit FC, FFLAGS, and the .f inference rules." This would allow the ports committers to more easily maintain those bits, and the few users who rely on those bits for software that is not in either Ports or the base system could probably easily adapt to such a change. But even if such a change isn't adopted, the default FFLAGS probably ought to be set to be the same as the default CFLAGS, including the option to specify -mtune=... That would simplify matters, and I think at the moment that they are too conservative. While we are on the topic, in reference to my earlier comment in conf/112997, is anyone working on adding basic OS support for some of the newer CPU instruction sets to FreeBSD? Even if we can't use them with the older base system compiler, I think that a growing number of users would like to use them with clang or the other newer compilers in Ports. b. From owner-freebsd-toolchain@FreeBSD.ORG Tue Feb 1 19:37:08 2011 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 E25C11065697; Tue, 1 Feb 2011 19:37:08 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 897068FC1E; Tue, 1 Feb 2011 19:37:08 +0000 (UTC) Received: by gwj21 with SMTP id 21so2824138gwj.13 for ; Tue, 01 Feb 2011 11:37:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=oKzdVPbclESjFYYwi/q9i8coC+Q6af0BGIfVBbK/njA=; b=A19hMnG5l9kQdGg9Vadp1oQ+V3iLe9EYV6XRENICSvdQiT01zhPbsA7WO6w/iE2y8C kwMibanUp8/GYmkiYHrDiild9KJr8x6JbTzUL9UZawsbp82kaTb2wgKOS6tO1H38iyn2 t8CKw99bcm2iUjvKUpDRraK+SAg4e674Mkrsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=R2ooGQS2lzz7apsM4NRj8KjPDexnQWIVXDv9Snqy1BpuS2Hx7pTbVzxoYQRSrRqNK8 WkPj3qAcwE0hW/hnbYxmScCtLTtVP42oSY8rsdSu1+gcx8gGbhtpoUQtHHq3g/pJCLdK LwiZ+E0SOQIm2WP3asqA/p9KX58sf7NUIEPM8= MIME-Version: 1.0 Received: by 10.236.95.17 with SMTP id o17mr16790363yhf.10.1296589027757; Tue, 01 Feb 2011 11:37:07 -0800 (PST) Received: by 10.236.105.197 with HTTP; Tue, 1 Feb 2011 11:37:07 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Feb 2011 14:37:07 -0500 Message-ID: From: "b. f." To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-toolchain@freebsd.org, gerald@freebsd.org Subject: Re: [toolchain] ${CC} in share/mk/bsd.cpu.mk X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bf1783@gmail.com List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:37:09 -0000 On 2/1/11, b. f. wrote: > Warner Losh wrote: >> On 02/01/2011 04:27, b. f. wrote: >> > Gerald Pfeifer wrote: >> >> On Sun, 30 Jan 2011, Alexander Best wrote: ... > But even if such a change isn't adopted, the default FFLAGS probably > ought to be set to be the same as the default CFLAGS, including the > option to specify -mtune=... That would simplify matters, and I think > at the moment that they are too conservative. ... Here I meant the equivalent of CPUCLFLAGS, which is actually -march=..., of course.