From owner-freebsd-toolchain@freebsd.org Sun Aug 14 16:24:48 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4006BBB9B8E; Sun, 14 Aug 2016 16:24:48 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (unknown [IPv6:2620:64:0:1:223:7dff:fea2:c8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 2CE691988; Sun, 14 Aug 2016 16:24:45 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id E8C212AA3A5; Sun, 14 Aug 2016 10:23:53 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 309171CDE4; Sun, 14 Aug 2016 12:24:36 -0400 (EDT) Date: Sun, 14 Aug 2016 12:24:36 -0400 From: Diane Bruce To: freebsd-toolchain@FreeBSD.org, freebsd-ports@freebsd.org Subject: Problems with our libgcc_s.so in base Message-ID: <20160814162436.GA32493@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 14 Aug 2016 16:24:48 -0000 Problems with libgcc_s.so in base If you compile with gcc and use our base libgcc it should DTRT *provided* our libgcc has defined functions that are up to date with current libgcc We compile with gcc, it needs foo() from libgcc to run doesn't matter what foo() is (A typical function would be T __multi3) So our libgcc provides a foo() and gcc is happy This means in theory, we can interchangeably use gcc and clang in ports. This also means it made the initial port work from from gcc in base to clang in base a lot easier. The problems come when we try to use architectures not fully supported by our libgcc_s.so or when we use fortran. However, our libgcc lies in two ways 1) our libgcc is mostly not GPL code anymore, though there are bits and pieces of GPL depending on what we don't have. This includes (or did) some of the work ian@ was trying to do with arm, various bits that arm libgcc provides from gcc were missing. 2) It claims to be only up to date with GCC 4.2.4 Everything is peachy keen until someone references a symbol which is in anything gcc compiled using a newer > GCC 4.2.4 compiler. The moment you load libgfortran, it has a requirement for GCC_4.6 or better, and if our libgcc is already loaded things fail. The reason ports gcc now has this requirment on 4.6 or better is fortran standard says we have to support quad floating point math. e.g. /usr/local/lib/gccXX/libquadmath.so We *could* lie in our libgcc_s and claim to be 4.6 which would simply mean libgfortran would not complain and simply load the missing libquadmath. If we updated the claimed GCC version in our libgcc_s.so to claim GCC_4.6, we really also should provide a libquadmath subsitute. The other approach is to rename our libgcc_s.so to libclang_s.so or some such and link base with it instead of libgcc_s.so I frankly think this in the long term is the cleaner solution. In the ports world, we have papered over this problem by adding -Wl,-rpath=${_GCC_RUNTIME} or similar to force programs to link against /usr/local/lib/gcc${GCCVERSION}/libgcc_s.so However, any program that uses python to build has to be patched to force this stanza and our ports cmake presently does not force this stanza to be added. Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-toolchain@freebsd.org Sun Aug 14 23:34:34 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00598BB96E4; Sun, 14 Aug 2016 23:34:34 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id E43441BDE; Sun, 14 Aug 2016 23:34:33 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 9FBBA2AA4C8; Sun, 14 Aug 2016 17:33:48 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id F2A591CDE4; Sun, 14 Aug 2016 19:34:30 -0400 (EDT) Date: Sun, 14 Aug 2016 19:34:30 -0400 From: Diane Bruce To: Steve Kargl Cc: freebsd-ports@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160814233430.GA35872@night.db.net> References: <20160814230351.GA10587@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160814230351.GA10587@troutmask.apl.washington.edu> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 14 Aug 2016 23:34:34 -0000 On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote: > > > The reason ports gcc now has this requirment on 4.6 or better is > > fortran standard says we have to support quad floating point math. > > e.g. /usr/local/lib/gccXX/libquadmath.so > > Diane, > > Can you please stop with the dis-information? No Fortran standard I'm happy to be corrected. In this case it's immaterial if it is a Fortran standard or not. It is what our present gcc from ports has given us. ... > > FreeBSD-ports could avoid libquadmath issues by building gcc > without it. See --without-libquadmath or --without-quadmath (I > don't remember the config option because it would be questionable > to neuter one of gfortran's strength). Correct. This blog entry I read some months ago outlines this exact problem we are having and suggests the identical solution. http://glennklockwood.blogspot.ca/2014/02/linux-perf-libquadmath-and-gfortrans.html quadmath does have an impact on performance. > > Freebsd-ports could also use a wrapper: > % cat ~/bin/gfc7 > #! /bin/sh > DIR=`id -P sgk | sed 's/\:/\ /g' | awk '{print $9}'` > export DIR > > LD_LIBRARY_PATH=$DIR/work/7/lib > export LD_LIBRARY_PATH > > LD_RUN_PATH=$DIR/work/7/lib > export LD_RUN_PATH > > $DIR/work/7/bin/gfortran -fno-backtrace $@ Yes. I have also suggested we use a wrapper to the ports guys. - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-toolchain@freebsd.org Mon Aug 15 00:20:35 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5A20BBA489; Mon, 15 Aug 2016 00:20:35 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A39F51148; Mon, 15 Aug 2016 00:20:35 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u7F0KWLR010918 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Aug 2016 17:20:32 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u7F0KWji010917; Sun, 14 Aug 2016 17:20:32 -0700 (PDT) (envelope-from sgk) Date: Sun, 14 Aug 2016 17:20:32 -0700 From: Steve Kargl To: Diane Bruce Cc: freebsd-ports@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160815002032.GA10882@troutmask.apl.washington.edu> References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160814233430.GA35872@night.db.net> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 15 Aug 2016 00:20:35 -0000 On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote: > On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote: > > > > FreeBSD-ports could avoid libquadmath issues by building gcc > > without it. See --without-libquadmath or --without-quadmath (I > > don't remember the config option because it would be questionable > > to neuter one of gfortran's strength). > > Correct. This blog entry I read some months ago outlines this > exact problem we are having and suggests the identical solution. > > http://glennklockwood.blogspot.ca/2014/02/linux-perf-libquadmath-and-gfortrans.html > > quadmath does have an impact on performance. > I read that blog a long time ago. It is quite humorous, because the author does not understand the storage requirements of Fortran. If one uses only the -fdefault-real-8 option to promote REAL to DOUBLE PRECISION, then storage requirements mandate that DP should be promoted to QP (if available). That's why there is the -fdefault-double-8. In additions, these options were never meant to be used in a situation where performance matters. These options are a crutch for lazy programmers, who don't want to properly port code to a wider precision. As the person who actually implemented these options in gfortran for backwards compatibility with g77, I can assure that very few people know what these options do. The problem lies in Fortran's COMMON and EQUIVALENCE statements, where storage alignment can be messed up by the -fdefault-* options. Other than properly porting code to a wider type, people should use the -freal-* (eg, -freal-4-real-8). I submitted a patch to fortran@gcc to deprecate the -fdefault-* option in January. The deprecation who have occurred over 2 major releases. But, too many people objected under POLA. > > Freebsd-ports could also use a wrapper: > > % cat ~/bin/gfc7 > > #! /bin/sh > > Yes. I have also suggested we use a wrapper to the ports guys. > There always the option to link apps that need libgfortran with the -static option. -- Steve From owner-freebsd-toolchain@freebsd.org Mon Aug 15 10:01:25 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C4E8BBACCA for ; Mon, 15 Aug 2016 10:01:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8BF131775 for ; Mon, 15 Aug 2016 10:01:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7FA1PO0098278 for ; Mon, 15 Aug 2016 10:01:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] [Regression] Compiler is using AVX instructions for CPUTYPE=btver1 Date: Mon, 15 Aug 2016 10:01:25 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bapt@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 15 Aug 2016 10:01:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 Baptiste Daroussin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dim@FreeBSD.org, | |freebsd-toolchain@FreeBSD.o | |rg --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Aug 15 13:32:11 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2340FBBA9F5 for ; Mon, 15 Aug 2016 13:32:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 126E41849 for ; Mon, 15 Aug 2016 13:32:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7FDW9Jp048322 for ; Mon, 15 Aug 2016 13:32:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] Compiler is using AVX instructions for CPUTYPE=btver1 Date: Mon, 15 Aug 2016 13:32:09 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: needs-qa, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: keywords cc short_desc bug_status flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 15 Aug 2016 13:32:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |needs-qa CC|freebsd-amd64@FreeBSD.org |re@FreeBSD.org Summary|[Regression] Compiler is |Compiler is using AVX |using AVX instructions for |instructions for |CPUTYPE=3Dbtver1 |CPUTYPE=3Dbtver1 Status|New |Open Flags| |mfc-stable11? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Aug 15 15:33:43 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A53E0BBA229 for ; Mon, 15 Aug 2016 15:33:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 948C016D8 for ; Mon, 15 Aug 2016 15:33:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7FFXgWj067772 for ; Mon, 15 Aug 2016 15:33:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] LLVM is using AVX instructions for CPUTYPE=btver1 Date: Mon, 15 Aug 2016 15:33:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: needs-qa, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: gerald@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 15 Aug 2016 15:33:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 Gerald Pfeifer changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Compiler is using AVX |LLVM is using AVX |instructions for |instructions for |CPUTYPE=3Dbtver1 |CPUTYPE=3Dbtver1 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Aug 15 17:21:57 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EAD5DBBA53F for ; Mon, 15 Aug 2016 17:21:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D9AAA1DCE for ; Mon, 15 Aug 2016 17:21:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7FHLv7J065343 for ; Mon, 15 Aug 2016 17:21:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] LLVM is using AVX instructions for CPUTYPE=btver1 Date: Mon, 15 Aug 2016 17:21:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: needs-qa, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: bug_status assigned_to attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 15 Aug 2016 17:21:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |In Progress Assignee|freebsd-bugs@FreeBSD.org |dim@FreeBSD.org --- Comment #1 from Dimitry Andric --- Created attachment 173705 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D173705&action= =3Dedit Import upstream fix to stop using xsave/avx on btver1 CPUs Michel, can you please try out this patch? As far as I can see, this causes clang to not generate AVX instructions anymore, at least for that sudo port. But I would appreciate independent verification. :) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Mon Aug 15 20:48:11 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69F12BBAA18 for ; Mon, 15 Aug 2016 20:48:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 596D916DD for ; Mon, 15 Aug 2016 20:48:11 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7FKmBuF092240 for ; Mon, 15 Aug 2016 20:48:11 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] LLVM is using AVX instructions for CPUTYPE=btver1 Date: Mon, 15 Aug 2016 20:48:11 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: needs-qa, patch, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 15 Aug 2016 20:48:11 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Tue Aug 16 11:07:05 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A156BBBB5DF for ; Tue, 16 Aug 2016 11:07:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8FE421D42 for ; Tue, 16 Aug 2016 11:07:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7GB75Z3083396 for ; Tue, 16 Aug 2016 11:07:05 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] LLVM is using AVX instructions for CPUTYPE=btver1 (AMD Bobcat) Date: Tue, 16 Aug 2016 11:07:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: needs-qa, patch, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: koobs@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: priority short_desc flagtypes.name Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 16 Aug 2016 11:07:05 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 Kubilay Kocak changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|--- |Normal Summary|LLVM is using AVX |LLVM is using AVX |instructions for |instructions for |CPUTYPE=3Dbtver1 |CPUTYPE=3Dbtver1 (AMD Bo= bcat) Flags| |mfc-stable9?, mfc-stable10? --- Comment #2 from Kubilay Kocak --- Setting high MFC expectations, but at least stable/11 (unknown impact on previous branches) @Dim please set mfc-stableX to + *after* MFC, or set to - with comment why = its not necessary/possible --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Aug 17 19:50:44 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22BD1BBDF9E for ; Wed, 17 Aug 2016 19:50:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11B771DD0 for ; Wed, 17 Aug 2016 19:50:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7HJohUK028791 for ; Wed, 17 Aug 2016 19:50:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] LLVM is using AVX instructions for CPUTYPE=btver1 (AMD Bobcat) Date: Wed, 17 Aug 2016 19:50:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: needs-qa, patch, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: demik+freebsd@lostwave.net X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 19:50:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 --- Comment #3 from Michel Depeige --- Quick follow : I'm trying to rebuild the world with the patch applied, but = the box is overheating. I'm trying to sort that out before winter :) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Aug 17 21:17:14 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 890A5BBDEE7; Wed, 17 Aug 2016 21:17:14 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6C4CD1E4F; Wed, 17 Aug 2016 21:17:14 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u7HLHAMs059252 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Aug 2016 14:17:10 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u7HLHAq3059251; Wed, 17 Aug 2016 14:17:10 -0700 (PDT) (envelope-from sgk) Date: Wed, 17 Aug 2016 14:17:10 -0700 From: Steve Kargl To: Diane Bruce Cc: freebsd-ports@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160817211710.GA59205@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160814233430.GA35872@night.db.net> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 21:17:14 -0000 On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote: > On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote: > > > > Freebsd-ports could also use a wrapper: > > % cat ~/bin/gfc7 > > #! /bin/sh > > DIR=`id -P sgk | sed 's/\:/\ /g' | awk '{print $9}'` > > export DIR > > > > LD_LIBRARY_PATH=$DIR/work/7/lib > > export LD_LIBRARY_PATH > > > > LD_RUN_PATH=$DIR/work/7/lib > > export LD_RUN_PATH > > > > $DIR/work/7/bin/gfortran -fno-backtrace $@ > > Yes. I have also suggested we use a wrapper to the ports guys. > I thought about this a bit, and cleaner solution might be to add the program suffix to libgcc_s.so.1. For example, % cat foo.f90 program foo print *, 'Hello' end program % gfortran6 -o z foo.f90 && ./z /lib/libgcc_s.so.1: version GCC_4.6.0 required by \ /usr/local/lib/gcc6/libgfortran.so.3 not found % ldconfig -r | grep libgcc 6:-lgcc_s.1 => /lib/libgcc_s.so.1 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1 Clearly, ldd is looking for 735 but finds 6. If the lang/gcc6 could be convinced to build, install, and use libgcc_s6.so.1, then the problem is solved without a wrapper. -- Steve From owner-freebsd-toolchain@freebsd.org Wed Aug 17 21:58:01 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CBCDBBD10D for ; Wed, 17 Aug 2016 21:58:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EFC9B129B for ; Wed, 17 Aug 2016 21:58:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7HLw0oQ059923 for ; Wed, 17 Aug 2016 21:58:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] LLVM is using AVX instructions for CPUTYPE=btver1 (AMD Bobcat) Date: Wed, 17 Aug 2016 21:58:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: needs-qa, patch, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 21:58:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 --- Comment #4 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Wed Aug 17 21:57:11 UTC 2016 New revision: 304319 URL: https://svnweb.freebsd.org/changeset/base/304319 Log: Pull in r262772 from upstream clang trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17682 Pull in r262782 from upstream llvm trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17683 This ensures clang does not emit AVX instructions for CPUTYPE=3Dbtver1. Reported by: Michel Depeige PR: 211864 MFC after: 3 days Changes: head/contrib/llvm/lib/Target/X86/X86.td head/contrib/llvm/tools/clang/lib/Basic/Targets.cpp head/lib/clang/freebsd_cc_version.h --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Aug 17 22:13:01 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DB52BBD544; Wed, 17 Aug 2016 22:13:01 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8D61F1A98; Wed, 17 Aug 2016 22:13:01 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 220142AA3AD; Wed, 17 Aug 2016 16:12:10 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id C60611CDE4; Wed, 17 Aug 2016 18:12:51 -0400 (EDT) Date: Wed, 17 Aug 2016 18:12:51 -0400 From: Diane Bruce To: kargl@uw.edu Cc: Diane Bruce , freebsd-ports@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160817221251.GA68398@night.db.net> References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160817211710.GA59205@troutmask.apl.washington.edu> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 22:13:01 -0000 On Wed, Aug 17, 2016 at 02:17:10PM -0700, Steve Kargl wrote: > On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote: > > On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote: > > > > > > Freebsd-ports could also use a wrapper: > > > % cat ~/bin/gfc7 > > > #! /bin/sh > > > DIR=`id -P sgk | sed 's/\:/\ /g' | awk '{print $9}'` > > > export DIR > > > > > > LD_LIBRARY_PATH=$DIR/work/7/lib > > > export LD_LIBRARY_PATH > > > > > > LD_RUN_PATH=$DIR/work/7/lib > > > export LD_RUN_PATH > > > > > > $DIR/work/7/bin/gfortran -fno-backtrace $@ > > > > Yes. I have also suggested we use a wrapper to the ports guys. > > > > I thought about this a bit, and cleaner solution might be > to add the program suffix to libgcc_s.so.1. For example, > > % cat foo.f90 > program foo > print *, 'Hello' > end program > % gfortran6 -o z foo.f90 && ./z > /lib/libgcc_s.so.1: version GCC_4.6.0 required by \ > /usr/local/lib/gcc6/libgfortran.so.3 not found > % ldconfig -r | grep libgcc > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1 > > Clearly, ldd is looking for 735 but finds 6. If the lang/gcc6 could > be convinced to build, install, and use libgcc_s6.so.1, then the > problem is solved without a wrapper. I like this solution. > > -- > Steve > Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-toolchain@freebsd.org Wed Aug 17 22:16:45 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C479BBBD64F for ; Wed, 17 Aug 2016 22:16:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B31561D74 for ; Wed, 17 Aug 2016 22:16:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7HMGj1L040392 for ; Wed, 17 Aug 2016 22:16:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] LLVM is using AVX instructions for CPUTYPE=btver1 (AMD Bobcat) Date: Wed, 17 Aug 2016 22:16:45 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: needs-qa, patch, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 22:16:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 --- Comment #5 from Dimitry Andric --- This only applies to clang 3.8.0, there's no need to merge it back to stabl= e/9 and stable/10, as they have clang 3.4.1. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Aug 18 00:26:37 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D98AFBBC933; Thu, 18 Aug 2016 00:26:37 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BF6F2174B; Thu, 18 Aug 2016 00:26:37 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u7I0QYaf059925 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 17 Aug 2016 17:26:34 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u7I0QYHo059924; Wed, 17 Aug 2016 17:26:34 -0700 (PDT) (envelope-from sgk) Date: Wed, 17 Aug 2016 17:26:34 -0700 From: Steve Kargl To: Diane Bruce Cc: kargl@uw.edu, freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160818002634.GA59893@troutmask.apl.washington.edu> References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160817221251.GA68398@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160817221251.GA68398@night.db.net> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 18 Aug 2016 00:26:38 -0000 On Wed, Aug 17, 2016 at 06:12:51PM -0400, Diane Bruce wrote: > On Wed, Aug 17, 2016 at 02:17:10PM -0700, Steve Kargl wrote: > > On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote: > > > On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote: > > > > > > > > Freebsd-ports could also use a wrapper: > > > > > > Yes. I have also suggested we use a wrapper to the ports guys. > > > > > > > I thought about this a bit, and cleaner solution might be > > to add the program suffix to libgcc_s.so.1. For example, > > > > % cat foo.f90 > > program foo > > print *, 'Hello' > > end program > > % gfortran6 -o z foo.f90 && ./z > > /lib/libgcc_s.so.1: version GCC_4.6.0 required by \ > > /usr/local/lib/gcc6/libgfortran.so.3 not found > > % ldconfig -r | grep libgcc > > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > > 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1 > > > > Clearly, ldd is looking for 735 but finds 6. If the lang/gcc6 could > > be convinced to build, install, and use libgcc_s6.so.1, then the > > problem is solved without a wrapper. > > I like this solution. > I have asked on gcc@gcc.gnu.org if it is possible to configure gcc as above. I know that one can bump the shared lib number, but that won't solve the problem. -- Steve From owner-freebsd-toolchain@freebsd.org Thu Aug 18 09:16:40 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F6D2BBC21B; Thu, 18 Aug 2016 09:16:40 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay103.isp.belgacom.be (mailrelay103.isp.belgacom.be [195.238.20.130]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B55814E5; Thu, 18 Aug 2016 09:16:37 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AOBwC9e7VX/9SdgG1eDoM2SQ18t1qBf?= =?us-ascii?q?RyGAQKBZjkUAgEBAQEBAQFeJ0EBBAmEEAEFOhwjEAsOCgklDyoeBhMbiBq8PwE?= =?us-ascii?q?BAQEBAQQBAQEBI4p3ihsBBJlEhiCIdHGOYkiLc4N4HjaDPz06MgGCNjKERAEBA?= =?us-ascii?q?Q?= Received: from 212.157-128-109.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([109.128.157.212]) by relay.skynet.be with ESMTP; 18 Aug 2016 11:15:24 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id u7I9FLEk035401; Thu, 18 Aug 2016 11:15:22 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Thu, 18 Aug 2016 11:15:21 +0200 From: Tijl Coosemans To: Steve Kargl Cc: kargl@uw.edu, Diane Bruce , freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> In-Reply-To: <20160817211710.GA59205@troutmask.apl.washington.edu> References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 18 Aug 2016 09:16:40 -0000 On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl wrote: > On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote: >> On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote: >>> Freebsd-ports could also use a wrapper: >>> % cat ~/bin/gfc7 >>> #! /bin/sh >>> DIR=`id -P sgk | sed 's/\:/\ /g' | awk '{print $9}'` >>> export DIR >>> >>> LD_LIBRARY_PATH=$DIR/work/7/lib >>> export LD_LIBRARY_PATH >>> >>> LD_RUN_PATH=$DIR/work/7/lib >>> export LD_RUN_PATH >>> >>> $DIR/work/7/bin/gfortran -fno-backtrace $@ >> >> Yes. I have also suggested we use a wrapper to the ports guys. > > I thought about this a bit, and cleaner solution might be > to add the program suffix to libgcc_s.so.1. For example, > > % cat foo.f90 > program foo > print *, 'Hello' > end program > % gfortran6 -o z foo.f90 && ./z > /lib/libgcc_s.so.1: version GCC_4.6.0 required by \ > /usr/local/lib/gcc6/libgfortran.so.3 not found > % ldconfig -r | grep libgcc > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1 > > Clearly, ldd is looking for 735 but finds 6. If the lang/gcc6 could > be convinced to build, install, and use libgcc_s6.so.1, then the > problem is solved without a wrapper. In this case the real cause of the problem is that compilers and linkers search /lib and /usr/lib last and ldconfig searches them first. Renaming the library is just a hack around that. From owner-freebsd-toolchain@freebsd.org Thu Aug 18 12:48:48 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCA44BBD67E; Thu, 18 Aug 2016 12:48:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E1EA16AB; Thu, 18 Aug 2016 12:48:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2a03:fc02:2:1:d8dd:a30a:c903:147b] (unknown [IPv6:2a03:fc02:2:1:d8dd:a30a:c903:147b]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 9FB4A379A2; Thu, 18 Aug 2016 14:48:44 +0200 (CEST) Subject: Re: Problems with out libgcc_s.so in base Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_53D58B0A-3E40-425C-8251-062DB0ADB539"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6.1 From: Dimitry Andric In-Reply-To: <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> Date: Thu, 18 Aug 2016 14:48:28 +0200 Cc: Steve Kargl , freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, kargl@uw.edu Message-Id: References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> To: Tijl Coosemans X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 18 Aug 2016 12:48:48 -0000 --Apple-Mail=_53D58B0A-3E40-425C-8251-062DB0ADB539 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 18 Aug 2016, at 11:15, Tijl Coosemans wrote: >=20 > On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl = wrote: ... >> % ldconfig -r | grep libgcc >> 6:-lgcc_s.1 =3D> /lib/libgcc_s.so.1 >> 735:-lgcc_s.1 =3D> /usr/local/lib/gcc6/libgcc_s.so.1 >>=20 >> Clearly, ldd is looking for 735 but finds 6. If the lang/gcc6 could >> be convinced to build, install, and use libgcc_s6.so.1, then the >> problem is solved without a wrapper. >=20 > In this case the real cause of the problem is that compilers and = linkers > search /lib and /usr/lib last and ldconfig searches them first. = Renaming > the library is just a hack around that. Well, even if you would adjust the compilers and linkers to look in /usr/local/lib first, how would you solve the problem of having multiple, possibly incompatible versions of the same library in different directories? For example, on one of my systems, I now have these: /usr/local/lib/gcc47/libgcc_s.so.1 /usr/local/lib/gcc48/libgcc_s.so.1 /usr/local/lib/gcc49/libgcc_s.so.1 /usr/local/lib/gcc5/libgcc_s.so.1 /usr/local/lib/gcc6/libgcc_s.so.1 /usr/local/lib/gcc7/libgcc_s.so.1 So which one are you going to put at the front of the path? The gcc7 version? If you are lucky that one is backwards compatible with all the previous ones, but still I would like it much better if a program compiled by, say, gcc5 was linked *explicitly* against the gcc5 version of libgcc_s.so. Steve's proposed scheme solves that quite nicely, in my opinion. The problem is only in the details, as usual. There will be many configure scripts and libtool-like utilities out there, that assume libgcc must be linked using -lgcc_s, not -lgcc_s$VERSION. -Dimitry --Apple-Mail=_53D58B0A-3E40-425C-8251-062DB0ADB539 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAle1rqsACgkQsF6jCi4glqNSkACgydIKGVVzIivLUMvS31yqvn6r WTgAn17Ir9XoD+c05qbjvHM7bHLn128Z =fwFb -----END PGP SIGNATURE----- --Apple-Mail=_53D58B0A-3E40-425C-8251-062DB0ADB539-- From owner-freebsd-toolchain@freebsd.org Thu Aug 18 15:44:51 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CCE4BBE738; Thu, 18 Aug 2016 15:44:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7614F1EA3; Thu, 18 Aug 2016 15:44:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u7IFio9D063009 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Aug 2016 08:44:50 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u7IFioLh063008; Thu, 18 Aug 2016 08:44:50 -0700 (PDT) (envelope-from sgk) Date: Thu, 18 Aug 2016 08:44:50 -0700 From: Steve Kargl To: Dimitry Andric Cc: Tijl Coosemans , freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, kargl@uw.edu Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160818154449.GA62868@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 18 Aug 2016 15:44:51 -0000 On Thu, Aug 18, 2016 at 02:48:28PM +0200, Dimitry Andric wrote: > On 18 Aug 2016, at 11:15, Tijl Coosemans wrote: > > > > On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl wrote: > ... > >> % ldconfig -r | grep libgcc > >> 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > >> 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1 > >> > >> Clearly, ldd is looking for 735 but finds 6. If the lang/gcc6 could > >> be convinced to build, install, and use libgcc_s6.so.1, then the > >> problem is solved without a wrapper. > > > > In this case the real cause of the problem is that compilers and linkers > > search /lib and /usr/lib last and ldconfig searches them first. Renaming > > the library is just a hack around that. > > Well, even if you would adjust the compilers and linkers to look in > /usr/local/lib first, how would you solve the problem of having > multiple, possibly incompatible versions of the same library in > different directories? > > For example, on one of my systems, I now have these: > > /usr/local/lib/gcc47/libgcc_s.so.1 > /usr/local/lib/gcc48/libgcc_s.so.1 > /usr/local/lib/gcc49/libgcc_s.so.1 > /usr/local/lib/gcc5/libgcc_s.so.1 > /usr/local/lib/gcc6/libgcc_s.so.1 > /usr/local/lib/gcc7/libgcc_s.so.1 > > So which one are you going to put at the front of the path? The gcc7 > version? If you are lucky that one is backwards compatible with all the > previous ones, but still I would like it much better if a program > compiled by, say, gcc5 was linked *explicitly* against the gcc5 version > of libgcc_s.so. > > Steve's proposed scheme solves that quite nicely, in my opinion. The > problem is only in the details, as usual. There will be many configure > scripts and libtool-like utilities out there, that assume libgcc must be > linked using -lgcc_s, not -lgcc_s$VERSION. I asked on the gcc@gcc.gnu.org if there is a configure option to go the above, and unfortunately there isn't. I was pointed to --enable-version-specific-runtime-libs, but was then told that whatever it does is broken for multilib installs. I had not considered libtool-like utilities, so Dimitry is probably right in that this may open a can of worms. Another hack for the ports system would be to unilaterally include an -Wl,-rpath option on the gfortran commmand line. Currently, -Wl,-rpath is added to FFLAGS, FCFLAGS, and LDFLAGS in fortran.mk. The problem is that some ports might reset FFLAGS after fortran.mk has been included in Makefile. This should do the trick (watch for cut-n-paster whitespace corruption): Index: fortran.mk =================================================================== --- fortran.mk (revision 419226) +++ fortran.mk (working copy) @@ -26,9 +26,8 @@ RUN_DEPENDS+= gfortran${_GCC_VER}:lang/gcc${_GCC_VER} .endif USE_BINUTILS= yes -F77= gfortran${_GCC_VER} -FC= gfortran${_GCC_VER} -FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} +F77= gfortran${_GCC_VER} -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} +FC= gfortran${_GCC_VER} -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} FCFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \ -L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin One potential issues may be mixed-language apps that use Fortran libraries, but link with gcc or g++. -- Steve From owner-freebsd-toolchain@freebsd.org Thu Aug 18 19:30:43 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1506FBBEE27 for ; Thu, 18 Aug 2016 19:30:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 040A9180A for ; Thu, 18 Aug 2016 19:30:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7IJUg3x074947 for ; Thu, 18 Aug 2016 19:30:42 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] LLVM is using AVX instructions for CPUTYPE=btver1 (AMD Bobcat) Date: Thu, 18 Aug 2016 19:30:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: needs-qa, patch, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: demik+freebsd@lostwave.net X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 18 Aug 2016 19:30:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 --- Comment #6 from Michel Depeige --- Hello, the patch is working as expected : no more vzeroupper ! I have rebuild successfully all my ports, even kernel, everything is working fine Thanks for your help ! Will this fix be in RC2 ? Regards --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Aug 18 20:01:54 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 238B8BBE7B8 for ; Thu, 18 Aug 2016 20:01:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1230C18F0 for ; Thu, 18 Aug 2016 20:01:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7IK1rJ2065568 for ; Thu, 18 Aug 2016 20:01:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] LLVM is using AVX instructions for CPUTYPE=btver1 (AMD Bobcat) Date: Thu, 18 Aug 2016 20:01:53 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: needs-qa, patch, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 18 Aug 2016 20:01:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 --- Comment #7 from Dimitry Andric --- (In reply to Michel Depeige from comment #6) > Will this fix be in RC2 ? I will merge it to stable/11 on August 20, when the timeout expires. Then I will contact the Release Engineering team for permission to merge it to the 11.0 release branch. This is not really a showstopper though, since you can work around it relatively easily by setting your CPUTYPE to something else. It is up to t= he Release Engineering team to decide. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Aug 18 23:15:48 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49DC7BBF4BF; Thu, 18 Aug 2016 23:15:48 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay110.isp.belgacom.be (mailrelay110.isp.belgacom.be [195.238.20.137]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 494B11EC1; Thu, 18 Aug 2016 23:15:46 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BsCADTQLZX/9SdgG1eg0RJDW0PuWggg?= =?us-ascii?q?jaDRwKBczwRAgEBAQEBAQFeJ4ReAQEEATocIwULCw4KCSUPKh4GE4gpDAq9LAE?= =?us-ascii?q?BAQEBAQEDAQEBAQEBIYp3ihsFjh2LKIYggn+FdXGOY0iLdYN4NCCDfDoyAYcsA?= =?us-ascii?q?QEB?= Received: from 212.157-128-109.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([109.128.157.212]) by relay.skynet.be with ESMTP; 19 Aug 2016 01:14:34 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id u7INEX7F040477; Fri, 19 Aug 2016 01:14:33 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Fri, 19 Aug 2016 01:14:32 +0200 From: Tijl Coosemans To: Dimitry Andric Cc: Steve Kargl , freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, kargl@uw.edu Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> In-Reply-To: References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 18 Aug 2016 23:15:48 -0000 On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric wrote: > On 18 Aug 2016, at 11:15, Tijl Coosemans wrote: >> On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl wrote: >>> % gfortran6 -o z foo.f90 && ./z >>> /lib/libgcc_s.so.1: version GCC_4.6.0 required by \ >>> /usr/local/lib/gcc6/libgfortran.so.3 not found >>> % ldconfig -r | grep libgcc >>> 6:-lgcc_s.1 => /lib/libgcc_s.so.1 >>> 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1 >>> >>> Clearly, ldd is looking for 735 but finds 6. If the lang/gcc6 could >>> be convinced to build, install, and use libgcc_s6.so.1, then the >>> problem is solved without a wrapper. >> >> In this case the real cause of the problem is that compilers and linkers >> search /lib and /usr/lib last and ldconfig searches them first. Renaming >> the library is just a hack around that. > > Well, even if you would adjust the compilers and linkers to look in > /usr/local/lib first, No, I wanted to change /etc/rc.d/ldconfig to put /lib and /usr/lib last. That would match base ld(1) so anything that links successfully at compile-time will also link successfully at run-time (if there are no other search order mismatches leading to conflicts). But, this means that in case of a name conflict between base and ports, the ports provided library is assumed to be the right one. I'm not 100% sure this is smart. Usually the ports version of a library is more recent and if the name is the same it should be backward compatible, but if that's not the case (older or not compatible) base utilities may fail to run (like ./z in the example above) and that's maybe worse than ports or locally built programs failing. > how would you solve the problem of having > multiple, possibly incompatible versions of the same library in > different directories? > > For example, on one of my systems, I now have these: > > /usr/local/lib/gcc47/libgcc_s.so.1 > /usr/local/lib/gcc48/libgcc_s.so.1 > /usr/local/lib/gcc49/libgcc_s.so.1 > /usr/local/lib/gcc5/libgcc_s.so.1 > /usr/local/lib/gcc6/libgcc_s.so.1 > /usr/local/lib/gcc7/libgcc_s.so.1 > > So which one are you going to put at the front of the path? The gcc7 > version? If you are lucky that one is backwards compatible with all the > previous ones, but still I would like it much better if a program > compiled by, say, gcc5 was linked *explicitly* against the gcc5 version > of libgcc_s.so. > > Steve's proposed scheme solves that quite nicely, in my opinion. The > problem is only in the details, as usual. There will be many configure > scripts and libtool-like utilities out there, that assume libgcc must be > linked using -lgcc_s, not -lgcc_s$VERSION. This is a separate problem that has been discussed many times before. The ports tree adds -Wl,-rpath to *FLAGS in several places to choose a library. I now noticed there is a FAQ about this at https://gcc.gnu.org/faq.html#rpath. It gives some suggestions including creating wrapper scripts, but they wouldn't work when code is compiled with gfortran but linked with Clang cc/c++. The only thing that works in this case is -Wl,-rpath. Another option would be to create a port that installs a recent version of libgcc in /usr/local/lib and let the gcc ports use that instead of their own copy. From owner-freebsd-toolchain@freebsd.org Thu Aug 18 23:50:56 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 695DFBBFF39; Thu, 18 Aug 2016 23:50:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3376618CF; Thu, 18 Aug 2016 23:50:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u7INonjj093219 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Aug 2016 16:50:49 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u7INonmt093218; Thu, 18 Aug 2016 16:50:49 -0700 (PDT) (envelope-from sgk) Date: Thu, 18 Aug 2016 16:50:49 -0700 From: Steve Kargl To: Tijl Coosemans Cc: Dimitry Andric , freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, kargl@uw.edu Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160818235049.GA93186@troutmask.apl.washington.edu> References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 18 Aug 2016 23:50:56 -0000 On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote: > > > > For example, on one of my systems, I now have these: > > > > /usr/local/lib/gcc47/libgcc_s.so.1 > > /usr/local/lib/gcc48/libgcc_s.so.1 > > /usr/local/lib/gcc49/libgcc_s.so.1 > > /usr/local/lib/gcc5/libgcc_s.so.1 > > /usr/local/lib/gcc6/libgcc_s.so.1 > > /usr/local/lib/gcc7/libgcc_s.so.1 > > > > So which one are you going to put at the front of the path? The gcc7 > > version? If you are lucky that one is backwards compatible with all the > > previous ones, but still I would like it much better if a program > > compiled by, say, gcc5 was linked *explicitly* against the gcc5 version > > of libgcc_s.so. > > > > Steve's proposed scheme solves that quite nicely, in my opinion. The > > problem is only in the details, as usual. There will be many configure > > scripts and libtool-like utilities out there, that assume libgcc must be > > linked using -lgcc_s, not -lgcc_s$VERSION. > > I now noticed there is a FAQ about this at > https://gcc.gnu.org/faq.html#rpath. It gives some suggestions including > creating wrapper scripts, but they wouldn't work when code is compiled > with gfortran but linked with Clang cc/c++. The only thing that works > in this case is -Wl,-rpath. Another option would be to create a port > that installs a recent version of libgcc in /usr/local/lib and let the > gcc ports use that instead of their own copy. elfdump -a libgfortran.so.3 shows dynamic: entry: 0 d_tag: DT_NEEDED d_val: libquadmath.so.0 entry: 1 d_tag: DT_NEEDED d_val: libm.so.5 entry: 2 d_tag: DT_NEEDED d_val: libgcc_s.so.1 entry: 3 d_tag: DT_NEEDED d_val: libc.so.7 entry: 4 d_tag: DT_SONAME d_val: libgfortran.so.3 entry: 5 d_tag: DT_RPATH d_val: /usr/local/lib/gcc6 I don't know how ELF or the ldd work, but shouldn't the DT_RPATH tell ldd to look for all of the above libraries in /usr/local/lib/gcc6 first. If a library isn't present, it would then look in ldconfig's hints file or fallback to /lib and /usr/lib/. But, I suppose we still run into issues as libgfortran.so.3 needs its companion libgcc_s.s.1 from DT_RPATH and libc.so.7 expects the one from /lib (or perhaps libcxxrt.so.1?). -- Steve From owner-freebsd-toolchain@freebsd.org Thu Aug 18 23:58:06 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2E73DBBE679; Thu, 18 Aug 2016 23:58:06 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (unknown [IPv6:2620:64:0:1:223:7dff:fea2:c8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 15E741CC9; Thu, 18 Aug 2016 23:58:06 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 226692AA411; Thu, 18 Aug 2016 17:57:19 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id E01241CDE4; Thu, 18 Aug 2016 19:58:01 -0400 (EDT) Date: Thu, 18 Aug 2016 19:58:01 -0400 From: Diane Bruce To: Steve Kargl Cc: Tijl Coosemans , freebsd-toolchain@freebsd.org, Dimitry Andric , freebsd-ports@freebsd.org, kargl@uw.edu Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160818235801.GA83722@night.db.net> References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> <20160818235049.GA93186@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160818235049.GA93186@troutmask.apl.washington.edu> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 18 Aug 2016 23:58:06 -0000 On Thu, Aug 18, 2016 at 04:50:49PM -0700, Steve Kargl wrote: > On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote: > > > > > > For example, on one of my systems, I now have these: > > > .... > entry: 5 > d_tag: DT_RPATH > d_val: /usr/local/lib/gcc6 > > I don't know how ELF or the ldd work, but shouldn't the DT_RPATH > tell ldd to look for all of the above libraries in /usr/local/lib/gcc6 > first. If a library isn't present, it would then look in ldconfig's > hints file or fallback to /lib and /usr/lib/. But, I suppose we > still run into issues as libgfortran.so.3 needs its companion libgcc_s.s.1 > from DT_RPATH and libc.so.7 expects the one from /lib (or perhaps > libcxxrt.so.1?). https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120 Anything compiled with cmake infrastructure loses the DT_RPATH. > -- > Steve > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" > Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-toolchain@freebsd.org Fri Aug 19 00:12:48 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4D24ABBEA64; Fri, 19 Aug 2016 00:12:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 260461644; Fri, 19 Aug 2016 00:12:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u7J0CiSl093680 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Aug 2016 17:12:44 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u7J0CiwW093679; Thu, 18 Aug 2016 17:12:44 -0700 (PDT) (envelope-from sgk) Date: Thu, 18 Aug 2016 17:12:44 -0700 From: Steve Kargl To: Diane Bruce Cc: Tijl Coosemans , freebsd-toolchain@freebsd.org, Dimitry Andric , freebsd-ports@freebsd.org, kargl@uw.edu Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160819001244.GA93672@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> <20160818235049.GA93186@troutmask.apl.washington.edu> <20160818235801.GA83722@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160818235801.GA83722@night.db.net> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 19 Aug 2016 00:12:48 -0000 On Thu, Aug 18, 2016 at 07:58:01PM -0400, Diane Bruce wrote: > On Thu, Aug 18, 2016 at 04:50:49PM -0700, Steve Kargl wrote: > > On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote: > > > > > > > > For example, on one of my systems, I now have these: > > > > > .... > > entry: 5 > > d_tag: DT_RPATH > > d_val: /usr/local/lib/gcc6 > > > > I don't know how ELF or the ldd work, but shouldn't the DT_RPATH > > tell ldd to look for all of the above libraries in /usr/local/lib/gcc6 > > first. If a library isn't present, it would then look in ldconfig's > > hints file or fallback to /lib and /usr/lib/. But, I suppose we > > still run into issues as libgfortran.so.3 needs its companion libgcc_s.s.1 > > from DT_RPATH and libc.so.7 expects the one from /lib (or perhaps > > libcxxrt.so.1?). > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120 > > Anything compiled with cmake infrastructure loses the DT_RPATH. > I know nothing about cmake, but it seems to be broken. :) -- Steve From owner-freebsd-toolchain@freebsd.org Fri Aug 19 00:43:07 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 80E09BBF2F3; Fri, 19 Aug 2016 00:43:07 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C2451368; Fri, 19 Aug 2016 00:43:07 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u7J0h4a6094053 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Aug 2016 17:43:04 -0700 (PDT) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u7J0h4h6094052; Thu, 18 Aug 2016 17:43:04 -0700 (PDT) (envelope-from kargl) Date: Thu, 18 Aug 2016 17:43:04 -0700 From: "Steven G. Kargl" To: Tijl Coosemans Cc: Dimitry Andric , Steve Kargl , freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, kargl@uw.edu Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160819004304.GA94021@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 19 Aug 2016 00:43:07 -0000 On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote: > On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric wrote: > > > how would you solve the problem of having > > multiple, possibly incompatible versions of the same library in > > different directories? > > > > For example, on one of my systems, I now have these: > > > > /usr/local/lib/gcc47/libgcc_s.so.1 > > /usr/local/lib/gcc48/libgcc_s.so.1 > > /usr/local/lib/gcc49/libgcc_s.so.1 > > /usr/local/lib/gcc5/libgcc_s.so.1 > > /usr/local/lib/gcc6/libgcc_s.so.1 > > /usr/local/lib/gcc7/libgcc_s.so.1 > > > > So which one are you going to put at the front of the path? The gcc7 > > version? If you are lucky that one is backwards compatible with all the > > previous ones, but still I would like it much better if a program > > compiled by, say, gcc5 was linked *explicitly* against the gcc5 version > > of libgcc_s.so. > > > > Steve's proposed scheme solves that quite nicely, in my opinion. The > > problem is only in the details, as usual. There will be many configure > > scripts and libtool-like utilities out there, that assume libgcc must be > > linked using -lgcc_s, not -lgcc_s$VERSION. > > This is a separate problem that has been discussed many times before. > The ports tree adds -Wl,-rpath to *FLAGS in several places to choose > a library. I now noticed there is a FAQ about this at > https://gcc.gnu.org/faq.html#rpath. It gives some suggestions including > creating wrapper scripts, but they wouldn't work when code is compiled > with gfortran but linked with Clang cc/c++. The only thing that works > in this case is -Wl,-rpath. Another option would be to create a port > that installs a recent version of libgcc in /usr/local/lib and let the > gcc ports use that instead of their own copy. It gross but it appears to work: % cd ~/work/6/lib % sed s/gcc_s/gcc_t/ < libgfortran.so.3 > zxc % mv zxc libgfortran.so.3 % elfdump -a libgfortran.so.3 | grep gcc_ d_val: libgcc_t.so.1 % ln -sf libgcc_s.so.1 libgcc_t.so.1 % ldconfig -R % ldconfig -r | grep libgcc 6:-lgcc_s.1 => /lib/libgcc_s.so.1 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1 745:-lgcc_t.1 => /usr/local/lib/gcc6/libgcc_t.so.1 % cd tmp % gfortran6 -o z foo.f90 && ./z Hello That is, the name clash in ldconfig can be avoided by editing libgfortran.so.3 to look for a symlinked libgcc_s.so.1. -- Steve http://troutmask.apl.washington.edu/~kargl/ From owner-freebsd-toolchain@freebsd.org Fri Aug 19 00:47:01 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6415FBBF3C3; Fri, 19 Aug 2016 00:47:01 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46E6C157C; Fri, 19 Aug 2016 00:47:01 +0000 (UTC) (envelope-from kargl@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u7J0kwla094170 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Aug 2016 17:46:58 -0700 (PDT) (envelope-from kargl@troutmask.apl.washington.edu) Received: (from kargl@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u7J0kwP4094169; Thu, 18 Aug 2016 17:46:58 -0700 (PDT) (envelope-from kargl) Date: Thu, 18 Aug 2016 17:46:58 -0700 From: "Steven G. Kargl" To: Tijl Coosemans Cc: Dimitry Andric , Steve Kargl , freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, kargl@uw.edu Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160819004658.GA94122@troutmask.apl.washington.edu> Reply-To: kargl@uw.edu References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> <20160819004304.GA94021@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160819004304.GA94021@troutmask.apl.washington.edu> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 19 Aug 2016 00:47:01 -0000 On Thu, Aug 18, 2016 at 05:43:04PM -0700, Steven G. Kargl wrote: > > % cd ~/work/6/lib Dang. This should have been "cd /usr/local/lib/gcc6" > % sed s/gcc_s/gcc_t/ < libgfortran.so.3 > zxc > % mv zxc libgfortran.so.3 > % elfdump -a libgfortran.so.3 | grep gcc_ > d_val: libgcc_t.so.1 > % ln -sf libgcc_s.so.1 libgcc_t.so.1 This magic can be done as a post-install step. > % ldconfig -R > % ldconfig -r | grep libgcc > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1 > 745:-lgcc_t.1 => /usr/local/lib/gcc6/libgcc_t.so.1 > > % cd tmp > % gfortran6 -o z foo.f90 && ./z > Hello > > That is, the name clash in ldconfig can be avoided by editing > libgfortran.so.3 to look for a symlinked libgcc_s.so.1. > > -- > Steve > http://troutmask.apl.washington.edu/~kargl/ -- Steve http://troutmask.apl.washington.edu/~kargl/ From owner-freebsd-toolchain@freebsd.org Fri Aug 19 07:28:21 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8099BBFECB; Fri, 19 Aug 2016 07:28:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5228312BD; Fri, 19 Aug 2016 07:28:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u7J7SEGh016516 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Aug 2016 10:28:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u7J7SEGh016516 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u7J7SEX7016515; Fri, 19 Aug 2016 10:28:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 19 Aug 2016 10:28:14 +0300 From: Konstantin Belousov To: Tijl Coosemans Cc: Dimitry Andric , freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, Steve Kargl , kargl@uw.edu Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160819072813.GB83214@kib.kiev.ua> References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 19 Aug 2016 07:28:21 -0000 On Fri, Aug 19, 2016 at 01:14:32AM +0200, Tijl Coosemans wrote: > On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric wrote: > > On 18 Aug 2016, at 11:15, Tijl Coosemans wrote: > >> On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl wrote: > >>> % gfortran6 -o z foo.f90 && ./z > >>> /lib/libgcc_s.so.1: version GCC_4.6.0 required by \ > >>> /usr/local/lib/gcc6/libgfortran.so.3 not found > >>> % ldconfig -r | grep libgcc > >>> 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > >>> 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1 > >>> > >>> Clearly, ldd is looking for 735 but finds 6. If the lang/gcc6 could > >>> be convinced to build, install, and use libgcc_s6.so.1, then the > >>> problem is solved without a wrapper. > >> > >> In this case the real cause of the problem is that compilers and linkers > >> search /lib and /usr/lib last and ldconfig searches them first. Renaming > >> the library is just a hack around that. > > > > Well, even if you would adjust the compilers and linkers to look in > > /usr/local/lib first, > > No, I wanted to change /etc/rc.d/ldconfig to put /lib and /usr/lib last. > That would match base ld(1) so anything that links successfully at > compile-time will also link successfully at run-time (if there are no > other search order mismatches leading to conflicts). > > But, this means that in case of a name conflict between base and ports, > the ports provided library is assumed to be the right one. I'm not 100% > sure this is smart. Usually the ports version of a library is more > recent and if the name is the same it should be backward compatible, but > if that's not the case (older or not compatible) base utilities may fail > to run (like ./z in the example above) and that's maybe worse than ports > or locally built programs failing. > > > how would you solve the problem of having > > multiple, possibly incompatible versions of the same library in > > different directories? > > > > For example, on one of my systems, I now have these: > > > > /usr/local/lib/gcc47/libgcc_s.so.1 > > /usr/local/lib/gcc48/libgcc_s.so.1 > > /usr/local/lib/gcc49/libgcc_s.so.1 > > /usr/local/lib/gcc5/libgcc_s.so.1 > > /usr/local/lib/gcc6/libgcc_s.so.1 > > /usr/local/lib/gcc7/libgcc_s.so.1 > > > > So which one are you going to put at the front of the path? The gcc7 > > version? If you are lucky that one is backwards compatible with all the > > previous ones, but still I would like it much better if a program > > compiled by, say, gcc5 was linked *explicitly* against the gcc5 version > > of libgcc_s.so. > > > > Steve's proposed scheme solves that quite nicely, in my opinion. The > > problem is only in the details, as usual. There will be many configure > > scripts and libtool-like utilities out there, that assume libgcc must be > > linked using -lgcc_s, not -lgcc_s$VERSION. > > This is a separate problem that has been discussed many times before. > The ports tree adds -Wl,-rpath to *FLAGS in several places to choose > a library. I now noticed there is a FAQ about this at > https://gcc.gnu.org/faq.html#rpath. It gives some suggestions including > creating wrapper scripts, but they wouldn't work when code is compiled > with gfortran but linked with Clang cc/c++. The only thing that works > in this case is -Wl,-rpath. Another option would be to create a port > that installs a recent version of libgcc in /usr/local/lib and let the > gcc ports use that instead of their own copy. The option which would fix all this mess is: 1. add rpath for gcc lib/ directory into spec file and 2. make ports collection use its own compiler instead of fighting with the base. From owner-freebsd-toolchain@freebsd.org Fri Aug 19 19:51:47 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19C4CBBFEA8; Fri, 19 Aug 2016 19:51:47 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay106.isp.belgacom.be (mailrelay106.isp.belgacom.be [195.238.20.133]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E3FE51470; Fri, 19 Aug 2016 19:51:45 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2C9BQAMYrdX/9SdgG1eg0RJDXyrRIwsg?= =?us-ascii?q?X0chgECgWk5FAIBAQEBAQEBXieEXwEFJxMcIxALDgoJJQ8SGB4GE4gXAxu2NA2?= =?us-ascii?q?EDgEBAQEBAQQBAQEBI4p4gkOHWAEEmRM0hiCGO4I5cY5lSIdthAiDeB42ghIcg?= =?us-ascii?q?U46NIctAQEB?= Received: from 212.157-128-109.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([109.128.157.212]) by relay.skynet.be with ESMTP; 19 Aug 2016 21:50:32 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id u7JJoTcr066249; Fri, 19 Aug 2016 21:50:30 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Fri, 19 Aug 2016 21:50:28 +0200 From: Tijl Coosemans To: Konstantin Belousov Cc: Dimitry Andric , freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, Steve Kargl , kargl@uw.edu Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160819215028.3d8e5b42@kalimero.tijl.coosemans.org> In-Reply-To: <20160819072813.GB83214@kib.kiev.ua> References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> <20160819072813.GB83214@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 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, 19 Aug 2016 19:51:47 -0000 On Fri, 19 Aug 2016 10:28:14 +0300 Konstantin Belousov wrote: > The option which would fix all this mess is: > 1. add rpath for gcc lib/ directory into spec file > and > 2. make ports collection use its own compiler instead of fighting with > the base. That still doesn't cover all cases, e.g.: port exec -> base lib -> libgcc_s.so.1 -> port lib -> recent libgcc_s.so.1 An example is: % echo 'int main(void){}' > test.c % clang37 -o test test.c -lexecinfo -lgfortran -L/usr/local/lib/gcc5 -Wl,-rpath,/usr/local/lib/gcc5 % ./test /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc5/libgfortran.so.3 not found The base library (libexecinfo) doesn't have DT_RPATH or DT_RUNPATH so the only way rtld can find the right libgcc_s.so is if the executable (test) has DT_RPATH and no DT_RUNPATH. Clang runs ld with --enable-new-dtags so the executable has DT_RUNPATH. DT_RPATH is deprecated in the Linux world so there are probably more ports that use --enable-new-dtags. Another example seems to be Rust. From owner-freebsd-toolchain@freebsd.org Sat Aug 20 12:49:36 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B89FBC0C10 for ; Sat, 20 Aug 2016 12:49:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5A3781624 for ; Sat, 20 Aug 2016 12:49:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7KCnZpq044551 for ; Sat, 20 Aug 2016 12:49:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] LLVM is using AVX instructions for CPUTYPE=btver1 (AMD Bobcat) Date: Sat, 20 Aug 2016 12:49:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: needs-qa, patch, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 12:49:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 --- Comment #8 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Sat Aug 20 12:49:06 UTC 2016 New revision: 304528 URL: https://svnweb.freebsd.org/changeset/base/304528 Log: MFC r304319: Pull in r262772 from upstream clang trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17682 Pull in r262782 from upstream llvm trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17683 This ensures clang does not emit AVX instructions for CPUTYPE=3Dbtver1. Reported by: Michel Depeige PR: 211864 Changes: _U stable/11/ stable/11/contrib/llvm/lib/Target/X86/X86.td stable/11/contrib/llvm/tools/clang/lib/Basic/Targets.cpp stable/11/lib/clang/freebsd_cc_version.h --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Aug 20 13:30:41 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FE63BC04F9 for ; Sat, 20 Aug 2016 13:30:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F2EA81988 for ; Sat, 20 Aug 2016 13:30:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7KDUeTg062729 for ; Sat, 20 Aug 2016 13:30:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] LLVM is using AVX instructions for CPUTYPE=btver1 (AMD Bobcat) Date: Sat, 20 Aug 2016 13:30:41 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: needs-qa, patch, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 13:30:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 --- Comment #9 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Sat Aug 20 13:29:59 UTC 2016 New revision: 304529 URL: https://svnweb.freebsd.org/changeset/base/304529 Log: MFC r304319: Pull in r262772 from upstream clang trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17682 Pull in r262782 from upstream llvm trunk (by Simon Pilgrim): [X86] AMD Bobcat CPU (btver1) doesn't support XSAVE btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE. Differential Revision: http://reviews.llvm.org/D17683 This ensures clang does not emit AVX instructions for CPUTYPE=3Dbtver1. Approved by: re (kib) Reported by: Michel Depeige PR: 211864 Changes: _U releng/11.0/ releng/11.0/contrib/llvm/lib/Target/X86/X86.td releng/11.0/contrib/llvm/tools/clang/lib/Basic/Targets.cpp releng/11.0/lib/clang/freebsd_cc_version.h --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Aug 20 13:37:44 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA728BC08FC for ; Sat, 20 Aug 2016 13:37:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D92F01DCB for ; Sat, 20 Aug 2016 13:37:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7KDbhfE077280 for ; Sat, 20 Aug 2016 13:37:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 211864] LLVM is using AVX instructions for CPUTYPE=btver1 (AMD Bobcat) Date: Sat, 20 Aug 2016 13:37:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 11.0-RC1 X-Bugzilla-Keywords: needs-qa, patch, regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: mfc-stable9- mfc-stable10- mfc-stable11+ X-Bugzilla-Changed-Fields: flagtypes.name bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 13:37:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211864 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|mfc-stable9?, |mfc-stable9-, |mfc-stable10?, |mfc-stable10-, |mfc-stable11? |mfc-stable11+ Status|In Progress |Closed Resolution|--- |FIXED --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sat Aug 20 15:10:51 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41A96BC0139; Sat, 20 Aug 2016 15:10:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA46F1347; Sat, 20 Aug 2016 15:10:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u7KFAjpY091982 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 20 Aug 2016 18:10:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u7KFAjpY091982 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u7KFAiTw091957; Sat, 20 Aug 2016 18:10:44 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 20 Aug 2016 18:10:44 +0300 From: Konstantin Belousov To: Tijl Coosemans Cc: Dimitry Andric , freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, Steve Kargl , kargl@uw.edu Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160820151044.GO83214@kib.kiev.ua> References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> <20160819072813.GB83214@kib.kiev.ua> <20160819215028.3d8e5b42@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160819215028.3d8e5b42@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 15:10:51 -0000 On Fri, Aug 19, 2016 at 09:50:28PM +0200, Tijl Coosemans wrote: > On Fri, 19 Aug 2016 10:28:14 +0300 Konstantin Belousov wrote: > > The option which would fix all this mess is: > > 1. add rpath for gcc lib/ directory into spec file > > and > > 2. make ports collection use its own compiler instead of fighting with > > the base. > > That still doesn't cover all cases, e.g.: > > port exec -> base lib -> libgcc_s.so.1 > -> port lib -> recent libgcc_s.so.1 > > An example is: > > % echo 'int main(void){}' > test.c > % clang37 -o test test.c -lexecinfo -lgfortran -L/usr/local/lib/gcc5 -Wl,-rpath,/usr/local/lib/gcc5 > % ./test > /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc5/libgfortran.so.3 not found > > The base library (libexecinfo) doesn't have DT_RPATH or DT_RUNPATH so the > only way rtld can find the right libgcc_s.so is if the executable (test) > has DT_RPATH and no DT_RUNPATH. Clang runs ld with --enable-new-dtags > so the executable has DT_RUNPATH. DT_RPATH is deprecated in the Linux > world so there are probably more ports that use --enable-new-dtags. > Another example seems to be Rust. Indeed, and I rechecked the find_library() code against the latest gABI once more. So base libraries linked against libgcc_s are /lib/libcxxrt.so.1 /usr/lib/libc++.so.1 /usr/lib/libexecinfo.so.1 /usr/lib/libprivatedevdctl.so.0 and only libexecinfo would be somewhat problematic. libcxxrt and libc++ come from C++ runtime, which must be provided by the port's compiler, the private library should not be linked to by behaving applications. I suppose that libexecinfo pull unwinder from libgcc_s. It might be possible just dlopen() libgcc_s for _Unwind_Backtrace, it seems. From owner-freebsd-toolchain@freebsd.org Sat Aug 20 17:53:01 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 57FA2BC0D20 for ; Sat, 20 Aug 2016 17:53:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3CC601C5E for ; Sat, 20 Aug 2016 17:53:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u7KHr0Mw039440 for ; Sat, 20 Aug 2016 17:53:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 192320] Use of thread_local produces linking errors on system version of clang++ Date: Sat, 20 Aug 2016 17:53:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: misc X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bdrewery@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kib@FreeBSD.org X-Bugzilla-Flags: mfc-stable9? mfc-stable10? mfc-stable11? X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2016 17:53:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D192320 Bryan Drewery changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bdrewery@FreeBSD.org --- Comment #13 from Bryan Drewery --- r303795 | kib | 2016-08-06 06:32:40 -0700 (Sat, 06 Aug 2016) | 37 lines Changed paths: M /head/lib/libc/include/libc_private.h M /head/lib/libc/stdlib/Makefile.inc M /head/lib/libc/stdlib/Symbol.map A /head/lib/libc/stdlib/cxa_thread_atexit.c M /head/lib/libc/stdlib/exit.c M /head/lib/libc/tests/stdlib/Makefile M /head/lib/libc/tests/stdlib/Makefile.depend A /head/lib/libc/tests/stdlib/cxa_thread_atexit_nothr_test.cc A /head/lib/libc/tests/stdlib/cxa_thread_atexit_test.cc M /head/lib/libthr/thread/thr_exit.c Add __cxa_thread_atexit(3) API implementation. This is the backing feature to implement C++11 thread storage duration specified by the thread_local keyword. A destructor for given thread-local object is registered to be executed at the thread termination time using __cxa_thread_atexit(). Libc calls the __cxa_thread_calls_dtors() during exit(3), before finalizers and atexit functions, and libthr calls the function at the thread termination time, after the stack unwinding and thread-specific key destruction. There are several uncertainties in the API which lacks a formal specification. Among them: - is it allowed to register destructors during destructing; we allow, but limiting the nesting level. If too many iterations detected, a diagnostic is issued to stderr and thread forcibly terminates for now. - how to handle destructors which belong to an unloading dso; for now, we ignore destructor calls for such entries, and issue a diagnostic. Linux does prevent dso unload until all threads with destructors from the dso terminated. It is supposed that the diagnostics allow to detect real-world applications relying on the above details and possibly adjust our implementation. Right now the choices were to provide the slim API (but that rarely stands the practice test). Tests are added to check generic functionality and to specify some of the above implementation choices. Submitted by: Mahdi Mokhtari Reviewed by: theraven Discussed with: dim (detection of -std=3Dc++11 supoort for tests) Sponsored by: The FreeBSD Foundation (my involvement) MFC after: 2 weeks Differential revisions: https://reviews.freebsd.org/D7224, https://reviews.freebsd.org/D7427 --=20 You are receiving this mail because: You are on the CC list for the bug.=