From owner-freebsd-toolchain@freebsd.org Sun Mar 13 04:16:54 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C064ACEABD for ; Sun, 13 Mar 2016 04:16:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C8B5C41 for ; Sun, 13 Mar 2016 04:16:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2D4Gqff037824 for ; Sun, 13 Mar 2016 04:16:54 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 04:16:53 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 04:16:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 --- Comment #6 from commit-hook@freebsd.org --- A commit references this bug: Author: brooks Date: Sun Mar 13 04:15:58 UTC 2016 New revision: 410942 URL: https://svnweb.freebsd.org/changeset/ports/410942 Log: Apply r219512 from LLVM which reportedly fixes a crash building firefox. PR: 207837 Changes: head/devel/llvm34/Makefile head/devel/llvm34/files/patch-svn-219512 head/devel/llvm35/Makefile head/devel/llvm35/files/patch-svn-219512 --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 12:13:00 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 0805DACE52E for ; Sun, 13 Mar 2016 12:13:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EC78AD01 for ; Sun, 13 Mar 2016 12:12:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2DCCxhI028835 for ; Sun, 13 Mar 2016 12:12:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 12:12:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: vikashb@where-ever.za.net X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 12:13:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 --- Comment #7 from Vikash Badal --- (In reply to Jan Beich from comment #3) I tried adding OPTIMIZED_CFLAGS=3Don to the make.conf for the poudriere jail ---Begin make.conf--- MACHINE=3Di386 MACHINE_ARCH=3Di386 ARCH=3D${MACHINE_ARCH} USE_PACKAGE_DEPENDS=3Dyes BATCH=3Dyes WRKDIRPREFIX=3D/wrkdirs PORTSDIR=3D/usr/ports PACKAGES=3D/packages DISTDIR=3D/distfiles #### /usr/local/etc/poudriere.d/RELENG_10_2_i386-make.conf #### WITH_PKGNG=3Dyes WITH_GALLIUM=3D"yes" DEFAULT_VERSIONS=3Dapache=3D2.2 php=3D5.6 OPTIMIZED_CFLAGS=3Don still fails full log: http://anger.where-ever.za.net/~vikashb/firefox-45.0_3,1-OPTIMIZED_CFLAGS_o= ff.log not sure if i missed the plot here --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 12:31: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 81A18ACEF72 for ; Sun, 13 Mar 2016 12:31:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71CD617FD for ; Sun, 13 Mar 2016 12:31:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2DCVvvw001493 for ; Sun, 13 Mar 2016 12:31:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 12:31:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 12:31:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jbeich@FreeBSD.org --- Comment #8 from Jan Beich --- (In reply to Vikash Badal from comment #7) > ---Begin OPTIONS List--- > [...] > OPTIMIZED_CFLAGS=3Doff: Use extra compiler optimizations $ make config -C /usr/ports/www/firefox I'll add a workaround later via USES=3Dcompiler:c++14-lang. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 14:43: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 1C560ACF523 for ; Sun, 13 Mar 2016 14:43:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02F9A1B4 for ; Sun, 13 Mar 2016 14:43:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2DEh3Js068975 for ; Sun, 13 Mar 2016 14:43:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 14:43:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 14:43:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 --- Comment #9 from commit-hook@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Mar 13 14:42:59 UTC 2016 New revision: 410973 URL: https://svnweb.freebsd.org/changeset/ports/410973 Log: www/firefox: work around Clang 3.4 crash with OPTIMIZED_CFLAGS=3Doff Pretend we want C++14 to pull more modern version of Clang on 10.x i386. PR: 207837 MFH: 2016Q1 Changes: head/Mk/bsd.gecko.mk --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 15:17: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 BAB76ACE4B4 for ; Sun, 13 Mar 2016 15:17:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A49628BF for ; Sun, 13 Mar 2016 15:17:12 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2DFHBEg023708 for ; Sun, 13 Mar 2016 15:17:12 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 15:17:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 15:17:12 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 --- Comment #10 from commit-hook@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Mar 13 15:17:03 UTC 2016 New revision: 410995 URL: https://svnweb.freebsd.org/changeset/ports/410995 Log: MFH: r410973 www/firefox: work around Clang 3.4 crash with OPTIMIZED_CFLAGS=3Doff Pretend we want C++14 to pull more modern version of Clang on 10.x i386. PR: 207837 Approved by: ports-secteam (junovitch) Changes: _U branches/2016Q1/ branches/2016Q1/Mk/bsd.gecko.mk --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 15:34: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 6548EACEA93 for ; Sun, 13 Mar 2016 15:34:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 55C91F51 for ; Sun, 13 Mar 2016 15:34:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2DFYNgi058410 for ; Sun, 13 Mar 2016 15:34:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 15:34:23 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 15:34:23 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 --- Comment #11 from Dimitry Andric --- (In reply to Vikash Badal from comment #7) > still fails >=20 > full log: >=20 > http://anger.where-ever.za.net/~vikashb/firefox-45.0_3,1- > OPTIMIZED_CFLAGS_off.log >=20 > not sure if i missed the plot here The patch hasn't been applied to stable/10 nor stable/9 yet, so unless you manually applied it, this is expected. Alternatively, build with either the clang34 or clang35 port, after updatin= g to ports r410942. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 16:26:48 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C281FACFD12 for ; Sun, 13 Mar 2016 16:26:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B349818FE for ; Sun, 13 Mar 2016 16:26:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2DGQmeX096431 for ; Sun, 13 Mar 2016 16:26:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 16:26:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 16:26:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 --- Comment #12 from Dimitry Andric --- Strangely, I tried building www/firefox on stable/10, from before r410973 w= as applied, and it builds just fine for me, even the problematic Unified_cpp_protocol_websocket0.cpp file. I'm unsure what is different in = my environment from the original submitter, though. This is on pretty plain stable/10 r294049, as of 2016-01-21. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 16:31:10 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 9C74CACFEA2 for ; Sun, 13 Mar 2016 16:31:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D50B1B11 for ; Sun, 13 Mar 2016 16:31:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2DGV9g4005635 for ; Sun, 13 Mar 2016 16:31:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 16:31:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 16:31:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 --- Comment #13 from Dimitry Andric --- Hm, for some reason my compiles get an additional -O3, and a -fomit-frame-pointer. When the frame pointer is omitted, there is a chance that more registers are available for general use, avoiding the original "r= an out of registers" error. Anybody have an idea why the firefox port gets different compilation flags = on different systems? Note that I don't have any CFLAGS in my /etc/make.conf,= so that's not it. :) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 17:00:27 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 75D9BACDA7C for ; Sun, 13 Mar 2016 17:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66A3F986 for ; Sun, 13 Mar 2016 17:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2DH0R5g068360 for ; Sun, 13 Mar 2016 17:00:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 17:00:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 17:00:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 --- Comment #14 from Jan Beich --- (In reply to Dimitry Andric from comment #13) OPTIMIZED_CFLAGS is enabled by default. It doesn't pass just -O3 but also --enable-optimize which lets vendor decide whether to pass -fomit-frame-poi= nter and (in later versions) rust -O. https://dxr.mozilla.org/mozilla-central/search?q=3DMOZ_OPTIMIZE --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 18:32:33 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 65F78ACFFD8 for ; Sun, 13 Mar 2016 18:32:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 568C4F5B for ; Sun, 13 Mar 2016 18:32:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2DIWWcV073126 for ; Sun, 13 Mar 2016 18:32:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 18:32:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 18:32:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 --- Comment #15 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Sun Mar 13 18:32:11 UTC 2016 New revision: 296800 URL: https://svnweb.freebsd.org/changeset/base/296800 Log: Pull in r219512 from upstream llvm trunk (by Hal Finkel): [MiSched] Fix a logic error in tryPressure() Fixes a logic error in the MachineScheduler found by Steve Montgomery (and confirmed by Andy). This has gone unfixed for months because the fix has been found to introduce some small performance regressions. However, Andy has recommended that, at this point, we fix this to avoid further dependence on the incorrect behavior (and then follow-up separately on any regressions), and I agree. Fixes PR18883. This fixes a possible "ran out of registers" error when compiling www/firefox 45.0 on i386. Direct commit to stable/10, because head already has this fix since the llvm/clang 3.6.0 import. PR: 207837 Changes: stable/10/contrib/llvm/lib/CodeGen/MachineScheduler.cpp --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 18: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 56008ACFFE3 for ; Sun, 13 Mar 2016 18:32:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40036F74 for ; Sun, 13 Mar 2016 18:32:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2DIWYtY073235 for ; Sun, 13 Mar 2016 18:32:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 18:32:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 18:32:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 --- Comment #16 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Sun Mar 13 18:32:18 UTC 2016 New revision: 296801 URL: https://svnweb.freebsd.org/changeset/base/296801 Log: Pull in r219512 from upstream llvm trunk (by Hal Finkel): [MiSched] Fix a logic error in tryPressure() Fixes a logic error in the MachineScheduler found by Steve Montgomery (and confirmed by Andy). This has gone unfixed for months because the fix has been found to introduce some small performance regressions. However, Andy has recommended that, at this point, we fix this to avoid further dependence on the incorrect behavior (and then follow-up separately on any regressions), and I agree. Fixes PR18883. This fixes a possible "ran out of registers" error when compiling www/firefox 45.0 on i386. Direct commit to stable/9, because head already has this fix since the llvm/clang 3.6.0 import. PR: 207837 Changes: stable/9/contrib/llvm/lib/CodeGen/MachineScheduler.cpp --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 18:39:27 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 D3969ACF275 for ; Sun, 13 Mar 2016 18:39:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4150133D for ; Sun, 13 Mar 2016 18:39:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2DIdRSH081715 for ; Sun, 13 Mar 2016 18:39:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 18:39:27 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 18:39:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |In Progress --- Comment #17 from Dimitry Andric --- I don't think it is likely this change will end up in 10.3, so the workarou= nd may need to be kept in place. Shall we close this bug now? --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 18:46: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 E2892ACF575 for ; Sun, 13 Mar 2016 18:46:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CB8CB1A61 for ; Sun, 13 Mar 2016 18:46:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u2DIPLMe025459 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 13 Mar 2016 11:25:21 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u2DIPL10025458 for freebsd-toolchain@freebsd.org; Sun, 13 Mar 2016 11:25:21 -0700 (PDT) (envelope-from sgk) Date: Sun, 13 Mar 2016 11:25:21 -0700 From: Steve Kargl To: freebsd-toolchain@freebsd.org Subject: clang gets numerical underflow wrong, please fix. Message-ID: <20160313182521.GA25361@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 18:46:13 -0000 Consider this small piece of code: #include #include float foo() { static const volatile float tiny = 1.e-30f; return (tiny * tiny); } int main(void) { float x; feclearexcept(FE_ALL_EXCEPT); x = foo(); if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: "); printf("x = %e\n", x); return 0; } clang seems to get the underflow condition wrong. % cc -o z a.c -lm && ./z FE_UNDERFLOW: x = 0.000000e+00 % cc -O -o z a.c -lm && ./z x = 1.000000e-60 <--- This is not a possible value! % gcc -o z a.c -lm && ./z FE_UNDERFLOW: x = 0.000000e+00 % gcc -O -o z a.c -lm && ./z FE_UNDERFLOW: x = 0.000000e+00 % uname -a FreeBSD laptop-kargl 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r296724: Sun Mar 13 09:12:38 PDT 2016 % cc --version FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) % gcc --version gcc (FreeBSD Ports Collection) 4.8.5 -- Steve From owner-freebsd-toolchain@freebsd.org Sun Mar 13 19:12: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 470A0ACE26C for ; Sun, 13 Mar 2016 19:12:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37513238 for ; Sun, 13 Mar 2016 19:12:57 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2DJCu3F087629 for ; Sun, 13 Mar 2016 19:12:57 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 19:12:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jbeich@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 19:12:57 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |FIXED --- Comment #18 from Jan Beich --- (In reply to Dimitry Andric from comment #17) > Shall we close this bug now? Maybe only adjust ports workaround for /stable/10 fix. According to Mk/bsd.ssp.mk -fstack-protector isn't enabled on /stable/9. --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 19:13:40 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F7C1ACE3F6 for ; Sun, 13 Mar 2016 19:13:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60020692 for ; Sun, 13 Mar 2016 19:13:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2DJDdZg088677 for ; Sun, 13 Mar 2016 19:13:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox: clang34 and clang35 crash on i386 with -O2 -fstack-protector (OPTIMIZED_CFLAGS=off) Date: Sun, 13 Mar 2016 19:13:40 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: gecko@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 19:13:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 --- Comment #19 from commit-hook@freebsd.org --- A commit references this bug: Author: jbeich Date: Sun Mar 13 19:13:07 UTC 2016 New revision: 411019 URL: https://svnweb.freebsd.org/changeset/ports/411019 Log: www/firefox: limit r410973 to OSVERSION before the fix PR: 207837 Changes: head/Mk/bsd.gecko.mk --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Sun Mar 13 20:04:16 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 4DFA5ACFC21 for ; Sun, 13 Mar 2016 20:04:16 +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 15244107B for ; Sun, 13 Mar 2016 20:04:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::7d53:d1bf:838d:a3e3] (unknown [IPv6:2001:7b8:3a7:0:7d53:d1bf:838d:a3e3]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7B8CF6B67; Sun, 13 Mar 2016 21:04:07 +0100 (CET) Subject: Re: clang gets numerical underflow wrong, please fix. Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_11C2F5B6-8463-491B-A91C-A51E76493731"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <20160313182521.GA25361@troutmask.apl.washington.edu> Date: Sun, 13 Mar 2016 21:03:57 +0100 Cc: freebsd-toolchain@freebsd.org Message-Id: <74970883-FE44-47C0-BDA0-92DB0723398A@FreeBSD.org> References: <20160313182521.GA25361@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 20:04:16 -0000 --Apple-Mail=_11C2F5B6-8463-491B-A91C-A51E76493731 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 Mar 2016, at 19:25, Steve Kargl = wrote: >=20 > Consider this small piece of code: >=20 > #include > #include >=20 > float > foo() > { > static const volatile float tiny =3D 1.e-30f; > return (tiny * tiny); > } >=20 > int > main(void) > { > float x; > feclearexcept(FE_ALL_EXCEPT); > x =3D foo(); > if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: "); > printf("x =3D %e\n", x); > return 0; > } >=20 > clang seems to get the underflow condition wrong. >=20 > % cc -o z a.c -lm && ./z > FE_UNDERFLOW: x =3D 0.000000e+00 >=20 > % cc -O -o z a.c -lm && ./z > x =3D 1.000000e-60 <--- This is not a possible value! >=20 > % gcc -o z a.c -lm && ./z > FE_UNDERFLOW: x =3D 0.000000e+00 >=20 > % gcc -O -o z a.c -lm && ./z > FE_UNDERFLOW: x =3D 0.000000e+00 Hmm, this is an interesting one. On amd64, it works as expected with clang, but there it always uses SSE, obviously: $ ./underflow-amd64 FE_UNDERFLOW: x =3D 0.000000e+00 The problem seems to be caused by the intermediate result being stored using fstpl instead of fstps, e.g. simplifying the sample program (to get rid of all the SSE stuff the fexxx() macros insert): int main(void) { float x; __uint16_t status; __fnclex(); x =3D foo(); __fnstsw(&status); printf("status: %#x\n", (unsigned)status); printf("x =3D %e\n", x); return 0; } With gcc, the assembly becomes: foo: flds tiny.1853 flds tiny.1853 fmulp %st, %st(1) ret [...] main: [...] fnclex call foo fstps 12(%esp) fnstsw %ax In this case, fmulp does not generate an underflow, but the fstps will. With clang, the assembly becomes: foo: flds foo.tiny fmuls foo.tiny retl [...] main: subl $24, %esp fnclex calll foo fstpl 12(%esp) # 8-byte Folded Spill fnstsw 22(%esp) So it's storing the intermediate result in a double, for some reason. The fnstsw will then result in zero, since there was no underflow at that point. I will submit a bug for this upstream, thanks for the report. -Dimitry --Apple-Mail=_11C2F5B6-8463-491B-A91C-A51E76493731 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.29 iEYEARECAAYFAlblx7YACgkQsF6jCi4glqNZZwCg31aoDFrKkjMxWFME/QNTcQAB 45gAniBh/gkRojA0mnSTGFXO2XyRoZor =GVRB -----END PGP SIGNATURE----- --Apple-Mail=_11C2F5B6-8463-491B-A91C-A51E76493731-- From owner-freebsd-toolchain@freebsd.org Sun Mar 13 20:10:05 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9AE2ACFDF7 for ; Sun, 13 Mar 2016 20:10:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A5BA413D0; Sun, 13 Mar 2016 20:10:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u2DKA4hZ026361 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 Mar 2016 13:10:04 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u2DKA4HZ026360; Sun, 13 Mar 2016 13:10:04 -0700 (PDT) (envelope-from sgk) Date: Sun, 13 Mar 2016 13:10:04 -0700 From: Steve Kargl To: Dimitry Andric Cc: freebsd-toolchain@freebsd.org Subject: Re: clang gets numerical underflow wrong, please fix. Message-ID: <20160313201004.GA26343@troutmask.apl.washington.edu> References: <20160313182521.GA25361@troutmask.apl.washington.edu> <74970883-FE44-47C0-BDA0-92DB0723398A@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74970883-FE44-47C0-BDA0-92DB0723398A@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 20:10:05 -0000 On Sun, Mar 13, 2016 at 09:03:57PM +0100, Dimitry Andric wrote: > On 13 Mar 2016, at 19:25, Steve Kargl wrote: > > > > Consider this small piece of code: > > > > #include > > #include > > > > float > > foo() > > { > > static const volatile float tiny = 1.e-30f; > > return (tiny * tiny); > > } > > > > int > > main(void) > > { > > float x; > > feclearexcept(FE_ALL_EXCEPT); > > x = foo(); > > if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: "); > > printf("x = %e\n", x); > > return 0; > > } > > > > clang seems to get the underflow condition wrong. > > > > % cc -o z a.c -lm && ./z > > FE_UNDERFLOW: x = 0.000000e+00 > > > > % cc -O -o z a.c -lm && ./z > > x = 1.000000e-60 <--- This is not a possible value! > > > > % gcc -o z a.c -lm && ./z > > FE_UNDERFLOW: x = 0.000000e+00 > > > > % gcc -O -o z a.c -lm && ./z > > FE_UNDERFLOW: x = 0.000000e+00 > > Hmm, this is an interesting one. On amd64, it works as expected with > clang, but there it always uses SSE, obviously: > > $ ./underflow-amd64 > FE_UNDERFLOW: x = 0.000000e+00 > > The problem seems to be caused by the intermediate result being stored > using fstpl instead of fstps, e.g. simplifying the sample program (to > get rid of all the SSE stuff the fexxx() macros insert): > > int main(void) > { > float x; > __uint16_t status; > __fnclex(); > x = foo(); > __fnstsw(&status); > printf("status: %#x\n", (unsigned)status); > printf("x = %e\n", x); > return 0; > } > > With gcc, the assembly becomes: > > foo: > flds tiny.1853 > flds tiny.1853 > fmulp %st, %st(1) > ret > [...] > main: > [...] > fnclex > call foo > fstps 12(%esp) > fnstsw %ax > > In this case, fmulp does not generate an underflow, but the fstps will. > With clang, the assembly becomes: > > foo: > flds foo.tiny > fmuls foo.tiny > retl > [...] > main: > subl $24, %esp > fnclex > calll foo > fstpl 12(%esp) # 8-byte Folded Spill > fnstsw 22(%esp) > > So it's storing the intermediate result in a double, for some reason. > The fnstsw will then result in zero, since there was no underflow at > that point. > > I will submit a bug for this upstream, thanks for the report. > Thanks for the quick reply. But, it must be using an 80-bit extended double instead of a double for storage. This variation #include #include int main(void) { int i; // float x = 1.f; double x = 1.; i = 0; feclearexcept(FE_ALL_EXCEPT); do { x /= 2; i++; } while(!fetestexcept(FE_UNDERFLOW)); if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: "); printf("x = %e after %d iterations\n", x, i); return 0; } yields % cc -O -o z b.c -lm && ./z FE_UNDERFLOW: x = 0.000000e+00 after 16435 iterations It should be 1075 iterations. Note, there is a similar issue with OVERFLOW. The upshot is that clang on current is probably miscompiling libm. -- Steve From owner-freebsd-toolchain@freebsd.org Sun Mar 13 23:32: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 84BE2ACE2B3 for ; Sun, 13 Mar 2016 23:32:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 57D68E04 for ; Sun, 13 Mar 2016 23:32:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id m184so204277198iof.1 for ; Sun, 13 Mar 2016 16:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=UP6rWHKlZjP8nd5igNROOXtbijv+33JDU8LJLkufcOg=; b=EPWbV3kSbIeec18GXFDxNQ7uaIZYhtg1O9uyV/ydets/1Tk5Etja057dgyUjNZV1AW Ud2vP8+uz0l/AnrcqDhufXz20DwFXzUO2Z9S51+Fc3sSjV3azVQ5OlglRiE5vyPga2ke 58FgfA3N+1bqSuAW4569vm0h1DyMChXHljkMe9o5i/RJOkL6VuEggeC/9op0xypSlIvv vI4oG0p3Ix++3yCGn6qDje2RQbQvP3LYn9j1/W5PE7I7RGZrp2Bzli9MQDiRm176YBx/ 0Mtn9f83eNtHBbfPTfhH1AHA0NV+Zy9u9Dp7Jf0DT2Cstyfr0/pfUsY09K/Lh62iyf2C NArQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=UP6rWHKlZjP8nd5igNROOXtbijv+33JDU8LJLkufcOg=; b=Q1RjdaIloFX0QTwzTjjZjnCOwkadF0HnRnlsW7gzrZHtcveSjqrjIjjV3k2NZTVhAu OEjfl8Tk+pFu5REduFWBgA3XlPG+MTIP9GfXjMmAA1iEn5YI9593JsL2K9Iq9Al96y75 IvBXjiIc+5B4e07zEFZ24OMSDslmHE3FF9DLe7gOa7pUADTJO16gBJCLNnGw7eHodiNC t7GjeVZ2woPu3nSuacZgLAOuyM1mNgYUPulSk4X60WeLBe1R7cjQPISu/iSEezpfRIs1 /tixUEtC5hsg/DD6Tb2kkSi5ct7aQI5cLiwAe6YlQkkO1EPvZhNarzzvhnSmYPKKMqPc Ik8A== X-Gm-Message-State: AD7BkJKxNV2KS+oNtB0Bd7M19ZFAW8CtWy58Z2mfC97PUbGXNrMBPmw8rtsNKFmZG+d4Ts7KgcJxiCiLQSbHMA== MIME-Version: 1.0 X-Received: by 10.107.14.209 with SMTP id 200mr20416953ioo.73.1457911975574; Sun, 13 Mar 2016 16:32:55 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Sun, 13 Mar 2016 16:32:55 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <779997a4a2f241b39db096bfed5cb84f@ultimatedns.net> References: <779997a4a2f241b39db096bfed5cb84f@ultimatedns.net> Date: Sun, 13 Mar 2016 17:32:55 -0600 X-Google-Sender-Auth: wT7NNAoy9BXtzVx5SRP3eP0SsNo Message-ID: Subject: Re: How to insist on only clang, for world/kernel? From: Warner Losh To: Chris H Cc: FreeBSD toolchain Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 23:32:56 -0000 Then you may be able to do make buildworld CC=clang (or whatever clang is compiled as. No guarantee, sine I've not played with 9.x in a while. Warner On Fri, Mar 11, 2016 at 8:20 AM, Chris H wrote: > On Thu, 10 Mar 2016 21:49:01 -0700 Warner Losh wrote > > > make buildworld WITH_CLANG=t WITH_CLANG_BOOTSTRAP=t WITHOUT_GCC=y > > WITHOUT_GCC_BOOTSTRAP=t WITH_CLANG_IS_CC=t > > make buildkernel > > > > But that's mostly default these days, so really most people get what you > > want by doing > > > > make buildworld buildkernel > > > > Warner > Thanks for the quick reply, Warner! > This is on RELENG_9, so I *don't* get that by default. ;) > But true. Everything else I run in on -CURRENT, and indeed gets > the options you indicate above out-of-the-box. > > Thanks again, Warner. > > > > On Thu, Mar 10, 2016 at 9:23 PM, Chris H wrote: > > > > > Greetings, > > > A recent build/install world/kernel on a fresh 9-STABLE. > > > I was surprised to see that, while clang was also built, > > > gcc was used to perform the build for at least world. > > > I performed some research to definitively determine the > > > magic incantation for at least src.conf(5). However, I > > > found too many possibilities to be sure. So I'm here > > > to beg for the answer. > > > > > > The most likely candidates I have so far > > > > > > FAVORITE_COMPILER=clang > > > MAKE_COMPILER_TYPE=clang > > > WITH_CLANG=true > > > CC=clang > > > CXX=clang++ > > > CPP=clang-cpp > > > > > > Thanks you. > > > > > --Chris > > -- > > > From owner-freebsd-toolchain@freebsd.org Mon Mar 14 00:02:31 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 DA525ACF0C0 for ; Mon, 14 Mar 2016 00:02:31 +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 6C56CDEB for ; Mon, 14 Mar 2016 00:02:31 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 55A166E9D; Mon, 14 Mar 2016 01:02:28 +0100 (CET) Subject: Re: clang gets numerical underflow wrong, please fix. Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_40B5429D-BCD2-4684-8E3A-55F296B73BBE"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <20160313201004.GA26343@troutmask.apl.washington.edu> Date: Mon, 14 Mar 2016 01:02:20 +0100 Cc: freebsd-toolchain@freebsd.org Message-Id: References: <20160313182521.GA25361@troutmask.apl.washington.edu> <74970883-FE44-47C0-BDA0-92DB0723398A@FreeBSD.org> <20160313201004.GA26343@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 14 Mar 2016 00:02:32 -0000 --Apple-Mail=_40B5429D-BCD2-4684-8E3A-55F296B73BBE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 Mar 2016, at 21:10, Steve Kargl = wrote: > On Sun, Mar 13, 2016 at 09:03:57PM +0100, Dimitry Andric wrote: ... >> So it's storing the intermediate result in a double, for some reason. >> The fnstsw will then result in zero, since there was no underflow at >> that point. >>=20 >> I will submit a bug for this upstream, thanks for the report. Submitted upstream as: https://llvm.org/bugs/show_bug.cgi?id=3D26931 > Thanks for the quick reply. But, it must be using an 80-bit > extended double instead of a double for storage. This variation >=20 > #include > #include >=20 > int > main(void) > { > int i; > // float x =3D 1.f; > double x =3D 1.; > i =3D 0; > feclearexcept(FE_ALL_EXCEPT); > do { > x /=3D 2; > i++; > } while(!fetestexcept(FE_UNDERFLOW)); > if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: "); > printf("x =3D %e after %d iterations\n", x, i); >=20 > return 0; > } >=20 > yields >=20 > % cc -O -o z b.c -lm && ./z > FE_UNDERFLOW: x =3D 0.000000e+00 after 16435 iterations >=20 > It should be 1075 iterations. >=20 > Note, there is a similar issue with OVERFLOW. The upshot is > that clang on current is probably miscompiling libm. With this example, I also get different results from gcc (4.8.5), depending on the optimization level: $ gcc -O underflow-iter.c -o underflow-iter-gcc -lm $ ./underflow-iter-gcc FE_UNDERFLOW: x =3D 0.000000e+00 after 1075 iterations $ gcc -O2 underflow-iter.c -o underflow-iter-gcc -lm $ ./underflow-iter-gcc FE_UNDERFLOW: x =3D 0.000000e+00 after 16435 iterations Similar for the overflow case: $ gcc -O overflow-iter.c -o overflow-iter-gcc -lm $ ./overflow-iter-gcc FE_OVERFLOW: x =3D inf after 1024 iterations $ gcc -O2 overflow-iter.c -o overflow-iter-gcc -lm $ ./overflow-iter-gcc FE_OVERFLOW: x =3D inf after 16384 iterations Are we depending on some sort of subtle undefined behavior here? With -O, the 'main loop' becomes: .L3: fld1 fstpl 24(%esp) movl $0, %ebx .L8: fldl 24(%esp) fld %st(0) faddp %st, %st(1) fstpl 24(%esp) addl $1, %ebx fnstsw %ax movl %eax, %esi movl __has_sse, %eax testl %eax, %eax je .L4 cmpl $2, %eax jne .L5 call __test_sse testl %eax, %eax je .L5 .L4: stmxcsr 44(%esp) jmp .L6 .L5: movl $0, 44(%esp) .L6: orl 44(%esp), %esi testl $8, %esi je .L8 With -O2, it becomes: .L3: fld1 xorl %ebx, %ebx .L12: fadd %st(0), %st addl $1, %ebx fnstsw %ax testl %edx, %edx movl %eax, %esi je .L10 cmpl $2, %edx je .L27 .L9: xorl %eax, %eax .L8: orl %eax, %esi andl $8, %esi je .L12 So it switches from using faddp and fstpl to direct fadd of %st(0) and %st. I assume that uses the internal 80 bit precision? Gcc also manages to move the __has_sse stuff out to further down in the function, but it does not really affect the result. -Dimitry --Apple-Mail=_40B5429D-BCD2-4684-8E3A-55F296B73BBE 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.29 iEYEARECAAYFAlbl/5MACgkQsF6jCi4glqO95wCfaSScY8fm/V7XtAcMJ7Xz7Ctw /OUAoISYUy/1dgZFhXFbT7wPyDRgSWZF =prQV -----END PGP SIGNATURE----- --Apple-Mail=_40B5429D-BCD2-4684-8E3A-55F296B73BBE-- From owner-freebsd-toolchain@freebsd.org Mon Mar 14 00:40: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 7F301ACFE69 for ; Mon, 14 Mar 2016 00:40:03 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6AACD111C; Mon, 14 Mar 2016 00:40:03 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u2E0e2bq028088 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 Mar 2016 17:40:02 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u2E0e2sl028087; Sun, 13 Mar 2016 17:40:02 -0700 (PDT) (envelope-from sgk) Date: Sun, 13 Mar 2016 17:40:02 -0700 From: Steve Kargl To: Dimitry Andric Cc: freebsd-toolchain@freebsd.org Subject: Re: clang gets numerical underflow wrong, please fix. Message-ID: <20160314004002.GA27922@troutmask.apl.washington.edu> References: <20160313182521.GA25361@troutmask.apl.washington.edu> <74970883-FE44-47C0-BDA0-92DB0723398A@FreeBSD.org> <20160313201004.GA26343@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 14 Mar 2016 00:40:03 -0000 On Mon, Mar 14, 2016 at 01:02:20AM +0100, Dimitry Andric wrote: > On 13 Mar 2016, at 21:10, Steve Kargl wrote: > > Thanks for the quick reply. But, it must be using an 80-bit > > extended double instead of a double for storage. This variation > > > > #include > > #include > > > > int > > main(void) > > { > > int i; > > // float x = 1.f; > > double x = 1.; > > i = 0; > > feclearexcept(FE_ALL_EXCEPT); > > do { > > x /= 2; > > i++; > > } while(!fetestexcept(FE_UNDERFLOW)); > > if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: "); > > printf("x = %e after %d iterations\n", x, i); > > > > return 0; > > } > > > > yields > > > > % cc -O -o z b.c -lm && ./z > > FE_UNDERFLOW: x = 0.000000e+00 after 16435 iterations > > > > It should be 1075 iterations. > > > > Note, there is a similar issue with OVERFLOW. The upshot is > > that clang on current is probably miscompiling libm. > > With this example, I also get different results from gcc (4.8.5), > depending on the optimization level: > > $ gcc -O underflow-iter.c -o underflow-iter-gcc -lm > $ ./underflow-iter-gcc > FE_UNDERFLOW: x = 0.000000e+00 after 1075 iterations > $ gcc -O2 underflow-iter.c -o underflow-iter-gcc -lm > $ ./underflow-iter-gcc > FE_UNDERFLOW: x = 0.000000e+00 after 16435 iterations > > Similar for the overflow case: > > $ gcc -O overflow-iter.c -o overflow-iter-gcc -lm > $ ./overflow-iter-gcc > FE_OVERFLOW: x = inf after 1024 iterations > $ gcc -O2 overflow-iter.c -o overflow-iter-gcc -lm > $ ./overflow-iter-gcc > FE_OVERFLOW: x = inf after 16384 iterations > > Are we depending on some sort of subtle undefined behavior here? I don't know. From n1256.pdf, 6.5.5, I can find The result of the binary * operator is the product of the operands. I can't find what happens when one operand is DBL_MAX and the other is greater than 1. The result is clearly an overflow condition. Annex F is normative text, which defers to IEC 60559. F.3 states -- The +, -, *, and / operators provide the IEC 60559 add, subtract, multiply, and divide operations. Annex F contains alot of text about "#pragma STDC FENV_ACCESS ON", but of course neither gcc nor clang implement this pragma. In particular, in F.8.1 one has Floating-point arithmetic operations ... may entail side effects which optimization shall honor, at least where the state of the FENV_ACCESS pragma is ``on''. The flags ... in the floating-point environment may be regarded as global variables; floating-point operations (+, *, etc.) implicitly ... write the flags. However, F.7.1 has F.7.1 Environment management IEC 60559 requires that floating-point operations implicitly raise floating-point exception status flags, ... When the state for the FENV_ACCESS pragma (defined in ) is ``on'', these changes to the floating-point state are treated as side effects which respect sequence points.313) 313) If the state for the FENV_ACCESS pragma is ``off'', the implementation is free to assume the floating-point control modes will be the default ones and the floating-point status flags will not be tested, which allows certain optimizations (see F.8). So, I'm guessing clang/llvm developers aer going to claim that the lack of implementation of the FENV_ACCESS pragme means "off". So, clang is unsuitable for real floating-point development. -- Steve From owner-freebsd-toolchain@freebsd.org Mon Mar 14 01:53: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 D27B3AD0780 for ; Mon, 14 Mar 2016 01:53:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B95CBECD; Mon, 14 Mar 2016 01:53:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u2E1rBji028274 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 13 Mar 2016 18:53:11 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u2E1rBdZ028273; Sun, 13 Mar 2016 18:53:11 -0700 (PDT) (envelope-from sgk) Date: Sun, 13 Mar 2016 18:53:11 -0700 From: Steve Kargl To: Dimitry Andric Cc: freebsd-toolchain@freebsd.org Subject: Re: clang gets numerical underflow wrong, please fix. Message-ID: <20160314015311.GA28237@troutmask.apl.washington.edu> References: <20160313182521.GA25361@troutmask.apl.washington.edu> <74970883-FE44-47C0-BDA0-92DB0723398A@FreeBSD.org> <20160313201004.GA26343@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 14 Mar 2016 01:53:12 -0000 On Mon, Mar 14, 2016 at 01:02:20AM +0100, Dimitry Andric wrote: > > $ gcc -O overflow-iter.c -o overflow-iter-gcc -lm > $ ./overflow-iter-gcc > FE_OVERFLOW: x = inf after 1024 iterations > $ gcc -O2 overflow-iter.c -o overflow-iter-gcc -lm > $ ./overflow-iter-gcc > FE_OVERFLOW: x = inf after 16384 iterations > Change the program to #include #include int main(void) { int i; float x = 1.f; i = 0; feclearexcept(FE_ALL_EXCEPT); do { x *= 2; i++; printf("%d %e\n", i, x); } while(!fetestexcept(FE_OVERFLOW)); if (fetestexcept(FE_OVERFLOW)) printf("FE_UNDERFLOW: "); printf("x = %e after %d iterations\n", x, i); return 0; } You'll get a bunch of invalid output before the OVERFLOW. % cc -O -o z b.c -lm && ./z | tail 1016 7.022239e+305 <-- not a valid float 1017 1.404448e+306 <-- not a valid float 1018 2.808896e+306 <-- not a valid float 1019 5.617791e+306 <-- not a valid float 1020 1.123558e+307 <-- not a valid float 1021 2.247116e+307 <-- not a valid float 1022 4.494233e+307 <-- not a valid float 1023 8.988466e+307 <-- not a valid float 1024 inf FE_UNDERFLOW: x = inf after 1024 iterations Clang is broken with or without #pragma FENV_ACCESS "on". -- Steve From owner-freebsd-toolchain@freebsd.org Mon Mar 14 04:21:10 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 67649AD0392 for ; Mon, 14 Mar 2016 04:21:10 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4498562F for ; Mon, 14 Mar 2016 04:21:09 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.14.9/8.14.9) with ESMTP id u2E4Kt1f070185; Sun, 13 Mar 2016 21:21:02 -0700 (PDT) (envelope-from bsd-lists@bsdforge.com) To: Warner Losh Cc: FreeBSD toolchain In-Reply-To: References: <779997a4a2f241b39db096bfed5cb84f@ultimatedns.net>, From: "Chris H" Subject: Re: How to insist on only clang, for world/kernel? Date: Sun, 13 Mar 2016 21:21:02 -0700 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <8a1bef70c8957e7f05eeef4d2d88703a@ultimatedns.net> Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 14 Mar 2016 04:21:10 -0000 On Sun, 13 Mar 2016 17:32:55 -0600 Warner Losh wrote > Then you may be able to do make buildworld CC=clang (or whatever clang is > compiled as. > No guarantee, sine I've not played with 9.x in a while. > > Warner Apologies. Appears my response wasn't clear. I had no difficulties getting clang (and only clang) by placing your suggestions in src.conf(5). Whereas prior to those, I got gcc as cc. Thanks again, Warner. > > > On Fri, Mar 11, 2016 at 8:20 AM, Chris H wrote: > > > On Thu, 10 Mar 2016 21:49:01 -0700 Warner Losh wrote > > > > > make buildworld WITH_CLANG=t WITH_CLANG_BOOTSTRAP=t WITHOUT_GCC=y > > > WITHOUT_GCC_BOOTSTRAP=t WITH_CLANG_IS_CC=t > > > make buildkernel > > > > > > But that's mostly default these days, so really most people get what you > > > want by doing > > > > > > make buildworld buildkernel > > > > > > Warner > > Thanks for the quick reply, Warner! > > This is on RELENG_9, so I *don't* get that by default. ;) > > But true. Everything else I run in on -CURRENT, and indeed gets > > the options you indicate above out-of-the-box. > > > > Thanks again, Warner. > > > > > > On Thu, Mar 10, 2016 at 9:23 PM, Chris H wrote: > > > > > > > Greetings, > > > > A recent build/install world/kernel on a fresh 9-STABLE. > > > > I was surprised to see that, while clang was also built, > > > > gcc was used to perform the build for at least world. > > > > I performed some research to definitively determine the > > > > magic incantation for at least src.conf(5). However, I > > > > found too many possibilities to be sure. So I'm here > > > > to beg for the answer. > > > > > > > > The most likely candidates I have so far > > > > > > > > FAVORITE_COMPILER=clang > > > > MAKE_COMPILER_TYPE=clang > > > > WITH_CLANG=true > > > > CC=clang > > > > CXX=clang++ > > > > CPP=clang-cpp > > > > > > > > Thanks you. > > > > > > > > --Chris > > > > -- > > > > > > --Chris -- From owner-freebsd-toolchain@freebsd.org Mon Mar 14 19:23:44 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EC16AD1F8F for ; Mon, 14 Mar 2016 19:23:44 +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 D4C537E7 for ; Mon, 14 Mar 2016 19:23:43 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::a43f:7b3f:ecbf:43e5] (unknown [IPv6:2001:7b8:3a7:0:a43f:7b3f:ecbf:43e5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4E0912FCE7; Mon, 14 Mar 2016 20:23:40 +0100 (CET) Subject: Re: clang gets numerical underflow wrong, please fix. Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_31F93044-399F-4178-AEAC-61A60D68E98B"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <20160314015311.GA28237@troutmask.apl.washington.edu> Date: Mon, 14 Mar 2016 20:23:33 +0100 Cc: freebsd-toolchain@freebsd.org Message-Id: <65DA5D5E-6BEE-4522-9478-B659724F9CDC@FreeBSD.org> References: <20160313182521.GA25361@troutmask.apl.washington.edu> <74970883-FE44-47C0-BDA0-92DB0723398A@FreeBSD.org> <20160313201004.GA26343@troutmask.apl.washington.edu> <20160314015311.GA28237@troutmask.apl.washington.edu> To: Steve Kargl X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 14 Mar 2016 19:23:44 -0000 --Apple-Mail=_31F93044-399F-4178-AEAC-61A60D68E98B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 14 Mar 2016, at 02:53, Steve Kargl = wrote: ... > #include > #include >=20 > int > main(void) > { > int i; > float x =3D 1.f; > i =3D 0; > feclearexcept(FE_ALL_EXCEPT); > do { > x *=3D 2; > i++; > printf("%d %e\n", i, x); > } while(!fetestexcept(FE_OVERFLOW)); > if (fetestexcept(FE_OVERFLOW)) printf("FE_UNDERFLOW: "); > printf("x =3D %e after %d iterations\n", x, i); >=20 > return 0; > } >=20 > You'll get a bunch of invalid output before the OVERFLOW. >=20 > % cc -O -o z b.c -lm && ./z | tail > 1016 7.022239e+305 <-- not a valid float > 1017 1.404448e+306 <-- not a valid float > 1018 2.808896e+306 <-- not a valid float > 1019 5.617791e+306 <-- not a valid float > 1020 1.123558e+307 <-- not a valid float > 1021 2.247116e+307 <-- not a valid float > 1022 4.494233e+307 <-- not a valid float > 1023 8.988466e+307 <-- not a valid float > 1024 inf > FE_UNDERFLOW: x =3D inf after 1024 iterations >=20 > Clang is broken with or without #pragma FENV_ACCESS "on". Well, it simply doesn't support that #pragma [1], just like gcc [2]. :-( Apparently compiler writers have trouble with this pragma, don't implement it, and assume that it's always off. Which then appears to make most (or all) fenv.h functions into undefined behavior. That said, making 'x' in your test case volatile helps, e.g. the main loop was: fadd %st(0), %st(0) fstl -20(%ebp) incl %esi movl %esi, 4(%esp) fstpl 8(%esp) movl $.L.str, (%esp) calll printf fnstsw -10(%ebp) and becomes: flds -16(%ebp) fadd %st(0), %st(0) fstps -16(%ebp) incl %esi flds -16(%ebp) fstpl 8(%esp) movl %esi, 4(%esp) movl $.L.str, (%esp) calll printf #APP fnstsw -10(%ebp) So the fstps causes an overflow when 128 iterations are reached: [...] 126 8.507059e+37 127 1.701412e+38 128 inf FE_UNDERFLOW: x =3D inf after 128 iterations Maybe this is a usable workaround for libm. -Dimitry [1] https://llvm.org/bugs/show_bug.cgi?id=3D8100 [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D34678 --Apple-Mail=_31F93044-399F-4178-AEAC-61A60D68E98B 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.29 iEYEARECAAYFAlbnD7sACgkQsF6jCi4glqO1pgCfV451ofXJJz9udR4DzWyPpPrx gLkAoK1IOJCSYSGWEaTBBiQ8SUHtdW6u =F9zX -----END PGP SIGNATURE----- --Apple-Mail=_31F93044-399F-4178-AEAC-61A60D68E98B-- From owner-freebsd-toolchain@freebsd.org Mon Mar 14 20:30:29 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 D0363AD0876 for ; Mon, 14 Mar 2016 20:30:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AB3F4F7; Mon, 14 Mar 2016 20:30:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id u2EKUNOH034962 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Mar 2016 13:30:23 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id u2EKUN50034961; Mon, 14 Mar 2016 13:30:23 -0700 (PDT) (envelope-from sgk) Date: Mon, 14 Mar 2016 13:30:23 -0700 From: Steve Kargl To: Dimitry Andric Cc: freebsd-toolchain@freebsd.org Subject: Re: clang gets numerical underflow wrong, please fix. Message-ID: <20160314203023.GA34638@troutmask.apl.washington.edu> References: <20160313182521.GA25361@troutmask.apl.washington.edu> <74970883-FE44-47C0-BDA0-92DB0723398A@FreeBSD.org> <20160313201004.GA26343@troutmask.apl.washington.edu> <20160314015311.GA28237@troutmask.apl.washington.edu> <65DA5D5E-6BEE-4522-9478-B659724F9CDC@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65DA5D5E-6BEE-4522-9478-B659724F9CDC@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 14 Mar 2016 20:30:29 -0000 On Mon, Mar 14, 2016 at 08:23:33PM +0100, Dimitry Andric wrote: > > Maybe this is a usable workaround for libm. > Thanks for looking into this. I just read the audit trail at llvm.org. Searching the clang user manual turns up The support for standard C in clang is feature-complete except for the C99 floating-point pragmas. There is no other statement concerning the implementation defined behavior. The understated assumption that FENV_ACCESS is tacitly set to OFF should be documented. It won't help possible libm issues. The libm function is trying to raise the FE_UNDERFLOW signal and return 0 to a program. As it is now, the libm function returns a nonzero invalid result. -- Steve From owner-freebsd-toolchain@freebsd.org Tue Mar 15 12:19: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 DA4FEAD0234 for ; Tue, 15 Mar 2016 12:19:25 +0000 (UTC) (envelope-from wjw@digiware.nl) 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 C78DD197 for ; Tue, 15 Mar 2016 12:19:25 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: by mailman.ysv.freebsd.org (Postfix) id C6655AD0233; Tue, 15 Mar 2016 12:19:25 +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 C5FB1AD0232 for ; Tue, 15 Mar 2016 12:19:25 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (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 90C62196 for ; Tue, 15 Mar 2016 12:19:25 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 46A0D153430 for ; Tue, 15 Mar 2016 13:19:17 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFHWErR1Syov; Tue, 15 Mar 2016 13:19:14 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:74da:8ef4:6da7:d3d2] (unknown [IPv6:2001:4cb8:3:1:74da:8ef4:6da7:d3d2]) by smtp.digiware.nl (Postfix) with ESMTP id 3E058153416 for ; Tue, 15 Mar 2016 12:41:15 +0100 (CET) To: toolchain@freebsd.org From: Willem Jan Withagen Subject: Crash in ostream < Date: Tue, 15 Mar 2016 12:41:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 12:19:26 -0000 Hi, While running Ceph tools I get a crash in fr 10 #10 0x00000000016d82ca in FileStore::omap_get_values(coll_t const&, ghobject_t const&, std::__1::set, std::__1::allocator >, std::__1::less, std::__1::allocator > >, std::__1::allocator, std::__1::allocator > > > const&, std::__1::map, std::__1::allocator >, ceph::buffer::list, std::__1::less, std::__1::allocator > >, std::__1::allocator, std::__1::allocator > const, ceph::buffer::list> > >*) () (gdb) l 95 int preload_erasure_code() 96 { 97 string plugins = g_conf->osd_erasure_code_plugins; 98 stringstream ss; 99 int r = ErasureCodePluginRegistry::instance().preload( 100 plugins, 101 g_conf->erasure_code_dir, 102 &ss); 103 if (r) 104 derr << ss.str() << dendl; (gdb) 105 else 106 dout(10) << ss.str() << dendl; 107 return r; 108 } 109 All of this seems to be inlined since I'm not able to get at ss or r #8 0x0000000000e16145 in std::__1::char_traits::length (__s=0x0) at /usr/include/c++/v1/string:640 640 static inline size_t length(const char_type* __s) {return strlen(__s);} Looking at the strlen implementation in /usr/srcs/head/src/lib/libc/string/strlen.c shows that strlen does not take 0x0 as pointer, so when we get here with __s = 0x0 all is lost. So I tried running it through 3.7, but since this is in the libraries with the bintools/os, I'd expect both versions to crash on this. Now the question I have to solve: is it the compiler/toolset/libraries is it a bug in the ceph code. --WjW From owner-freebsd-toolchain@freebsd.org Tue Mar 15 18:52:36 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7BA8AD2BE3 for ; Tue, 15 Mar 2016 18:52:36 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id B2D1F11A6 for ; Tue, 15 Mar 2016 18:52:36 +0000 (UTC) (envelope-from dimitry@andric.com) Received: by mailman.ysv.freebsd.org (Postfix) id B2235AD2BE2; Tue, 15 Mar 2016 18:52:36 +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 B1B9DAD2BE1 for ; Tue, 15 Mar 2016 18:52:36 +0000 (UTC) (envelope-from dimitry@andric.com) 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 60A2E11A5 for ; Tue, 15 Mar 2016 18:52:36 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8591D2FE6F; Tue, 15 Mar 2016 19:52:32 +0100 (CET) Subject: Re: Crash in ostream < In-Reply-To: <56E7F4DB.2000404@digiware.nl> Date: Tue, 15 Mar 2016 19:52:23 +0100 Cc: toolchain@freebsd.org Message-Id: <53A640CD-4F24-4242-8252-B27225A20071@andric.com> References: <56E7F4DB.2000404@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 18:52:36 -0000 --Apple-Mail=_48D33D00-7598-4A06-AC2B-D83CCA6237C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 15 Mar 2016, at 12:41, Willem Jan Withagen wrote: >=20 > While running Ceph tools I get a crash in > fr 10 > #10 0x00000000016d82ca in FileStore::omap_get_values(coll_t const&, = ghobject_t const&, std::__1::set, std::__1::allocator >, = std::__1::less, = std::__1::allocator > >, = std::__1::allocator, std::__1::allocator > > > const&, = std::__1::map, = std::__1::allocator >, ceph::buffer::list, = std::__1::less, = std::__1::allocator > >, = std::__1::allocator, std::__1::allocator > const, = ceph::buffer::list> > >*) () > (gdb) l > 95 int preload_erasure_code() > 96 { > 97 string plugins =3D g_conf->osd_erasure_code_plugins; > 98 stringstream ss; > 99 int r =3D ErasureCodePluginRegistry::instance().preload( > 100 plugins, > 101 g_conf->erasure_code_dir, > 102 &ss); > 103 if (r) > 104 derr << ss.str() << dendl; > (gdb) > 105 else > 106 dout(10) << ss.str() << dendl; > 107 return r; > 108 } > 109 >=20 > All of this seems to be inlined since I'm not able to get at ss or r >=20 >=20 > #8 0x0000000000e16145 in std::__1::char_traits::length = (__s=3D0x0) at /usr/include/c++/v1/string:640 > 640 static inline size_t length(const char_type* __s) {return = strlen(__s);} What happened here is that something attempted to initialize a std::string with a NULL pointer, and that isn't allowed. As you saw in the debugger, the constructor just runs strlen() on the incoming string, and that will segfault. > Looking at the strlen implementation in > /usr/srcs/head/src/lib/libc/string/strlen.c >=20 > shows that strlen does not take 0x0 as pointer, so when we get here = with __s =3D 0x0 all is lost. > So I tried running it through 3.7, but since this is in the libraries = with the bintools/os, I'd expect > both versions to crash on this. >=20 > Now the question I have to solve: > is it the compiler/toolset/libraries > is it a bug in the ceph code. Most likely a bug in the Ceph code. Try figuring out where the NULL pointer originally came from. -Dimitry --Apple-Mail=_48D33D00-7598-4A06-AC2B-D83CCA6237C6 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.29 iEYEARECAAYFAlboWe8ACgkQsF6jCi4glqMwbACdGt0cmUbBlB+BqNzj855qKCMS KQ0AoOIsIViuYUEDkMK29sf6COV4NzkL =2ZzA -----END PGP SIGNATURE----- --Apple-Mail=_48D33D00-7598-4A06-AC2B-D83CCA6237C6-- From owner-freebsd-toolchain@freebsd.org Tue Mar 15 20:51: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 489D0AD00B3 for ; Tue, 15 Mar 2016 20:51:20 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 33FD22084 for ; Tue, 15 Mar 2016 20:51:20 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: by mailman.ysv.freebsd.org (Postfix) id 2FC41AD00B1; Tue, 15 Mar 2016 20:51:20 +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 2F690AD00AF for ; Tue, 15 Mar 2016 20:51:20 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [31.223.170.169]) (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 B86732082 for ; Tue, 15 Mar 2016 20:51:18 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 6CE6C1534CB; Tue, 15 Mar 2016 21:51:15 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfS2PoujM6Vh; Tue, 15 Mar 2016 21:50:48 +0100 (CET) Received: from [192.168.10.10] (asus [192.168.10.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id C35C3153413; Tue, 15 Mar 2016 21:50:48 +0100 (CET) Subject: Re: Crash in ostream < References: <56E7F4DB.2000404@digiware.nl> <53A640CD-4F24-4242-8252-B27225A20071@andric.com> Cc: toolchain@freebsd.org From: Willem Jan Withagen Message-ID: <56E875A8.4090309@digiware.nl> Date: Tue, 15 Mar 2016 21:50:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <53A640CD-4F24-4242-8252-B27225A20071@andric.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 20:51:20 -0000 On 15-3-2016 19:52, Dimitry Andric wrote: > On 15 Mar 2016, at 12:41, Willem Jan Withagen wrote: >> >> While running Ceph tools I get a crash in >> fr 10 >> #10 0x00000000016d82ca in FileStore::omap_get_values(coll_t const&, ghobject_t const&, std::__1::set, std::__1::allocator >, std::__1::less, std::__1::allocator > >, std::__1::allocator, std::__1::allocator > > > const&, std::__1::map, std::__1::allocator >, ceph::buffer::list, std::__1::less, std::__1::allocator > >, std::__1::allocator, std::__1::allocator > const, ceph::buffer::list> > >*) () >> (gdb) l >> 95 int preload_erasure_code() >> 96 { >> 97 string plugins = g_conf->osd_erasure_code_plugins; >> 98 stringstream ss; >> 99 int r = ErasureCodePluginRegistry::instance().preload( >> 100 plugins, >> 101 g_conf->erasure_code_dir, >> 102 &ss); >> 103 if (r) >> 104 derr << ss.str() << dendl; >> (gdb) >> 105 else >> 106 dout(10) << ss.str() << dendl; >> 107 return r; >> 108 } >> 109 >> >> All of this seems to be inlined since I'm not able to get at ss or r >> >> >> #8 0x0000000000e16145 in std::__1::char_traits::length (__s=0x0) at /usr/include/c++/v1/string:640 >> 640 static inline size_t length(const char_type* __s) {return strlen(__s);} > > What happened here is that something attempted to initialize a > std::string with a NULL pointer, and that isn't allowed. As you saw in > the debugger, the constructor just runs strlen() on the incoming string, > and that will segfault. > > >> Looking at the strlen implementation in >> /usr/srcs/head/src/lib/libc/string/strlen.c >> >> shows that strlen does not take 0x0 as pointer, so when we get here with __s = 0x0 all is lost. >> So I tried running it through 3.7, but since this is in the libraries with the bintools/os, I'd expect >> both versions to crash on this. >> >> Now the question I have to solve: >> is it the compiler/toolset/libraries >> is it a bug in the ceph code. > > Most likely a bug in the Ceph code. Try figuring out where the NULL > pointer originally came from. I've started with compiling wit -O0 but that probably will still inline the pieces of code designated as such. Otherwise I'll have to resort to inserting asserts. I'm now using gdb 7.1, loading lldb gives me a sort of strange commandline that looks like utf-8-ish??? Would lldb give better analysis of the structures? --WjW From owner-freebsd-toolchain@freebsd.org Tue Mar 15 21:20:54 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A07FBAD0CBD for ; Tue, 15 Mar 2016 21:20:54 +0000 (UTC) (envelope-from dim@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 8AC351192 for ; Tue, 15 Mar 2016 21:20:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 8A37AAD0CBC; Tue, 15 Mar 2016 21:20:54 +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 89E81AD0CBB for ; Tue, 15 Mar 2016 21:20:54 +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 4FF7D1190 for ; Tue, 15 Mar 2016 21:20:54 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::8d74:9b5a:eb74:345f] (unknown [IPv6:2001:7b8:3a7:0:8d74:9b5a:eb74:345f]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id AC4DF2F066; Tue, 15 Mar 2016 22:20:50 +0100 (CET) Subject: Re: Crash in ostream < In-Reply-To: <56E875A8.4090309@digiware.nl> Date: Tue, 15 Mar 2016 22:20:39 +0100 Cc: toolchain@freebsd.org Message-Id: References: <56E7F4DB.2000404@digiware.nl> <53A640CD-4F24-4242-8252-B27225A20071@andric.com> <56E875A8.4090309@digiware.nl> To: Willem Jan Withagen X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 21:20:54 -0000 --Apple-Mail=_C81120C4-349A-4053-A7AF-545C45FFF916 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 On 15 Mar 2016, at 21:50, Willem Jan Withagen wrote: > > On 15-3-2016 19:52, Dimitry Andric wrote: ... Most likely a bug in the Ceph code. Try figuring out where the NULL >> pointer originally came from. > > I've started with compiling wit -O0 but that probably will still inline > the pieces of code designated as such. Otherwise I'll have to resort to > inserting asserts. > > I'm now using gdb 7.1, loading lldb gives me a sort of strange > commandline that looks like utf-8-ish??? > Would lldb give better analysis of the structures? Maybe, but compiling at least some files with -O0 might help. With regards to the weird keyboard input, this was a problem (or bad side effect) of a recent libedit import, in r296175. Pedro Giffuni rolled it back in r296435, after that lldb's line editor should work OK again. -Dimitry --Apple-Mail=_C81120C4-349A-4053-A7AF-545C45FFF916 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.29 iEYEARECAAYFAlbofLIACgkQsF6jCi4glqOyywCg/5UIfYZUwMCk1bQSZv/JyEZM T7oAni74PvO33gb8s2dP2plBI5LsGYx1 =K8Xo -----END PGP SIGNATURE----- --Apple-Mail=_C81120C4-349A-4053-A7AF-545C45FFF916-- From owner-freebsd-toolchain@freebsd.org Wed Mar 16 21:27: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 06EE0AD27C7 for ; Wed, 16 Mar 2016 21:27:55 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from smtp.burggraben.net (smtp.burggraben.net [IPv6:2a01:4f8:140:50a2::3:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ns.exwg.net", Issuer "Christoph Moench-Tegeder" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AA408AEE for ; Wed, 16 Mar 2016 21:27:54 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from localhost (localhost [127.0.0.1]) by smtp.burggraben.net (Postfix) with ESMTP id 935316002EB for ; Wed, 16 Mar 2016 22:27:51 +0100 (CET) X-Spam-Scanned: by amavisd-new at exwg.net Received: from smtp.burggraben.net ([127.0.0.1]) by localhost (ns.burggraben.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zQtuXdlCLM8 for ; Wed, 16 Mar 2016 22:27:50 +0100 (CET) Received: from squirrel.exwg.net (unknown [62.237.32.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "squirrel.exwg.net", Issuer "Christoph Moench-Tegeder" (verified OK)) by smtp.burggraben.net (Postfix) with ESMTPS for ; Wed, 16 Mar 2016 22:27:50 +0100 (CET) Received: by squirrel.exwg.net (Postfix, from userid 1000) id 7DE8961FAC; Wed, 16 Mar 2016 22:27:49 +0100 (CET) Date: Wed, 16 Mar 2016 22:27:49 +0100 From: Christoph Moench-Tegeder To: freebsd-toolchain@freebsd.org Subject: c++/libc++ help needed for chromium update Message-ID: <20160316212749.GA1426@squirrel.exwg.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 16 Mar 2016 21:27:55 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I'm currently working on updating www/chromium to the latest version (the 49 versions). Recently (that is, during development of version 49) the chromium developers allowed some c++11 features to be used. Included in those is std::move(), replacing their homegrown rvalue-reference-generating code (the .Pass() hack). That required me to use lang/clang36 as a compiler (with our clang 3.4.1 in FreeBSD 10 I got a bunch of obviously "wrong errors"). The following is my interpretation, grain-of-salt applies. There's one issue remaining: this line https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/internal_api/public/data_batch_impl.cc#15 causes an compiler error - complaining that a copy-assignment operator had to be used but the operator had been deleted (error message attached, it's a little unwieldy). The scoped_ptr implementation is this one: https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/base/memory/scoped_ptr.h and the magic DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND() has been defined here: https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/base/move.h#35 The key_data_pairs_ thing is a std::vector https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/internal_api/public/data_batch_impl.h#41 while KeyAndData is a std::pair<> https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/api/data_batch.h#18 (I think you get the hang of it...) As clang is the "official" compiler used upstream, and after some research into C++ land (I'm from the plain C side), I'm suspecting that our libc++ is at fault (and it's behind upstream, of course, but there's no "simple" way of importing a new one - devel/libc++ leaves the templates in /usr/include alone). Build results on FreeBSD 11 are still... building Could anyone point me in a direction to resolve this? Regards, Christoph -- Spare Space --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=chromium49_deleted_operator Content-Transfer-Encoding: quoted-printable FAILED: /usr/local/bin/clang++36 -MMD -MF obj/sync/internal_api/public/sync= _core.data_batch_impl.o.d -DV8_DEPRECATION_WARNINGS -DCLD_VERSION=3D2 -D_FI= LE_OFFSET_BITS=3D64 -DNO_TCMALLOC -DDISABLE_NACL -DCHROMIUM_BUILD -DCR_CLAN= G_REVISION=3D255169-1 -DUSE_AURA=3D1 -DUSE_ASH=3D1 -DUSE_PANGO=3D1 -DUSE_CA= IRO=3D1 -DUSE_DEFAULT_RENDER_THEME=3D1 -DUSE_LIBJPEG_TURBO=3D1 -DUSE_X11=3D= 1 -DUSE_CLIPBOARD_AURAX11=3D1 -DENABLE_ONE_CLICK_SIGNIN -DENABLE_WEBRTC=3D1= -DENABLE_MEDIA_ROUTER=3D1 -DUSE_PROPRIETARY_CODECS -DENABLE_CONFIGURATION_= POLICY -DENABLE_NOTIFICATIONS -DDONT_EMBED_BUILD_METADATA -DFIELDTRIAL_TEST= ING_ENABLED -DENABLE_TASK_MANAGER=3D1 -DENABLE_EXTENSIONS=3D1 -DENABLE_PDF= =3D1 -DENABLE_PLUGINS=3D1 -DENABLE_SESSION_SERVICE=3D1 -DENABLE_THEMES=3D1 = -DENABLE_AUTOFILL_DIALOG=3D1 -DENABLE_BACKGROUND=3D1 -DENABLE_PRINTING=3D1 = -DENABLE_BASIC_PRINTING=3D1 -DENABLE_PRINT_PREVIEW=3D1 -DENABLE_SPELLCHECK= =3D1 -DENABLE_CAPTIVE_PORTAL_DETECTION=3D1 -DENABLE_APP_LIST=3D1 -DENABLE_S= ETTINGS_APP=3D1 -DENABLE_SUPERVISED_USERS=3D1 -DENABLE_MDNS=3D1 -DENABLE_SE= RVICE_DISCOVERY=3D1 -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSIN= G_DB_LOCAL -DSYNC_IMPLEMENTATION -DU_USING_ICU_NAMESPACE=3D0 -DPROTOBUF_USE= _DLLS -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DU= SE_LIBPCI=3D1 -DUSE_OPENSSL=3D1 -DUSE_GLIB=3D1 -DUSE_NSS_CERTS=3D1 -D__STDC= _CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNO= TATIONS_ENABLED=3D0 -D_FORTIFY_SOURCE=3D2 -Igen/shim_headers/snappy/target = -Igen/shim_headers/re2/target -Igen/shim_headers/icuuc/target -Igen/shim_he= aders/icui18n/target -Igen/shim_headers/libevent/target -Igen -I../.. -I../= =2E./third_party/leveldatabase/src/include -I../../third_party/leveldatabas= e/src -I../../third_party/leveldatabase -I../../third_party/protobuf -I../.= =2E/third_party/protobuf/src -I../../third_party/zlib -Igen/protoc_out -fst= ack-protector --param=3Dssp-buffer-size=3D4 -pthread -fno-strict-aliasing = -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fvisib= ility=3Dhidden -pipe -fPIC -fcolor-diagnostics -Wheader-hygiene -Wfor-loop-= analysis -Wno-char-subscripts -Wno-unneeded-internal-declaration -Wno-cover= ed-switch-default -Wstring-conversion -Wno-c++11-narrowing -Wno-deprecated-= register -Wno-inconsistent-missing-override -Wno-shift-negative-value -Wexi= t-time-destructors -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/= include -I/usr/local/include -pthread -I/usr/local/include -I/usr/local/inc= lude -I/usr/local/include/nss -I/usr/local/include/nss/nss -I/usr/local/inc= lude/nspr -Wno-header-guard -m64 -march=3Dx86-64 -O2 -fno-ident -fdata-sect= ions -ffunction-sections -funwind-tables -O2 -pipe -march=3Dcore2 -isystem/= usr/local/include -I/usr/local/include/atk-1.0 -Wno-unknown-warning-option = -fstack-protector -fno-strict-aliasing -fno-exceptions -fno-rtti -fno-threa= dsafe-statics -fvisibility-inlines-hidden -std=3Dgnu++11 -c ../../sync/int= ernal_api/public/data_batch_impl.cc -o obj/sync/internal_api/public/sync_co= re.data_batch_impl.o In file included from ../../sync/internal_api/public/data_batch_impl.cc:5: In file included from ../../sync/internal_api/public/data_batch_impl.h:10: In file included from /usr/include/c++/v1/string:439: In file included from /usr/include/c++/v1/algorithm:627: /usr/include/c++/v1/utility:284:11: error: call to deleted constructor of '= scoped_ptr >' second(__p.second) ^ ~~~~~~~~~~ /usr/include/c++/v1/memory:1645:31: note: in instantiation of member functi= on 'std::__1::pair, scoped_ptr > >::pair' requeste= d here ::new((void*)__p) _Up(_VSTD::forward<_Args>(__args)...); ^ /usr/include/c++/v1/memory:1572:18: note: in instantiation of function temp= late specialization 'std::__1::allocator, scoped_ptr > > >::construct, scoped_ptr > >, const std::__1::pair, scoped_= ptr = > > &>' requested here {__a.construct(__p, _VSTD::forward<_Args>(__args)...);} ^ /usr/include/c++/v1/memory:1453:14: note: in instantiation of function temp= late specialization 'std::__1::allocator_traits, scoped_ptr > > > >::__construct, scoped_ptr > >, const std::__1::pair, scoped_ptr > > &>' requested here {__construct(__has_construct(), ^ /usr/include/c++/v1/memory:1535:17: note: in instantiation of function temp= late specialization 'std::__1::allocator_traits, scoped_ptr > > > >::construct, scoped_ptr > >, const std::__1::pair, scoped_ptr > > &>' requested here construct(__a, _VSTD::__to_raw_pointer(__end2-1), _VSTD::mo= ve_if_noexcept(*--__end1)); ^ /usr/include/c++/v1/vector:897:21: note: in instantiation of function templ= ate specialization 'std::__1::allocator_traits, scoped_ptr > > > >::__construct_backward, scoped_ptr > > *>' requested here __alloc_traits::__construct_backward(this->__alloc(), this->__begin_, t= his->__end_, __v.__begin_); ^ /usr/include/c++/v1/vector:1583:5: note: in instantiation of member functio= n 'std::__1::vector, scoped_ptr= > >= , std::__1::allocator, scoped_p= tr >= > > >::__swap_out_circular_buffer' requested here __swap_out_circular_buffer(__v); ^ /usr/include/c++/v1/vector:1620:9: note: in instantiation of function templ= ate specialization 'std::__1::vector, scoped_ptr > >, std::__1::allocator, scoped_ptr > > > >::__push_back_slow_path, scoped_ptr > > >' requested here __push_back_slow_path(_VSTD::move(__x)); ^ =2E./../sync/internal_api/public/data_batch_impl.cc:15:19: note: in instant= iation of member function 'std::__1::vector, scoped_ptr > >, std::__1::allocator, scoped_ptr > > > >::push_back' requested here key_data_pairs_.push_back(KeyAndData(client_key, std::move(specifics))); ^ =2E./../base/memory/scoped_ptr.h:241:47: note: 'scoped_ptr' has been explic= itly marked deleted here DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND(scoped_ptr) ^ =2E./../base/move.h:47:3: note: expanded from macro 'DISALLOW_COPY_AND_ASSI= GN_WITH_MOVE_FOR_BIND' type(const type&) =3D delete; \ ^ 1 error generated. --ikeVEW9yuYc//A+q-- From owner-freebsd-toolchain@freebsd.org Wed Mar 16 22:36: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 145EEAD3CD3 for ; Wed, 16 Mar 2016 22:36:13 +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 B0E89B12 for ; Wed, 16 Mar 2016 22:36:12 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::ecf9:a174:3b2:d2d8] (unknown [IPv6:2001:7b8:3a7:0:ecf9:a174:3b2:d2d8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 225462F330; Wed, 16 Mar 2016 23:36:09 +0100 (CET) Subject: Re: c++/libc++ help needed for chromium update Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6864711C-923F-4D64-9735-06113A7ECDEE"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <20160316212749.GA1426@squirrel.exwg.net> Date: Wed, 16 Mar 2016 23:36:01 +0100 Cc: freebsd-toolchain@freebsd.org Message-Id: <458AB9BF-4D4F-4F72-B2D7-79ACC8E19108@FreeBSD.org> References: <20160316212749.GA1426@squirrel.exwg.net> To: Christoph Moench-Tegeder X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 16 Mar 2016 22:36:13 -0000 --Apple-Mail=_6864711C-923F-4D64-9735-06113A7ECDEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 16 Mar 2016, at 22:27, Christoph Moench-Tegeder = wrote: >=20 > I'm currently working on updating www/chromium to the latest > version (the 49 versions). Recently (that is, during development > of version 49) the chromium developers allowed some c++11 features > to be used. > Included in those is std::move(), replacing their homegrown > rvalue-reference-generating code (the .Pass() hack). That > required me to use lang/clang36 as a compiler (with our > clang 3.4.1 in FreeBSD 10 I got a bunch of obviously "wrong > errors"). >=20 > The following is my interpretation, grain-of-salt applies. >=20 > There's one issue remaining: this line > = https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/int= ernal_api/public/data_batch_impl.cc#15 > causes an compiler error - complaining that a copy-assignment > operator had to be used but the operator had been deleted (error > message attached, it's a little unwieldy). >=20 > The scoped_ptr implementation is this one: > = https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/base/mem= ory/scoped_ptr.h > and the magic DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND() > has been defined here: > = https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/base/mov= e.h#35 >=20 > The key_data_pairs_ thing is a std::vector > = https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/int= ernal_api/public/data_batch_impl.h#41 > while KeyAndData is a std::pair<> > = https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/api= /data_batch.h#18 >=20 > (I think you get the hang of it...) >=20 > As clang is the "official" compiler used upstream, and after some > research into C++ land (I'm from the plain C side), I'm suspecting > that our libc++ is at fault (and it's behind upstream, of course, > but there's no "simple" way of importing a new one - devel/libc++ > leaves the templates in /usr/include alone). Build results on > FreeBSD 11 are still... building >=20 > Could anyone point me in a direction to resolve this? While you are waiting for the FreeBSD 11 builds to complete, there are maybe a few things you could try. In r261801 [1], we turned off the _LIBCPP_TRIVIAL_PAIR_COPY_CTOR option in libc++, because it made the ABI incompatible with the version of libc++ we had shipped before that time. However, this option makes the std::pair copy constructor non-trivial, and this is a possible cause for your compilation error. The relevant part in is: template struct _LIBCPP_TYPE_VIS_ONLY pair { [...] #if !defined(_LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS) && = _LIBCPP_TRIVIAL_PAIR_COPY_CTOR _LIBCPP_INLINE_VISIBILITY pair(const pair& __p) =3D default; #elif !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) || = !_LIBCPP_TRIVIAL_PAIR_COPY_CTOR _LIBCPP_INLINE_VISIBILITY pair(const pair& __p) _NOEXCEPT_(is_nothrow_copy_constructible::value && is_nothrow_copy_constructible::value) : first(__p.first), second(__p.second) { } #endif E.g. in the case of a trivial copy constructor, it is created with "=3D default", but otherwise it uses the copy constructors of the 'first' and 'second' members. If these copy constructors are inaccessible or deleted, as it looks like in this case, you will get an error about it. The first thing you could try is to compile the Chromium source with -D_LIBCPP_TRIVIAL_PAIR_COPY_CTOR=3D1 added to the flags. This will re-enable the trivial copy constructor for std::pair, but it is possibly incompatible with precompiled libc++.so on your system. Therefore, things might break at runtime, in interesting ways. Another thing you could try is to change the definition of scoped_ptr, and comment out the deletion of its copy constructor. However, I'm unsure what side effects this may cause, as it is probably unwise to copy scoped_ptrs. Last but not least, please ask about this on the Chromium mailing lists. There must be lots of C++ libraries out there with non-trivial std::pair copy constructors, and they must have some sort of workaround for those. -Dimitry [1] http://svnweb.freebsd.org/changeset/base/261801 --Apple-Mail=_6864711C-923F-4D64-9735-06113A7ECDEE 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.29 iEYEARECAAYFAlbp39gACgkQsF6jCi4glqNUGgCgxG++i1RjGLNNegbuojzbvM0p sn0AoN1o3Lsfjg7+EuKOhfAQD3/Rinhb =UqHN -----END PGP SIGNATURE----- --Apple-Mail=_6864711C-923F-4D64-9735-06113A7ECDEE-- From owner-freebsd-toolchain@freebsd.org Wed Mar 16 22:46: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 60BB3AD202B for ; Wed, 16 Mar 2016 22:46:03 +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 27FA2221 for ; Wed, 16 Mar 2016 22:46:02 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::ecf9:a174:3b2:d2d8] (unknown [IPv6:2001:7b8:3a7:0:ecf9:a174:3b2:d2d8]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 301622F350; Wed, 16 Mar 2016 23:46:01 +0100 (CET) Subject: Re: c++/libc++ help needed for chromium update Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_934D2CE4-3466-42A2-B9D9-13294C56B532"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <458AB9BF-4D4F-4F72-B2D7-79ACC8E19108@FreeBSD.org> Date: Wed, 16 Mar 2016 23:46:00 +0100 Cc: freebsd-toolchain@freebsd.org Message-Id: <8B77EACE-EE6D-412F-97AB-9226FDE02951@FreeBSD.org> References: <20160316212749.GA1426@squirrel.exwg.net> <458AB9BF-4D4F-4F72-B2D7-79ACC8E19108@FreeBSD.org> To: Christoph Moench-Tegeder X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 16 Mar 2016 22:46:03 -0000 --Apple-Mail=_934D2CE4-3466-42A2-B9D9-13294C56B532 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 16 Mar 2016, at 23:36, Dimitry Andric wrote: >=20 > On 16 Mar 2016, at 22:27, Christoph Moench-Tegeder = wrote: ... >> Could anyone point me in a direction to resolve this? ... > Last but not least, please ask about this on the Chromium mailing = lists. > There must be lots of C++ libraries out there with non-trivial = std::pair > copy constructors, and they must have some sort of workaround for = those. Yet another thing you could try is changing DataBatchImpl::Put() as = follows: --- a/data_batch_impl.cc 2016-03-16 23:43:50.000000000 +0100 +++ b/data_batch_impl.cc 2016-03-16 23:44:01.000000000 +0100 @@ -12,7 +12,7 @@ DataBatchImpl::~DataBatchImpl() {} void DataBatchImpl::Put(const std::string& client_key, scoped_ptr specifics) { - key_data_pairs_.push_back(KeyAndData(client_key, = std::move(specifics))); + key_data_pairs_.push_back(std::move(KeyAndData(client_key, = std::move(specifics)))); } bool DataBatchImpl::HasNext() const { I'm not 100% sure this will work, but it might... :) -Dimitry --Apple-Mail=_934D2CE4-3466-42A2-B9D9-13294C56B532 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.29 iEYEARECAAYFAlbp4igACgkQsF6jCi4glqOBtACfdDlFmOQExvwKbNcMwj8Wom4r 1GYAn3XpCfGEbdYzUSWu5j6p3A7Mk5Qn =oCzf -----END PGP SIGNATURE----- --Apple-Mail=_934D2CE4-3466-42A2-B9D9-13294C56B532-- From owner-freebsd-toolchain@freebsd.org Thu Mar 17 11:38: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 24A7BAD45A8 for ; Thu, 17 Mar 2016 11:38:34 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from smtp.burggraben.net (smtp.burggraben.net [IPv6:2a01:4f8:140:50a2::3:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ns.exwg.net", Issuer "Christoph Moench-Tegeder" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DF5B9AE2; Thu, 17 Mar 2016 11:38:33 +0000 (UTC) (envelope-from cmt@burggraben.net) Received: from localhost (localhost [127.0.0.1]) by smtp.burggraben.net (Postfix) with ESMTP id C4BCE6002EB; Thu, 17 Mar 2016 12:38:30 +0100 (CET) X-Spam-Scanned: by amavisd-new at exwg.net Received: from smtp.burggraben.net ([127.0.0.1]) by localhost (ns.burggraben.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekPXWaEqj7-Z; Thu, 17 Mar 2016 12:38:30 +0100 (CET) Received: from squirrel.exwg.net (unknown [62.237.32.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "squirrel.exwg.net", Issuer "Christoph Moench-Tegeder" (verified OK)) by smtp.burggraben.net (Postfix) with ESMTPS; Thu, 17 Mar 2016 12:38:30 +0100 (CET) Received: by squirrel.exwg.net (Postfix, from userid 1000) id 9156261FA6; Thu, 17 Mar 2016 12:38:29 +0100 (CET) Date: Thu, 17 Mar 2016 12:38:29 +0100 From: Christoph Moench-Tegeder To: Dimitry Andric Cc: freebsd-toolchain@freebsd.org Subject: Re: c++/libc++ help needed for chromium update Message-ID: <20160317113829.GA1752@squirrel.exwg.net> References: <20160316212749.GA1426@squirrel.exwg.net> <458AB9BF-4D4F-4F72-B2D7-79ACC8E19108@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <458AB9BF-4D4F-4F72-B2D7-79ACC8E19108@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 17 Mar 2016 11:38:34 -0000 ## Dimitry Andric (dim@FreeBSD.org): > In r261801 [1], we turned off the _LIBCPP_TRIVIAL_PAIR_COPY_CTOR option > in libc++, because it made the ABI incompatible with the version of > libc++ we had shipped before that time. However, this option makes the > std::pair copy constructor non-trivial, and this is a possible cause for > your compilation error. Ah, that sounds plausible. Let's see what the compiler says :) > Another thing you could try is to change the definition of scoped_ptr, > and comment out the deletion of its copy constructor. However, I'm > unsure what side effects this may cause, as it is probably unwise to > copy scoped_ptrs. Additionally, the scoped_ptrs are used widely throughout chromium, I'm not sure I'd be able to "fix" all the places. > Last but not least, please ask about this on the Chromium mailing lists. > There must be lots of C++ libraries out there with non-trivial std::pair > copy constructors, and they must have some sort of workaround for those. It's in the nature of chromium that it's Open Source, but the list of target platforms is rather short - officially supported are Windows (and I don't know how many people build their own chromium there), OS X and Linux. Chromium tends to bundle a lot of dependencies, I believe the default build process on Linux even brings it's own private clang installation if you don't stop it. The only other "special" build I'm aware of is OpenBSD, and they use gcc 4.9 with it's bundled libstdc++ (their base system uses the old gcc). So I guess we're the odd ones with our libc++... Regards, Christoph -- Spare Space From owner-freebsd-toolchain@freebsd.org Fri Mar 18 17:23:00 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 861DAAD5C0F for ; Fri, 18 Mar 2016 17:23:00 +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 4C01FF47 for ; Fri, 18 Mar 2016 17:23:00 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::55c4:44d3:46e9:f07c] (unknown [IPv6:2001:7b8:3a7:0:55c4:44d3:46e9:f07c]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B5E132F323; Fri, 18 Mar 2016 18:22:56 +0100 (CET) Subject: Re: c++/libc++ help needed for chromium update Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CC201581-BFAF-4B77-A030-09F8931B515B"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <20160317113829.GA1752@squirrel.exwg.net> Date: Fri, 18 Mar 2016 18:22:56 +0100 Cc: freebsd-toolchain@freebsd.org Message-Id: References: <20160316212749.GA1426@squirrel.exwg.net> <458AB9BF-4D4F-4F72-B2D7-79ACC8E19108@FreeBSD.org> <20160317113829.GA1752@squirrel.exwg.net> To: Christoph Moench-Tegeder X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 18 Mar 2016 17:23:00 -0000 --Apple-Mail=_CC201581-BFAF-4B77-A030-09F8931B515B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17 Mar 2016, at 12:38, Christoph Moench-Tegeder = wrote: ... >> Last but not least, please ask about this on the Chromium mailing = lists. >> There must be lots of C++ libraries out there with non-trivial = std::pair >> copy constructors, and they must have some sort of workaround for = those. >=20 > It's in the nature of chromium that it's Open Source, but the list of > target platforms is rather short - officially supported are Windows > (and I don't know how many people build their own chromium there), > OS X and Linux. Chromium tends to bundle a lot of dependencies, I > believe the default build process on Linux even brings it's own > private clang installation if you don't stop it. The only other > "special" build I'm aware of is OpenBSD, and they use gcc 4.9 > with it's bundled libstdc++ (their base system uses the old gcc). > So I guess we're the odd ones with our libc++... Not really, OSX also uses libc++ these days. However, they use the trivial pair copy constructor by default, as upstream libc++ does. See = /Applications/Xcode.app/Contents//Developer/Toolchains/XcodeDefault.xctool= chain/usr/include/c++/v1/__config on a Mac with Xcode installed, which has: 650 #ifndef _LIBCPP_TRIVIAL_PAIR_COPY_CTOR 651 # define _LIBCPP_TRIVIAL_PAIR_COPY_CTOR 1 652 #endif So not having the trivial pair copy constructor makes us the odd ones out, but until now I didn't see any port failing because of it. We could enable this feature, but then we'd have to bump our libc++ version, together with all the followup hassle. It would still be interesting to find some workaround in Chrome's code, though. It used to build in the previous version? (I remember building it successfully a few times in the past, at least.) -Dimitry --Apple-Mail=_CC201581-BFAF-4B77-A030-09F8931B515B 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.29 iEYEARECAAYFAlbsOXAACgkQsF6jCi4glqPFcgCgz1Utm4KY4FfKCg6vDBUnW3oF 9fcAn3UMmUOhvkbLuNHB0KQHGaNIwmeB =AVkx -----END PGP SIGNATURE----- --Apple-Mail=_CC201581-BFAF-4B77-A030-09F8931B515B-- From owner-freebsd-toolchain@freebsd.org Sat Mar 19 08:44:00 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 BFCC7AD4A7E for ; Sat, 19 Mar 2016 08:44:00 +0000 (UTC) (envelope-from dc552@hermes.cam.ac.uk) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) (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 8D9DEE64; Sat, 19 Mar 2016 08:44:00 +0000 (UTC) (envelope-from dc552@hermes.cam.ac.uk) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from [195.55.253.10] (port=22885 helo=[10.30.2.16]) by ppsw-43.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:587) with esmtpsa (PLAIN:dc552) (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1ahCUH-0004kA-mn (Exim 4.86_36-e07b163) (return-path ); Sat, 19 Mar 2016 08:43:57 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: c++/libc++ help needed for chromium update From: David Chisnall In-Reply-To: Date: Sat, 19 Mar 2016 08:43:54 +0000 Cc: Christoph Moench-Tegeder , freebsd-toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160316212749.GA1426@squirrel.exwg.net> <458AB9BF-4D4F-4F72-B2D7-79ACC8E19108@FreeBSD.org> <20160317113829.GA1752@squirrel.exwg.net> To: Dimitry Andric X-Mailer: Apple Mail (2.2104) Sender: "Dr D. Chisnall" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.21 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, 19 Mar 2016 08:44:00 -0000 On 18 Mar 2016, at 17:22, Dimitry Andric wrote: >=20 > We > could enable this feature, but then we'd have to bump our libc++ > version, together with all the followup hassle. There are quite a few ABI-breaking changes in libc++. Some improve = standards compliance and a few improve performance. I=E2=80=99d like = for us to enable them all (with associated so version bump) in 11. At = this point, it might make sense to do the same for libc++ in ports and = move ports over to depending on the ports version on <11. David