From owner-freebsd-toolchain@freebsd.org Mon May 23 16:40:23 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 55207B47024 for ; Mon, 23 May 2016 16:40:23 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 42356173C for ; Mon, 23 May 2016 16:40:23 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3D8C8B47022; Mon, 23 May 2016 16:40:23 +0000 (UTC) Delivered-To: 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 3D020B47020; Mon, 23 May 2016 16:40:23 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 2F5AD1739; Mon, 23 May 2016 16:40:23 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 274341F73; Mon, 23 May 2016 16:40:23 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id D49F91C459; Mon, 23 May 2016 16:40:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id xId9nFujGyMG; Mon, 23 May 2016 16:40:20 +0000 (UTC) To: current@FreeBSD.org, toolchain@FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 538561C44C From: Bryan Drewery Subject: WITH_SYSTEM_COMPILER: Skip Clang/GCC bootstrap [Critical note for Toolchain changes] Organization: FreeBSD Message-ID: Date: Mon, 23 May 2016 09:40:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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, 23 May 2016 16:40:23 -0000 In head is now the WITH_SYSTEM_COMPILER option. It is off-by-default for now but hopefully will be on-by-default relatively quickly. It will skip building the bootstrap Clang for buildworld/kernel-toolchain/universe if /usr/bin/cc matches the tree. It will also skip GCC if building for the same arch as the host system. The Clang/GCC-to-by-installed will be still be built though. See https://svnweb.freebsd.org/changeset/base/300354 for more details. A critical note to toolchain developers, or anyone who touches the Clang or GCC source files. If you modify these files or add a new target architecture into Clang, please bump the revision in the appropriate file= : Clang: lib/clang/include/clang/Basic/Version.inc FREEBSD_CC_VERSION GCC: gnu/usr.bin/cc/cc_tools/freebsd-native.h FBSD_CC_VER Still left todo: - Build one version of clang in universe if the WITH_SYSTEM_COMPILER logic does not pass. --=20 Regards, Bryan Drewery From owner-freebsd-toolchain@freebsd.org Mon May 23 21:47: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 935E0B47C34 for ; Mon, 23 May 2016 21:47:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-168.reflexion.net [208.70.211.168]) (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 4943319F1 for ; Mon, 23 May 2016 21:47:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23074 invoked from network); 23 May 2016 21:41:40 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 23 May 2016 21:41:40 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 23 May 2016 17:41:06 -0400 (EDT) Received: (qmail 7591 invoked from network); 23 May 2016 21:41:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 23 May 2016 21:41:06 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id BE0051C43E2; Mon, 23 May 2016 14:41:03 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: WITH_SYSTEM_COMPILER: Skip Clang/GCC bootstrap [Critical note for Toolchain changes] Message-Id: <986EF3DE-84DA-4867-AD94-384EA3733144@dsl-only.net> Date: Mon, 23 May 2016 14:41:07 -0700 To: FreeBSD Current , Bryan Drewery , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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: Mon, 23 May 2016 21:47:51 -0000 Relative to (Bryan Drewery Mon May 23 16:40:23 UTC 2016): > A critical note to toolchain developers, or anyone who touches the = Clang > or GCC source files. If you modify these files or add a new target > architecture into Clang, please bump the revision in the appropriate = file: >=20 > Clang: lib/clang/include/clang/Basic/Version.inc FREEBSD_CC_VERSION > GCC: gnu/usr.bin/cc/cc_tools/freebsd-native.h FBSD_CC_VER quoting from https://svnweb.freebsd.org/changeset/base/300354 : > This relies on the macros being incremented whenever any change occurs > to these compilers that warrant rebuilding files. It also should = never > repeat earlier values. It appears that someone that tries to make or test clang patches without = using a committer bit to be the one updating the official source will = have trouble meeting this criteria. I've been in that situation in the = past. Reverting back to, say, CURRENT after a patch is adopted is = another example of version number progression problems. It may be that official value updates to FREEBSD_CC_VERSION should be = spaced apart leaving versions available between official version numbers = for such local activities without version identification conflicts. There are also projects such as the /project/clang*-import ones that = might have version number transition issues between it and CURRENT at = various stages for those working on the project and anyone that is just = following the project while it is active. I followed clang380-import and = reported on some powerpc64/powerpc/armv6 issues during the project so = I've been in this situation in the past. It is not clear to me what the right things would have been to do and = when to do it if this FREEBSD_CC_VERSION criteria had been in place at = the time. Similar comments probably apply to FBSD_CC_VER and gcc/g++. Is it as simple as "never use WITH_SYSTEM_COMPILER" for patch/update = explorations that are not yet official commits on CURRENT or STABLE? = Does the version number involved then matter? =3D=3D=3D Mark Millard markmi@dsl-only.net From owner-freebsd-toolchain@freebsd.org Mon May 23 21:50: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 8FCB4B47C7C; Mon, 23 May 2016 21:50:34 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 802F31A94; Mon, 23 May 2016 21:50:34 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 77A561CC3; Mon, 23 May 2016 21:50:34 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 2F8961CCCA; Mon, 23 May 2016 21:50:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id ysQLM3bvcZUd; Mon, 23 May 2016 21:50:31 +0000 (UTC) Subject: Re: WITH_SYSTEM_COMPILER: Skip Clang/GCC bootstrap [Critical note for Toolchain changes] DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 468471CCC1 To: Mark Millard , FreeBSD Current , FreeBSD Toolchain References: <986EF3DE-84DA-4867-AD94-384EA3733144@dsl-only.net> From: Bryan Drewery Organization: FreeBSD Message-ID: <0aa6b29d-100e-6b10-efb3-933200cb0119@FreeBSD.org> Date: Mon, 23 May 2016 14:50:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <986EF3DE-84DA-4867-AD94-384EA3733144@dsl-only.net> Content-Type: text/plain; charset=windows-1252 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: Mon, 23 May 2016 21:50:34 -0000 On 5/23/16 2:41 PM, Mark Millard wrote: > Relative to (Bryan Drewery Mon May 23 16:40:23 UTC 2016): > >> A critical note to toolchain developers, or anyone who touches the Clang >> or GCC source files. If you modify these files or add a new target >> architecture into Clang, please bump the revision in the appropriate file: >> >> Clang: lib/clang/include/clang/Basic/Version.inc FREEBSD_CC_VERSION >> GCC: gnu/usr.bin/cc/cc_tools/freebsd-native.h FBSD_CC_VER > > quoting from https://svnweb.freebsd.org/changeset/base/300354 : > >> This relies on the macros being incremented whenever any change occurs >> to these compilers that warrant rebuilding files. It also should never >> repeat earlier values. > > It appears that someone that tries to make or test clang patches without using a committer bit to be the one updating the official source will have trouble meeting this criteria. I've been in that situation in the past. Reverting back to, say, CURRENT after a patch is adopted is another example of version number progression problems. > If you are testing a local patch you can modify the files yourself as well. Or just set WITHOUT_SYSTEM_COMPILER. > It may be that official value updates to FREEBSD_CC_VERSION should be spaced apart leaving versions available between official version numbers for such local activities without version identification conflicts. > > There are also projects such as the /project/clang*-import ones that might have version number transition issues between it and CURRENT at various stages for those working on the project and anyone that is just following the project while it is active. I followed clang380-import and reported on some powerpc64/powerpc/armv6 issues during the project so I've been in this situation in the past. > For project branches they could just use some unique number or disable the option. > It is not clear to me what the right things would have been to do and when to do it if this FREEBSD_CC_VERSION criteria had been in place at the time. > > Similar comments probably apply to FBSD_CC_VER and gcc/g++. > > Is it as simple as "never use WITH_SYSTEM_COMPILER" for patch/update explorations that are not yet official commits on CURRENT or STABLE? Does the version number involved then matter? > > === > Mark Millard > markmi@dsl-only.net > -- Regards, Bryan Drewery From owner-freebsd-toolchain@freebsd.org Mon May 23 22:26:24 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 C5365B4778E for ; Mon, 23 May 2016 22:26:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-194.reflexion.net [208.70.211.194]) (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 8AD2E18D5 for ; Mon, 23 May 2016 22:26:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 6223 invoked from network); 23 May 2016 21:59:44 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 23 May 2016 21:59:44 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Mon, 23 May 2016 17:59:48 -0400 (EDT) Received: (qmail 21030 invoked from network); 23 May 2016 21:59:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 23 May 2016 21:59:47 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 17BED1C43D6; Mon, 23 May 2016 14:59:38 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: WITH_SYSTEM_COMPILER: Skip Clang/GCC bootstrap [Critical note for Toolchain changes] From: Mark Millard In-Reply-To: <0aa6b29d-100e-6b10-efb3-933200cb0119@FreeBSD.org> Date: Mon, 23 May 2016 14:59:41 -0700 Cc: FreeBSD Current , FreeBSD Toolchain Message-Id: <2600671A-777E-4C72-90F4-25F79C48D1FA@dsl-only.net> References: <986EF3DE-84DA-4867-AD94-384EA3733144@dsl-only.net> <0aa6b29d-100e-6b10-efb3-933200cb0119@FreeBSD.org> To: Bryan Drewery X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 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, 23 May 2016 22:26:24 -0000 On 2016-May-23, at 2:50 PM, Bryan Drewery = wrote: > On 5/23/16 2:41 PM, Mark Millard wrote: >> Relative to (Bryan Drewery Mon May 23 16:40:23 UTC 2016): >>=20 >>> A critical note to toolchain developers, or anyone who touches the = Clang >>> or GCC source files. If you modify these files or add a new target >>> architecture into Clang, please bump the revision in the appropriate = file: >>>=20 >>> Clang: lib/clang/include/clang/Basic/Version.inc FREEBSD_CC_VERSION >>> GCC: gnu/usr.bin/cc/cc_tools/freebsd-native.h FBSD_CC_VER >>=20 >> quoting from https://svnweb.freebsd.org/changeset/base/300354 : >>=20 >>> This relies on the macros being incremented whenever any change = occurs >>> to these compilers that warrant rebuilding files. It also should = never >>> repeat earlier values. >>=20 >> It appears that someone that tries to make or test clang patches = without using a committer bit to be the one updating the official source = will have trouble meeting this criteria. I've been in that situation in = the past. Reverting back to, say, CURRENT after a patch is adopted is = another example of version number progression problems. >>=20 >=20 > If you are testing a local patch you can modify the files yourself as > well. Or just set WITHOUT_SYSTEM_COMPILER. But what temporary private value assignment will only "increment" and = yet "never repeat repeat earlier values" once the temporary period is = over and official numbering again is in use? Looks to me like = WITHOUT_SYSTEM_COMPILER is required for such contexts. >> It may be that official value updates to FREEBSD_CC_VERSION should be = spaced apart leaving versions available between official version numbers = for such local activities without version identification conflicts. >>=20 >> There are also projects such as the /project/clang*-import ones that = might have version number transition issues between it and CURRENT at = various stages for those working on the project and anyone that is just = following the project while it is active. I followed clang380-import and = reported on some powerpc64/powerpc/armv6 issues during the project so = I've been in this situation in the past. >>=20 >=20 > For project branches they could just use some unique number or disable > the option. So in some contexts the "increment" and/or "never repeat repeat earlier = values" do not apply (including when a temporary local assignment goes = to no longer being in use)? It still looks to me like = WITHOUT_SYSTEM_COMPILER is required for such contexts. >> It is not clear to me what the right things would have been to do and = when to do it if this FREEBSD_CC_VERSION criteria had been in place at = the time. >>=20 >> Similar comments probably apply to FBSD_CC_VER and gcc/g++. >>=20 >> Is it as simple as "never use WITH_SYSTEM_COMPILER" for patch/update = explorations that are not yet official commits on CURRENT or STABLE? = Does the version number involved then matter? >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >=20 >=20 > --=20 > Regards, > Bryan Drewery =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed May 25 16:13:03 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 512F0B49B1A for ; Wed, 25 May 2016 16:13:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-194.reflexion.net [208.70.211.194]) (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 B05171C7D for ; Wed, 25 May 2016 16:13:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32761 invoked from network); 25 May 2016 16:12:50 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 May 2016 16:12:50 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Wed, 25 May 2016 12:12:59 -0400 (EDT) Received: (qmail 21872 invoked from network); 25 May 2016 16:12:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 May 2016 16:12:59 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7B4BC1C43DB; Wed, 25 May 2016 09:12:51 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT: lang/gcc, lang/gcc5, lang/gcc6-devel, lang/llvm38, etc. do not build on/for armv6 (now implicitly hard float) Date: Wed, 25 May 2016 09:12:53 -0700 Message-Id: <1E66E56C-E615-4180-A3F2-E8E48E26B6CD@dsl-only.net> Cc: FreeBSD Toolchain To: Gerald Pfeifer , Brooks Davis , freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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: Wed, 25 May 2016 16:13:03 -0000 I'm not sure that Gerald or Brooks were CC'd on a report made to the = arm list about armv6 builds of gcc and llvm being broken now because of = hard float now being implicit: (the first report listed below has more detail directly visible for gcc = examples) https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013931.html and: https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013930.html https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013932.html https://lists.freebsd.org/pipermail/freebsd-arm/2016-May/013933.html The first (013931.html) shows that xgcc for configure:3686 for contest.c = ends up with the likes of: /usr/local/bin/ld: error: a.out uses VFP register arguments, /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o does not /usr/local/bin/ld: failed to merge target specific data of file /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtbegin.o /usr/local/bin/ld: error: a.out uses VFP register arguments, /tmp//cchNL2QG.o does not /usr/local/bin/ld: failed to merge target specific data of file = /tmp//cchNL2QG.o /usr/local/bin/ld: error: a.out uses VFP register arguments, /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o does not /usr/local/bin/ld: failed to merge target specific data of file /wrkdirs/usr/ports/lang/gcc/work/.build/./gcc/crtend.o collect2: error: ld returned 1 exit status and points to gcc/config.gcc only having TARGET_FREEBSD_ARM_HARD_FLOAT=3D1= for arm*hf-*-freebsd* . But now armv6*-*-freebsd* is also hard float = for 11.0-CURRENT. Of course until everyone updates to modern enough armv6 context a mix of = softfloat and hardfloat will be around. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu May 26 17:59: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 3DC40B4B366 for ; Thu, 26 May 2016 17:59:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-192.reflexion.net [208.70.211.192]) (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 0251517E9 for ; Thu, 26 May 2016 17:59:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13707 invoked from network); 26 May 2016 17:00:26 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 26 May 2016 17:00:26 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 26 May 2016 13:00:31 -0400 (EDT) Received: (qmail 18503 invoked from network); 26 May 2016 17:00:31 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 26 May 2016 17:00:31 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2BF851C43E9; Thu, 26 May 2016 09:59:51 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: xorg broken on Beaglebone black revision 300438 [some armv7 instructions do not match new kernel code?] From: Mark Millard In-Reply-To: <1464130548.1204.25.camel@freebsd.org> Date: Thu, 26 May 2016 09:59:53 -0700 Cc: freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <1464127156.1204.10.camel@freebsd.org> <1464130548.1204.25.camel@freebsd.org> To: Ian Lepore 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, 26 May 2016 17:59:56 -0000 It may be that the following just means that more would have to be = described to be complete about the expectations for the usage-context = for the new alignment code in the kernel. But I ask anyway. It appears to me that the following code in the 11.0-CURRENT -r300701 = check in: > +#if __ARM_ARCH >=3D 6 > +#define _ALIGNBYTES (sizeof(int) - 1) > +#else > #define _ALIGNBYTES (sizeof(long long) - 1) > +#endif > #define _ALIGN(p) (((unsigned)(p) + _ALIGNBYTES) & = ~_ALIGNBYTES) and: > + * armv4 and v5 require alignment to the type's size. armv6 and = later require > + * that an 8-byte type be aligned to at least a 4-byte boundary; = access to > + * smaller types can be unaligned. > */ >=20 > +#if __ARM_ARCH >=3D 6 > +#define ALIGNED_POINTER(p, t) (((sizeof(t) !=3D 8) || = ((unsigned)(p) & 3) =3D=3D 0)) > +#else has the implicit assumption that some armv7 instructions will not be = used: those that violate the claimed and implicit alignment requirements = even for SCTRLR.A=3D0. The "ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition" = Table A3-1 "Alignment requirements of load/store instructions" has a = "SCTRL.A is 0" column that still lists various examples of "Alignment = fault" instead of "Unaligned access" for some instructions. Even = "Halfword" has a couple of instructions that still get "Alignment fault" = for armv7, not just 8 byte wide operations. The instructions showing "Alignment fault" under the "SCTLR.A is 0" = column are (or at least include): Halfword: LDREXH, STREXH Word: LDREX, STREX, all forms of "LDM, STM, PDRD, RFE, SRS, STRD, SWP", = PUSH (except for T3 and A2 encodings), POP (except for T3 and A2 = encodings), LDC, LDC12, STC, STC2, VLDM, VLDR, VPOP, VPUSH, VSTM, VSTR Doubleword: LRDEXD, STREXD : specified: VLD1, VLD2, VLD3, VLD4, VST1, VST2, VST3, VST4 Is the updated FreeBSD kernel supporting armv7 making the requirement = that none of these be used? (Thus clang and gcc would need to never add = use of them under FreeBSD-allowed compiler options.) The specific potential mismatches that I noticed are: (Below I'll use "Halfword" and the like as if they were C/C++ type names = directly.) Expanding the definition for ALIGNED_POINTER(p,Halfword) is: (sizeof(Halfword) !=3D 8) || ((unsigned)(p) & 3) =3D=3D 0) which evaluates to TRUE even for odd addresses used in LDREXH and STREXH = instructions. Yet such would get the "Alignment fault" under "SCTLR.A is = 0". A similar point goes for ALIGNED_POINTER(p,Word) and its list of = instructions showing "Alignment fault" under "SCTLR.A is 0". Presuming sizeof(int)=3D=3D4: _ALIGNBYTES =3D=3D (sizeof(int) - 1) and = in turn (sizeof(int) - 1) =3D=3D 3. Presuming also: sizeof(Doubleword) =3D=3D 8 . Then expanding _ALIGN(p) gives: ((unsigned)(p)+3) & ~3) but for sizeof(*p)=3D=3D8 the result can be an odd multiple of 4 which = would get an "Alignment fault" under "SCTLR.A is 0" for LRDEXD and/or = STREXD instructions. (I've not worded the above to be explicit about : (or @) = notation use that would have similar issues.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-May-24, at 3:55 PM, Ian Lepore wrote: On Tue, 2016-05-24 at 15:19 -0700, Mark Millard wrote: > On 2016-May-24, at 2:59 PM, Ian Lepore wrote: >=20 >> On Tue, 2016-05-24 at 14:35 -0700, Mark Millard wrote: >>> Quoting from Otac=EDlio Tue May 24 00:06:10 UTC 2016 and its locore >>> -v6.S changes: >>>=20 >>>> - orr r7, #CPU_CONTROL_UNAL_ENABLE >>>> - orr r7, #CPU_CONTROL_AFLT_ENABLE >>>> + bic r7, #CPU_CONTROL_UNAL_ENABLE >>>> + bic r7, #CPU_CONTROL_AFLT_ENABLE >>>=20 >>> -r295256 (2016-Feb-14) changed from: >>>=20 >>> bic r7, #CPU_CONTROL_UNAL_ENABLE >>>=20 >>> to: >>>=20 >>> orr r7, #CPU_CONTROL_UNAL_ENABLE >>>=20 >>> in two places (moving it a few lines down for each example as >>> well). >>> So this much of the proposed changes would be reverting the=20 >>> -r295256 >>> change. The check in comment indicates the bit is RAO/SBOP for >>> armv7. >>> For armv6 the check in comment claims it controls armv5 >>> compatible >>> alignment support. >>>=20 >>> But: >>>=20 >>> orr r7, #CPU_CONTROL_AFLT_ENABLE >>>=20 >>> has been in locore-v6.S since the file's first checkin. So this >>> change to bic here be new. >>>=20 >>> What is the FreeBSD intent for each of the two new settings for >>> armv7? armv6? >>>=20 >>=20 >> It was always wrong to clear CPU_CONTROL_UNAL_ENABLE on armv7 (it's >> documented as RAO/SBOP). Setting it on armv6 makes the v6 (which >> is >> only the RPi in our world) behave the same as v7. So that change >> was >> just a bugfix. >>=20 >> I think FreeBSD is the only major OS left that is enforcing strict >> alignment on armv6/v7 and it causes a lot of trouble for ports and >> other 3rd party software, and prevents us from enabling certain >> compiler options and optimizations. I'm very close to a commit to >> stop >> enforcing strict alignment (clear rather than >> CPU_CONTROL_AFLT_ENABLE). >> I've been testing it yesterday and today, and haven't run into any >> trouble at all. >>=20 >> -- Ian >=20 > Good to know. I had submitted at least one port bug report that will > likely need to be canceled if this goes through. Effectively its an > ABI change allowing a wider variety of code to be compliant. >=20 It was partly all that testing you did a few months ago, and the PRs and discussions coming out of that, which are driving these changes.=20 If I could get away with procrastinating a bit more, I probably would (always too busy), but with the big hardfloat abi change and with a code freeze coming up later this week, this seems like the last chance to do some disruptive changes that are long overdue. > Is the kernel involved in emulating access/instructions via some > technique for misaligned access for armv6/armv7 for some types of > instructions? Are there performance issues/tradeoffs that might > contribute to sometimes choosing to be careful about alignment? >=20 Nope, no emulation, the hardware is able to do this, we've just always run with alignment faults enabled, partly because base freebsd already has to work on other strict-alignment hardware anyway. The driver of this change is ports more than anything -- increasingly you run into code that assumes #ifdef __arm__ is sufficient to mean "unaligned access will work". There are a few arm instructions that still require alignment, but (at least in theory) the compiler knows about that and only emits those instructions when it knows they're safe (such as it knowing that the stack stays aligned to 8-byte boundaries in non-leaf functions). We'll see; everything seems okay in testing I've done so far. Performance-wise, there is a cost for unaligned access. The hardware has to do more work so unaligned accesses take extra cycles. On the other hand, if the data is unaligned, you also have to use extra cycles, potentially a lot of them, to copy-align the data or access it a byte at a time and reassmble it in a register. In theory this should be faster than doing copy-align stuff. -- Ian > In one way I liked the strict alignment environment being around: It > allowed easily testing if software was more portable for such issues > vs. not. (Not that FreeBSD should use such criteria for its choices.) >=20 From owner-freebsd-toolchain@freebsd.org Thu May 26 18:46:24 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 D38F6B4B059 for ; Thu, 26 May 2016 18:46:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-170.reflexion.net [208.70.211.170]) (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 96FC41DA7 for ; Thu, 26 May 2016 18:46:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29627 invoked from network); 26 May 2016 18:46:52 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 26 May 2016 18:46:52 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 26 May 2016 14:46:25 -0400 (EDT) Received: (qmail 30263 invoked from network); 26 May 2016 18:46:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 26 May 2016 18:46:25 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B694EB1E001; Thu, 26 May 2016 11:46:16 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: xorg broken on Beaglebone black revision 300438 [some armv7 instructions do not match new kernel code?] From: Mark Millard In-Reply-To: Date: Thu, 26 May 2016 11:46:19 -0700 Cc: freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <1464127156.1204.10.camel@freebsd.org> <1464130548.1204.25.camel@freebsd.org> To: Ian Lepore 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, 26 May 2016 18:46:24 -0000 [I'm just fixing some typos that I've noticed and adding a couple of = short notes for ease of interpretation.] On 2016-May-26, at 9:59 AM, Mark Millard wrote: > It may be that the following just means that more would have to be = described to be complete about the expectations for the usage-context = for the new alignment code in the kernel. But I ask anyway. >=20 > It appears to me that the following code in the 11.0-CURRENT -r300701 = check in: >=20 >> +#if __ARM_ARCH >=3D 6 >> +#define _ALIGNBYTES (sizeof(int) - 1) >> +#else >> #define _ALIGNBYTES (sizeof(long long) - 1) >> +#endif >> #define _ALIGN(p) (((unsigned)(p) + _ALIGNBYTES) & = ~_ALIGNBYTES) >=20 > and: >=20 >> + * armv4 and v5 require alignment to the type's size. armv6 and = later require >> + * that an 8-byte type be aligned to at least a 4-byte boundary; = access to >> + * smaller types can be unaligned. >> */ >>=20 >> +#if __ARM_ARCH >=3D 6 >> +#define ALIGNED_POINTER(p, t) (((sizeof(t) !=3D 8) || = ((unsigned)(p) & 3) =3D=3D 0)) >> +#else >=20 >=20 > has the implicit assumption that some armv7 instructions will not be = used: those that violate the claimed and implicit alignment requirements = even for SCTRLR.A=3D0. >=20 > The "ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition" = Table A3-1 "Alignment requirements of load/store instructions" has a = "SCTRL.A is 0" column that still lists various examples of "Alignment = fault" instead of "Unaligned access" for some instructions. Even = "Halfword" has a couple of instructions that still get "Alignment fault" = for armv7, not just 8 byte wide operations. >=20 > The instructions showing "Alignment fault" under the "SCTLR.A is 0" = column are (or at least include): The sizes below, such as Halfword, are the "Alignment check" sizes = listed in Table A3-1. The "SCTRL.A is 0" columns lists "Result if check = fails when" SCTRL.A is 0. > Halfword: LDREXH, STREXH >=20 > Word: LDREX, STREX, all forms of "LDM, STM, PDRD, RFE, SRS, STRD, = SWP", PUSH (except for T3 and A2 encodings), POP (except for T3 and A2 = encodings), LDC, LDC12, STC, STC2, VLDM, VLDR, VPOP, VPUSH, VSTM, VSTR >=20 > Doubleword: LRDEXD, STREXD LDREXD (not LRD. . .). > : specified: VLD1, VLD2, VLD3, VLD4, VST1, VST2, VST3, VST4 >=20 >=20 > Is the updated FreeBSD kernel supporting armv7 making the requirement = that none of these be used? (Thus clang and gcc would need to never add = use of them under FreeBSD-allowed compiler options.) >=20 >=20 > The specific potential mismatches that I noticed are: >=20 > (Below I'll use "Halfword" and the like as if they were C/C++ type = names directly.) >=20 > Expanding the definition for ALIGNED_POINTER(p,Halfword) is: >=20 > (sizeof(Halfword) !=3D 8) || ((unsigned)(p) & 3) =3D=3D 0) >=20 > which evaluates to TRUE even for odd addresses used in LDREXH and = STREXH instructions. Yet such would get the "Alignment fault" under = "SCTLR.A is 0". >=20 > A similar point goes for ALIGNED_POINTER(p,Word) and its list of = instructions showing "Alignment fault" under "SCTLR.A is 0". For the ALIGNED_POINTER(p,Doubleword) I instead just listed the = _ALIGN(p) form of the issue below. The ALIGNED_POINTER(p,Doubleword) = evaluates to TRUE in cases where two instructions would get an = "Alignment fault" under "SCTLR.A is 0". See below. > Presuming sizeof(int)=3D=3D4: _ALIGNBYTES =3D=3D (sizeof(int) - 1) and = in turn (sizeof(int) - 1) =3D=3D 3. > Presuming also: sizeof(Doubleword) =3D=3D 8 . >=20 > Then expanding _ALIGN(p) gives: >=20 > ((unsigned)(p)+3) & ~3) >=20 > but for sizeof(*p)=3D=3D8 the result can be an odd multiple of 4 which = would get an "Alignment fault" under "SCTLR.A is 0" for LRDEXD and/or = STREXD instructions. LDREXD (not LRD. . .). > (I've not worded the above to be explicit about : (or @) = notation use that would have similar issues.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-May-24, at 3:55 PM, Ian Lepore wrote: On Tue, 2016-05-24 at 15:19 -0700, Mark Millard wrote: > On 2016-May-24, at 2:59 PM, Ian Lepore wrote: >=20 >> On Tue, 2016-05-24 at 14:35 -0700, Mark Millard wrote: >>> Quoting from Otac=EDlio Tue May 24 00:06:10 UTC 2016 and its locore >>> -v6.S changes: >>>=20 >>>> - orr r7, #CPU_CONTROL_UNAL_ENABLE >>>> - orr r7, #CPU_CONTROL_AFLT_ENABLE >>>> + bic r7, #CPU_CONTROL_UNAL_ENABLE >>>> + bic r7, #CPU_CONTROL_AFLT_ENABLE >>>=20 >>> -r295256 (2016-Feb-14) changed from: >>>=20 >>> bic r7, #CPU_CONTROL_UNAL_ENABLE >>>=20 >>> to: >>>=20 >>> orr r7, #CPU_CONTROL_UNAL_ENABLE >>>=20 >>> in two places (moving it a few lines down for each example as >>> well). >>> So this much of the proposed changes would be reverting the=20 >>> -r295256 >>> change. The check in comment indicates the bit is RAO/SBOP for >>> armv7. >>> For armv6 the check in comment claims it controls armv5 >>> compatible >>> alignment support. >>>=20 >>> But: >>>=20 >>> orr r7, #CPU_CONTROL_AFLT_ENABLE >>>=20 >>> has been in locore-v6.S since the file's first checkin. So this >>> change to bic here be new. >>>=20 >>> What is the FreeBSD intent for each of the two new settings for >>> armv7? armv6? >>>=20 >>=20 >> It was always wrong to clear CPU_CONTROL_UNAL_ENABLE on armv7 (it's >> documented as RAO/SBOP). Setting it on armv6 makes the v6 (which >> is >> only the RPi in our world) behave the same as v7. So that change >> was >> just a bugfix. >>=20 >> I think FreeBSD is the only major OS left that is enforcing strict >> alignment on armv6/v7 and it causes a lot of trouble for ports and >> other 3rd party software, and prevents us from enabling certain >> compiler options and optimizations. I'm very close to a commit to >> stop >> enforcing strict alignment (clear rather than >> CPU_CONTROL_AFLT_ENABLE). >> I've been testing it yesterday and today, and haven't run into any >> trouble at all. >>=20 >> -- Ian >=20 > Good to know. I had submitted at least one port bug report that will > likely need to be canceled if this goes through. Effectively its an > ABI change allowing a wider variety of code to be compliant. >=20 It was partly all that testing you did a few months ago, and the PRs and discussions coming out of that, which are driving these changes.=20 If I could get away with procrastinating a bit more, I probably would (always too busy), but with the big hardfloat abi change and with a code freeze coming up later this week, this seems like the last chance to do some disruptive changes that are long overdue. > Is the kernel involved in emulating access/instructions via some > technique for misaligned access for armv6/armv7 for some types of > instructions? Are there performance issues/tradeoffs that might > contribute to sometimes choosing to be careful about alignment? >=20 Nope, no emulation, the hardware is able to do this, we've just always run with alignment faults enabled, partly because base freebsd already has to work on other strict-alignment hardware anyway. The driver of this change is ports more than anything -- increasingly you run into code that assumes #ifdef __arm__ is sufficient to mean "unaligned access will work". There are a few arm instructions that still require alignment, but (at least in theory) the compiler knows about that and only emits those instructions when it knows they're safe (such as it knowing that the stack stays aligned to 8-byte boundaries in non-leaf functions). We'll see; everything seems okay in testing I've done so far. Performance-wise, there is a cost for unaligned access. The hardware has to do more work so unaligned accesses take extra cycles. On the other hand, if the data is unaligned, you also have to use extra cycles, potentially a lot of them, to copy-align the data or access it a byte at a time and reassmble it in a register. In theory this should be faster than doing copy-align stuff. -- Ian > In one way I liked the strict alignment environment being around: It > allowed easily testing if software was more portable for such issues > vs. not. (Not that FreeBSD should use such criteria for its choices.) >=20 From owner-freebsd-toolchain@freebsd.org Thu May 26 22:10:13 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 B1885B4CC5C for ; Thu, 26 May 2016 22:10:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-172.reflexion.net [208.70.211.172]) (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 658851FA4 for ; Thu, 26 May 2016 22:10:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11117 invoked from network); 26 May 2016 22:03:23 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 26 May 2016 22:03:23 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 26 May 2016 18:03:32 -0400 (EDT) Received: (qmail 8767 invoked from network); 26 May 2016 22:03:32 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 26 May 2016 22:03:32 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id CFFF61C43D6; Thu, 26 May 2016 15:03:22 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses] Date: Thu, 26 May 2016 15:03:26 -0700 Message-Id: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> Cc: freebsd-arm , FreeBSD Toolchain , mandree@FreeBSD.org To: freebsd-sparc64@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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, 26 May 2016 22:10:13 -0000 Is is safe to interpret that an rpi2 armv7/cortex-a7 unaligned access = failure [from before -r300694] would (likely?) also be a failure on some = forms of FreeBSD SPARC use? Why I ask: One of the ports that I had submitted a bug report for unaligned access = problems on a rpi2 (armv7-a/cortex-a7 style handling) was: archivers/lzo2 ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207096 ). I'd = recently commented that the report might go away after testing what is = now -r300694 (allowing more unaligned access on, for example, = armv7-a/cortex-a7). Matthias Andree has since asked in a comment: > ISTR SPARC architectures also barf on unaligned access, so is it worth = bothering the upstream author? I have generally stuck to architectures for which I have examples to = observe, if nothing else than to validate at least some of my = understanding that is from reading materials. I normally only submit = what I've observed in some form. I've no such SPARC context nor do I have knowledge/reference material = for SPARCs. Nor am I familiar with the choices FreeBSD may have made for = SPARC configuration coverage. As a matter of hear-say my impression is that some SPARCs can be = configured to require some variation of strict alignment. But I do not know how much I can infer from what I observed on a rpi2 = (armv7-a/cortex-a7) to FreeBSD SPARC use getting similar results for at = least come configurations. Nor do I have access to a test environment = for SPARC. So I wonder if my archivers/lzo2 submittal in question should survive = because of SPARC even if the problem is validated to go away for the = updated rpi2 like contexts (with armv7-a/cortex-a7 tailoring possibly = involved). I have some other submittals that might face the same type of = question. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu May 26 23:53:15 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 663DEB48DDB for ; Thu, 26 May 2016 23:53:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-171.reflexion.net [208.70.211.171]) (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 2B23E182A for ; Thu, 26 May 2016 23:53:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24921 invoked from network); 26 May 2016 23:53:09 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 May 2016 23:53:09 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 26 May 2016 19:53:06 -0400 (EDT) Received: (qmail 1394 invoked from network); 26 May 2016 23:53:05 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 26 May 2016 23:53:05 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A37B71C43E9; Thu, 26 May 2016 16:53:02 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 11.0-CURRENT -r300770 libc++ update vs. lang/powerpc64-xtoolchain-gcc: no go [self hosted powerpc64 context] Date: Thu, 26 May 2016 16:53:07 -0700 Message-Id: <95E2A9D6-8E1A-46FB-84FF-60927A6F1CE4@dsl-only.net> Cc: freebsd-ports@freebsd.org To: FreeBSD Toolchain , FreeBSD PowerPC ML , dim@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) 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, 26 May 2016 23:53:15 -0000 I do buildworld/buildkernel on a powerpc64 targeting itself via = lang/powerpc64-xtoolchain-gcc (a.k.a. lang/powerpc64-gcc for the most = part). [Getting that lang/powerpc64-gcc installed for self-hosted use = does take some work-around activity.] I have buildworld build clang (but = not use it). [I've been doing this with 11.0-CURRENT for a long time.] Actually I use lang/gcc49 as the "system compiler" and = lang/powerpc64-gcc as the self-hosting so-called "cross compiler". (I = later list the src.conf content.) gcc4.2.1 is not installed. Trying to go from: > # uname -apKU > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #36 r300531M: Mon = May 23 20:13:52 PDT 2016 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc powerpc64 1100111 1100111 (for which -r300531 built and installed fine this way) to -r300777 now = fails with errors such as: > --- lib/libc++__L --- > In file included from = /usr/src/lib/libc++/../../contrib/libc++/include/iterator:346:0, > from = /usr/src/lib/libc++/../../contrib/libc++/include/memory:606, > from = /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:628, > from = /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10: > /usr/src/lib/libc++/../../contrib/libc++/include/iosfwd:176:14: error: = 'mbstate_t' was not declared in this scope > typedef fpos streampos; > ^ > /usr/src/lib/libc++/../../contrib/libc++/include/iosfwd:176:23: error: = template argument 1 is invalid > typedef fpos streampos; > ^ > /usr/src/lib/libc++/../../contrib/libc++/include/iosfwd:177:14: error: = 'mbstate_t' was not declared in this scope > typedef fpos wstreampos; > ^ > /usr/src/lib/libc++/../../contrib/libc++/include/iosfwd:177:23: error: = template argument 1 is invalid > typedef fpos wstreampos; > ^ > /usr/src/lib/libc++/../../contrib/libc++/include/iosfwd:179:14: error: = 'mbstate_t' was not declared in this scope > typedef fpos u16streampos; > ^ > /usr/src/lib/libc++/../../contrib/libc++/include/iosfwd:179:23: error: = template argument 1 is invalid > typedef fpos u16streampos; > ^ > /usr/src/lib/libc++/../../contrib/libc++/include/iosfwd:180:14: error: = 'mbstate_t' was not declared in this scope > typedef fpos u32streampos; > ^ > /usr/src/lib/libc++/../../contrib/libc++/include/iosfwd:180:23: error: = template argument 1 is invalid > typedef fpos u32streampos; > ^ . . . > --- lib/libc++__L --- > In file included from = /usr/src/lib/libc++/../../contrib/libc++/include/cmath:301:0, > from = /usr/src/lib/libc++/../../contrib/libc++/include/random:1638, > from = /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:11: > /usr/src/lib/libc++/../../contrib/libc++/include/math.h: In function = 'float abs(float)': > /usr/src/lib/libc++/../../contrib/libc++/include/math.h:646:53: error: = 'fabsf' was not declared in this scope > abs(float __lcpp_x) _NOEXCEPT {return fabsf(__lcpp_x);} > ^ > /usr/src/lib/libc++/../../contrib/libc++/include/math.h: In function = 'double abs(double)': > /usr/src/lib/libc++/../../contrib/libc++/include/math.h:650:53: error: = 'fabs' was not declared in this scope > abs(double __lcpp_x) _NOEXCEPT {return fabs(__lcpp_x);} > ^ . . . > --- lib/libc++__L --- > /usr/src/lib/libc++/../../contrib/libc++/include/math.h: In function = 'long double abs(long double)': > /usr/src/lib/libc++/../../contrib/libc++/include/math.h:654:59: error: = 'fabsl' was not declared in this scope > abs(long double __lcpp_x) _NOEXCEPT {return fabsl(__lcpp_x);} > ^ > /usr/src/lib/libc++/../../contrib/libc++/include/math.h: In function = 'float acos(float)': > /usr/src/lib/libc++/../../contrib/libc++/include/math.h:660:105: = error: 'acosf' was not declared in this scope > inline _LIBCPP_INLINE_VISIBILITY float acos(float __lcpp_x) = _NOEXCEPT {return acosf(__lcpp_x);} > = ^ > /usr/src/lib/libc++/../../contrib/libc++/include/math.h: In function = 'long double acos(long double)': > /usr/src/lib/libc++/../../contrib/libc++/include/math.h:661:105: = error: 'acosl' was not declared in this scope > inline _LIBCPP_INLINE_VISIBILITY long double acos(long double = __lcpp_x) _NOEXCEPT {return acosl(__lcpp_x);} > = ^ > /usr/src/lib/libc++/../../contrib/libc++/include/math.h: In function = 'typename std::__1::enable_if::value, = double>::type acos(_A1)': > /usr/src/lib/libc++/../../contrib/libc++/include/math.h:667:59: error: = call of overloaded 'acos(double)' is ambiguous > acos(_A1 __lcpp_x) _NOEXCEPT {return acos((double)__lcpp_x);} > ^ > /usr/src/lib/libc++/../../contrib/libc++/include/math.h:660:46: note: = candidate: float acos(float) > inline _LIBCPP_INLINE_VISIBILITY float acos(float __lcpp_x) = _NOEXCEPT {return acosf(__lcpp_x);} > ^ > /usr/src/lib/libc++/../../contrib/libc++/include/math.h:661:46: note: = candidate: long double acos(long double) > inline _LIBCPP_INLINE_VISIBILITY long double acos(long double = __lcpp_x) _NOEXCEPT {return acosl(__lcpp_x);} > ^ > /usr/src/lib/libc++/../../contrib/libc++/include/math.h: In function = 'float asin(float)': > /usr/src/lib/libc++/../../contrib/libc++/include/math.h:672:105: = error: 'asinf' was not declared in this scope > inline _LIBCPP_INLINE_VISIBILITY float asin(float __lcpp_x) = _NOEXCEPT {return asinf(__lcpp_x);} > = ^ > /usr/src/lib/libc++/../../contrib/libc++/include/math.h: In function = 'long double asin(long double)': > /usr/src/lib/libc++/../../contrib/libc++/include/math.h:673:105: = error: 'asinl' was not declared in this scope > inline _LIBCPP_INLINE_VISIBILITY long double asin(long double = __lcpp_x) _NOEXCEPT {return asinl(__lcpp_x);} > = ^ . . . > --- lib/libc++__L --- > /usr/src/lib/libc++/../../contrib/libc++/include/math.h:673:46: note: = candidate: long double asin(long double) > inline _LIBCPP_INLINE_VISIBILITY long double asin(long double = __lcpp_x) _NOEXCEPT {return asinl(__lcpp_x);} > ^ . . . I'll not list it all: There is a lot. Supporting details: An example of the include paths in use (from -v) is: > --- lib/libc++__L --- > #include "..." search starts here: > #include <...> search starts here: > /usr/src/lib/libc++/../../contrib/libc++/include > /usr/src/lib/libc++/../../contrib/libcxxrt > /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1 > /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include > /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include > /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed > End of search list. # more ~/src.configs/make.conf=20 CFLAGS.gcc+=3D -v # more ~/src.configs/src.conf.powerpc64-xtoolchain.powerpc64-host=20 TO_TYPE=3Dpowerpc64 TOOLS_TO_TYPE=3D${TO_TYPE} FROM_TYPE=3Dpowerpc64 TOOLS_FROM_TYPE=3D${FROM_TYPE} VERSION_CONTEXT=3D11.0 # KERNCONF=3DGENERIC64vtsc-NODEBUG TARGET=3Dpowerpc .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITH_BOOT=3D #WITH_LIB32=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_LLDB=3D # # powerpc64 LIB32 builds via gcc 4.9 or later variants that I've tried # but the LIB32 does not work [crtbeginS code problem(s)] WITHOUT_LIB32=3D WITHOUT_GCC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D #CFLAGS+=3D -DELF_VERBOSE # WITH_DEBUG_FILES=3D # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related bintutils. . = . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc= c = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g= ++ = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-c= pp .export XCC .export XCXX .export XCPP XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # For FROM (host) stages . . . # =46rom gccXY (such as gcc49 but not xtoolchain) # TOOLS_FROM_TYPE's appropriate binutils. . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3Denv C_INCLUDE_PATH=3D/usr/include /usr/local/bin/gcc49 -L/usr/lib CXX=3Denv C_INCLUDE_PATH=3D/usr/include = CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++49 -std=3Dc++11= -nostdinc++ -L/usr/lib CPP=3D/usr/local/bin/cpp49 .export CC .export CXX .export CPP = AS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= s = AR=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/a= r = LD=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/l= d = NM=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/n= m = OBJCOPY=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objcopy = OBJDUMP=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/objdump = RANLIB=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/b= in/ranlib = SIZE=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin= /size #NO-SUCH: = STRINGS=3D/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/= bin/strings STRINGS=3D/usr/local/bin/strings .export AS .export AR .export LD .export NM .export OBJCOPY .export OBJDUMP .export RANLIB .export SIZE .export STRINGS .endif # svnlite info /usr/src/ Path: /usr/src Working Copy Root Path: /usr/src URL: https://svn0.us-west.freebsd.org/base/head Relative URL: ^/head Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 300777 Node Kind: directory Schedule: normal Last Changed Author: manu Last Changed Rev: 300777 Last Changed Date: 2016-05-26 14:09:07 -0700 (Thu, 26 May 2016) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri May 27 03:21: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 DBF7EB4C16F; Fri, 27 May 2016 03:21:35 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC1031679; Fri, 27 May 2016 03:21:35 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: by mail-pa0-x22b.google.com with SMTP id bz2so6068294pad.1; Thu, 26 May 2016 20:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=dkWu8SyHWKW0ZPWcskkPm00TWK2Cs6wAUUvMjRCtKkM=; b=RbElxn1pCnRaRLhOwMkUNklzSzViq2spBYg892WQP8F2bSBg2WmVhDlhYPKA07QPM8 c8CFvwYmtb6GGg56DBdPpAUoNIQir0QlNGA7rDw5NX8bjNFSIugJSlVBV3O33SSsP0tE hyniL55uh5EhoJkkAS38zl4a0uKZw1l+POQSneNxfNwTI9MM0zch3eX+3qny4suzH9iQ c45HUuhfzvoDuRwJWMjkIixKweVjSYhTprMAscUZGC6rYO9KvXaOWcSFjVpiiDCIt6AJ fsxliFYR8b401Eq0wqq2sn694gFUMRL+mV8snWzPvyB49i5OnpADs2F5F3XeaMgzSAQd fopw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=dkWu8SyHWKW0ZPWcskkPm00TWK2Cs6wAUUvMjRCtKkM=; b=QU2dLTOta2v6gUhvXMSV/+R05U0JPNM+VYPRgZv7qyydaFZ0tLntFRoiOrPdDi+mXF +cM9zu3DxpcD6z3H6muH1DOTA6cb7zgxcON3dDx7+rKqwzP8cD8v9j8KxWvgOOR6U2kO XlwZiq1KUrLdeyMigS4kT3TavykIbdMb0gRoiZp/FFFXHjBvIU2qOK3jK2iVE9Dk4EEL OiAtdegZQCEXOvHerTRVr64dFHn1Te2ePCeH0MyxkOh3HotpXxBa1hDP+Lbv29ZfNAyC YLlcNmnpISMJuTO2cNagN9dk00zSs0R1dw4LI+L7DbUCDbO5ZztOZFLI+WMGwatzWB6J enIw== X-Gm-Message-State: ALyK8tL55qa8VO2gV4dxoZHHCBMB4Ye/mlFZ076or4X6ukePdOjpIxNpLmEPBAqqFOxaACjroeodIVxGNVODpQ== MIME-Version: 1.0 X-Received: by 10.66.26.165 with SMTP id m5mr18269601pag.155.1464319295224; Thu, 26 May 2016 20:21:35 -0700 (PDT) Received: by 10.66.183.232 with HTTP; Thu, 26 May 2016 20:21:35 -0700 (PDT) In-Reply-To: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> Date: Fri, 27 May 2016 05:21:35 +0200 Message-ID: Subject: Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses] From: Cedric Blancher To: Mark Millard Cc: freebsd-sparc64@freebsd.org, freebsd-arm , FreeBSD Toolchain , mandree@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 27 May 2016 03:21:36 -0000 All pure RISC implementations enforce 'natural alignment' - a 32bit data type must be aligned 32bit, i.e. 4 bytes, a 64bit data type must be 8 byte aligned, a 128bit data type must be 16 byte aligned. Some RISC implementations are not pure, but still the misalignment comes with a (performance) penalty, either by issuing two loads or running through a whole trap handler (!!!!) function with hundreds of instructions. Ced On 27 May 2016 at 00:03, Mark Millard wrote: > Is is safe to interpret that an rpi2 armv7/cortex-a7 unaligned access fai= lure [from before -r300694] would (likely?) also be a failure on some forms= of FreeBSD SPARC use? > > > Why I ask: > > One of the ports that I had submitted a bug report for unaligned access p= roblems on a rpi2 (armv7-a/cortex-a7 style handling) was: > > archivers/lzo2 > > ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207096 ). I'd recen= tly commented that the report might go away after testing what is now -r300= 694 (allowing more unaligned access on, for example, armv7-a/cortex-a7). > > Matthias Andree has since asked in a comment: > >> ISTR SPARC architectures also barf on unaligned access, so is it worth b= othering the upstream author? > > I have generally stuck to architectures for which I have examples to obse= rve, if nothing else than to validate at least some of my understanding tha= t is from reading materials. I normally only submit what I've observed in s= ome form. > > I've no such SPARC context nor do I have knowledge/reference material for= SPARCs. Nor am I familiar with the choices FreeBSD may have made for SPARC= configuration coverage. > > As a matter of hear-say my impression is that some SPARCs can be configur= ed to require some variation of strict alignment. > > But I do not know how much I can infer from what I observed on a rpi2 (ar= mv7-a/cortex-a7) to FreeBSD SPARC use getting similar results for at least = come configurations. Nor do I have access to a test environment for SPARC. > > So I wonder if my archivers/lzo2 submittal in question should survive bec= ause of SPARC even if the problem is validated to go away for the updated r= pi2 like contexts (with armv7-a/cortex-a7 tailoring possibly involved). I h= ave some other submittals that might face the same type of question. > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org= " --=20 Cedric Blancher Institute Pasteur From owner-freebsd-toolchain@freebsd.org Fri May 27 03:59:04 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 D95BBB4C893 for ; Fri, 27 May 2016 03:59:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-171.reflexion.net [208.70.211.171]) (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 9DE631A33 for ; Fri, 27 May 2016 03:59:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16825 invoked from network); 27 May 2016 03:59:32 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 27 May 2016 03:59:32 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Thu, 26 May 2016 23:59:40 -0400 (EDT) Received: (qmail 31337 invoked from network); 27 May 2016 03:59:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 27 May 2016 03:59:39 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3D9151C43E9; Thu, 26 May 2016 20:58:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses] From: Mark Millard In-Reply-To: Date: Thu, 26 May 2016 20:59:01 -0700 Cc: freebsd-sparc64@freebsd.org, freebsd-arm , FreeBSD Toolchain , mandree@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> To: Cedric Blancher 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: Fri, 27 May 2016 03:59:05 -0000 On 2016-May-26, at 8:21 PM, Cedric Blancher = wrote: > All pure RISC implementations enforce 'natural alignment' - a 32bit > data type must be aligned 32bit, i.e. 4 bytes, a 64bit data type must > be 8 byte aligned, a 128bit data type must be 16 byte aligned. > Some RISC implementations are not pure, but still the misalignment > comes with a (performance) penalty, either by issuing two loads or > running through a whole trap handler (!!!!) function with hundreds of > instructions. >=20 > Ced Thanks for the notes. Having once worked in a "micros" group in a logic analyzer product line = for many years, working on the software tools that were used for that = subject area, I'm very familiar with that general structure of = alternatives --but not with SPARC specifics. In your terminology: I've = no clue how pure of a RISC implementation is involved for any SPARC = variation. I'm looking for SPARC-specific information that suggests if the defect = report originally for armv7-a/cortex-a7 as FreeBSD formerly configured = things instead also likely applies to some SPARC variation/configuration = that FreeBSD supports. (See later below.) If FreeBSD has some other fairly strict alignment context that is not a = SPARC that might also serve. Unless upstream can be told that some specific FreeBSD variant is = unsupported by their software because of presuming unaligned access is = okay, I doubt that a report to upstream should be made based on FreeBSD = as a context. (This presumes that the port passes a test under the new = armv7-a/cortex-a7 and related alignment requirements. I'm not to that = point yet.) > On 27 May 2016 at 00:03, Mark Millard wrote: >> Is is safe to interpret that an rpi2 armv7/cortex-a7 unaligned access = failure [from before -r300694] would (likely?) also be a failure on some = forms of FreeBSD SPARC use? >>=20 >>=20 >> Why I ask: >>=20 >> One of the ports that I had submitted a bug report for unaligned = access problems on a rpi2 (armv7-a/cortex-a7 style handling) was: >>=20 >> archivers/lzo2 >>=20 >> ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207096 ). I'd = recently commented that the report might go away after testing what is = now -r300694 (allowing more unaligned access on, for example, = armv7-a/cortex-a7). >>=20 >> Matthias Andree has since asked in a comment: >>=20 >>> ISTR SPARC architectures also barf on unaligned access, so is it = worth bothering the upstream author? >>=20 >> I have generally stuck to architectures for which I have examples to = observe, if nothing else than to validate at least some of my = understanding that is from reading materials. I normally only submit = what I've observed in some form. >>=20 >> I've no such SPARC context nor do I have knowledge/reference material = for SPARCs. Nor am I familiar with the choices FreeBSD may have made for = SPARC configuration coverage. >>=20 >> As a matter of hear-say my impression is that some SPARCs can be = configured to require some variation of strict alignment. >>=20 >> But I do not know how much I can infer from what I observed on a rpi2 = (armv7-a/cortex-a7) to FreeBSD SPARC use getting similar results for at = least come configurations. Nor do I have access to a test environment = for SPARC. >>=20 >> So I wonder if my archivers/lzo2 submittal in question should survive = because of SPARC even if the problem is validated to go away for the = updated rpi2 like contexts (with armv7-a/cortex-a7 tailoring possibly = involved). I have some other submittals that might face the same type of = question. >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-sparc64@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 >> To unsubscribe, send any mail to = "freebsd-sparc64-unsubscribe@freebsd.org" >=20 >=20 >=20 > --=20 > Cedric Blancher > Institute Pasteur =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri May 27 04:14:55 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 57498B4CC90; Fri, 27 May 2016 04:14:55 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26C331325; Fri, 27 May 2016 04:14:55 +0000 (UTC) (envelope-from cedric.blancher@gmail.com) Received: by mail-pf0-x22f.google.com with SMTP id g64so37760909pfb.2; Thu, 26 May 2016 21:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=sBSNRe3gf63kFJ5c21VlMqTvZ/omf2EELZiyqpV2UZs=; b=VmsPzDRCR5BOXLHf7BOEQZ+h9OZhzum42bxIAT6Na1Y0OWIUMSFekRNkFdpFJ5dV9P Re9RrzB8FlEuIM2hJP1mTsx52qo4lN3w8LSJc1f8wLY7wz8GmztJt9XDDNmApjYnEJSo vDFDbnYBDqudcJFz5BRiEDKSXazpce8AlNM3mkS9ynSJdJDB+sDiZGCxwXEd5NikyG84 EdQduIi3yUGUV3UC70Cle2hq9oAuKJWDPyOAeBAOA0e12ur7tGL8m+PVAXCmDQAfN8kF PeYhw4R4OJU/bJxlZIznOo4M/jHTjn+6jzrcAH2B/2D+q5OXfdgUPZXyPVql+8XT83/H U1Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=sBSNRe3gf63kFJ5c21VlMqTvZ/omf2EELZiyqpV2UZs=; b=iTZ8Daco9S/I4ifPGBve2jvfwmuJAS6lkfe6i0n4YXgChz940tZ0HHOasve8kZqXwE BWYwdNlywS+4/PXdLoKIyqoGAd4jbFJ5pI+r/C2T0cWLOzqRuZXfVtZvNlUe5vUK/46i wdK75QPTPiG+IJ4x55msRgXBM5S0aRMEHTICEnPSro0O1Yj3YIzMojamelDjZFxlP0Bb Rcw76M018CxxI/dYC0+AlB4zPeDHLinHT5r82jtTFYefgJevMuJjbxicbrQMzVo5VXxq +Wxj6AqKGN9dMdJ1AMYBy++qHxb/kW4Ybs8T26Fm1rBxHJPmqJC7uB2Tr8PCV9IKO7mN U2+w== X-Gm-Message-State: ALyK8tJ6hI4xxKHFlxi5Bbaw//IJNuVRqoGf0jEK6h31rij70S9IIuHmEA2gp9NtARGeyxsPNwpcNn2BiPWVpw== MIME-Version: 1.0 X-Received: by 10.98.19.5 with SMTP id b5mr19187982pfj.153.1464322494570; Thu, 26 May 2016 21:14:54 -0700 (PDT) Received: by 10.66.183.232 with HTTP; Thu, 26 May 2016 21:14:54 -0700 (PDT) In-Reply-To: References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> Date: Fri, 27 May 2016 06:14:54 +0200 Message-ID: Subject: Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses] From: Cedric Blancher To: Mark Millard Cc: freebsd-sparc64@freebsd.org, freebsd-arm , FreeBSD Toolchain , mandree@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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, 27 May 2016 04:14:55 -0000 SPARCv7, SPARCv8 and SPARCv9 mandate natural alignment like all 'normal' RISC implementations. SPARCv9 ABI adds some 'special' instructions (separate from the normal load/store instructions) for unaligned access, but as said they come with costs, as stated before PLUS the risk that they are unimplemented in the actual hardware and trigger emulation traps. Ced On 27 May 2016 at 05:59, Mark Millard wrote: > On 2016-May-26, at 8:21 PM, Cedric Blancher w= rote: > >> All pure RISC implementations enforce 'natural alignment' - a 32bit >> data type must be aligned 32bit, i.e. 4 bytes, a 64bit data type must >> be 8 byte aligned, a 128bit data type must be 16 byte aligned. >> Some RISC implementations are not pure, but still the misalignment >> comes with a (performance) penalty, either by issuing two loads or >> running through a whole trap handler (!!!!) function with hundreds of >> instructions. >> >> Ced > > Thanks for the notes. > > Having once worked in a "micros" group in a logic analyzer product line f= or many years, working on the software tools that were used for that subjec= t area, I'm very familiar with that general structure of alternatives --but= not with SPARC specifics. In your terminology: I've no clue how pure of a = RISC implementation is involved for any SPARC variation. > > I'm looking for SPARC-specific information that suggests if the defect re= port originally for armv7-a/cortex-a7 as FreeBSD formerly configured things= instead also likely applies to some SPARC variation/configuration that Fre= eBSD supports. (See later below.) > > If FreeBSD has some other fairly strict alignment context that is not a S= PARC that might also serve. > > Unless upstream can be told that some specific FreeBSD variant is unsuppo= rted by their software because of presuming unaligned access is okay, I dou= bt that a report to upstream should be made based on FreeBSD as a context. = (This presumes that the port passes a test under the new armv7-a/cortex-a7 = and related alignment requirements. I'm not to that point yet.) > >> On 27 May 2016 at 00:03, Mark Millard wrote: >>> Is is safe to interpret that an rpi2 armv7/cortex-a7 unaligned access f= ailure [from before -r300694] would (likely?) also be a failure on some for= ms of FreeBSD SPARC use? >>> >>> >>> Why I ask: >>> >>> One of the ports that I had submitted a bug report for unaligned access= problems on a rpi2 (armv7-a/cortex-a7 style handling) was: >>> >>> archivers/lzo2 >>> >>> ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207096 ). I'd rec= ently commented that the report might go away after testing what is now -r3= 00694 (allowing more unaligned access on, for example, armv7-a/cortex-a7). >>> >>> Matthias Andree has since asked in a comment: >>> >>>> ISTR SPARC architectures also barf on unaligned access, so is it worth= bothering the upstream author? >>> >>> I have generally stuck to architectures for which I have examples to ob= serve, if nothing else than to validate at least some of my understanding t= hat is from reading materials. I normally only submit what I've observed in= some form. >>> >>> I've no such SPARC context nor do I have knowledge/reference material f= or SPARCs. Nor am I familiar with the choices FreeBSD may have made for SPA= RC configuration coverage. >>> >>> As a matter of hear-say my impression is that some SPARCs can be config= ured to require some variation of strict alignment. >>> >>> But I do not know how much I can infer from what I observed on a rpi2 (= armv7-a/cortex-a7) to FreeBSD SPARC use getting similar results for at leas= t come configurations. Nor do I have access to a test environment for SPARC= . >>> >>> So I wonder if my archivers/lzo2 submittal in question should survive b= ecause of SPARC even if the problem is validated to go away for the updated= rpi2 like contexts (with armv7-a/cortex-a7 tailoring possibly involved). I= have some other submittals that might face the same type of question. >>> >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>> >>> _______________________________________________ >>> freebsd-sparc64@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 >>> To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.o= rg" >> >> >> >> -- >> Cedric Blancher >> Institute Pasteur > > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > --=20 Cedric Blancher Institute Pasteur From owner-freebsd-toolchain@freebsd.org Fri May 27 07:30: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 37F29B4BDAD; Fri, 27 May 2016 07:30:34 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D694112B; Fri, 27 May 2016 07:30:33 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mandree.no-ip.org ([78.48.16.123]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lg6op-1btmfG333D-00pZAw; Fri, 27 May 2016 09:30:21 +0200 Received: from [IPv6:::1] (localhost6.localdomain6 [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id 7EDAA23CF40; Fri, 27 May 2016 09:30:19 +0200 (CEST) Subject: Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses] To: Cedric Blancher , Mark Millard References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> Cc: freebsd-sparc64@freebsd.org, freebsd-arm , FreeBSD Toolchain From: Matthias Andree Message-ID: <5747F78A.5020103@gmx.de> Date: Fri, 27 May 2016 09:30:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K0:x4Dzr8rnhGNCAllALYKVEMmLxtNzsdMnMdvKIg7iiIFtSxJIc3F DJkwkTurVDChYM0tLhSEzrJMpr7QtAYtVyl9o1d4X+PfD0qJKNOikWMRArwl3tqOCOOwCcA zO66467O5WlSgKq0uPiBSCg/WBE5k9bO2VfddEdNsuZHgYSguw9XM/HPOoR5UjSFJlXv6qI Lqb5UpRxnUoZz++R933hw== X-UI-Out-Filterresults: notjunk:1;V01:K0:E75w9CCR9Zo=:b2T1Qls706obKcMBPZD1J6 bOFjVIeUeXM5F9WUZqfyYljblg6nh0thPkoEMeY5uDx3wVp+yyGUiyWIDQW55ST17y149fwq5 OLMm0gKzfjfLTYc37HTqROr9yDlaXSWBes5WW1xofgf9z9IXYrc2prlMfdzQcVKdsjT2ZMqK3 n2xtbjrFPJuHJAm4CUNF/WrzwZHRHKXVpzR8pCEKrBoOdUQ23/nzJRAJc3xmbIh/MDWGqM7hK AlCxtiOQ86SFPzsjGfuIshq3WK1Bw9vabeDNOL/Gv3NRqwnAo6KtI5TZIIFeKba7hICxBCW29 Sebbi/NzOmPGUU9N052CYQR/ZiECc/vMvPy7gfNea5qt68PG97YSspwKEJ/LOjf2N2AIFePwb AkHngImjDvpj/akYGbnwWVKpdFR1ImSCQQIHeQ0ZAsXT9vmqn3CCUKZRDGDgTjI21cDTGOT1I U8sTBI9GwuHDBarip4KsWqT5NaaQdK4hVWAAQo795MV+sepa7xzYi9R6GibJUlbRtoyFDccI9 KHpYiNci8AharOkPpwDXBKNzUem/QfiJIwue6DqimH/Sf4z+Axg7aZReilTpd29DHaebZsrJM lGZoVokipGCbAlTq8+mzQiasHy9XM7U5BKhedtY1nau2kUgRjBVqRqwLA4344SubShxgSQma3 bU9zfg4LR5Zg5rMHfbdj+PPePp1v3waZ4pKn5vRqQZyYNmosuxcCalfNdd8AfSmXKwOmn3tpS p5NiLnagNEP4trgeaYPAm1rwF4FyR6B2woKssOTSesYsPk9HVDCKKF5Ahky0bzUXpZWaYo1Ma zBmeoGa 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, 27 May 2016 07:30:34 -0000 Am 27.05.2016 um 06:14 schrieb Cedric Blancher: > SPARCv7, SPARCv8 and SPARCv9 mandate natural alignment like all > 'normal' RISC implementations. SPARCv9 ABI adds some 'special' > instructions (separate from the normal load/store instructions) for > unaligned access, but as said they come with costs, as stated before > PLUS the risk that they are unimplemented in the actual hardware and > trigger emulation traps. LZO libraries (archivers/lzo2) are mainly about speed end efficiency for mobile or otherwise energy-challenged devices, so we probably want to avoid unaligned access whatsoever in the port even if the crash happens outside inner loops. Now looking at the PR, there's a resolved core dump that leaves me with the impression it's trying to get 16 bit from an odd address, without digging too deep. Someone stop me here if I'm misinterpreting this. Where the take-home message for me was in Comment 4: > While options like -mno-unaligned-access will make the compiled code > avoid adding new misalignments as "optimizations" when the original > code does not misalign it will not repair code that directly generates > misalignments. (The alignment fixes to clang++ were all source code > fixes, not compiler option changes.) Meaning that this, for now, appears to be a port bug. Now, below is my current plan in the role of the port's maintainer, and any assistance will be appreciated (<- that's soliciting input) 1 - figure if this affects other RISC architectures. Cedric got the SPARC on the hook, but I'm open for input on other arch's. If someone can report back if the lzo2 port runs into unaligned-access-emulation traps on FreeBSD/sparc*, that would be helpful. I do not have access to SPARC computers any more. 2 - find someone to review the ARM and AARCH related #if preprocessor stuff in ./include/lzo/lzodefs.h in the port's WRKSRC after unpacking. 3 - if it's nothing we can do about, get Markus F. X. J. Oberhumer into the loop and ask him to make his code work on strict-alignment computers and possibly provide initial patches. Finally a question of my personal interest for the ARM7 folks: How much of an effort is it to get a RPi configured to the point that I can reproduce the problem? Is it more something to do over a coffee, or will it take a week of frequent hand-holding and compiles over night? The RPi seems pretty affordable and I meant to get one (for Linux) anyways, I might just get another SD card for FreeBSD 11. From owner-freebsd-toolchain@freebsd.org Fri May 27 11:35: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 D35AAB4C0A8 for ; Fri, 27 May 2016 11:35:57 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-191.reflexion.net [208.70.211.191]) (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 92D951105 for ; Fri, 27 May 2016 11:35:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28344 invoked from network); 27 May 2016 11:36:27 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 May 2016 11:36:27 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Fri, 27 May 2016 07:35:53 -0400 (EDT) Received: (qmail 9321 invoked from network); 27 May 2016 11:35:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 27 May 2016 11:35:53 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id EF0601C43F4; Fri, 27 May 2016 04:35:46 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses] From: Mark Millard In-Reply-To: <5747F78A.5020103@gmx.de> Date: Fri, 27 May 2016 04:35:54 -0700 Cc: Cedric Blancher , freebsd-sparc64@freebsd.org, freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> <5747F78A.5020103@gmx.de> To: Matthias Andree 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: Fri, 27 May 2016 11:35:57 -0000 On 2016-May-27, at 12:30 AM, Matthias Andree = wrote: > Am 27.05.2016 um 06:14 schrieb Cedric Blancher: >> SPARCv7, SPARCv8 and SPARCv9 mandate natural alignment like all >> 'normal' RISC implementations. SPARCv9 ABI adds some 'special' >> instructions (separate from the normal load/store instructions) for >> unaligned access, but as said they come with costs, as stated before >> PLUS the risk that they are unimplemented in the actual hardware and >> trigger emulation traps. >=20 > LZO libraries (archivers/lzo2) are mainly about speed end efficiency = for > mobile or otherwise energy-challenged devices, so we probably want to > avoid unaligned access whatsoever in the port even if the crash = happens > outside inner loops. >=20 > >=20 > Now looking at the PR, there's a resolved core dump that leaves me = with > the impression it's trying to get 16 bit from an odd address, without > digging too deep. Someone stop me here if I'm misinterpreting this. That is what the ldrh instruction would be doing given the value listed = for r0. Before the recent kernel change that attempt caused an = exception. Now it would to the misaligned access without complaint. (But = I've not got as far as testing such yet: other things are taking my = time.) > > Where the take-home message for me was in Comment 4: >=20 >> While options like -mno-unaligned-access will make the compiled code >> avoid adding new misalignments as "optimizations" when the original >> code does not misalign it will not repair code that directly = generates >> misalignments. (The alignment fixes to clang++ were all source code >> fixes, not compiler option changes.) >=20 > Meaning that this, for now, appears to be a port bug. >=20 > Now, below is my current plan in the role of the port's maintainer, = and > any assistance will be appreciated (<- that's soliciting input) >=20 > 1 - figure if this affects other RISC architectures. Cedric got the > SPARC on the hook, but I'm open for input on other arch's. >=20 > If someone can report back if the lzo2 port runs into > unaligned-access-emulation traps on FreeBSD/sparc*, that would be > helpful. I do not have access to SPARC computers any more. I also have no access to any SPARC variants. > 2 - find someone to review the ARM and AARCH related #if preprocessor > stuff in ./include/lzo/lzodefs.h in the port's WRKSRC after unpacking. >=20 >=20 > 3 - if it's nothing we can do about, get Markus F. X. J. Oberhumer = into > the loop and ask him to make his code work on strict-alignment = computers > and possibly provide initial patches. >=20 >=20 > Finally a question of my personal interest for the ARM7 folks: >=20 > How much of an effort is it to get a RPi configured to the point that = I > can reproduce the problem? Is it more something to do over a coffee, = or > will it take a week of frequent hand-holding and compiles over night? > The RPi seems pretty affordable and I meant to get one (for Linux) > anyways, I might just get another SD card for FreeBSD 11. The rpi vintage matters: Original rpi's (before rpi2): ARM1176JZF-S, 32-bit (not armv6 nor = armv7-a/cortex-a7) rpi2: armv7-a/cortex-a7, 32-bit (this is where the problem was = originally shown) rpi3: cortex-A53, 64-bit (not supported by FreeBSD 11.0 yet) (I've done no testing of an original rpi and do not know its behavior. = Original rpi's would be slower.) As far as I know you would need an rpi2 specifically and likely a = now-older 11.0-CURRENT vintage that is pickier about alignment (or a = more modern kernel adjusted back to being picker). I've not been using the 11.0 snapshots to install but building from = source on an amd64 context and copying over the installation materials = separately. Also I have / on a usb drive instead of a slower SD card. An = SD card is still required for part of the boot sequence for such = contexts but is otherwise is normally unused as I do things. I did buildworld/buildkernel once on the rpi2 itself and it took about = 14 hours at the time as I remember. By contrast, all my port builds from source were on the rpi2 itself, not = cross builds. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri May 27 12:03:23 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 75A3AB4A53D; Fri, 27 May 2016 12:03:23 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (chuckie.co.uk [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3707C1A5D; Fri, 27 May 2016 12:03:22 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from host31-50-169-25.range31-50.btcentralplus.com ([31.50.169.25] helo=[192.168.1.65]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1b6GD6-00077b-K1; Fri, 27 May 2016 12:45:49 +0100 To: Mark Millard , Matthias Andree References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> <5747F78A.5020103@gmx.de> Cc: freebsd-arm , FreeBSD Toolchain , freebsd-sparc64@freebsd.org From: Mark Cave-Ayland Message-ID: <5748334B.6070504@ilande.co.uk> Date: Fri, 27 May 2016 12:45:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 31.50.169.25 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on s16892447.onlinehome-server.info X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Subject: Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses] X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: Yes (on s16892447.onlinehome-server.info) 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, 27 May 2016 12:03:23 -0000 On 27/05/16 12:35, Mark Millard wrote: >> 1 - figure if this affects other RISC architectures. Cedric got the >> SPARC on the hook, but I'm open for input on other arch's. >> >> If someone can report back if the lzo2 port runs into >> unaligned-access-emulation traps on FreeBSD/sparc*, that would be >> helpful. I do not have access to SPARC computers any more. > > I also have no access to any SPARC variants. If you grab yourself a copy of the latest QEMU 2.6, you should be able to happily install FreeBSD-current under qemu-system-sparc64 in -nographic mode. The emulation is still a work-in-progress but one of its primary use cases is allow people to generate builds even if they don't have access to the real hardware. ATB, Mark. From owner-freebsd-toolchain@freebsd.org Fri May 27 18:15:46 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 EF3AFB4C05B for ; Fri, 27 May 2016 18:15:46 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 5CB401044 for ; Fri, 27 May 2016 18:15:45 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 08d546ab-2437-11e6-8d8d-01a8ff6afd94 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.eu.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 27 May 2016 18:15:46 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u4RIFc0U008102; Fri, 27 May 2016 12:15:38 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1464372938.1204.98.camel@freebsd.org> Subject: Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses] From: Ian Lepore To: Mark Millard , Matthias Andree Cc: freebsd-arm , FreeBSD Toolchain , Cedric Blancher , freebsd-sparc64@freebsd.org Date: Fri, 27 May 2016 12:15:38 -0600 In-Reply-To: References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> <5747F78A.5020103@gmx.de> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 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, 27 May 2016 18:15:47 -0000 On Fri, 2016-05-27 at 04:35 -0700, Mark Millard wrote: > On 2016-May-27, at 12:30 AM, Matthias Andree > wrote: > > > Am 27.05.2016 um 06:14 schrieb Cedric Blancher: > > > [...] > The rpi vintage matters: > > Original rpi's (before rpi2): ARM1176JZF-S, 32-bit (not armv6 nor > armv7-a/cortex-a7) > Original rpi is indeed 1176JZF-S, which IS armv6. The differences between it and armv7 are almost entirely in the cache maintenence routines, and notably not in handling unaligned access the way we now configure the hardware. Bottom line: this is an old slow chip and you'll be nothing but frustrated using it. If you're going to get an rpi, get the much faster rpi2, which is a quad-core system. These days you may be even better off with something even newer based on the Allwinner chips (banana pi, cubieboard, a bunch of others), thanks to the excellent support work done recent (and still happening) by Jarred and Emmanuel. But I'm not sure of the price comparisons. -- Ian From owner-freebsd-toolchain@freebsd.org Fri May 27 18:52:03 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 463E1B4C95C for ; Fri, 27 May 2016 18:52:03 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 A21991B58 for ; Fri, 27 May 2016 18:52:01 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 192b0ab7-243c-11e6-8d8d-01a8ff6afd94 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.eu.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 27 May 2016 18:52:01 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u4RIprAf008169; Fri, 27 May 2016 12:51:53 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1464375113.1204.120.camel@freebsd.org> Subject: Re: Are there SPARC [or other] aligned memory access requirements to avoid exceptions? [now that 11.0's armv6/v7 is allowing more unaligned accesses] From: Ian Lepore To: Matthias Andree , Cedric Blancher , Mark Millard Cc: freebsd-arm , FreeBSD Toolchain , freebsd-sparc64@freebsd.org Date: Fri, 27 May 2016 12:51:53 -0600 In-Reply-To: <5747F78A.5020103@gmx.de> References: <7AFD3661-9764-434B-A387-FD31B62DD77E@dsl-only.net> <5747F78A.5020103@gmx.de> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 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, 27 May 2016 18:52:03 -0000 On Fri, 2016-05-27 at 09:30 +0200, Matthias Andree wrote: > Am 27.05.2016 um 06:14 schrieb Cedric Blancher: > > [...] > > > 2 - find someone to review the ARM and AARCH related #if preprocessor > stuff in ./include/lzo/lzodefs.h in the port's WRKSRC after > unpacking. > I just had a look. I think the cause of bugzilla 207096 is probably found on line 2544 of lzodefs.h: # elif 1 && defined(__TARGET_ARCH_ARM) && ((__TARGET_ARCH_ARM)+0 >= 7) A similar check on line 2551 assumes armv6-a and -r profiles also support unaligned. Our freebsd clang would normally not define __ARM_FEATURE_UNALIGNED (checked on line 2528 of lzodefs.h) unless someone had specifically added the -munaligned-access option; in the PR we see it specifically has -mno-unaligned-access. But it also has -march=armv7 (our default is v6 due to the rpi and the ongoing stupidity that we pretend v6 and v7 are "the same enough" to not need separate names). So with __ARM_FEATURE_UNALIGNED not defined and arch = armv7, the check on line 2544 makes the assumption (incorrect until a few days ago) that if the arch is v7, we must have support for unaligned access. I think that assumption is right for every major OS, but there could be special embedded environments where it's incorrect. (In fact, a highly specialized embedded system is pretty much the ONLY place you'd expect someone to legitimately disable unaligned accesses, now that freebsd gets it right). I think the right thing to do is: if __ARM_ARCH is defined, that means the current compiler properly supports the ACLE feature symbols[1] and thus only __ARM_FEATURE_UNALIGNED should be consulted. If __ARM_ARCH is not defined, then __ARM_FEATURE_UNALIGNED can't be used, and a fallback to guessing based on arch might be valid. [1] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053c/IHI0053C_acle_2_0.pdf -- Ian From owner-freebsd-toolchain@freebsd.org Fri May 27 20:50: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 8A908B4D61A; Fri, 27 May 2016 20:50:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (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 53C571388; Fri, 27 May 2016 20:50:14 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::89b4:6d81:b8c1:5a81] (unknown [IPv6:2001:7b8:3a7:0:89b4:6d81:b8c1:5a81]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 20B74177A7; Fri, 27 May 2016 22:50:11 +0200 (CEST) Subject: Re: 11.0-CURRENT -r300770 libc++ update vs. lang/powerpc64-xtoolchain-gcc: no go [self hosted powerpc64 context] Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F2ECBE1C-F72C-46A2-BFB2-EBAC9E31F8D9"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <95E2A9D6-8E1A-46FB-84FF-60927A6F1CE4@dsl-only.net> Date: Fri, 27 May 2016 22:50:03 +0200 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-ports@freebsd.org Message-Id: <8FAD594D-4349-4EA7-A712-D3792537FB1D@FreeBSD.org> References: <95E2A9D6-8E1A-46FB-84FF-60927A6F1CE4@dsl-only.net> To: Mark Millard 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: Fri, 27 May 2016 20:50:14 -0000 --Apple-Mail=_F2ECBE1C-F72C-46A2-BFB2-EBAC9E31F8D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 May 2016, at 01:53, Mark Millard wrote: >=20 > I do buildworld/buildkernel on a powerpc64 targeting itself via = lang/powerpc64-xtoolchain-gcc (a.k.a. lang/powerpc64-gcc for the most = part). [Getting that lang/powerpc64-gcc installed for self-hosted use = does take some work-around activity.] I have buildworld build clang (but = not use it). [I've been doing this with 11.0-CURRENT for a long time.] >=20 > Actually I use lang/gcc49 as the "system compiler" and = lang/powerpc64-gcc as the self-hosting so-called "cross compiler". (I = later list the src.conf content.) gcc4.2.1 is not installed. >=20 > Trying to go from: >=20 >> # uname -apKU >> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #36 r300531M: Mon = May 23 20:13:52 PDT 2016 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc powerpc64 1100111 1100111 >=20 > (for which -r300531 built and installed fine this way) to -r300777 now = fails with errors such as: >=20 >> --- lib/libc++__L --- >> In file included from = /usr/src/lib/libc++/../../contrib/libc++/include/iterator:346:0, >> from = /usr/src/lib/libc++/../../contrib/libc++/include/memory:606, >> from = /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:628, >> from = /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10: >> /usr/src/lib/libc++/../../contrib/libc++/include/iosfwd:176:14: = error: 'mbstate_t' was not declared in this scope >> typedef fpos streampos; >> ^ This is hopefully fixed by r300873 now. Can you please verify? -Dimitry --Apple-Mail=_F2ECBE1C-F72C-46A2-BFB2-EBAC9E31F8D9 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 iEYEARECAAYFAldIswIACgkQsF6jCi4glqMN6QCeLcfevnjrK4xIuXQT7sZ//0gJ c7YAoN2zu3s7+Us/rb14dOY5/0s5VkDH =+Ksh -----END PGP SIGNATURE----- --Apple-Mail=_F2ECBE1C-F72C-46A2-BFB2-EBAC9E31F8D9-- From owner-freebsd-toolchain@freebsd.org Fri May 27 21:56:23 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 B19A2B4CB62 for ; Fri, 27 May 2016 21:56:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-178.reflexion.net [208.70.211.178]) (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 64CAC1C27 for ; Fri, 27 May 2016 21:56:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19495 invoked from network); 27 May 2016 21:56:46 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 27 May 2016 21:56:46 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Fri, 27 May 2016 17:56:13 -0400 (EDT) Received: (qmail 27325 invoked from network); 27 May 2016 21:56:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 27 May 2016 21:56:13 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 74C931C43D6; Fri, 27 May 2016 14:56:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0-CURRENT -r300770 libc++ update vs. lang/powerpc64-xtoolchain-gcc: no go [self hosted powerpc64 context] From: Mark Millard In-Reply-To: <8FAD594D-4349-4EA7-A712-D3792537FB1D@FreeBSD.org> Date: Fri, 27 May 2016 14:56:15 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <95E2A9D6-8E1A-46FB-84FF-60927A6F1CE4@dsl-only.net> <8FAD594D-4349-4EA7-A712-D3792537FB1D@FreeBSD.org> To: Dimitry Andric 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: Fri, 27 May 2016 21:56:23 -0000 On 2016-May-27, at 1:50 PM, Dimitry Andric wrote: >=20 > On 27 May 2016, at 01:53, Mark Millard wrote: >>=20 >> I do buildworld/buildkernel on a powerpc64 targeting itself via = lang/powerpc64-xtoolchain-gcc (a.k.a. lang/powerpc64-gcc for the most = part). [Getting that lang/powerpc64-gcc installed for self-hosted use = does take some work-around activity.] I have buildworld build clang (but = not use it). [I've been doing this with 11.0-CURRENT for a long time.] >>=20 >> Actually I use lang/gcc49 as the "system compiler" and = lang/powerpc64-gcc as the self-hosting so-called "cross compiler". (I = later list the src.conf content.) gcc4.2.1 is not installed. >>=20 >> Trying to go from: >>=20 >>> # uname -apKU >>> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #36 r300531M: Mon = May 23 20:13:52 PDT 2016 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc powerpc64 1100111 1100111 >>=20 >> (for which -r300531 built and installed fine this way) to -r300777 = now fails with errors such as: >>=20 >>> --- lib/libc++__L --- >>> In file included from = /usr/src/lib/libc++/../../contrib/libc++/include/iterator:346:0, >>> from = /usr/src/lib/libc++/../../contrib/libc++/include/memory:606, >>> from = /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:628, >>> from = /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10: >>> /usr/src/lib/libc++/../../contrib/libc++/include/iosfwd:176:14: = error: 'mbstate_t' was not declared in this scope >>> typedef fpos streampos; >>> ^ >=20 > This is hopefully fixed by r300873 now. Can you please verify? >=20 > -Dimitry buildworld/buildkernel started, based on -r300875 for powerpc64 under/on = powerpc64 FreeBSD via lang/powerpc-xtoolchain-gcc as the so-called = "cross compiler". If it completes successfully it takes about 8 hours = for what I normally include in such builds. I've also started a clang-based buildworld for powerpc (non-64) under = powerpc FreeBSD as a cross check. (This environment involves work = arounds, such as changes to signal delivery to avoid clang's code = generation ABI violations in its stack handling. A clang based = buildkernel would not complete so I would use a separate gcc 4.2.1 = kernel build to get an overall system.) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri May 27 23:40: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 E60CEB4D359 for ; Fri, 27 May 2016 23:40:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-180.reflexion.net [208.70.211.180]) (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 9959414C3 for ; Fri, 27 May 2016 23:40:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3577 invoked from network); 27 May 2016 23:40:59 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 27 May 2016 23:40:59 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Fri, 27 May 2016 19:41:05 -0400 (EDT) Received: (qmail 12950 invoked from network); 27 May 2016 23:41:04 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 27 May 2016 23:41:04 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 97DEE1C43D6; Fri, 27 May 2016 16:40:15 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0-CURRENT -r300770 libc++ update vs. lang/powerpc64-xtoolchain-gcc: no go [self hosted powerpc64 context] From: Mark Millard In-Reply-To: Date: Fri, 27 May 2016 16:40:26 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <42773110-C392-4168-9B94-6902807DB530@dsl-only.net> References: <95E2A9D6-8E1A-46FB-84FF-60927A6F1CE4@dsl-only.net> <8FAD594D-4349-4EA7-A712-D3792537FB1D@FreeBSD.org> To: Dimitry Andric 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: Fri, 27 May 2016 23:40:35 -0000 [I'm top posting the results of the failed build.] It looks like the following has been addresses in -r300884. libcompat = also got a -isystem in -r300885. -r300886 did "Move external GCC = compiler hacks to bsd.sys.mk". So I'll retry based on -r300886. Failure details. . . Both the powerpc64 lang/powerpc64-xtoolchain-gcc and powerpc clang = combinations failed for -r300875. The details are rather different this = time and might not be related to your libc++ changes. Both contexts got = the same error. powerpc64 lang/powerpc64-xtoolchain-gcc: > --- all_subdir_cddl/lib/libzpool --- > In file included from = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs/arc.c:144:0: > /usr/src/sys/vm/vm_pageout.h:77:8: error: unknown type name 'bool' > extern bool vm_pageout_wanted; > ^ > /usr/src/sys/vm/vm_pageout.h:78:8: error: unknown type name 'bool' > extern bool vm_pages_needed; > ^ The -v search list information was: > ignoring nonexistent directory = "/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/local/include" > ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerp= c64-portbld-freebsd11.0/include" > ignoring duplicate directory = "/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include" > ignoring nonexistent directory = "/usr/src/cddl/lib/libzpool/../../../lib/libpthread/thread" > ignoring nonexistent directory = "/usr/src/cddl/lib/libzpool/../../../lib/libpthread/sys" > #include "..." search starts here: > #include <...> search starts here: > /usr/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris > /usr/src/cddl/lib/libzpool/../../compat/opensolaris/include > /usr/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem > = /usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common > = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/sys > = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs > = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zf= s > = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n > /usr/src/cddl/lib/libzpool/../../contrib/opensolaris/head > /usr/src/cddl/lib/libzpool/../../lib/libumem > /usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair > /usr/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include > /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include > /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include > /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed > End of search list. This was for: > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -isystem = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp = -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris = -I/usr/src/cddl/lib/libzpool/../../compat/opensolaris/include = -I/usr/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem = -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common= = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon/sys = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon/fs/zfs = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/= zfs = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/head = -I/usr/src/cddl/lib/libzpool/../../lib/libumem = -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair = -DWANTS_MUTEX_OWNED = -I/usr/src/cddl/lib/libzpool/../../../lib/libpthread/thread = -I/usr/src/cddl/lib/libzpool/../../../lib/libpthread/sys = -I/usr/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -g = -DDEBUG=3D1 -DNEED_SOLARIS_BOOLEAN -MD -MF.depend.arc.o -MTarc.o = -std=3Diso9899:1999 -fstack-protector-strong -Wno-pointer-sign = -Wno-error=3Dunused-function -Wno-error=3Denum-compare = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare = -Wno-error=3Duninitialized -Wno-error=3Darray-bounds = -Wno-error=3Dclobbered -Wno-error=3Dcast-align -Wno-error=3Dextra = -Wno-error=3Dattributes -Wno-error=3Dinline = -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value = -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas = -v -c = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs/arc.c -o arc.o powerpc sytem clang: > --- all_subdir_cddl/lib/libzpool --- > In file included from = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs/arc.c:144: > = /usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/include/vm/vm_pageout.h:77:= 8: error: unknown type name 'bool' > extern bool vm_pageout_wanted; > ^ > = /usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/include/vm/vm_pageout.h:78:= 8: error: unknown type name 'bool' > extern bool vm_pages_needed; > ^ This was for: > --- arc.o --- > cc -O2 -pipe = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris = -I/usr/src/cddl/lib/libzpool/../../compat/opensolaris/include = -I/usr/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem = -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common= = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon/sys = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon/fs/zfs = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/= zfs = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/head = -I/usr/src/cddl/lib/libzpool/../../lib/libumem = -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair = -DWANTS_MUTEX_OWNED = -I/usr/src/cddl/lib/libzpool/../../../lib/libpthread/thread = -I/usr/src/cddl/lib/libzpool/../../../lib/libpthread/sys = -I/usr/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -g = -DDEBUG=3D1 -DNEED_SOLARIS_BOOLEAN -MD -MF.depend.arc.o -MTarc.o = -std=3Diso9899:1999 -fstack-protector-strong -Wno-pointer-sign = -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs/arc.c -o arc.o =3D=3D=3D Mark Millard markmi@dsl-only.net On 2016-May-27, at 2:56 PM, Mark Millard wrote: > On 2016-May-27, at 1:50 PM, Dimitry Andric wrote: >>=20 >> On 27 May 2016, at 01:53, Mark Millard = wrote: >>>=20 >>> I do buildworld/buildkernel on a powerpc64 targeting itself via = lang/powerpc64-xtoolchain-gcc (a.k.a. lang/powerpc64-gcc for the most = part). [Getting that lang/powerpc64-gcc installed for self-hosted use = does take some work-around activity.] I have buildworld build clang (but = not use it). [I've been doing this with 11.0-CURRENT for a long time.] >>>=20 >>> Actually I use lang/gcc49 as the "system compiler" and = lang/powerpc64-gcc as the self-hosting so-called "cross compiler". (I = later list the src.conf content.) gcc4.2.1 is not installed. >>>=20 >>> Trying to go from: >>>=20 >>>> # uname -apKU >>>> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #36 r300531M: = Mon May 23 20:13:52 PDT 2016 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc powerpc64 1100111 1100111 >>>=20 >>> (for which -r300531 built and installed fine this way) to -r300777 = now fails with errors such as: >>>=20 >>>> --- lib/libc++__L --- >>>> In file included from = /usr/src/lib/libc++/../../contrib/libc++/include/iterator:346:0, >>>> from = /usr/src/lib/libc++/../../contrib/libc++/include/memory:606, >>>> from = /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:628, >>>> from = /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10: >>>> /usr/src/lib/libc++/../../contrib/libc++/include/iosfwd:176:14: = error: 'mbstate_t' was not declared in this scope >>>> typedef fpos streampos; >>>> ^ >>=20 >> This is hopefully fixed by r300873 now. Can you please verify? >>=20 >> -Dimitry >=20 > buildworld/buildkernel started, based on -r300875 for powerpc64 = under/on powerpc64 FreeBSD via lang/powerpc-xtoolchain-gcc as the = so-called "cross compiler". If it completes successfully it takes about = 8 hours for what I normally include in such builds. >=20 > I've also started a clang-based buildworld for powerpc (non-64) under = powerpc FreeBSD as a cross check. (This environment involves work = arounds, such as changes to signal delivery to avoid clang's code = generation ABI violations in its stack handling. A clang based = buildkernel would not complete so I would use a separate gcc 4.2.1 = kernel build to get an overall system.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 From owner-freebsd-toolchain@freebsd.org Fri May 27 23:48:49 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 D227EB4DB1B; Fri, 27 May 2016 23:48:49 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B25D31DA1; Fri, 27 May 2016 23:48:49 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 9FCCB1E08; Fri, 27 May 2016 23:48:49 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 5793D1C7F0; Fri, 27 May 2016 23:48:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id 7S2INREXGb1K; Fri, 27 May 2016 23:48:46 +0000 (UTC) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 892BE1C7E8 To: Mark Millard References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: Date: Fri, 27 May 2016 16:48:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a099HRpH0Rd4p8BCJmLo4SFJILRLnWuQP" 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, 27 May 2016 23:48:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a099HRpH0Rd4p8BCJmLo4SFJILRLnWuQP Content-Type: multipart/mixed; boundary="M9NelqhHQwKjGgnen3eiJxH3GEVFVQoDr" From: Bryan Drewery To: Mark Millard Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh Message-ID: Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> In-Reply-To: --M9NelqhHQwKjGgnen3eiJxH3GEVFVQoDr Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/31/2016 8:33 PM, Mark Millard wrote: > I appears that C++ needs its own override for where to find C++ header = before looking in the gcc49 specific places. Yes, the hacks for that are builtin already. Passing C_INCLUDE_PATH and others may break it. > These sorts of odd, hard to avoid dependencies are part of why I asked = if there was a standard/recommend assignment to use for CC/XCC: I was hop= ing there was a known-good way to compile that avoided the issues, possib= ly by using powerpc64-gcc tools for CC/XCC as well. You shouldn't need to pass any extra -I/-isystem or env vars for paths. The problem in this thread was just the ports compiler using /usr/local/include when not using a --sysroot. This is only in the early phase of the build. Mind trying this patch? https://people.freebsd.org/~bdrewery/patches/gcc-no-local-include.patch I assume you are using that port, if not you can apply the same change to whichever your ports gcc came from. It removes the /usr/local/include path. It is somewhat the wrong fix vs "fixing the order", but the /usr/local/lib path is not in there now and you must use -rpath with the ports gcc anyhow. So the ports gcc is already broken for /usr/local, it should be fully broken or fully fixed, not half broken to the point of breaking other things. I'm still just curious if it fixes the problems with "stage 3" finding the wrong dwarf header, and if removing your own include path hacks progresses the build further. --=20 Regards, Bryan Drewery --M9NelqhHQwKjGgnen3eiJxH3GEVFVQoDr-- --a099HRpH0Rd4p8BCJmLo4SFJILRLnWuQP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJXSNzkAAoJEDXXcbtuRpfP4GUIAIz6WXc3FKViwoFD7NQmVzSd Wa3b2JZycnbGPohZx+JtSwYYENoYb9GhkJxM2x0LIzBzdl9FCxlWVP9yTQzYVV8x HJ+oGeH70vLh2G6wd1J+z+AT82k4WYslme4xNMYVdqPK+O9F5qGgzPRdQYqLvp+d uu1TessA4a6bGSarL8bcTeNUMRUXnz52dKV0cP4RrFq30pj96RWVrikjCQUeRDGc Yd13loJXH8N4lZoOsQ7q2MX5B8r75rAtwE5oQLFjr3JTTP2TPBNPjI+HyStBEX87 hmWGkR+doXs3OwQXZa0zN7iQSZZucO40D1lgZrWhghgU4U2HX7N16ufS+v8y5nk= =9qo8 -----END PGP SIGNATURE----- --a099HRpH0Rd4p8BCJmLo4SFJILRLnWuQP-- From owner-freebsd-toolchain@freebsd.org Sat May 28 00:15:38 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 365C6B4A87E for ; Sat, 28 May 2016 00:15:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-179.reflexion.net [208.70.211.179]) (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 DB8BA1799 for ; Sat, 28 May 2016 00:15:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15698 invoked from network); 28 May 2016 00:16:03 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 May 2016 00:16:03 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Fri, 27 May 2016 20:16:08 -0400 (EDT) Received: (qmail 31042 invoked from network); 28 May 2016 00:16:08 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 May 2016 00:16:08 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D686B1C43D6; Fri, 27 May 2016 17:15:18 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Mark Millard In-Reply-To: Date: Fri, 27 May 2016 17:15:30 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> To: Bryan Drewery 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: Sat, 28 May 2016 00:15:38 -0000 On 2016-May-27, at 4:48 PM, Bryan Drewery = wrote: > On 3/31/2016 8:33 PM, Mark Millard wrote: >> I appears that C++ needs its own override for where to find C++ = header before looking in the gcc49 specific places. >=20 > Yes, the hacks for that are builtin already. Passing C_INCLUDE_PATH = and > others may break it. When I try the experiment I'll try to remember to disable any such env = based workarounds that I currently have in place. >> These sorts of odd, hard to avoid dependencies are part of why I = asked if there was a standard/recommend assignment to use for CC/XCC: I = was hoping there was a known-good way to compile that avoided the = issues, possibly by using powerpc64-gcc tools for CC/XCC as well. >=20 > You shouldn't need to pass any extra -I/-isystem or env vars for = paths. > The problem in this thread was just the ports compiler using > /usr/local/include when not using a --sysroot. This is only in the > early phase of the build. >=20 > Mind trying this patch? I'm currently doing libc++ related build experiments for Dimitry Andric. = A successful build would end about 8 hours from now. So it will be a = while before I can get to your experiment. > = https://people.freebsd.org/~bdrewery/patches/gcc-no-local-include.patch >=20 > I assume you are using that port, if not you can apply the same change > to whichever your ports gcc came from. For the powerpc64 context I use lang/gcc49 and = devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc which is a 5.3 = variant that has file conflicts with lang/gcc5's 5.3). I use lang/gcc49 = instead of lang/gcc5 because of devel/powerpc64-gcc conflicting. No gcc = 4.2.1 present or built. System clang built but unused. > It removes the /usr/local/include path. It is somewhat the wrong fix = vs > "fixing the order", but the /usr/local/lib path is not in there now = and > you must use -rpath with the ports gcc anyhow. So the ports gcc is > already broken for /usr/local, it should be fully broken or fully = fixed, > not half broken to the point of breaking other things. + --with-local-prefix=3D/usr/include \ looks wrong to me. The default is not /usr/local/include but just = /usr/local . Quoting https://gcc.gnu.org/install/configure.html : --with-local-prefix=3Ddirname Specify the installation directory for local include files. The default = is /usr/local. Specify this option if you want the compiler to search = directory dirname/include for locally installed header files instead of = /usr/local/include. So your change would generate /usr/include/include for the overall = include path from what I can tell. Do you want: + --with-local-prefix=3D/usr \ instead? > I'm still just curious if it fixes the problems with "stage 3" finding > the wrong dwarf header, and if removing your own include path hacks > progresses the build further. >=20 > --=20 > Regards, > Bryan Drewery =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat May 28 00:23:17 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 E5628B4AD17; Sat, 28 May 2016 00:23:17 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C3BD41F31; Sat, 28 May 2016 00:23:17 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id B49801DF6; Sat, 28 May 2016 00:23:17 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 737F41C95A; Sat, 28 May 2016 00:23:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id vXrffyANGt8j; Sat, 28 May 2016 00:23:14 +0000 (UTC) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 071DD1C953 To: Mark Millard References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> Date: Fri, 27 May 2016 17:23:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MqvQqiHlb4VmlPLFG9esdnjOXb7N5lEqn" 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, 28 May 2016 00:23:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MqvQqiHlb4VmlPLFG9esdnjOXb7N5lEqn Content-Type: multipart/mixed; boundary="tGshdqlP0rlgdO9uVTkS4VDL8krieGeNJ" From: Bryan Drewery To: Mark Millard Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh Message-ID: <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> In-Reply-To: <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> --tGshdqlP0rlgdO9uVTkS4VDL8krieGeNJ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/27/2016 5:15 PM, Mark Millard wrote: > + --with-local-prefix=3D/usr/include \ >=20 > looks wrong to me. The default is not /usr/local/include but just /usr/= local . Quoting https://gcc.gnu.org/install/configure.html : >=20 > --with-local-prefix=3Ddirname > Specify the installation directory for local include files. The default= is /usr/local. Specify this option if you want the compiler to search di= rectory dirname/include for locally installed header files instead of /us= r/local/include. >=20 > So your change would generate /usr/include/include for the overall incl= ude path from what I can tell. >=20 > Do you want: >=20 > + --with-local-prefix=3D/usr \ >=20 > instead? You're right, but it makes no real difference since it removes /usr/local/include: > ignoring nonexistent directory "/root/svn/ports/lang/gcc49/work/stage/u= sr/local/bin/../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../.= =2E/../x86_64-portbld-freebsd11.0/include" > ignoring duplicate directory "/root/svn/ports/lang/gcc49/work/stage/usr= /local/bin/../lib/gcc49/gcc/../../../lib/gcc49/gcc/x86_64-portbld-freebsd= 11.0/4.9.4/include" > ignoring nonexistent directory "/usr/include/include" ^ yes wrong > ignoring duplicate directory "/root/svn/ports/lang/gcc49/work/stage/usr= /local/bin/../lib/gcc49/gcc/../../../lib/gcc49/gcc/x86_64-portbld-freebsd= 11.0/4.9.4/include-fixed" > ignoring nonexistent directory "/root/svn/ports/lang/gcc49/work/stage/u= sr/local/bin/../lib/gcc49/gcc/../../../lib/gcc49/gcc/x86_64-portbld-freeb= sd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/include" > #include "..." search starts here: > #include <...> search starts here: > /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x= 86_64-portbld-freebsd11.0/4.9.4/include > /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x= 86_64-portbld-freebsd11.0/4.9.4/include-fixed > /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/.= =2E/../../include > /usr/include ^ Still added > End of search list. --=20 Regards, Bryan Drewery --tGshdqlP0rlgdO9uVTkS4VDL8krieGeNJ-- --MqvQqiHlb4VmlPLFG9esdnjOXb7N5lEqn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJXSOT3AAoJEDXXcbtuRpfPmOcIAMrr0NmRMziJym0wvridxmY+ im8HGeWhFIFyXzi4XzqKbtbbyNDzhmXX+LfFhLvlzMbfv0mSArggVawUxe4YrT1v 4jFZ0daxWuVq+h7GzV97KgzxuAu0fwG3FN4XOFn9igcqFB4xg+iIXYBWDn6Bdbdc kec/HIcPvbtPb9TtRuDQkQAzR7zwEzp7SSP+FlIIssob9XNeRUF2YmixJBn6xvMv 1ji/p/rDggdFv9bQphTA7+92JHKxvBxHIl4ADw1fJZbC5gZb8cx5lWNlzXwt03iT 9JRXjy+7vVIbZzLqgDReUwmwMs29oxbwFpssu5sh3bfHCsLDvPKwDllorfjSYq0= =2QZ7 -----END PGP SIGNATURE----- --MqvQqiHlb4VmlPLFG9esdnjOXb7N5lEqn-- From owner-freebsd-toolchain@freebsd.org Sat May 28 01:04:12 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 859CFB4B6D4 for ; Sat, 28 May 2016 01:04:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-175.reflexion.net [208.70.211.175]) (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 39510109D for ; Sat, 28 May 2016 01:04:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31679 invoked from network); 28 May 2016 01:04:35 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 May 2016 01:04:35 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Fri, 27 May 2016 21:04:43 -0400 (EDT) Received: (qmail 16073 invoked from network); 28 May 2016 01:04:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 May 2016 01:04:42 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1F0DD1C43D2; Fri, 27 May 2016 18:03:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0-CURRENT -r300770 libc++ update vs. lang/powerpc64-xtoolchain-gcc: no go [self hosted powerpc64 context] From: Mark Millard In-Reply-To: <42773110-C392-4168-9B94-6902807DB530@dsl-only.net> Date: Fri, 27 May 2016 18:04:04 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <3BAE82F4-3BF4-4F02-9BFF-3F2290D3C82D@dsl-only.net> References: <95E2A9D6-8E1A-46FB-84FF-60927A6F1CE4@dsl-only.net> <8FAD594D-4349-4EA7-A712-D3792537FB1D@FreeBSD.org> <42773110-C392-4168-9B94-6902807DB530@dsl-only.net> To: Dimitry Andric 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: Sat, 28 May 2016 01:04:12 -0000 [Top posting failure results again.] -r300886 for powerpc64 failed for each of: = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis/AnalysisDeclContext.cpp = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/li= b/ARCMigrate/ARCMT.cpp with the likes of: > --- all_subdir_lib/clang --- > In file included from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/../../lib/clang/= include/llvm/Support/DataTypes.h:36:0, > from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include/llvm/ADT= /Hashing.h:48, > from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include/llvm/ADT= /ArrayRef.h:13, > from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include/llvm/ADT= /APInt.h:19, > from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include/llvm/ADT= /APFloat.h:20, > from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/incl= ude/clang/AST/APValue.h:18, > from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/incl= ude/clang/AST/Decl.h:17, > from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/incl= ude/clang/Analysis/AnalysisContext.h:18, > from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis/AnalysisDeclContext.cpp:15: > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :309:9: error: '::signbit' has not been declared > using ::signbit; > ^ > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :310:9: error: '::fpclassify' has not been declared > using ::fpclassify; > ^ > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :311:9: error: '::isfinite' has not been declared > using ::isfinite; > ^ > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :312:9: error: '::isinf' has not been declared > using ::isinf; > ^ > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :313:9: error: '::isnan' has not been declared > using ::isnan; > ^ > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :314:9: error: '::isnormal' has not been declared > using ::isnormal; > ^ > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :315:9: error: '::isgreater' has not been declared > using ::isgreater; > ^ > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :316:9: error: '::isgreaterequal' has not been declared > using ::isgreaterequal; > ^ > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :317:9: error: '::isless' has not been declared > using ::isless; > ^ > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :318:9: error: '::islessequal' has not been declared > using ::islessequal; > ^ > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :319:9: error: '::islessgreater' has not been declared > using ::islessgreater; > ^ > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :320:9: error: '::isunordered' has not been declared > using ::isunordered; > ^ > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :321:9: error: '::isunordered' has not been declared > using ::isunordered; > ^ > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :327:9: error: '::abs' has not been declared > using ::abs; > ^ . . . (then later the other file gets similar results) . . . > --- all_subdir_lib/clang --- > In file included from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clan= g/include/llvm/Support/DataTypes.h:36:0, > from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include/llvm/A= DT/Hashing.h:48, > from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include/llvm/A= DT/ArrayRef.h:13, > from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include/llvm/A= DT/DenseMapInfo.h:17, > from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include/llvm/A= DT/DenseMap.h:17, > from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/in= clude/clang/ARCMigrate/FileRemapper.h:14, > from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/in= clude/clang/ARCMigrate/ARCMT.h:13, > from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/li= b/ARCMigrate/Internals.h:13, > from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/li= b/ARCMigrate/ARCMT.cpp:10: > = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :309:9: error: '::signbit' has not been declared > using ::signbit; > ^ . . . (similar list) . . . Based on (from a -v output): > ignoring nonexistent directory = "/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/local/include" > ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerp= c64-portbld-freebsd11.0/include" > ignoring duplicate directory = "/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include > = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/incl= ude > = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis > . > = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/../../lib/clang/= include > /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include > /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1 > /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include > /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed > End of search list. I could try building without clang being included if you want. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-May-27, at 4:40 PM, Mark Millard wrote: > [I'm top posting the results of the failed build.] >=20 > It looks like the following has been addresses in -r300884. libcompat = also got a -isystem in -r300885. -r300886 did "Move external GCC = compiler hacks to bsd.sys.mk". >=20 > So I'll retry based on -r300886. >=20 >=20 >=20 > Failure details. . . >=20 >=20 > Both the powerpc64 lang/powerpc64-xtoolchain-gcc and powerpc clang = combinations failed for -r300875. The details are rather different this = time and might not be related to your libc++ changes. Both contexts got = the same error. >=20 > powerpc64 lang/powerpc64-xtoolchain-gcc: >=20 >> --- all_subdir_cddl/lib/libzpool --- >> In file included from = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs/arc.c:144:0: >> /usr/src/sys/vm/vm_pageout.h:77:8: error: unknown type name 'bool' >> extern bool vm_pageout_wanted; >> ^ >> /usr/src/sys/vm/vm_pageout.h:78:8: error: unknown type name 'bool' >> extern bool vm_pages_needed; >> ^ >=20 >=20 > The -v search list information was: >=20 >> ignoring nonexistent directory = "/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/local/include" >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerp= c64-portbld-freebsd11.0/include" >> ignoring duplicate directory = "/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include" >> ignoring nonexistent directory = "/usr/src/cddl/lib/libzpool/../../../lib/libpthread/thread" >> ignoring nonexistent directory = "/usr/src/cddl/lib/libzpool/../../../lib/libpthread/sys" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris >> /usr/src/cddl/lib/libzpool/../../compat/opensolaris/include >> /usr/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem >> = /usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common >> = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/sys >> = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs >> = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zf= s >> = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n >> /usr/src/cddl/lib/libzpool/../../contrib/opensolaris/head >> /usr/src/cddl/lib/libzpool/../../lib/libumem >> /usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair >> /usr/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include >> /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed >> End of search list. >=20 > This was for: >=20 >> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -isystem = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp = -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris = -I/usr/src/cddl/lib/libzpool/../../compat/opensolaris/include = -I/usr/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem = -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common= = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon/sys = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon/fs/zfs = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/= zfs = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/head = -I/usr/src/cddl/lib/libzpool/../../lib/libumem = -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair = -DWANTS_MUTEX_OWNED = -I/usr/src/cddl/lib/libzpool/../../../lib/libpthread/thread = -I/usr/src/cddl/lib/libzpool/../../../lib/libpthread/sys = -I/usr/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -g = -DDEBUG=3D1 -DNEED_SOLARIS_BOOLEAN -MD -MF.depend.arc.o -MTarc.o = -std=3Diso9899:1999 -fstack-protector-strong -Wno-pointer-sign = -Wno-error=3Dunused-function -Wno-error=3Denum-compare = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare = -Wno-error=3Duninitialized -Wno-error=3Darray-bounds = -Wno-error=3Dclobbered -Wno-error=3Dcast-align -Wno-error=3Dextra = -Wno-error=3Dattributes -Wno-error=3Dinline = -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value = -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas = -v -c = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs/arc.c -o arc.o >=20 >=20 > powerpc sytem clang: >=20 >> --- all_subdir_cddl/lib/libzpool --- >> In file included from = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs/arc.c:144: >> = /usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/include/vm/vm_pageout.h:77:= 8: error: unknown type name 'bool' >> extern bool vm_pageout_wanted; >> ^ >> = /usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/include/vm/vm_pageout.h:78:= 8: error: unknown type name 'bool' >> extern bool vm_pages_needed; >> ^ >=20 > This was for: >=20 >> --- arc.o --- >> cc -O2 -pipe = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris = -I/usr/src/cddl/lib/libzpool/../../compat/opensolaris/include = -I/usr/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem = -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common= = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon/sys = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon/fs/zfs = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/= zfs = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/head = -I/usr/src/cddl/lib/libzpool/../../lib/libumem = -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair = -DWANTS_MUTEX_OWNED = -I/usr/src/cddl/lib/libzpool/../../../lib/libpthread/thread = -I/usr/src/cddl/lib/libzpool/../../../lib/libpthread/sys = -I/usr/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -g = -DDEBUG=3D1 -DNEED_SOLARIS_BOOLEAN -MD -MF.depend.arc.o -MTarc.o = -std=3Diso9899:1999 -fstack-protector-strong -Wno-pointer-sign = -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs/arc.c -o arc.o >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi@dsl-only.net >=20 > On 2016-May-27, at 2:56 PM, Mark Millard wrote: >=20 >> On 2016-May-27, at 1:50 PM, Dimitry Andric = wrote: >>>=20 >>> On 27 May 2016, at 01:53, Mark Millard = wrote: >>>>=20 >>>> I do buildworld/buildkernel on a powerpc64 targeting itself via = lang/powerpc64-xtoolchain-gcc (a.k.a. lang/powerpc64-gcc for the most = part). [Getting that lang/powerpc64-gcc installed for self-hosted use = does take some work-around activity.] I have buildworld build clang (but = not use it). [I've been doing this with 11.0-CURRENT for a long time.] >>>>=20 >>>> Actually I use lang/gcc49 as the "system compiler" and = lang/powerpc64-gcc as the self-hosting so-called "cross compiler". (I = later list the src.conf content.) gcc4.2.1 is not installed. >>>>=20 >>>> Trying to go from: >>>>=20 >>>>> # uname -apKU >>>>> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #36 r300531M: = Mon May 23 20:13:52 PDT 2016 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc powerpc64 1100111 1100111 >>>>=20 >>>> (for which -r300531 built and installed fine this way) to -r300777 = now fails with errors such as: >>>>=20 >>>>> --- lib/libc++__L --- >>>>> In file included from = /usr/src/lib/libc++/../../contrib/libc++/include/iterator:346:0, >>>>> from = /usr/src/lib/libc++/../../contrib/libc++/include/memory:606, >>>>> from = /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:628, >>>>> from = /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10: >>>>> /usr/src/lib/libc++/../../contrib/libc++/include/iosfwd:176:14: = error: 'mbstate_t' was not declared in this scope >>>>> typedef fpos streampos; >>>>> ^ >>>=20 >>> This is hopefully fixed by r300873 now. Can you please verify? >>>=20 >>> -Dimitry >>=20 >> buildworld/buildkernel started, based on -r300875 for powerpc64 = under/on powerpc64 FreeBSD via lang/powerpc-xtoolchain-gcc as the = so-called "cross compiler". If it completes successfully it takes about = 8 hours for what I normally include in such builds. >>=20 >> I've also started a clang-based buildworld for powerpc (non-64) under = powerpc FreeBSD as a cross check. (This environment involves work = arounds, such as changes to signal delivery to avoid clang's code = generation ABI violations in its stack handling. A clang based = buildkernel would not complete so I would use a separate gcc 4.2.1 = kernel build to get an overall system.) >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >>=20 >=20 From owner-freebsd-toolchain@freebsd.org Sat May 28 02:04:12 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 97EC3B4D10F for ; Sat, 28 May 2016 02:04:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-188.reflexion.net [208.70.211.188]) (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 55A9B116F for ; Sat, 28 May 2016 02:04:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19635 invoked from network); 28 May 2016 02:04:37 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 May 2016 02:04:37 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Fri, 27 May 2016 22:04:43 -0400 (EDT) Received: (qmail 11721 invoked from network); 28 May 2016 02:04:42 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 May 2016 02:04:42 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B957DB1E001; Fri, 27 May 2016 19:03:52 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Mark Millard In-Reply-To: <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> Date: Fri, 27 May 2016 19:04:04 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <72F5F9FD-5854-455D-8844-C4E1887DCE9F@dsl-only.net> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> To: Bryan Drewery 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: Sat, 28 May 2016 02:04:12 -0000 FYI. . . I expect that building gcc49 with: + --with-local-prefix=3D/usr \ will help with system build activities via gcc49/g++49 by avoiding = /usr/local/include interfering. But I also expect that various port builds based on that same = gcc49/g++49 will have problems from not explicitly forcing = /usr/local/include to be looked at when appropriate/required --unless = something else is in place to do that separately. I expect some implicit = /usr/local/include references to the likes of some of the below list: > # diff -qr /usr/include/ /usr/local/include/ | grep /local/ | more > Only in /usr/local/include/: apr-1 > Files /usr/include/atf-c/defs.h and /usr/local/include/atf-c/defs.h = differ > Only in /usr/local/include/: autosprintf.h > Only in /usr/local/include/: bfd.h > Only in /usr/local/include/: bfdlink.h > Only in /usr/local/include/: boost > Only in /usr/local/include/: curl > Only in /usr/local/include/: db5 > Only in /usr/local/include/: dis-asm.h > Files /usr/include/dwarf.h and /usr/local/include/dwarf.h differ > Only in /usr/local/include/: editline > Only in /usr/local/include/: expat.h > Only in /usr/local/include/: expat_config.h > Only in /usr/local/include/: expat_external.h > Only in /usr/local/include/: ffi.h > Only in /usr/local/include/: ffitarget.h > Only in /usr/local/include/: gdbm.h > Only in /usr/local/include/: gettext-po.h > Only in /usr/local/include/: gmp.h > Only in /usr/local/include/: gmpxx.h > Only in /usr/local/include/: gnumake.h > Files /usr/include/histedit.h and /usr/local/include/histedit.h differ > Only in /usr/local/include/: idn-free.h > Only in /usr/local/include/: idn-int.h > Only in /usr/local/include/: idna.h > Only in /usr/local/include/: layout > Files /usr/include/libdwarf.h and /usr/local/include/libdwarf.h differ > Only in /usr/local/include/: libintl.h > Only in /usr/local/include/: lua52 > Only in /usr/local/include/: lutok > Only in /usr/local/include/: mpc.h > Only in /usr/local/include/: mpf2mpfr.h > Only in /usr/local/include/: mpfr.h > Only in /usr/local/include/: pkg.h > Only in /usr/local/include/: plugin-api.h > Only in /usr/local/include/: pr29.h > Only in /usr/local/include/: punycode.h > Only in /usr/local/include/: python2.7 > Only in /usr/local/include/: readline > Only in /usr/local/include/: ruby-2.2 > Only in /usr/local/include/: serf-1 > Only in /usr/local/include/: sqlite3.h > Only in /usr/local/include/: sqlite3ext.h > Only in /usr/local/include/: stringprep.h > Only in /usr/local/include/: subversion-1 > Only in /usr/local/include/: sudo_plugin.h > Only in /usr/local/include/: symcat.h > Only in /usr/local/include/: tld.h > Only in /usr/local/include/: unicode > Only in /usr/local/include/: yaml.h It might be that even gcc compilers built by the adjusted gcc49 would = not find, say, gmp.h or mpfr.h . dwarfdump's build/install installs /usr/local/include/dwarf.h and = /usr/local/include/libdwarf.h to match its code. Such examples can need = careful control over which file is used (here dwarf.h and libdwarf.h in = /usr/include vs. /usr/local/include ). (It will still be some time before I get to switch to this = with-local-prefix experiment.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-May-27, at 5:23 PM, Bryan Drewery = wrote: > On 5/27/2016 5:15 PM, Mark Millard wrote: >> + --with-local-prefix=3D/usr/include \ >>=20 >> looks wrong to me. The default is not /usr/local/include but just = /usr/local . Quoting https://gcc.gnu.org/install/configure.html : >>=20 >> --with-local-prefix=3Ddirname >> Specify the installation directory for local include files. The = default is /usr/local. Specify this option if you want the compiler to = search directory dirname/include for locally installed header files = instead of /usr/local/include. >>=20 >> So your change would generate /usr/include/include for the overall = include path from what I can tell. >>=20 >> Do you want: >>=20 >> + --with-local-prefix=3D/usr \ >>=20 >> instead? >=20 > You're right, but it makes no real difference since it removes > /usr/local/include: >=20 >> ignoring nonexistent directory = "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x86_= 64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/inc= lude" >> ignoring duplicate directory = "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/../.= ./../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include" >> ignoring nonexistent directory "/usr/include/include" >=20 > ^ yes wrong >=20 >> ignoring duplicate directory = "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/../.= ./../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed" >> ignoring nonexistent directory = "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/../.= ./../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-= portbld-freebsd11.0/include" >> #include "..." search starts here: >> #include <...> search starts here: >> = /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x86_6= 4-portbld-freebsd11.0/4.9.4/include >> = /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x86_6= 4-portbld-freebsd11.0/4.9.4/include-fixed >> = /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/../..= /../include >> /usr/include >=20 > ^ Still added >=20 >> End of search list. >=20 >=20 >=20 > --=20 > Regards, > Bryan Drewery >=20 >=20 From owner-freebsd-toolchain@freebsd.org Sat May 28 02:35: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 B73ECB4D8CF for ; Sat, 28 May 2016 02:35:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-192.reflexion.net [208.70.211.192]) (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 767921F06 for ; Sat, 28 May 2016 02:35:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19452 invoked from network); 28 May 2016 02:35:50 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 May 2016 02:35:50 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Fri, 27 May 2016 22:35:15 -0400 (EDT) Received: (qmail 11462 invoked from network); 28 May 2016 02:35:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 May 2016 02:35:15 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1A28A1C43D2; Fri, 27 May 2016 19:35:05 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Mark Millard In-Reply-To: <72F5F9FD-5854-455D-8844-C4E1887DCE9F@dsl-only.net> Date: Fri, 27 May 2016 19:35:16 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> <72F5F9FD-5854-455D-8844-C4E1887DCE9F@dsl-only.net> To: Bryan Drewery 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: Sat, 28 May 2016 02:35:25 -0000 On 2016-May-27, at 7:04 PM, Mark Millard wrote: > FYI. . . >=20 > I expect that building gcc49 with: >=20 > + --with-local-prefix=3D/usr \ >=20 > will help with system build activities via gcc49/g++49 by avoiding = /usr/local/include interfering. >=20 > But I also expect that various port builds based on that same = gcc49/g++49 will have problems from not explicitly forcing = /usr/local/include to be looked at when appropriate/required --unless = something else is in place to do that separately. I expect some implicit = /usr/local/include references to the likes of some of the below list: >=20 >> # diff -qr /usr/include/ /usr/local/include/ | grep /local/ | more >> Only in /usr/local/include/: apr-1 >> Files /usr/include/atf-c/defs.h and /usr/local/include/atf-c/defs.h = differ >> Only in /usr/local/include/: autosprintf.h >> Only in /usr/local/include/: bfd.h >> Only in /usr/local/include/: bfdlink.h >> Only in /usr/local/include/: boost >> Only in /usr/local/include/: curl >> Only in /usr/local/include/: db5 >> Only in /usr/local/include/: dis-asm.h >> Files /usr/include/dwarf.h and /usr/local/include/dwarf.h differ >> Only in /usr/local/include/: editline >> Only in /usr/local/include/: expat.h >> Only in /usr/local/include/: expat_config.h >> Only in /usr/local/include/: expat_external.h >> Only in /usr/local/include/: ffi.h >> Only in /usr/local/include/: ffitarget.h >> Only in /usr/local/include/: gdbm.h >> Only in /usr/local/include/: gettext-po.h >> Only in /usr/local/include/: gmp.h >> Only in /usr/local/include/: gmpxx.h >> Only in /usr/local/include/: gnumake.h >> Files /usr/include/histedit.h and /usr/local/include/histedit.h = differ >> Only in /usr/local/include/: idn-free.h >> Only in /usr/local/include/: idn-int.h >> Only in /usr/local/include/: idna.h >> Only in /usr/local/include/: layout >> Files /usr/include/libdwarf.h and /usr/local/include/libdwarf.h = differ >> Only in /usr/local/include/: libintl.h >> Only in /usr/local/include/: lua52 >> Only in /usr/local/include/: lutok >> Only in /usr/local/include/: mpc.h >> Only in /usr/local/include/: mpf2mpfr.h >> Only in /usr/local/include/: mpfr.h >> Only in /usr/local/include/: pkg.h >> Only in /usr/local/include/: plugin-api.h >> Only in /usr/local/include/: pr29.h >> Only in /usr/local/include/: punycode.h >> Only in /usr/local/include/: python2.7 >> Only in /usr/local/include/: readline >> Only in /usr/local/include/: ruby-2.2 >> Only in /usr/local/include/: serf-1 >> Only in /usr/local/include/: sqlite3.h >> Only in /usr/local/include/: sqlite3ext.h >> Only in /usr/local/include/: stringprep.h >> Only in /usr/local/include/: subversion-1 >> Only in /usr/local/include/: sudo_plugin.h >> Only in /usr/local/include/: symcat.h >> Only in /usr/local/include/: tld.h >> Only in /usr/local/include/: unicode >> Only in /usr/local/include/: yaml.h >=20 > It might be that even gcc compilers built by the adjusted gcc49 would = not find, say, gmp.h or mpfr.h . >=20 > dwarfdump's build/install installs /usr/local/include/dwarf.h and = /usr/local/include/libdwarf.h to match its code. Such examples can need = careful control over which file is used (here dwarf.h and libdwarf.h in = /usr/include vs. /usr/local/include ). >=20 > (It will still be some time before I get to switch to this = with-local-prefix experiment.) >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net Given the above I may try using + --with-local-prefix=3D/usr \ only for building devel/powerpc64-gcc initially because I do not use = devel/powerpc64-gcc to build ports, just for system-build activities. = devel/powerpc64-gcc has the /usr/local/include problem for system build = activities too. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-May-27, at 5:23 PM, Bryan Drewery = wrote: > On 5/27/2016 5:15 PM, Mark Millard wrote: >> + --with-local-prefix=3D/usr/include \ >>=20 >> looks wrong to me. The default is not /usr/local/include but just = /usr/local . Quoting https://gcc.gnu.org/install/configure.html : >>=20 >> --with-local-prefix=3Ddirname >> Specify the installation directory for local include files. The = default is /usr/local. Specify this option if you want the compiler to = search directory dirname/include for locally installed header files = instead of /usr/local/include. >>=20 >> So your change would generate /usr/include/include for the overall = include path from what I can tell. >>=20 >> Do you want: >>=20 >> + --with-local-prefix=3D/usr \ >>=20 >> instead? >=20 > You're right, but it makes no real difference since it removes > /usr/local/include: >=20 >> ignoring nonexistent directory = "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x86_= 64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/inc= lude" >> ignoring duplicate directory = "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/../.= ./../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include" >> ignoring nonexistent directory "/usr/include/include" >=20 > ^ yes wrong >=20 >> ignoring duplicate directory = "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/../.= ./../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed" >> ignoring nonexistent directory = "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/../.= ./../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-= portbld-freebsd11.0/include" >> #include "..." search starts here: >> #include <...> search starts here: >> = /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x86_6= 4-portbld-freebsd11.0/4.9.4/include >> = /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x86_6= 4-portbld-freebsd11.0/4.9.4/include-fixed >> = /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/../..= /../include >> /usr/include >=20 > ^ Still added >=20 >> End of search list. >=20 >=20 >=20 > --=20 > Regards, > Bryan Drewery >=20 >=20 From owner-freebsd-toolchain@freebsd.org Sat May 28 04:18:03 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 F030AB4D13F for ; Sat, 28 May 2016 04:18:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-172.reflexion.net [208.70.211.172]) (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 B4ACE16DA for ; Sat, 28 May 2016 04:18:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15702 invoked from network); 28 May 2016 04:17:57 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 May 2016 04:17:57 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 28 May 2016 00:18:39 -0400 (EDT) Received: (qmail 17840 invoked from network); 28 May 2016 04:18:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 May 2016 04:18:38 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 3B7491C43E9; Fri, 27 May 2016 21:17:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0-CURRENT -r300770 libc++ update vs. lang/powerpc64-xtoolchain-gcc: no go [self hosted powerpc64 context] From: Mark Millard In-Reply-To: <3BAE82F4-3BF4-4F02-9BFF-3F2290D3C82D@dsl-only.net> Date: Fri, 27 May 2016 21:18:00 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-ports@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0C88C11C-154A-459B-98EB-2A80A166DBCE@dsl-only.net> References: <95E2A9D6-8E1A-46FB-84FF-60927A6F1CE4@dsl-only.net> <8FAD594D-4349-4EA7-A712-D3792537FB1D@FreeBSD.org> <42773110-C392-4168-9B94-6902807DB530@dsl-only.net> <3BAE82F4-3BF4-4F02-9BFF-3F2290D3C82D@dsl-only.net> To: Dimitry Andric 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: Sat, 28 May 2016 04:18:04 -0000 On 2016-May-27, at 6:04 PM, Mark Millard wrote: > [Top posting failure results again.] >=20 > -r300886 for powerpc64 failed for each of: >=20 > = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis/AnalysisDeclContext.cpp >=20 > = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/li= b/ARCMigrate/ARCMT.cpp >=20 > with the likes of: >=20 >> --- all_subdir_lib/clang --- >> In file included from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/../../lib/clang/= include/llvm/Support/DataTypes.h:36:0, >> from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include/llvm/ADT= /Hashing.h:48, >> from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include/llvm/ADT= /ArrayRef.h:13, >> from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include/llvm/ADT= /APInt.h:19, >> from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include/llvm/ADT= /APFloat.h:20, >> from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/incl= ude/clang/AST/APValue.h:18, >> from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/incl= ude/clang/AST/Decl.h:17, >> from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/incl= ude/clang/Analysis/AnalysisContext.h:18, >> from = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis/AnalysisDeclContext.cpp:15: >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :309:9: error: '::signbit' has not been declared >> using ::signbit; >> ^ >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :310:9: error: '::fpclassify' has not been declared >> using ::fpclassify; >> ^ >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :311:9: error: '::isfinite' has not been declared >> using ::isfinite; >> ^ >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :312:9: error: '::isinf' has not been declared >> using ::isinf; >> ^ >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :313:9: error: '::isnan' has not been declared >> using ::isnan; >> ^ >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :314:9: error: '::isnormal' has not been declared >> using ::isnormal; >> ^ >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :315:9: error: '::isgreater' has not been declared >> using ::isgreater; >> ^ >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :316:9: error: '::isgreaterequal' has not been declared >> using ::isgreaterequal; >> ^ >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :317:9: error: '::isless' has not been declared >> using ::isless; >> ^ >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :318:9: error: '::islessequal' has not been declared >> using ::islessequal; >> ^ >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :319:9: error: '::islessgreater' has not been declared >> using ::islessgreater; >> ^ >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :320:9: error: '::isunordered' has not been declared >> using ::isunordered; >> ^ >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :321:9: error: '::isunordered' has not been declared >> using ::isunordered; >> ^ >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :327:9: error: '::abs' has not been declared >> using ::abs; >> ^ >=20 > . . . (then later the other file gets similar results) . . . >=20 >> --- all_subdir_lib/clang --- >> In file included from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/../../lib/clan= g/include/llvm/Support/DataTypes.h:36:0, >> from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include/llvm/A= DT/Hashing.h:48, >> from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include/llvm/A= DT/ArrayRef.h:13, >> from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include/llvm/A= DT/DenseMapInfo.h:17, >> from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/include/llvm/A= DT/DenseMap.h:17, >> from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/in= clude/clang/ARCMigrate/FileRemapper.h:14, >> from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/in= clude/clang/ARCMigrate/ARCMT.h:13, >> from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/li= b/ARCMigrate/Internals.h:13, >> from = /usr/src/lib/clang/libclangarcmigrate/../../../contrib/llvm/tools/clang/li= b/ARCMigrate/ARCMT.cpp:10: >> = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/cmath= :309:9: error: '::signbit' has not been declared >> using ::signbit; >> ^ > . . . (similar list) . . . >=20 >=20 > Based on (from a -v output): >=20 >> ignoring nonexistent directory = "/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/local/include" >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerp= c64-portbld-freebsd11.0/include" >> ignoring duplicate directory = "/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include >> = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/incl= ude >> = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/= Analysis >> . >> = /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/../../lib/clang/= include >> /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include >> /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1 >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed >> End of search list. >=20 > I could try building without clang being included if you want. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net The -r300886 powerpc64 devel/powerpc64-gcc combination with no clang = build included has failed: --- all_subdir_usr.bin --- endian.h(111): warning: bitwise operation on signed value possibly = nonportable [117] endian.h(127): warning: extra bits set to 0 in conversion of 'unsigned = int' to 'unsigned long long', op & [309] types.h(316): warning: bitwise operation on signed value possibly = nonportable [117] types.h(317): warning: bitwise operation on signed value possibly = nonportable [117] types.h(318): warning: bitwise operation on signed value possibly = nonportable [117] types.h(319): warning: bitwise operation on signed value possibly = nonportable [117] types.h(355): warning: conversion to 'unsigned int' due to prototype, = arg #1 [259] types.h(355): warning: conversion from 'unsigned long long' to 'unsigned = int' may lose accuracy, arg #1 [298] types.h(355): warning: conversion to 'unsigned int' due to prototype, = arg #1 [259] types.h(355): warning: conversion from 'unsigned long long' to 'unsigned = int' may lose accuracy, arg #1 [298] stdarg.h(40): syntax error [249] stdarg.h(98): syntax error [249] llib-lposix(307): syntax error [249] llib-lposix(308): syntax error [249] llib-lposix(309): syntax error [249] llib-lposix(309): cannot recover from previous errors [224] *** [llib-lposix.ln] Error code 1 make[5]: stopped in /usr/src/usr.bin/xlint/llib 1 error The -r300886 powerpc (non-64) system-clang based combination for = buildworld had no such problem and included rebuilding clang. So the = problems are apparently devel/powerpc64-gcc specific or at least = gcc-port specific. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-May-27, at 4:40 PM, Mark Millard wrote: > [I'm top posting the results of the failed build.] >=20 > It looks like the following has been addresses in -r300884. libcompat = also got a -isystem in -r300885. -r300886 did "Move external GCC = compiler hacks to bsd.sys.mk". >=20 > So I'll retry based on -r300886. >=20 >=20 >=20 > Failure details. . . >=20 >=20 > Both the powerpc64 lang/powerpc64-xtoolchain-gcc and powerpc clang = combinations failed for -r300875. The details are rather different this = time and might not be related to your libc++ changes. Both contexts got = the same error. >=20 > powerpc64 lang/powerpc64-xtoolchain-gcc: >=20 >> --- all_subdir_cddl/lib/libzpool --- >> In file included from = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs/arc.c:144:0: >> /usr/src/sys/vm/vm_pageout.h:77:8: error: unknown type name 'bool' >> extern bool vm_pageout_wanted; >> ^ >> /usr/src/sys/vm/vm_pageout.h:78:8: error: unknown type name 'bool' >> extern bool vm_pages_needed; >> ^ >=20 >=20 > The -v search list information was: >=20 >> ignoring nonexistent directory = "/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/local/include" >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerp= c64-portbld-freebsd11.0/include" >> ignoring duplicate directory = "/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include" >> ignoring nonexistent directory = "/usr/src/cddl/lib/libzpool/../../../lib/libpthread/thread" >> ignoring nonexistent directory = "/usr/src/cddl/lib/libzpool/../../../lib/libpthread/sys" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris >> /usr/src/cddl/lib/libzpool/../../compat/opensolaris/include >> /usr/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem >> = /usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common >> = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/sys >> = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs >> = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/zf= s >> = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n >> /usr/src/cddl/lib/libzpool/../../contrib/opensolaris/head >> /usr/src/cddl/lib/libzpool/../../lib/libumem >> /usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair >> /usr/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include >> /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed >> End of search list. >=20 > This was for: >=20 >> /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -isystem = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include = -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp = -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris = -I/usr/src/cddl/lib/libzpool/../../compat/opensolaris/include = -I/usr/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem = -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common= = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon/sys = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon/fs/zfs = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/= zfs = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/head = -I/usr/src/cddl/lib/libzpool/../../lib/libumem = -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair = -DWANTS_MUTEX_OWNED = -I/usr/src/cddl/lib/libzpool/../../../lib/libpthread/thread = -I/usr/src/cddl/lib/libzpool/../../../lib/libpthread/sys = -I/usr/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -g = -DDEBUG=3D1 -DNEED_SOLARIS_BOOLEAN -MD -MF.depend.arc.o -MTarc.o = -std=3Diso9899:1999 -fstack-protector-strong -Wno-pointer-sign = -Wno-error=3Dunused-function -Wno-error=3Denum-compare = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare = -Wno-error=3Duninitialized -Wno-error=3Darray-bounds = -Wno-error=3Dclobbered -Wno-error=3Dcast-align -Wno-error=3Dextra = -Wno-error=3Dattributes -Wno-error=3Dinline = -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value = -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress -Wno-unknown-pragmas = -v -c = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs/arc.c -o arc.o >=20 >=20 > powerpc sytem clang: >=20 >> --- all_subdir_cddl/lib/libzpool --- >> In file included from = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs/arc.c:144: >> = /usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/include/vm/vm_pageout.h:77:= 8: error: unknown type name 'bool' >> extern bool vm_pageout_wanted; >> ^ >> = /usr/obj/clang/powerpc.powerpc/usr/src/tmp/usr/include/vm/vm_pageout.h:78:= 8: error: unknown type name 'bool' >> extern bool vm_pages_needed; >> ^ >=20 > This was for: >=20 >> --- arc.o --- >> cc -O2 -pipe = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/compat/opensolaris = -I/usr/src/cddl/lib/libzpool/../../compat/opensolaris/include = -I/usr/src/cddl/lib/libzpool/../../compat/opensolaris/lib/libumem = -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libzpool/common= = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon/sys = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon/fs/zfs = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/common/= zfs = -I/usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/com= mon -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/head = -I/usr/src/cddl/lib/libzpool/../../lib/libumem = -I/usr/src/cddl/lib/libzpool/../../contrib/opensolaris/lib/libnvpair = -DWANTS_MUTEX_OWNED = -I/usr/src/cddl/lib/libzpool/../../../lib/libpthread/thread = -I/usr/src/cddl/lib/libzpool/../../../lib/libpthread/sys = -I/usr/src/cddl/lib/libzpool/../../../lib/libthr/arch/powerpc/include -g = -DDEBUG=3D1 -DNEED_SOLARIS_BOOLEAN -MD -MF.depend.arc.o -MTarc.o = -std=3Diso9899:1999 -fstack-protector-strong -Wno-pointer-sign = -Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int = -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value = -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion = -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c = /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/commo= n/fs/zfs/arc.c -o arc.o >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi@dsl-only.net >=20 > On 2016-May-27, at 2:56 PM, Mark Millard wrote: >=20 >> On 2016-May-27, at 1:50 PM, Dimitry Andric = wrote: >>>=20 >>> On 27 May 2016, at 01:53, Mark Millard = wrote: >>>>=20 >>>> I do buildworld/buildkernel on a powerpc64 targeting itself via = lang/powerpc64-xtoolchain-gcc (a.k.a. lang/powerpc64-gcc for the most = part). [Getting that lang/powerpc64-gcc installed for self-hosted use = does take some work-around activity.] I have buildworld build clang (but = not use it). [I've been doing this with 11.0-CURRENT for a long time.] >>>>=20 >>>> Actually I use lang/gcc49 as the "system compiler" and = lang/powerpc64-gcc as the self-hosting so-called "cross compiler". (I = later list the src.conf content.) gcc4.2.1 is not installed. >>>>=20 >>>> Trying to go from: >>>>=20 >>>>> # uname -apKU >>>>> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #36 r300531M: = Mon May 23 20:13:52 PDT 2016 = root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64v= tsc-NODEBUG powerpc powerpc64 1100111 1100111 >>>>=20 >>>> (for which -r300531 built and installed fine this way) to -r300777 = now fails with errors such as: >>>>=20 >>>>> --- lib/libc++__L --- >>>>> In file included from = /usr/src/lib/libc++/../../contrib/libc++/include/iterator:346:0, >>>>> from = /usr/src/lib/libc++/../../contrib/libc++/include/memory:606, >>>>> from = /usr/src/lib/libc++/../../contrib/libc++/include/algorithm:628, >>>>> from = /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp:10: >>>>> /usr/src/lib/libc++/../../contrib/libc++/include/iosfwd:176:14: = error: 'mbstate_t' was not declared in this scope >>>>> typedef fpos streampos; >>>>> ^ >>>=20 >>> This is hopefully fixed by r300873 now. Can you please verify? >>>=20 >>> -Dimitry >>=20 >> buildworld/buildkernel started, based on -r300875 for powerpc64 = under/on powerpc64 FreeBSD via lang/powerpc-xtoolchain-gcc as the = so-called "cross compiler". If it completes successfully it takes about = 8 hours for what I normally include in such builds. >>=20 >> I've also started a clang-based buildworld for powerpc (non-64) under = powerpc FreeBSD as a cross check. (This environment involves work = arounds, such as changes to signal delivery to avoid clang's code = generation ABI violations in its stack handling. A clang based = buildkernel would not complete so I would use a separate gcc 4.2.1 = kernel build to get an overall system.) >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >>=20 >=20 From owner-freebsd-toolchain@freebsd.org Sat May 28 09:24: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 BF231B4C60E for ; Sat, 28 May 2016 09:24:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-167.reflexion.net [208.70.211.167]) (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 7E5351FF4 for ; Sat, 28 May 2016 09:24:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13311 invoked from network); 28 May 2016 09:25:07 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 May 2016 09:25:07 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 28 May 2016 05:25:13 -0400 (EDT) Received: (qmail 25560 invoked from network); 28 May 2016 09:25:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 May 2016 09:25:13 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4DBF51C43D2; Sat, 28 May 2016 02:24:34 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Mark Millard In-Reply-To: Date: Sat, 28 May 2016 02:24:34 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh Content-Transfer-Encoding: quoted-printable Message-Id: <0FA52C68-43C4-489D-9EB2-2339C2B812F5@dsl-only.net> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> <72F5F9FD-5854-455D-8844-C4E1887DCE9F@dsl-only.net> To: Bryan Drewery 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: Sat, 28 May 2016 09:24:37 -0000 --with-local-prefix=3D/usr was insufficient to avoid /usr/local/include = in the search list in powerpc64-gcc: > ignoring duplicate directory = "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include" > ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerp= c64-portbld-freebsd11.0/include" > ignoring duplicate directory = "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/src/gnu/lib/libssp/libssp_nonshared/.. > = /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libss= p > = /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/inclu= de > /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include > /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include > /usr/local/include > /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed > End of search list. Which came from (which shows the --with-local-prefix=3D/usr use): > Configured with: = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.3.0/configure = --target=3Dpowerpc64-portbld-freebsd11.0 --disable-nls = --enable-languages=3Dc,c++ --without-headers --with-gmp=3D/usr/local = --with-local-prefix=3D/usr --with-pkgversion=3D'FreeBSD Ports Collection = for powerpc64' --with-system-zlib = --with-as=3D/usr/local/bin/powerpc64-freebsd-as = --with-ld=3D/usr/local/bin/powerpc64-freebsd-ld --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/ --build=3Dpowerpc64-portbld-freebsd11.0 In Makefile terms: > # svnlite diff /usr/ports/devel/powerpc64-gcc/Makefile=20 > Index: /usr/ports/devel/powerpc64-gcc/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/ports/devel/powerpc64-gcc/Makefile (revision 415874) > +++ /usr/ports/devel/powerpc64-gcc/Makefile (working copy) > @@ -43,6 +43,7 @@ > CONFIGURE_ARGS+=3D--target=3D${GCC_TARGET} --disable-nls = --enable-languages=3Dc,c++ \ > --without-headers \ > --with-gmp=3D${LOCALBASE} \ > + --with-local-prefix=3D/usr \ > --with-pkgversion=3D"FreeBSD Ports Collection for = ${PKGNAMEPREFIX:C/-//g}" \ > --with-system-zlib \ > --with-as=3D${LOCALBASE}/bin/${BU_PREFIX}-as \ Note: "Specifying --prefix has no effect on which directory GCC searches = for local header files". Some interesting wording is: "The same value can be used for both = --with-local-prefix and --prefix provided it is not /usr" and "This can = be used to avoid the default search of /usr/local/include". Also: "The = purpose of --prefix is to specify where to install GCC" and "The local = header files in /usr/local/include=97if you put any in that = directory=97are not part of GCC". My overall interpretation of that is that in my context: = --with-local-prefix=3D/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3= .0 a.k.a.: --with-local-prefix=3D${LOCALBASE}/lib/gcc/${GCC_TARGET}/${PORTVERSION} would make for a redundant overall search path without changing the = ordering. I have not figured out why /usr/local/include continued to show up and = /usr/include did not. I wonder if they have special logic for if /usr is = assigned and so force back there specified default. I'll try rebuilding devel/powerpc64-gcc again based on: --with-local-prefix=3D${LOCALBASE}/lib/gcc/${GCC_TARGET}/${PORTVERSION} =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-May-27, at 7:35 PM, Mark Millard wrote: > On 2016-May-27, at 7:04 PM, Mark Millard = wrote: >=20 >> FYI. . . >>=20 >> I expect that building gcc49 with: >>=20 >> + --with-local-prefix=3D/usr \ >>=20 >> will help with system build activities via gcc49/g++49 by avoiding = /usr/local/include interfering. >>=20 >> But I also expect that various port builds based on that same = gcc49/g++49 will have problems from not explicitly forcing = /usr/local/include to be looked at when appropriate/required --unless = something else is in place to do that separately. I expect some implicit = /usr/local/include references to the likes of some of the below list: >>=20 >>> # diff -qr /usr/include/ /usr/local/include/ | grep /local/ | more >>> Only in /usr/local/include/: apr-1 >>> Files /usr/include/atf-c/defs.h and /usr/local/include/atf-c/defs.h = differ >>> Only in /usr/local/include/: autosprintf.h >>> Only in /usr/local/include/: bfd.h >>> Only in /usr/local/include/: bfdlink.h >>> Only in /usr/local/include/: boost >>> Only in /usr/local/include/: curl >>> Only in /usr/local/include/: db5 >>> Only in /usr/local/include/: dis-asm.h >>> Files /usr/include/dwarf.h and /usr/local/include/dwarf.h differ >>> Only in /usr/local/include/: editline >>> Only in /usr/local/include/: expat.h >>> Only in /usr/local/include/: expat_config.h >>> Only in /usr/local/include/: expat_external.h >>> Only in /usr/local/include/: ffi.h >>> Only in /usr/local/include/: ffitarget.h >>> Only in /usr/local/include/: gdbm.h >>> Only in /usr/local/include/: gettext-po.h >>> Only in /usr/local/include/: gmp.h >>> Only in /usr/local/include/: gmpxx.h >>> Only in /usr/local/include/: gnumake.h >>> Files /usr/include/histedit.h and /usr/local/include/histedit.h = differ >>> Only in /usr/local/include/: idn-free.h >>> Only in /usr/local/include/: idn-int.h >>> Only in /usr/local/include/: idna.h >>> Only in /usr/local/include/: layout >>> Files /usr/include/libdwarf.h and /usr/local/include/libdwarf.h = differ >>> Only in /usr/local/include/: libintl.h >>> Only in /usr/local/include/: lua52 >>> Only in /usr/local/include/: lutok >>> Only in /usr/local/include/: mpc.h >>> Only in /usr/local/include/: mpf2mpfr.h >>> Only in /usr/local/include/: mpfr.h >>> Only in /usr/local/include/: pkg.h >>> Only in /usr/local/include/: plugin-api.h >>> Only in /usr/local/include/: pr29.h >>> Only in /usr/local/include/: punycode.h >>> Only in /usr/local/include/: python2.7 >>> Only in /usr/local/include/: readline >>> Only in /usr/local/include/: ruby-2.2 >>> Only in /usr/local/include/: serf-1 >>> Only in /usr/local/include/: sqlite3.h >>> Only in /usr/local/include/: sqlite3ext.h >>> Only in /usr/local/include/: stringprep.h >>> Only in /usr/local/include/: subversion-1 >>> Only in /usr/local/include/: sudo_plugin.h >>> Only in /usr/local/include/: symcat.h >>> Only in /usr/local/include/: tld.h >>> Only in /usr/local/include/: unicode >>> Only in /usr/local/include/: yaml.h >>=20 >> It might be that even gcc compilers built by the adjusted gcc49 would = not find, say, gmp.h or mpfr.h . >>=20 >> dwarfdump's build/install installs /usr/local/include/dwarf.h and = /usr/local/include/libdwarf.h to match its code. Such examples can need = careful control over which file is used (here dwarf.h and libdwarf.h in = /usr/include vs. /usr/local/include ). >>=20 >> (It will still be some time before I get to switch to this = with-local-prefix experiment.) >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > Given the above I may try using >=20 > + --with-local-prefix=3D/usr \ >=20 > only for building devel/powerpc64-gcc initially because I do not use = devel/powerpc64-gcc to build ports, just for system-build activities. = devel/powerpc64-gcc has the /usr/local/include problem for system build = activities too. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 On 2016-May-27, at 5:23 PM, Bryan Drewery = wrote: > On 5/27/2016 5:15 PM, Mark Millard wrote: >> + --with-local-prefix=3D/usr/include \ >>=20 >> looks wrong to me. The default is not /usr/local/include but just = /usr/local . Quoting https://gcc.gnu.org/install/configure.html : >>=20 >> --with-local-prefix=3Ddirname >> Specify the installation directory for local include files. The = default is /usr/local. Specify this option if you want the compiler to = search directory dirname/include for locally installed header files = instead of /usr/local/include. >>=20 >> So your change would generate /usr/include/include for the overall = include path from what I can tell. >>=20 >> Do you want: >>=20 >> + --with-local-prefix=3D/usr \ >>=20 >> instead? >=20 > You're right, but it makes no real difference since it removes > /usr/local/include: >=20 >> ignoring nonexistent directory = "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x86_= 64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-portbld-freebsd11.0/inc= lude" >> ignoring duplicate directory = "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/../.= ./../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include" >> ignoring nonexistent directory "/usr/include/include" >=20 > ^ yes wrong >=20 >> ignoring duplicate directory = "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/../.= ./../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed" >> ignoring nonexistent directory = "/root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/../.= ./../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/../../../../../x86_64-= portbld-freebsd11.0/include" >> #include "..." search starts here: >> #include <...> search starts here: >> = /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x86_6= 4-portbld-freebsd11.0/4.9.4/include >> = /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x86_6= 4-portbld-freebsd11.0/4.9.4/include-fixed >> = /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/../..= /../include >> /usr/include >=20 > ^ Still added >=20 >> End of search list. >=20 >=20 >=20 > --=20 > Regards, > Bryan Drewery >=20 >=20 From owner-freebsd-toolchain@freebsd.org Sat May 28 13:32: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 76B77B4E6E1; Sat, 28 May 2016 13:32:35 +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 378C81655; Sat, 28 May 2016 13:32:34 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::cce6:66d6:4bdd:cc70] (unknown [IPv6:2001:7b8:3a7:0:cce6:66d6:4bdd:cc70]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D18EF18AEA; Sat, 28 May 2016 15:32:32 +0200 (CEST) Subject: Re: 11.0-CURRENT -r300770 libc++ update vs. lang/powerpc64-xtoolchain-gcc: no go [self hosted powerpc64 context] Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FF5AB575-B720-48C8-976E-25288B17E822"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <0C88C11C-154A-459B-98EB-2A80A166DBCE@dsl-only.net> Date: Sat, 28 May 2016 15:32:23 +0200 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-ports@freebsd.org Message-Id: References: <95E2A9D6-8E1A-46FB-84FF-60927A6F1CE4@dsl-only.net> <8FAD594D-4349-4EA7-A712-D3792537FB1D@FreeBSD.org> <42773110-C392-4168-9B94-6902807DB530@dsl-only.net> <3BAE82F4-3BF4-4F02-9BFF-3F2290D3C82D@dsl-only.net> <0C88C11C-154A-459B-98EB-2A80A166DBCE@dsl-only.net> To: Mark Millard 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: Sat, 28 May 2016 13:32:35 -0000 --Apple-Mail=_FF5AB575-B720-48C8-976E-25288B17E822 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28 May 2016, at 06:18, Mark Millard wrote: ... > The -r300886 powerpc64 devel/powerpc64-gcc combination with no clang = build included has failed: >=20 > --- all_subdir_usr.bin --- > endian.h(111): warning: bitwise operation on signed value possibly = nonportable [117] > endian.h(127): warning: extra bits set to 0 in conversion of 'unsigned = int' to 'unsigned long long', op & [309] > types.h(316): warning: bitwise operation on signed value possibly = nonportable [117] > types.h(317): warning: bitwise operation on signed value possibly = nonportable [117] > types.h(318): warning: bitwise operation on signed value possibly = nonportable [117] > types.h(319): warning: bitwise operation on signed value possibly = nonportable [117] > types.h(355): warning: conversion to 'unsigned int' due to prototype, = arg #1 [259] > types.h(355): warning: conversion from 'unsigned long long' to = 'unsigned int' may lose accuracy, arg #1 [298] > types.h(355): warning: conversion to 'unsigned int' due to prototype, = arg #1 [259] > types.h(355): warning: conversion from 'unsigned long long' to = 'unsigned int' may lose accuracy, arg #1 [298] > stdarg.h(40): syntax error [249] > stdarg.h(98): syntax error [249] > llib-lposix(307): syntax error [249] > llib-lposix(308): syntax error [249] > llib-lposix(309): syntax error [249] > llib-lposix(309): cannot recover from previous errors [224] > *** [llib-lposix.ln] Error code 1 For me, r300886 didn't build at all, when I tried: CROSS_TOOLCHAIN=3Dpowerpc64-gcc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 = \ __MAKE_CONF=3D/dev/null SRCCONF=3D/dev/null make buildworld It always errors out at the very first file built for the libraries stage: -------------------------------------------------------------- >>> stage 4.2: building libraries -------------------------------------------------------------- cd /usr/src; CROSS_TOOLCHAIN=3D"powerpc64-gcc" = MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Di386 MACHINE=3Di386 = CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin = GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font = GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac = CC=3D"/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = --sysroot=3D/usr/obj/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/" = CXX=3D"/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ = --sysroot=3D/usr/obj/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/" = CPP=3D"/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp = --sysroot=3D/usr/obj/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/" = AS=3D"/usr/local/powerpc64-freebsd/bin/as" = AR=3D"/usr/local/powerpc64-freebsd/bin/ar" = LD=3D"/usr/local/powerpc64-freebsd/bin/ld" = NM=3D/usr/local/powerpc64-freebsd/bin/nm = OBJDUMP=3D/usr/local/powerpc64-freebsd/bin/objdump = OBJCOPY=3D"/usr/local/powerpc64-freebsd/bin/objcopy" = RANLIB=3D/usr/local/powerpc64-freebsd/bin/ranlib = STRINGS=3D/usr/local/powerpc64-freebsd/bin/ = SIZE=3D"/usr/local/powerpc64-freebsd/bin/size" INSTALL=3D"sh = /usr/src/tools/install.sh" = PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/us= r/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/o= bj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -f = Makefile.inc1 DESTDIR=3D/usr/obj/usr/src/tmp -DNO_FSCHG MK_HTML=3Dno = -DNO_LINT MK_MAN=3Dno MK_PROFILE=3Dno MK_TESTS=3Dno = MK_TESTS_SUPPORT=3Dyes libraries cd /usr/src; make -f Makefile.inc1 _prereq_libs; make -f Makefile.inc1 = _startup_libs; make -f Makefile.inc1 _prebuild_libs; make -f = Makefile.inc1 _generic_libs =3D=3D=3D> gnu/lib/libssp/libssp_nonshared (obj,all,install) building static ssp_nonshared library /usr/local/powerpc64-freebsd/bin/ar -crD libssp_nonshared.a = `NM=3D'/usr/local/powerpc64-freebsd/bin/nm' NMFLAGS=3D'' lorder = ssp-local.o | tsort -q` /usr/local/powerpc64-freebsd/bin/ranlib -D libssp_nonshared.a sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 = libssp_nonshared.a /usr/obj/usr/src/tmp/usr/lib/ =3D=3D=3D> gnu/lib/libgcc (obj,all,install) LC_ALL=3DC awk -f = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk < optionlist = > options.h /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = --sysroot=3D/usr/obj/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -c = -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED = -DHAVE_GTHR_DEFAULT = -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include = -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config = -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. = -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=3Dgnu99 = -Wno-error=3Dunused-function -Wno-error=3Denum-compare = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare = -Wno-error=3Duninitialized -Wno-error=3Darray-bounds = -Wno-error=3Dclobbered -Wno-error=3Dcast-align -Wno-error=3Dextra = -Wno-error=3Dattributes -Wno-error=3Dinline = -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value = -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress = -fvisibility=3Dhidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D3 = -DElfW=3D__ElfN -o unwind-dw2.o = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c In file included from = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:47:0, from = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:32: = /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include/stddef.h:56= :24: fatal error: sys/_types.h: No such file or directory compilation terminated. *** Error code 1 This is because r300886 filters out the -isystem options that point to ${WORLDTMP}/usr/include. When I build using r300885, it errors out while building the atf-c++ libraries: =3D=3D=3D> lib/atf/libatf-c++ (all) /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -isystem = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1 -std=3Dc++11 = -nostdinc++ -L/usr/obj/powerpc.powerpc64/usr/src/tmp/../lib/libc++ = -isystem /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include = -L/usr/obj/powerpc.powerpc64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/powerpc.powerpc64/usr/src/tmp = -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe -DHAVE_CONFIG_H = -I/usr/src/contrib/atf -I/usr/src/lib/atf/libatf-c++/../libatf-c -I. = -DHAVE_CONFIG_H -MD -MF.depend.application.o -MTapplication.o = -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k = -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized = -Wno-error=3Dunused-function -Wno-error=3Denum-compare = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare = -Wno-error=3Duninitialized -Wno-error=3Darray-bounds = -Wno-error=3Dclobbered -Wno-error=3Dcast-align -Wno-error=3Dextra = -Wno-error=3Dattributes -Wno-error=3Dinline = -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value = -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress -c = /usr/src/contrib/atf/atf-c++/detail/application.cpp -o application.o In file included from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/memory:616:0, from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/algorithm:628, from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/string:439, from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/__locale:15, from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/ios:216, from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/ostream:138, from = /usr/src/contrib/atf/atf-c++/detail/application.hpp:29, from = /usr/src/contrib/atf/atf-c++/detail/application.cpp:26: /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/atomic:571:0: = error: "_Atomic" redefined [-Werror] #define _Atomic(x) __gcc_atomic::__gcc_atomic_t ^ In file included from /usr/src/sys/sys/endian.h:32:0, from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/__config:96, from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/ostream:137, from = /usr/src/contrib/atf/atf-c++/detail/application.hpp:29, from = /usr/src/contrib/atf/atf-c++/detail/application.cpp:26: /usr/src/sys/sys/cdefs.h:283:0: note: this is the location of the = previous definition #define _Atomic(T) struct { T volatile __val; } ^ It appears that there is a conflict between how sys/cdefs.h defines _Atomic() and how the libc++ headers define it. It looks like the definition in the libc++ headers is more suitable for gcc, so maybe we should disable our custom definition in sys/defs.h when an external gcc is used? Or at least, disable it when compiling for C++. -Dimitry --Apple-Mail=_FF5AB575-B720-48C8-976E-25288B17E822 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 iEYEARECAAYFAldJnfAACgkQsF6jCi4glqO3NACfZVSSBhZWl3P58A3RzC6OD9Ro JuIAoJlvJBV9bBE14AktH7eD3XCvtz+2 =TaYs -----END PGP SIGNATURE----- --Apple-Mail=_FF5AB575-B720-48C8-976E-25288B17E822-- From owner-freebsd-toolchain@freebsd.org Sat May 28 16:44: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 5EEF7B4E5F4 for ; Sat, 28 May 2016 16:44:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-187.reflexion.net [208.70.211.187]) (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 21EF41ADD for ; Sat, 28 May 2016 16:44:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 20160 invoked from network); 28 May 2016 16:44:14 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 May 2016 16:44:14 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 28 May 2016 12:44:15 -0400 (EDT) Received: (qmail 18883 invoked from network); 28 May 2016 16:44:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 May 2016 16:44:15 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 9579EB1E001; Sat, 28 May 2016 09:44:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0-CURRENT -r300770 libc++ update vs. lang/powerpc64-xtoolchain-gcc: no go [self hosted powerpc64 context] From: Mark Millard In-Reply-To: Date: Sat, 28 May 2016 09:44:17 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-ports@freebsd.org, Bryan Drewery Content-Transfer-Encoding: quoted-printable Message-Id: References: <95E2A9D6-8E1A-46FB-84FF-60927A6F1CE4@dsl-only.net> <8FAD594D-4349-4EA7-A712-D3792537FB1D@FreeBSD.org> <42773110-C392-4168-9B94-6902807DB530@dsl-only.net> <3BAE82F4-3BF4-4F02-9BFF-3F2290D3C82D@dsl-only.net> <0C88C11C-154A-459B-98EB-2A80A166DBCE@dsl-only.net> To: Dimitry Andric 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: Sat, 28 May 2016 16:44:25 -0000 I'll update to 11.0 -r300904 to pick up the external toolchain fix for = -r300886's problem. > CROSS_TOOLCHAIN=3Dpowerpc64-gcc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64= \ > __MAKE_CONF=3D/dev/null SRCCONF=3D/dev/null make buildworld The above likely would have problems with finding files in = /usr/local/include when devel/powerpc64-gcc is in use and various ports = have been built. If you use -v for the gcc based compiles the search = list will show /usr/local/include in the list the way that = devel/powerpc64-gcc is normally built. In my context there are some = files from ports there that would conflict with some system headers. Bryan Drewery is having me do experiments with building gcc with = --with-local-prefix assigned to avoid this. (I started these experiments = after my last report to you.) Before this I was using C_INCLUDE_PAPTH = and CPLUS_INCLUDE_PATH to have /usr/include and /usr/include/c++/v1 = searched before /usr/local/include based paths. Actually so far I'm only doing the experiment with devel/powerpc64-gcc = (used as the so-called "cross compiler" in my self-hosted context), not = with the lang/gcc49 that I use as the system compiler: for lang/gcc49 = I'm still using C_INCLUDE_PAPTH and CPLUS_INCLUDE_PATH to avoid = /usr/local/include based paths from finding files. In part this is = because I expect port building problems if I use lang/gcc49 to build = ports without lang/gcc49 having /usr/local/include implicitly. I do not = use devel/powerpc64-gcc to build ports. As stands I will next be trying building devel/powerpc64-gcc based on: --with-local-prefix=3D${LOCALBASE}/lib/gcc/${GCC_TARGET}/${PORTVERSION} which should make the search list entry (when it tacks on /include) a = redundant one with the one that follows what would otherwise be = /usr/local/include in the list. Using --with-local-prefix=3D/usr still = resulted in /usr/local/include being in the search list. No surprise = given that https://gcc.gnu.org/install/configure.html says: > Do not specify /usr as the --with-local-prefix! The directory you use = for --with-local-prefix must not contain any of the system's standard = header files. If it did contain them, certain programs would be = miscompiled (including GNU Emacs, on certain targets), because this = would override and nullify the header file corrections made by the = fixincludes script. It looks like they have code to detect the attempt to use /usr and = prevent it. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-May-28, at 6:32 AM, Dimitry Andric wrote: > On 28 May 2016, at 06:18, Mark Millard wrote: > ... >> The -r300886 powerpc64 devel/powerpc64-gcc combination with no clang = build included has failed: >>=20 >> --- all_subdir_usr.bin --- >> endian.h(111): warning: bitwise operation on signed value possibly = nonportable [117] >> endian.h(127): warning: extra bits set to 0 in conversion of = 'unsigned int' to 'unsigned long long', op & [309] >> types.h(316): warning: bitwise operation on signed value possibly = nonportable [117] >> types.h(317): warning: bitwise operation on signed value possibly = nonportable [117] >> types.h(318): warning: bitwise operation on signed value possibly = nonportable [117] >> types.h(319): warning: bitwise operation on signed value possibly = nonportable [117] >> types.h(355): warning: conversion to 'unsigned int' due to prototype, = arg #1 [259] >> types.h(355): warning: conversion from 'unsigned long long' to = 'unsigned int' may lose accuracy, arg #1 [298] >> types.h(355): warning: conversion to 'unsigned int' due to prototype, = arg #1 [259] >> types.h(355): warning: conversion from 'unsigned long long' to = 'unsigned int' may lose accuracy, arg #1 [298] >> stdarg.h(40): syntax error [249] >> stdarg.h(98): syntax error [249] >> llib-lposix(307): syntax error [249] >> llib-lposix(308): syntax error [249] >> llib-lposix(309): syntax error [249] >> llib-lposix(309): cannot recover from previous errors [224] >> *** [llib-lposix.ln] Error code 1 >=20 > For me, r300886 didn't build at all, when I tried: >=20 > CROSS_TOOLCHAIN=3Dpowerpc64-gcc TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64= \ > __MAKE_CONF=3D/dev/null SRCCONF=3D/dev/null make buildworld >=20 > It always errors out at the very first file built for the libraries > stage: >=20 > -------------------------------------------------------------- >>>> stage 4.2: building libraries > -------------------------------------------------------------- > cd /usr/src; CROSS_TOOLCHAIN=3D"powerpc64-gcc" = MAKEOBJDIRPREFIX=3D/usr/obj MACHINE_ARCH=3Di386 MACHINE=3Di386 = CPUTYPE=3D GROFF_BIN_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/bin = GROFF_FONT_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/groff_font = GROFF_TMAC_PATH=3D/usr/obj/usr/src/tmp/legacy/usr/share/tmac = CC=3D"/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = --sysroot=3D/usr/obj/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/" = CXX=3D"/usr/local/bin/powerpc64-portbld-freebsd11.0-g++ = --sysroot=3D/usr/obj/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/" = CPP=3D"/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp = --sysroot=3D/usr/obj/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/" = AS=3D"/usr/local/powerpc64-freebsd/bin/as" = AR=3D"/usr/local/powerpc64-freebsd/bin/ar" = LD=3D"/usr/local/powerpc64-freebsd/bin/ld" = NM=3D/usr/local/powerpc64-freebsd/bin/nm = OBJDUMP=3D/usr/local/powerpc64-freebsd/bin/objdump = OBJCOPY=3D"/usr/local/powerpc64-freebsd/bin/objcopy" = RANLIB=3D/usr/local/powerpc64-freebsd/bin/ranlib = STRINGS=3D/usr/local/powerpc64-freebsd/bin/ = SIZE=3D"/usr/local/powerpc64-freebsd/bin/size" INSTALL=3D"sh = /usr/src/tools/install.sh" = PATH=3D/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/us= r/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/o= bj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin make -f = Makefile.inc1 DESTDIR=3D/usr/obj/usr/src/tmp -DNO_FSCHG MK_HTML=3Dno = -DNO_LINT MK_MAN=3Dno MK_PROFILE=3Dno MK_TESTS=3Dno = MK_TESTS_SUPPORT=3Dyes libraries > cd /usr/src; make -f Makefile.inc1 _prereq_libs; make -f = Makefile.inc1 _startup_libs; make -f Makefile.inc1 _prebuild_libs; = make -f Makefile.inc1 _generic_libs > =3D=3D=3D> gnu/lib/libssp/libssp_nonshared (obj,all,install) > building static ssp_nonshared library > /usr/local/powerpc64-freebsd/bin/ar -crD libssp_nonshared.a = `NM=3D'/usr/local/powerpc64-freebsd/bin/nm' NMFLAGS=3D'' lorder = ssp-local.o | tsort -q` > /usr/local/powerpc64-freebsd/bin/ranlib -D libssp_nonshared.a > sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 = libssp_nonshared.a /usr/obj/usr/src/tmp/usr/lib/ > =3D=3D=3D> gnu/lib/libgcc (obj,all,install) > LC_ALL=3DC awk -f = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk -f = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk < optionlist = > options.h > /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc = --sysroot=3D/usr/obj/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -c = -O2 -pipe -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED = -DHAVE_GTHR_DEFAULT = -I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include = -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config = -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. = -I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=3Dgnu99 = -Wno-error=3Dunused-function -Wno-error=3Denum-compare = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare = -Wno-error=3Duninitialized -Wno-error=3Darray-bounds = -Wno-error=3Dclobbered -Wno-error=3Dcast-align -Wno-error=3Dextra = -Wno-error=3Dattributes -Wno-error=3Dinline = -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value = -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress = -fvisibility=3Dhidden -DHIDE_EXPORTS -fPIC -fexceptions -D__GLIBC__=3D3 = -DElfW=3D__ElfN -o unwind-dw2.o = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c > In file included from = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/tsystem.h:47:0, > from = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:32: > = /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include/stddef.h:56= :24: fatal error: sys/_types.h: No such file or directory > compilation terminated. > *** Error code 1 >=20 > This is because r300886 filters out the -isystem options that point to > ${WORLDTMP}/usr/include. When I build using r300885, it errors out > while building the atf-c++ libraries: >=20 > =3D=3D=3D> lib/atf/libatf-c++ (all) > /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -isystem = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1 -std=3Dc++11 = -nostdinc++ -L/usr/obj/powerpc.powerpc64/usr/src/tmp/../lib/libc++ = -isystem /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include = -L/usr/obj/powerpc.powerpc64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/powerpc.powerpc64/usr/src/tmp = -B/usr/local/powerpc64-freebsd/bin/ -O2 -pipe -DHAVE_CONFIG_H = -I/usr/src/contrib/atf -I/usr/src/lib/atf/libatf-c++/../libatf-c -I. = -DHAVE_CONFIG_H -MD -MF.depend.application.o -MTapplication.o = -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k = -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitialized = -Wno-error=3Dunused-function -Wno-error=3Denum-compare = -Wno-error=3Dlogical-not-parentheses -Wno-error=3Dbool-compare = -Wno-error=3Duninitialized -Wno-error=3Darray-bounds = -Wno-error=3Dclobbered -Wno-error=3Dcast-align -Wno-error=3Dextra = -Wno-error=3Dattributes -Wno-error=3Dinline = -Wno-error=3Dunused-but-set-variable -Wno-error=3Dunused-value = -Wno-error=3Dstrict-aliasing -Wno-error=3Daddress -c = /usr/src/contrib/atf/atf-c++/detail/application.cpp -o application.o > In file included from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/memory:616:0, > from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/algorithm:628, > from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/string:439, > from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/__locale:15, > from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/ios:216, > from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/ostream:138, > from = /usr/src/contrib/atf/atf-c++/detail/application.hpp:29, > from = /usr/src/contrib/atf/atf-c++/detail/application.cpp:26: > = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/atomic:571:0: = error: "_Atomic" redefined [-Werror] > #define _Atomic(x) __gcc_atomic::__gcc_atomic_t > ^ > In file included from /usr/src/sys/sys/endian.h:32:0, > from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/__config:96, > from = /usr/obj/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1/ostream:137, > from = /usr/src/contrib/atf/atf-c++/detail/application.hpp:29, > from = /usr/src/contrib/atf/atf-c++/detail/application.cpp:26: > /usr/src/sys/sys/cdefs.h:283:0: note: this is the location of the = previous definition > #define _Atomic(T) struct { T volatile __val; } > ^ >=20 > It appears that there is a conflict between how sys/cdefs.h defines > _Atomic() and how the libc++ headers define it. It looks like the > definition in the libc++ headers is more suitable for gcc, so maybe we > should disable our custom definition in sys/defs.h when an external = gcc > is used? Or at least, disable it when compiling for C++. >=20 > -Dimitry >=20 From owner-freebsd-toolchain@freebsd.org Sat May 28 17:41:03 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 6D5A7B4DF5D for ; Sat, 28 May 2016 17:41:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-191.reflexion.net [208.70.211.191]) (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 2CB6A18C6 for ; Sat, 28 May 2016 17:41:02 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23648 invoked from network); 28 May 2016 17:41:32 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 May 2016 17:41:32 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 28 May 2016 13:41:38 -0400 (EDT) Received: (qmail 10368 invoked from network); 28 May 2016 17:41:38 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 May 2016 17:41:38 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E5FC81C43D6; Sat, 28 May 2016 10:40:56 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Mark Millard In-Reply-To: <0FA52C68-43C4-489D-9EB2-2339C2B812F5@dsl-only.net> Date: Sat, 28 May 2016 10:40:59 -0700 Cc: FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <068D322F-E46F-4FD8-8DA0-BD7D17FD2A06@dsl-only.net> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> <72F5F9FD-5854-455D-8844-C4E1887DCE9F@dsl-only.net> <0FA52C68-43C4-489D-9EB2-2339C2B812F5@dsl-only.net> To: Bryan Drewery 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: Sat, 28 May 2016 17:41:03 -0000 [Top post of failure to get rid of /usr/local/include from = devel/powerpc64-gcc search list.] I have tried: > # svnlite diff /usr/ports/devel/powerpc64-gcc/ > Index: /usr/ports/devel/powerpc64-gcc/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/ports/devel/powerpc64-gcc/Makefile (revision 415874) > +++ /usr/ports/devel/powerpc64-gcc/Makefile (working copy) > @@ -43,6 +43,7 @@ > CONFIGURE_ARGS+=3D--target=3D${GCC_TARGET} --disable-nls = --enable-languages=3Dc,c++ \ > --without-headers \ > --with-gmp=3D${LOCALBASE} \ > + = --with-local-prefix=3D${LOCALBASE}/lib/gcc/${GCC_TARGET}/${PORTVERSION} = \ > --with-pkgversion=3D"FreeBSD Ports Collection for = ${PKGNAMEPREFIX:C/-//g}" \ > --with-system-zlib \ > --with-as=3D${LOCALBASE}/bin/${BU_PREFIX}-as \ which when rebuilt in a powerpc64 context shows up with: = --with-local-prefix=3D/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3= .0 in the "Configured with" (from using -v): > Target: powerpc64-portbld-freebsd11.0 > Configured with: = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.3.0/configure = --target=3Dpowerpc64-portbld-freebsd11.0 --disable-nls = --enable-languages=3Dc,c++ --without-headers --with-gmp=3D/usr/local = --with-local-prefix=3D/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3= .0 --with-pkgversion=3D'FreeBSD Ports Collection for powerpc64' = --with-system-zlib --with-as=3D/usr/local/bin/powerpc64-freebsd-as = --with-ld=3D/usr/local/bin/powerpc64-freebsd-ld --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/ --build=3Dpowerpc64-portbld-freebsd11.0 But /usr/local/include still shows up in the search list, for example: > ignoring nonexistent directory = "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/local/lib/g= cc/powerpc64-portbld-freebsd11.0/5.3.0/include" > ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerp= c64-portbld-freebsd11.0/include" > ignoring duplicate directory = "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/src/lib/msun/powerpc > /usr/src/lib/msun/src > /usr/src/lib/libc/include > /usr/src/lib/libc/powerpc > /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include > /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include > /usr/local/include > /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed > End of search list. [Despite some prior mis-wording in other messages: The line match for = --with-local-prefix=3D 's value with "/include" appended matches the = line prior to /usr/local/include in the search list, not the following = line.] So far I'm unsuccessful at avoiding /usr/local/include being in the = search list. I'm still at the stage of C_INCLUDE_PAPTH and = CPLUS_INCLUDE_PATH being the best means that I've found to force = /usr/include based paths to win when there are conflicts in = /usr/local/include from ports that have been built. So far I'm only doing the experiment with devel/powerpc64-gcc (used as = the so-called "cross compiler" in my powerpc64 self-hosted context), not = with the lang/gcc49 that I use as the system compiler. For lang/gcc49 = I'm still using C_INCLUDE_PAPTH and CPLUS_INCLUDE_PATH to avoid = /usr/local/include based paths from finding files. In part this is = because I expect port building problems if I use lang/gcc49 to build = ports without lang/gcc49 having /usr/local/include implicitly. I do not = use devel/powerpc64-gcc to build ports. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-May-28, at 2:24 AM, Mark Millard wrote: > --with-local-prefix=3D/usr was insufficient to avoid = /usr/local/include in the search list in powerpc64-gcc: >=20 >> ignoring duplicate directory = "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include" >> ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerp= c64-portbld-freebsd11.0/include" >> ignoring duplicate directory = "/usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/src/gnu/lib/libssp/libssp_nonshared/.. >> = /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libss= p >> = /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/inclu= de >> /usr/obj/xtoolchain_noclang/powerpc.powerpc64/usr/src/tmp/usr/include >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include >> /usr/local/include >> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed >> End of search list. >=20 > Which came from (which shows the --with-local-prefix=3D/usr use): >=20 >> Configured with: = /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.3.0/configure = --target=3Dpowerpc64-portbld-freebsd11.0 --disable-nls = --enable-languages=3Dc,c++ --without-headers --with-gmp=3D/usr/local = --with-local-prefix=3D/usr --with-pkgversion=3D'FreeBSD Ports Collection = for powerpc64' --with-system-zlib = --with-as=3D/usr/local/bin/powerpc64-freebsd-as = --with-ld=3D/usr/local/bin/powerpc64-freebsd-ld --prefix=3D/usr/local = --localstatedir=3D/var --mandir=3D/usr/local/man = --infodir=3D/usr/local/info/ --build=3Dpowerpc64-portbld-freebsd11.0 >=20 > In Makefile terms: >=20 >> # svnlite diff /usr/ports/devel/powerpc64-gcc/Makefile=20 >> Index: /usr/ports/devel/powerpc64-gcc/Makefile >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/ports/devel/powerpc64-gcc/Makefile (revision 415874) >> +++ /usr/ports/devel/powerpc64-gcc/Makefile (working copy) >> @@ -43,6 +43,7 @@ >> CONFIGURE_ARGS+=3D--target=3D${GCC_TARGET} --disable-nls = --enable-languages=3Dc,c++ \ >> --without-headers \ >> --with-gmp=3D${LOCALBASE} \ >> + --with-local-prefix=3D/usr \ >> --with-pkgversion=3D"FreeBSD Ports Collection for = ${PKGNAMEPREFIX:C/-//g}" \ >> --with-system-zlib \ >> --with-as=3D${LOCALBASE}/bin/${BU_PREFIX}-as \ >=20 >=20 > Note: "Specifying --prefix has no effect on which directory GCC = searches for local header files". >=20 > Some interesting wording is: "The same value can be used for both = --with-local-prefix and --prefix provided it is not /usr" and "This can = be used to avoid the default search of /usr/local/include". Also: "The = purpose of --prefix is to specify where to install GCC" and "The local = header files in /usr/local/include=97if you put any in that = directory=97are not part of GCC". >=20 > My overall interpretation of that is that in my context: >=20 > = --with-local-prefix=3D/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3= .0 >=20 > a.k.a.: >=20 > --with-local-prefix=3D${LOCALBASE}/lib/gcc/${GCC_TARGET}/${PORTVERSION} >=20 > would make for a redundant overall search path without changing the = ordering. >=20 > I have not figured out why /usr/local/include continued to show up and = /usr/include did not. I wonder if they have special logic for if /usr is = assigned and so force back there specified default. >=20 > I'll try rebuilding devel/powerpc64-gcc again based on: >=20 > --with-local-prefix=3D${LOCALBASE}/lib/gcc/${GCC_TARGET}/${PORTVERSION} >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat May 28 19:03:20 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 DD356B4E1C6; Sat, 28 May 2016 19:03:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 987CE186C; Sat, 28 May 2016 19:03:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x22f.google.com with SMTP id ct2so11822817igb.0; Sat, 28 May 2016 12:03:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=SL6ajehpKZ9S+hvJxO8dnGj8lT6eX3Y9ygm+1M8S1BE=; b=hQsMe0IkTzZT5f+Oa6J2+5rA2NR5girxAVPw5gPR/+VJfDvdBNzUU4obA0Mi0UXUYu P//G0IG7HrcF8vWkeJbLitwXQ1pUTqvy4nm7X4XYy5wIts2pvEIy9lvoIW9Lu1dA3CQk nEMwI3uobyEB5WsfELOwN3cQBkegWd6hKz/XNbfEef+DMv1GecBopnVg1DNZA+02fAyV n/0zowLlyggrsxxuAnxAOHz5I8yktL70kGmwgZupea1rCVmT9/scl6fMjuU/lgEVVIq/ ML6+QJt5KNuYtESjq152k8y54Wxi9eWifgY/aijdLSit3D+RjxcFZArqWH9t84CHSrJ/ VFgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=SL6ajehpKZ9S+hvJxO8dnGj8lT6eX3Y9ygm+1M8S1BE=; b=FgRRHYBBzNPkGIyzeSafLoeSIIc4TBMIlzWaDCnGYWdhGg4zeofPQv7NLH1euqxL9+ rOxd5cMY1CsuFaRcfZs0UAM5PsTCfYSv1dYJ7svwINaV7dVDzvk78GZyFPv5huprgd9J pktVDHxnRlYB9eNonYq8PqAXwP8RgZLxgf/m8BUcpnSlm/GV459aip4WflTNGSGZXjbJ QVdmuzAdrI0EJCCe5wJLq0DJ2Eevj8lmrVfE3YHnc2z5m2oSdB9BFGBvjt5v3jzce1Iu qicccsejgsuG1dRdOwKQNa18IJGOKyYi2DwUboBel6idJe7vFsOPhPrVul8g5u26mL9Y fD1A== X-Gm-Message-State: ALyK8tJI3TGfu2LzPOhXFL3zLWBVdvmvWYNpD93pCDmboGQb6RopOwy/NYl0Rp2ZAVI3D1moM/M73Zr4yTekFg== MIME-Version: 1.0 X-Received: by 10.50.3.73 with SMTP id a9mr3014289iga.22.1464462199663; Sat, 28 May 2016 12:03:19 -0700 (PDT) Received: by 10.36.113.3 with HTTP; Sat, 28 May 2016 12:03:19 -0700 (PDT) In-Reply-To: <068D322F-E46F-4FD8-8DA0-BD7D17FD2A06@dsl-only.net> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> <72F5F9FD-5854-455D-8844-C4E1887DCE9F@dsl-only.net> <0FA52C68-43C4-489D-9EB2-2339C2B812F5@dsl-only.net> <068D322F-E46F-4FD8-8DA0-BD7D17FD2A06@dsl-only.net> Date: Sat, 28 May 2016 12:03:19 -0700 Message-ID: Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Adrian Chadd To: Mark Millard Cc: Bryan Drewery , FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh , Dimitry Andric Content-Type: text/plain; charset=UTF-8 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, 28 May 2016 19:03:21 -0000 [snip] hi, please don't patch the ports compiler assumptions about things like this. We should be targeting external toolchains on OSes (eg macosx) where it may already generate freebsd binaries and as such we should be calling the compiler/linker with all the flags it needs. Having a patched compiler default for mips made things way, way harder than it needed to be. -adrian From owner-freebsd-toolchain@freebsd.org Sat May 28 21:30: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 6CE02B4E490 for ; Sat, 28 May 2016 21:30:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-190.reflexion.net [208.70.211.190]) (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 26EAB1CAD for ; Sat, 28 May 2016 21:30:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31297 invoked from network); 28 May 2016 21:30:13 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 28 May 2016 21:30:13 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 28 May 2016 17:30:17 -0400 (EDT) Received: (qmail 10773 invoked from network); 28 May 2016 21:30:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 May 2016 21:30:16 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 35AA8B1E001; Sat, 28 May 2016 14:30:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) From: Mark Millard In-Reply-To: Date: Sat, 28 May 2016 14:30:10 -0700 Cc: Bryan Drewery , FreeBSD Current , FreeBSD Toolchain , FreeBSD PowerPC ML , Gerald Pfeifer , Warner Losh , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> <70a54660-775d-c12c-b991-507d26ce1342@FreeBSD.org> <72F5F9FD-5854-455D-8844-C4E1887DCE9F@dsl-only.net> <0FA52C68-43C4-489D-9EB2-2339C2B812F5@dsl-only.net> <068D322F-E46F-4FD8-8DA0-BD7D17FD2A06@dsl-only.net> To: Adrian Chadd 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: Sat, 28 May 2016 21:30:14 -0000 On 2016-May-28, at 12:03 PM, Adrian Chadd = wrote: > [snip] >=20 > hi, >=20 > please don't patch the ports compiler assumptions about things like > this. We should be targeting external toolchains on OSes (eg macosx) > where it may already generate freebsd binaries and as such we should > be calling the compiler/linker with all the flags it needs. >=20 > Having a patched compiler default for mips made things way, way harder > than it needed to be. >=20 >=20 >=20 > -adrian Are there specific technical examples of specific lessons learned from = the "patched compiler default for mips" context? Is there an intent to use /usr/src/. . . materials for = buildworld/buildkernel and the like from a non-FreeBSD context? Are = there examples? Currently I'm just providing evidence that some FreeBSD committers have = requested. I'm not a committer for FreeBSD or for upstream and will not = be making any FreeBSD system or ports changes outside my personal = context. I'm no direct risk to FreeBSD. So your note is more for the = folks having me cross check xtoolchain and related behavior than for me. Notes on my context. . . (stop reading if you do not care) Unfortunately powerpc64 and powerpc still can not be clang based overall = for buildworld/buildkernel. I will say that in my use of devel/powerpc64-xtoolchain-gcc (and so = devel/powerpc64-gcc ) to have a libc++ based FreeBSD on powerpc64 I've = always had to have some form of work around to avoid /usr/local/include = causing buildworld failures from use of the wrong files for buildworld = purposes. I have either: A) temporarily renamed files below /usr/local/include/ to avoid them = being used (or otherwise blocked /usr/local/include access) or B) used C_INCLUDE_PATH and CPLUS_INCLUDE_PATH to cause the C/C++ = compiles to look below /usr/include/ before looking below = /usr/local/include/ . (I've also experimented with extra -I's and the = like.) So far I've not used devel/powerpc64-gcc to build ports under FreeBSD. = So far I've only built ports from a self-hosted context (no cross-built = ports). So I tend to use something like lang/gcc49 to build ports. I'm = not likely to adopt a technique for building the likes of lang/gcc49 = that messes up using it to build ports. I normally self-host buildworld/buildkernel on a powerpc64 FreeBSD = context, an odd use of devel/powerpc64-gcc . But I have at times also = cross-built from an amd64 FreeBSD context and it also can have the = "wrong files for buildworld" problem for /usr/local/include/ in FreeBSD. I've never tried buildworld/buildkernel from a non-FreeBSD context and = so have never built devel/powerpc64-gcc or anything like its = configuration outside FreeBSD. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sat May 28 22:12: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 999FDB4E11E for ; Sat, 28 May 2016 22:12:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-177.reflexion.net [208.70.211.177]) (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 49FC01849 for ; Sat, 28 May 2016 22:12:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4380 invoked from network); 28 May 2016 22:12:39 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 May 2016 22:12:39 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.90.3) with SMTP; Sat, 28 May 2016 18:12:35 -0400 (EDT) Received: (qmail 26134 invoked from network); 28 May 2016 22:12:35 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 May 2016 22:12:35 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 717B4B1E001; Sat, 28 May 2016 15:12:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: 11.0-CURRENT -r300770 libc++ update vs. lang/powerpc64-xtoolchain-gcc: no go [self hosted powerpc64 context] From: Mark Millard In-Reply-To: Date: Sat, 28 May 2016 15:12:37 -0700 Cc: FreeBSD Toolchain , FreeBSD PowerPC ML , freebsd-ports@freebsd.org, Bryan Drewery Content-Transfer-Encoding: quoted-printable Message-Id: <81D66DC8-4260-4C02-8B0F-54621478D0F2@dsl-only.net> References: <95E2A9D6-8E1A-46FB-84FF-60927A6F1CE4@dsl-only.net> <8FAD594D-4349-4EA7-A712-D3792537FB1D@FreeBSD.org> <42773110-C392-4168-9B94-6902807DB530@dsl-only.net> <3BAE82F4-3BF4-4F02-9BFF-3F2290D3C82D@dsl-only.net> <0C88C11C-154A-459B-98EB-2A80A166DBCE@dsl-only.net> To: Dimitry Andric 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: Sat, 28 May 2016 22:12:45 -0000 For 11.0 -r300904 using devel/powerpc64-gcc on powerpc64 (not building = clang) I get the failures: > --- all_subdir_usr.bin --- . . . (some warnings) . . . > stdarg.h(40): syntax error [249] > stdarg.h(98): syntax error [249] > llib-lposix(307): syntax error [249] > llib-lposix(308): syntax error [249] > llib-lposix(309): syntax error [249] > llib-lposix(309): cannot recover from previous errors [224] > *** [llib-lposix.ln] Error code 1 >=20 > make[5]: stopped in /usr/src/usr.bin/xlint/llib > 1 error The 3 llib-lposix lines happen to be the lines using va_list: > int (vfprintf)(FILE *stream, const char *format, va_list arg); > int (vprintf)(const char *format, va_list arg); > int (vsprintf)(char *s, const char *format, va_list arg); As for stdarg.h (va_list related text will end up being involved as = well): > # ls -l /usr/include/stdarg.h=20 > lrwxr-xr-x 1 root wheel 16 May 23 21:22 /usr/include/stdarg.h -> = machine/stdarg.h > # ls -l = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/stdarg.h > lrwxr-xr-x 1 root wheel 16 May 27 16:59 = /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/stdarg.h = -> machine/stdarg.h There is also: /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include/stdarg.h (which seems to be the one in use). The usr/include/stdarg.h line 40's in each case are the #endif in: > #ifndef _VA_LIST_DECLARED > #define _VA_LIST_DECLARED > typedef __va_list va_list; > #endif By contrast the 5.3.0/include/stdarg.h has the typedef below as line 40: > #ifndef __GNUC_VA_LIST > #define __GNUC_VA_LIST > typedef __builtin_va_list __gnuc_va_list; > #endif usr/include/stdarg.h line 98 in each case is the sizeof line in: > #define __va_longlong(type) = \ > (__builtin_classify_type(*(type *)0) =3D=3D = __INTEGER_TYPE_CLASS && \ > sizeof(type) =3D=3D 8) By contrast the 5.3.0/include/stdarg.h has the typedef below as line 98: > #ifndef __va_list__ > typedef __gnuc_va_list va_list; > #endif /* not __va_list__ */ It would appear that = /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include/stdarg.h = is the one in use during the failure. =3D=3D=3D Mark Millard markmi at dsl-only.net