From owner-freebsd-toolchain@freebsd.org Sun Mar 6 01:13: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 F04B09DB98F for ; Sun, 6 Mar 2016 01:13:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.2]) (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 8BF237F6 for ; Sun, 6 Mar 2016 01:13:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29372 invoked from network); 6 Mar 2016 01:13:40 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Mar 2016 01:13:40 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 05 Mar 2016 20:13:37 -0500 (EST) Received: (qmail 12143 invoked from network); 6 Mar 2016 01:13:37 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 6 Mar 2016 01:13:37 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2656A1C43D7; Sat, 5 Mar 2016 17:13:17 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 207732 submitted: libgcc_s .eh_frame handling messes up interpreting powerpc/powerpc64 frame pointer register use produced by clang 3.8.0 Message-Id: <7BC7F7FF-FF5C-4BE9-875C-6997BC194295@dsl-only.net> Date: Sat, 5 Mar 2016 17:13:21 -0800 To: Roman Divacky , FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) 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, 06 Mar 2016 01:13:30 -0000 I have submitted FreeBSD bug 207732: libgcc_s .eh_frame handling messes up interpreting powerpc/powerpc64 = frame pointer register use produced by clang 3.8.0 In essence clang++ 3.8.0 generates Frame Pointer Register based code = (r31 in addition to the r1 stack pointer) that g++ 4.2.1/4.9/5.3 = (normally) do not and so the clang++ 3.8.0 code ends up touching an = error in libgcc_s interpreting .eh_frame information for C++ exception = handling that gcc 4.2.1 and the like side step by not using such a Frame = Pointer register. Note: The context for libgcc_s was a clang 3.8.0 based buildworld. A gcc = buildworld does not involve such a Frame Pointer Register. I do not know if any TARGET_ARCH's other than powerpc/powerpc64 also = generate such Frame Pointer Register like code and so might touch the = same error. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Mar 6 08:19:46 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0200B9DA3F9 for ; Sun, 6 Mar 2016 08:19:46 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.2]) (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 AB39B304 for ; Sun, 6 Mar 2016 08:19:45 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 9657 invoked from network); 6 Mar 2016 08:19:42 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 6 Mar 2016 08:19:42 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 06 Mar 2016 03:19:47 -0500 (EST) Received: (qmail 5983 invoked from network); 6 Mar 2016 08:19:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 6 Mar 2016 08:19:47 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 58D181C43D7; Sun, 6 Mar 2016 00:19:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 207732 submitted: libgcc_s .eh_frame handling messes up interpreting powerpc/powerpc64 frame pointer register use produced by clang 3.8.0 [I was wrong] From: Mark Millard In-Reply-To: <7BC7F7FF-FF5C-4BE9-875C-6997BC194295@dsl-only.net> Date: Sun, 6 Mar 2016 00:19:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <76083A2C-9659-46A9-B9DC-6944C50AF4E9@dsl-only.net> References: <7BC7F7FF-FF5C-4BE9-875C-6997BC194295@dsl-only.net> To: Roman Divacky , FreeBSD PowerPC ML , FreeBSD Toolchain X-Mailer: Apple Mail (2.2104) 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, 06 Mar 2016 08:19:46 -0000 On 2016-Mar-5, at 5:13 PM, Mark Millard wrote: >=20 > I have submitted FreeBSD bug 207732: >=20 > libgcc_s .eh_frame handling messes up interpreting powerpc/powerpc64 = frame pointer register use produced by clang 3.8.0 >=20 > In essence clang++ 3.8.0 generates Frame Pointer Register based code = (r31 in addition to the r1 stack pointer) that g++ 4.2.1/4.9/5.3 = (normally) do not and so the clang++ 3.8.0 code ends up touching an = error in libgcc_s interpreting .eh_frame information for C++ exception = handling that gcc 4.2.1 and the like side step by not using such a Frame = Pointer register. >=20 > Note: The context for libgcc_s was a clang 3.8.0 based buildworld. A = gcc buildworld does not involve such a Frame Pointer Register. >=20 > I do not know if any TARGET_ARCH's other than powerpc/powerpc64 also = generate such Frame Pointer Register like code and so might touch the = same error. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net With the other errors identified and reported for .eh_frame and C++ = exception handling for powerpc it is getting harder to tell if a problem = is a new problem or a consequence of the other ones. (Various problems = have no work around yet to avoid them.) This turned out to be a consequence of other problems. Such was easier to discover once I induced gcc 4.2.1 to generate some = example code with r31 in use as a frame pointer. (I used alloca and = default optimization.) Observing the result's behavior and the .eh_frame = output indicated I'd originally misinterpreted where the earliest = problem was in the clang 3.8.0 context. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Sun Mar 6 11:48:49 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DAE92AB724B for ; Sun, 6 Mar 2016 11:48:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-1.reflexion.net [208.70.210.1]) (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 90DCF893 for ; Sun, 6 Mar 2016 11:48:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25672 invoked from network); 6 Mar 2016 11:48:48 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 6 Mar 2016 11:48:48 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 06 Mar 2016 06:49:02 -0500 (EST) Received: (qmail 1110 invoked from network); 6 Mar 2016 11:49:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 6 Mar 2016 11:49:02 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id BF3FC1C43CC; Sun, 6 Mar 2016 03:48:45 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Bug 207736 submitted for TARGET_ARCH=powerpc (& ppc64?) clang 3.8.0 frame-pointer code generation error for _Unwind_RaiseException Message-Id: Date: Sun, 6 Mar 2016 03:48:46 -0800 To: Roman Divacky , FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) 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, 06 Mar 2016 11:48:50 -0000 [This has been reported on llvm bugzilla: 26856.] The below causes gdb difficulties for its stack handling: more than just = exception handling is at issue. I just happened to notice it via = exception handling. Function _Unwind_RaiseException below is from a FreeBSD = TARGET_ARCH=3Dpowerpc "buildworld" using clang 3.8.0. Dump of assembler code for function _Unwind_RaiseException: 0x41b2ab80 <+0>: mflr r0 0x41b2ab84 <+4>: stw r31,-148(r1) 0x41b2ab88 <+8>: stw r30,-152(r1) 0x41b2ab8c <+12>: stw r0,4(r1) 0x41b2ab90 <+16>: stwu r1,-2992(r1) 0x41b2ab94 <+20>: mr r31,r1 . . . 0x41b2abe0 <+96>: stw r31,2844(r31) (which replaces the earlier save of the old Frame pointer R31 value with a copy of r1's current value. Note the offset relationships with the r1 adjustment: -2992+2844=3D-148) . . . 0x41b2add0 <+592>: lwz r31,2844(r31) (This restores the r1 value that resulted from the "stwu r1,-2992(r1)" = into R31.) . . . 0x41b2ae30 <+688>: lwz r31,-148(r1) (This restores the r1 value that resulted from the "stwu r1,-2992(r1)" = into R31.) . . . The wrong r31 value is present when _Unwind_RaiseException returns. But before that while _Unwind_RaiseException is active the C++ exception = handling infrastructure has been given bad r31 information for around = _Unwind_RaiseException's frame. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Mar 9 12:36:26 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 4D37AAC7EBE for ; Wed, 9 Mar 2016 12:36:26 +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 3DD71EE7 for ; Wed, 9 Mar 2016 12:36:26 +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 u29CaPxA033420 for ; Wed, 9 Mar 2016 12:36:26 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox build fails on i386 Date: Wed, 09 Mar 2016 12:36:26 +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: New 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: Wed, 09 Mar 2016 12:36:26 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-toolchain@FreeBSD.o | |rg --- Comment #1 from Jan Beich --- (In reply to Vikash Badal from comment #0) > http://anger.where-ever.za.net/~vikashb/firefox-45.0_1,1.log fetch(1) says "Connection refused". > fatal error: error in backend: ran out of registers during register alloc= ation [...] > diagnostic msg: PLEASE submit ... and include the crash backtrace, prepro= cessed source, and associated run script. I don't have 10.2 i386 jail set up but at least 10.1 i386 builds fine[1]. C= an you follow the instruction, so clang maintainer has more chance reproducing= the crash outside of firefox build? [1] http://beefy5.nyi.freebsd.org/data/101i386-default/410591/logs/firefox-45.0= _1,1.log --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Mar 9 14:24: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 63DA6AC944F for ; Wed, 9 Mar 2016 14:24:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5429398E for ; Wed, 9 Mar 2016 14:24:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u29EOaD6081537 for ; Wed, 9 Mar 2016 14:24:36 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 207837] www/firefox build fails on i386 Date: Wed, 09 Mar 2016 14:24:36 +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: New 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: Wed, 09 Mar 2016 14:24:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 --- Comment #2 from Vikash Badal --- no sure how to obtain this info lldb37 c++.core (lldb) bt error: invalid process please advise --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Wed Mar 9 19:23:32 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 88507AC9D1B for ; Wed, 9 Mar 2016 19:23:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (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 3E0D91A5C for ; Wed, 9 Mar 2016 19:23:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14490 invoked from network); 9 Mar 2016 19:17:10 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 9 Mar 2016 19:17:10 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Wed, 09 Mar 2016 14:16:55 -0500 (EST) Received: (qmail 8681 invoked from network); 9 Mar 2016 19:16:55 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 9 Mar 2016 19:16:55 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C25F91C43CC; Wed, 9 Mar 2016 11:16:47 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Ulrich Weigand has confirmed 3 of my 4 llvm bug submittals for clang 3.8.0 targeting powerpc/powerpc64. . . Date: Wed, 9 Mar 2016 11:16:50 -0800 Message-Id: Cc: Roman Divacky To: FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) 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, 09 Mar 2016 19:23:32 -0000 [He also includes a note about ELFV2 ABI for powerpc64le.] Quoting llvm 26856 Comment 6 (he put the text in the 26856 submittal but = the content also covers 26519 and most of 26844): > Ulrich Weigand 2016-03-09 11:53:17 CST >=20 > Yes, there's indeed a couple of problems here, which affect different = areas. >=20 > 1) On 32-bit ppc, LLVM violates the ABI by storing below the stack = pointer even though the ABI does not provide a "red zone". This affects = every function with a stack frame, and could in theory lead to spurious = crashes when an asynchronous signal overwrites this area. This seems to = be a known issue; the source code contains FIXME lines: > // FIXME: On PPC32 SVR4, we must not spill before claiming the = stackframe. >=20 > 2) In some scenarios, registers may be spilled/restored twice to the = stack. This happens because while most of the spilling happens in = PPCFrameLowering::spillCalleeSavedRegisters, a few selected registers = are also spilled in PPCFrameLowering::emitPrologue. Those registers are = the frame pointer, base pointer, PIC base pointer, link register, and = condition code register. For the latter two, code ensures that they can = never be spilled in both places (for CR, there is extra code in = spillCalleeSavedRegisters; for LR, the register is removed from = SavedRegs in determineCalleeSaves). >=20 > However, for FP, BP, and PBP, nothing ensures the registers are not = spilled twice. It is probably *rare* for this to happen, because the = register allocator will not use those registers within the function if = they're needed for their special purpose, but it can happen in rare = cases. This includes the case of a system unwinder routine that uses = __builtin_unwind_init, but could also include other routines that = clobber one of those registers, e.g. the following case: >=20 > void func (void); >=20 > void test (void) > { > func (); > asm ("nop" : : : "31"); > } >=20 > When it happens that a register is spilled twice, the code as such = still works correctly, but the DWARF CFI unwind info associated with the = routine will be broken, which can mess up both C++ exception handling = and debugging. >=20 > 3) For the specific case of system unwinder routines that use = __builtin_unwind_init and/or __builtin_eh_return, special things need to = happen in the prolog and epilog that are not required for any other = routine. This in particular includes setting up save areas and CFI = records for the EH data registers (r3 ... r6). [See bug #26844. ] For = the ELFv2 ABI (powerpc64le), it also include using three separate save = areas for the three caller-saved condition register fields, so that the = EH logic can overwrite their values independently. >=20 > None of this is currently implemented in LLVM, since on Linux = generally GCC is used to build the system unwind libraries, and no other = code in the system ever needs those special constructs. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Wed Mar 9 20:24:08 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 560A3AC92BF for ; Wed, 9 Mar 2016 20:24:08 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-5.reflexion.net [208.70.210.5]) (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 1B3BE1E95 for ; Wed, 9 Mar 2016 20:24:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31936 invoked from network); 9 Mar 2016 20:24:03 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 9 Mar 2016 20:24:03 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Wed, 09 Mar 2016 15:24:22 -0500 (EST) Received: (qmail 21535 invoked from network); 9 Mar 2016 20:24:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 9 Mar 2016 20:24:21 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 848D21C43CC; Wed, 9 Mar 2016 12:24:01 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Ulrich Weigand has confirmed 3 of my 4 llvm bug submittals for clang 3.8.0 targeting powerpc/powerpc64. . . From: Mark Millard In-Reply-To: Date: Wed, 9 Mar 2016 12:24:04 -0800 Cc: Roman Divacky Content-Transfer-Encoding: quoted-printable Message-Id: References: To: FreeBSD PowerPC ML , FreeBSD Toolchain X-Mailer: Apple Mail (2.2104) 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, 09 Mar 2016 20:24:08 -0000 On 2016-Mar-9, at 11:16 AM, Mark Millard wrote: >=20 > [He also includes a note about ELFV2 ABI for powerpc64le.] >=20 > Quoting llvm 26856 Comment 6 (he put the text in the 26856 submittal = but the content also covers 26519 and most of 26844): >=20 >> Ulrich Weigand 2016-03-09 11:53:17 CST >>=20 >> Yes, there's indeed a couple of problems here, which affect different = areas. >>=20 >> 1) On 32-bit ppc, LLVM violates the ABI by storing below the stack = pointer even though the ABI does not provide a "red zone". This affects = every function with a stack frame, and could in theory lead to spurious = crashes when an asynchronous signal overwrites this area. This seems to = be a known issue; the source code contains FIXME lines: >> // FIXME: On PPC32 SVR4, we must not spill before claiming the = stackframe. >>=20 >> 2) In some scenarios, registers may be spilled/restored twice to the = stack. This happens because while most of the spilling happens in = PPCFrameLowering::spillCalleeSavedRegisters, a few selected registers = are also spilled in PPCFrameLowering::emitPrologue. Those registers are = the frame pointer, base pointer, PIC base pointer, link register, and = condition code register. For the latter two, code ensures that they can = never be spilled in both places (for CR, there is extra code in = spillCalleeSavedRegisters; for LR, the register is removed from = SavedRegs in determineCalleeSaves). >>=20 >> However, for FP, BP, and PBP, nothing ensures the registers are not = spilled twice. It is probably *rare* for this to happen, because the = register allocator will not use those registers within the function if = they're needed for their special purpose, but it can happen in rare = cases. This includes the case of a system unwinder routine that uses = __builtin_unwind_init, but could also include other routines that = clobber one of those registers, e.g. the following case: >>=20 >> void func (void); >>=20 >> void test (void) >> { >> func (); >> asm ("nop" : : : "31"); >> } >>=20 >> When it happens that a register is spilled twice, the code as such = still works correctly, but the DWARF CFI unwind info associated with the = routine will be broken, which can mess up both C++ exception handling = and debugging. >>=20 >> 3) For the specific case of system unwinder routines that use = __builtin_unwind_init and/or __builtin_eh_return, special things need to = happen in the prolog and epilog that are not required for any other = routine. This in particular includes setting up save areas and CFI = records for the EH data registers (r3 ... r6). [See bug #26844. ] For = the ELFv2 ABI (powerpc64le), it also include using three separate save = areas for the three caller-saved condition register fields, so that the = EH logic can overwrite their values independently. >>=20 >> None of this is currently implemented in LLVM, since on Linux = generally GCC is used to build the system unwind libraries, and no other = code in the system ever needs those special constructs. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net One point of his note is wrong: when the 2nd "spill" of a register is = after it had been changed it makes a bigger difference. I commented = back: > However, for FP, BP, and PBP, nothing ensures the registers are not = spilled > twice.. . . >=20 > When it happens that a register is spilled twice, the code as such = still > works correctly, but the DWARF CFI unwind info associated with the = routine > will be broken, which can mess up both C++ exception handling and = debugging. I will note that the Frame Pointer Register (r31) being saved again to = the same location but after it was adjusted to match the adjusted stack = pointer in the callee does not work correctly in that the restore of the = Frame Pointer for the return to the caller will restore the wrong = pointer value. If the caller then uses r31 without separately also restoring r31 first = then it will be addressing the wrong memory on the stack. The observed/reported code sequence had the 2nd r31 store in the callee = after r31 had been adjusted to match the adjusted stack pointer in the = callee. So more than C++ exception handling and debugging is broken for the = reported code sequence. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Thu Mar 10 06:53:39 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 20D9FACAEF9 for ; Thu, 10 Mar 2016 06:53:39 +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 01F7022D for ; Thu, 10 Mar 2016 06:53:39 +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 u2A6rc2W064727 for ; Thu, 10 Mar 2016 06:53:38 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 Date: Thu, 10 Mar 2016 06:53:39 +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: flagtypes.name short_desc 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: Thu, 10 Mar 2016 06:53:39 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|maintainer-feedback?(gecko@ |maintainer-feedback+ |FreeBSD.org) | Summary|www/firefox build fails on |www/firefox: clang34 and |i386 |clang35 crash on i386 with | |-O2 -fstack-protector Status|New |Open --- Comment #3 from Jan Beich --- lldb37 $(which c++) --core c++.core and if you've built world with symbols (e.g. DEBUG_FLAGS=3D-g) it'll show something like the following. After chec= king your full log I can reproduce it on lang/clang34, lang/clang35, /usr/bin/cl= ang on 10.1, 10.2, 10.3 with -m32 -O2 -fstack-protector. It doesn't crash with = -O0, -O1, -O3. As a workaround try building with OPTIMIZED_CFLAGS=3Don, using lang/clang3[6-8] or lang/gcc*. (lldb) bt * thread #1: tid =3D 100230, 0x00000008064fae9a libc.so.7`thr_kill + 10 at thr_kill.S:3, name =3D 'clang', stop reason =3D signal SIGABRT * frame #0: 0x00000008064fae9a libc.so.7`thr_kill + 10 at thr_kill.S:3 frame #1: 0x00000008064fae6b libc.so.7`__raise(s=3D6) + 59 at raise.c= :52 [opt] frame #2: 0x00000008064fae26 libc.so.7`abort + 150 at abort.c:77 [opt] frame #3: 0x000000080657e931 libc.so.7`__assert(func=3D, file=3D, line=3D, failedexpr=3D) + 8= 1 at assert.c:51 [opt] frame #4: 0x0000000001f63483 clang`clang::Lexer::resetExtendedTokenMode(this=3D0x00007fffffff8680) + 67 = at Lexer.cpp:134 frame #5: 0x0000000001f6c958 clang`clang::Lexer::LexEndOfFile(this=3D0x00007fffffff8680, Result=3D0x00007fffffff85c8, CurPtr=3D"") + 88 at Lexer.cpp:2463 frame #6: 0x0000000001f6dbb4 clang`clang::Lexer::LexTokenInternal(this=3D0x00007fffffff8680, Result=3D0x00007fffffff85c8, TokAtPhysicalStartOfLine=3Dfalse) + 420 at Lexer.cpp:2915 frame #7: 0x0000000001f6c8a8 clang`clang::Lexer::Lex(this=3D0x00007fffffff8680, Result=3D0x00007fffffff8= 5c8) + 216 at Lexer.cpp:2866 frame #8: 0x000000000063c2f3 clang`clang::Lexer::LexFromRawLexer(this=3D0x00007fffffff8680, Result=3D0x00007fffffff85c8) + 83 at Lexer.h:156 frame #9: 0x0000000001aa50e5 clang`(anonymous namespace)::InclusionRewriter::Process(this=3D0x0000000806c5f0f0, FileId=3D= (ID =3D 1624), FileType=3DC_User) + 3989 at InclusionRewriter.cpp:495 frame #10: 0x0000000001aa4667 clang`(anonymous namespace)::InclusionRewriter::Process(this=3D0x0000000806c5f0f0, FileId=3D= (ID =3D 1622), FileType=3DC_User) + 1303 at InclusionRewriter.cpp:401 frame #11: 0x0000000001aa4667 clang`(anonymous namespace)::InclusionRewriter::Process(this=3D0x0000000806c5f0f0, FileId=3D= (ID =3D 667), FileType=3DC_User) + 1303 at InclusionRewriter.cpp:401 frame #12: 0x0000000001aa4667 clang`(anonymous namespace)::InclusionRewriter::Process(this=3D0x0000000806c5f0f0, FileId=3D= (ID =3D 666), FileType=3DC_User) + 1303 at InclusionRewriter.cpp:401 frame #13: 0x0000000001aa4667 clang`(anonymous namespace)::InclusionRewriter::Process(this=3D0x0000000806c5f0f0, FileId=3D= (ID =3D 665), FileType=3DC_User) + 1303 at InclusionRewriter.cpp:401 frame #14: 0x0000000001aa4667 clang`(anonymous namespace)::InclusionRewriter::Process(this=3D0x0000000806c5f0f0, FileId=3D= (ID =3D 9), FileType=3DC_User) + 1303 at InclusionRewriter.cpp:401 frame #15: 0x0000000001aa4667 clang`(anonymous namespace)::InclusionRewriter::Process(this=3D0x0000000806c5f0f0, FileId=3D= (ID =3D 8), FileType=3DC_User) + 1303 at InclusionRewriter.cpp:401 frame #16: 0x0000000001aa4667 clang`(anonymous namespace)::InclusionRewriter::Process(this=3D0x0000000806c5f0f0, FileId=3D= (ID =3D 1), FileType=3DC_User) + 1303 at InclusionRewriter.cpp:401 frame #17: 0x0000000001aa3f83 clang`clang::RewriteIncludesInInput(PP=3D0x0000000806c50800, OS=3D0x0000000806c1a980, Opts=3D0x0000000806c37408) + 579 at InclusionRewriter.cpp:548 frame #18: 0x0000000001aa19bf clang`clang::RewriteIncludesAction::ExecuteAction(this=3D0x0000000806c1a0c0= ) + 175 at FrontendActions.cpp:190 frame #19: 0x0000000000633b37 clang`clang::FrontendAction::Execute(this=3D0x0000000806c1a0c0) + 183 at FrontendAction.cpp:378 frame #20: 0x00000000005f196e clang`clang::CompilerInstance::ExecuteAction(this=3D0x0000000806c34000, Act=3D0x0000000806c1a0c0) + 846 at CompilerInstance.cpp:707 frame #21: 0x00000000005b0996 clang`clang::ExecuteCompilerInvocation(Clang=3D0x0000000806c34000) + 1958 at ExecuteCompilerInvocation.cpp:236 frame #22: 0x000000000059a281 clang`cc1_main(ArgBegin=3D0x00007ffffff= fd028, ArgEnd=3D0x00007fffffffd400, Argv0=3D"/usr/local/llvm34/bin/clang", MainAddr=3D0x00000000005a78e0) + 993 at cc1_main.cpp:100 frame #23: 0x00000000005a7cc6 clang`main(argc_=3D125, argv_=3D0x00007fffffffd888) + 806 at driver.cpp:314 frame #24: 0x00000000005994cf clang`_start(ap=3D, cleanup=3D) + 383 at crt1.c:72 [opt] --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Mar 10 07:04:38 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40CBCACA43A for ; Thu, 10 Mar 2016 07:04:38 +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 18AD0A63 for ; Thu, 10 Mar 2016 07:04:38 +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 u2A74bnM030496 for ; Thu, 10 Mar 2016 07:04:37 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 Date: Thu, 10 Mar 2016 07:04:38 +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: Thu, 10 Mar 2016 07:04:38 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 --- Comment #4 from Jan Beich --- (In reply to Vikash Badal from comment #0) > c++: note: diagnostic msg: Error generating preprocessed source(s). This probably means we have to shave Unified_cpp_protocol_websocket0.cpp of extra code manually. Firefox no longer supports non-unified build. Steps to reproduce: $ cd www/firefox $ make $ pkg install clang34 $ cd $(make -V WRKSRC) $ clang++34 -m32 -o Unified_cpp_protocol_websocket0.o -c -I obj-*/dist/stl_wrappers -I obj-*/dist/system_wrappers -include config/gcc_hidden.h -DOS_POSIX=3D1 -DOS_FREEBSD=3D1 -DOS_BSD=3D1 -DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -Inetwerk/protocol/websocket -I. -I obj-*/ipc/ipdl/_ipdlheaders -Iipc/chromium/src -Iipc/glue -Idom/base -Inetwerk/base -I obj-*/dist/inclu= de=20 -I/usr/local/include/nspr -I/usr/local/include/nss -I/usr/local/include/nss= /nss -I/usr/local/include -I/usr/local/include -I/usr/local/include/pixman-1=20= =20 -fPIC -DMOZILLA_CLIENT -include obj-*/mozilla-config.h -Qunused-arguments -isystem/usr/local/include -DLIBICONV_PLUG -Qunused-arguments -Wall -Wempty-body -Woverloaded-virtual -Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wno-inline-new-delete -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-unknown-warning-option -Wno-return-type-c-linka= ge -O2 -pipe -DLIBICONV_PLUG -fstack-protector -fno-strict-aliasing -DLIBICONV_PLUG -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -std=3Dgnu++0x -pipe -DNDEBUG -DTRIMMED -fno-omit-frame-pointer=20=20=20= =20=20 obj-*/netwerk/protocol/websocket/Unified_cpp_protocol_websocket0.cpp --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Thu Mar 10 07:08:06 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A517ACA54B for ; Thu, 10 Mar 2016 07:08:06 +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 1A565AE5 for ; Thu, 10 Mar 2016 07:08:06 +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 u2A785HQ035426 for ; Thu, 10 Mar 2016 07:08:05 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: Thu, 10 Mar 2016 07:08:06 +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: short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.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, 10 Mar 2016 07:08:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 Jan Beich changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|www/firefox: clang34 and |www/firefox: clang34 and |clang35 crash on i386 with |clang35 crash on i386 with |-O2 -fstack-protector |-O2 -fstack-protector | |(OPTIMIZED_CFLAGS=3Doff) --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-toolchain@freebsd.org Fri Mar 11 04:22:47 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9207ACA637 for ; Fri, 11 Mar 2016 04:22:47 +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 6D1D474E for ; Fri, 11 Mar 2016 04:22:46 +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 u2B4N4VM030207 for ; Thu, 10 Mar 2016 20:23:11 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: "FreeBSD toolchain" From: "Chris H" Subject: How to insist on only clang, for world/kernel? Date: Thu, 10 Mar 2016 20:23:11 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: 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: Fri, 11 Mar 2016 04:22:47 -0000 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 Fri Mar 11 04:49:02 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 A4FE9ACB08B for ; Fri, 11 Mar 2016 04:49:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 6F4D0F4E for ; Fri, 11 Mar 2016 04:49:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id n190so132380203iof.0 for ; Thu, 10 Mar 2016 20:49:02 -0800 (PST) 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=wzYm7Ls3Wd8pA10Sg2mFMXb7jpVSgeogQ+L5kSmWY9s=; b=KuOW1XpL9qLdOW2l68Oj+tiVPsjJgfMOI/bFqPKbDLEgqocpPCQRCjkaId52Q/bRcK LDPmS6Ln5+Z5oawgto85Bw+jmn4hoIKngWtVtF0eoO881/gddZOcVk1SC0G5XsmUECpr edPsjc6Ts4XpRhWHZNGxidb9vOaz7ot+4mkjOep9dj7VjfZI2n0bAIVHq4k379pR2ad/ j+yqeYoHSzDXAp59OvXjxcbeBeNx1Gi4CXbUdfnVug0UXwCQVgdlgp+NoFlkTWhdASyt T+WjmwUBzPHtEMBIIOUrBpgStcNenJes4MtJv2imbRY2K0hxoZ30sgCeUom/KHxSRp5Z Oghw== 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=wzYm7Ls3Wd8pA10Sg2mFMXb7jpVSgeogQ+L5kSmWY9s=; b=Q5W+eYqCweQNaF/BasC5uF4bVyl8+bSWyvGDyXzdQGtwf7w0dFOJpcYbZvsyH5N49L i5xvr+plaC6JqSvysHxRFItBc10SCXhAwC36f7xhfOCox+ZZ4SHvC0ZtdTztXuvGoV3o GKCIWI/T6KSoe9Td3I6KDQqwrva6gDzcXMuuK44t6LRr/mx1h7x4mEhJAxwn7nV5siKb 2T2w4cg9NL+s46w9dikAyDv3zmyaamblv7MVjcg+eyMxwH+X5goAMWnqGuIQGMFSuyq7 WrHomD5ZBr83mdcM3gQ8UIaM8PFOQqBoqbNwS3ICtfVLlUgfrJyan5HO1SStaeW59PRM XEpQ== X-Gm-Message-State: AD7BkJJAjoWHwQdmugex6EAhbgTcEiOQS0d+sHZoNVL9egcZx10Z0M2pO6qM1n3R109mHmRYDlZYWz7Ttq8M3w== MIME-Version: 1.0 X-Received: by 10.107.135.226 with SMTP id r95mr7128490ioi.59.1457671741915; Thu, 10 Mar 2016 20:49:01 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Thu, 10 Mar 2016 20:49:01 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: Date: Thu, 10 Mar 2016 21:49:01 -0700 X-Google-Sender-Auth: 0bpBgOeIG3Go_hUXTTl0Qdpbv5c 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: Fri, 11 Mar 2016 04:49:02 -0000 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 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 > > -- > > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to " > freebsd-toolchain-unsubscribe@freebsd.org" > From owner-freebsd-toolchain@freebsd.org Fri Mar 11 09:28: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 94629ACBAB3 for ; Fri, 11 Mar 2016 09:28:12 +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 5F0FFEF9 for ; Fri, 11 Mar 2016 09:28:12 +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 A42291534C8 for ; Fri, 11 Mar 2016 10:28:02 +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 Axr5Di9xs_-r; Fri, 11 Mar 2016 10:27:43 +0100 (CET) Received: from [IPv6:2001:4cb8:3:1:38d0:712c:3d0b:2e41] (unknown [IPv6:2001:4cb8:3:1:38d0:712c:3d0b:2e41]) by smtp.digiware.nl (Postfix) with ESMTP id A4B3F1534CD for ; Fri, 11 Mar 2016 10:27:43 +0100 (CET) To: freebsd-toolchain@freebsd.org From: Willem Jan Withagen Subject: Running Clang 3.7 on Current.... Organization: Digiware Management b.v. Message-ID: <56E28F8A.5000201@digiware.nl> Date: Fri, 11 Mar 2016 10:27:38 +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: Fri, 11 Mar 2016 09:28:12 -0000 Hi, CURRENT has recently received the upgrade to Clang 3.8. Now I run into the problem that some of the tests with Ceph are all of a sudden failing.... Mainly manifesting itself because of access errors thru pointers in very complex records structs. (Which is almost always in C++ :) ) Either pointers are 0x0, or to invalid memory. This can be attributed to a few things, some of them: - changes in the Ceph code Which is possible since I rebased since I started using 3.8. - Subtle difference in corner cases, and overlaping structs get written wrongly. - A compiler bug - other issues .... Ceph is run thru extensive tests while building, after which there is another large QA testset run by the Ceph-team in their openstack with even more and complexer tests. So real programming "errors" would be caught in this process. To exclude the compiler I'd like to run a compile/build/test run with 3.7 Can I just install the ports 3.7 version without endangering my 3.8 current installation. Then it'll just be set 'CC=clang37 C++=clang37++ make' and see what comes of it. Thanx, --WjW From owner-freebsd-toolchain@freebsd.org Fri Mar 11 09:36:32 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 8EBC9ACBE33 for ; Fri, 11 Mar 2016 09:36:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-4.reflexion.net [208.70.210.4]) (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 5467B12BF for ; Fri, 11 Mar 2016 09:36:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24937 invoked from network); 11 Mar 2016 09:36:42 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 11 Mar 2016 09:36:42 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 11 Mar 2016 04:36:27 -0500 (EST) Received: (qmail 22309 invoked from network); 11 Mar 2016 09:36:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 11 Mar 2016 09:36:27 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id A838C1C43CD; Fri, 11 Mar 2016 01:36:22 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: Ulrich Weigand has confirmed 3 of my 4 llvm bug submittals for clang 3.8.0 targeting powerpc/powerpc64. . . From: Mark Millard In-Reply-To: Date: Fri, 11 Mar 2016 01:36:22 -0800 Cc: Roman Divacky Content-Transfer-Encoding: quoted-printable Message-Id: <2ADD6542-E994-4FF9-B743-F6A03B1DCBCC@dsl-only.net> References: To: FreeBSD PowerPC ML , FreeBSD Toolchain X-Mailer: Apple Mail (2.2104) 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, 11 Mar 2016 09:36:32 -0000 [Some more details confirmed.] On 2016-Mar-9, at 12:24 PM, Mark Millard wrote: >=20 > On 2016-Mar-9, at 11:16 AM, Mark Millard = wrote: >>=20 >> [He also includes a note about ELFV2 ABI for powerpc64le.] >>=20 >> Quoting llvm 26856 Comment 6 (he put the text in the 26856 submittal = but the content also covers 26519 and most of 26844): >>=20 >>> Ulrich Weigand 2016-03-09 11:53:17 CST >>>=20 >>> Yes, there's indeed a couple of problems here, which affect = different areas. >>>=20 >>> 1) On 32-bit ppc, LLVM violates the ABI by storing below the stack = pointer even though the ABI does not provide a "red zone". This affects = every function with a stack frame, and could in theory lead to spurious = crashes when an asynchronous signal overwrites this area. This seems to = be a known issue; the source code contains FIXME lines: >>> // FIXME: On PPC32 SVR4, we must not spill before claiming the = stackframe. >>>=20 >>> 2) In some scenarios, registers may be spilled/restored twice to the = stack. This happens because while most of the spilling happens in = PPCFrameLowering::spillCalleeSavedRegisters, a few selected registers = are also spilled in PPCFrameLowering::emitPrologue. Those registers are = the frame pointer, base pointer, PIC base pointer, link register, and = condition code register. For the latter two, code ensures that they can = never be spilled in both places (for CR, there is extra code in = spillCalleeSavedRegisters; for LR, the register is removed from = SavedRegs in determineCalleeSaves). >>>=20 >>> However, for FP, BP, and PBP, nothing ensures the registers are not = spilled twice. It is probably *rare* for this to happen, because the = register allocator will not use those registers within the function if = they're needed for their special purpose, but it can happen in rare = cases. This includes the case of a system unwinder routine that uses = __builtin_unwind_init, but could also include other routines that = clobber one of those registers, e.g. the following case: >>>=20 >>> void func (void); >>>=20 >>> void test (void) >>> { >>> func (); >>> asm ("nop" : : : "31"); >>> } >>>=20 >>> When it happens that a register is spilled twice, the code as such = still works correctly, but the DWARF CFI unwind info associated with the = routine will be broken, which can mess up both C++ exception handling = and debugging. >>>=20 >>> 3) For the specific case of system unwinder routines that use = __builtin_unwind_init and/or __builtin_eh_return, special things need to = happen in the prolog and epilog that are not required for any other = routine. This in particular includes setting up save areas and CFI = records for the EH data registers (r3 ... r6). [See bug #26844. ] For = the ELFv2 ABI (powerpc64le), it also include using three separate save = areas for the three caller-saved condition register fields, so that the = EH logic can overwrite their values independently. >>>=20 >>> None of this is currently implemented in LLVM, since on Linux = generally GCC is used to build the system unwind libraries, and no other = code in the system ever needs those special constructs. >>=20 >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >=20 > One point of his note is wrong: when the 2nd "spill" of a register is = after it had been changed it makes a bigger difference. I commented = back: >=20 >=20 >> However, for FP, BP, and PBP, nothing ensures the registers are not = spilled >> twice.. . . >>=20 >> When it happens that a register is spilled twice, the code as such = still >> works correctly, but the DWARF CFI unwind info associated with the = routine >> will be broken, which can mess up both C++ exception handling and = debugging. >=20 >=20 > I will note that the Frame Pointer Register (r31) being saved again to = the same location but after it was adjusted to match the adjusted stack = pointer in the callee does not work correctly in that the restore of the = Frame Pointer for the return to the caller will restore the wrong = pointer value. >=20 > If the caller then uses r31 without separately also restoring r31 = first then it will be addressing the wrong memory on the stack. >=20 > The observed/reported code sequence had the 2nd r31 store in the = callee after r31 had been adjusted to match the adjusted stack pointer = in the callee. >=20 > So more than C++ exception handling and debugging is broken for the = reported code sequence. The new comments are. . . > Comment # 9 on bug 26856 from Ulrich Weigand > (In reply to comment #8) >=20 > > (In reply to comment #6 > ) > >=20 > > > However, for FP, BP, and PBP, nothing ensures the registers are = not spilled > > > twice.. . . > > >=20 > > > When it happens that a register is spilled twice, the code as such = still > > > works correctly, but the DWARF CFI unwind info associated with the = routine > > > will be broken, which can mess up both C++ exception handling and = debugging. > >=20 > > I will note that the Frame Pointer Register (r31) being saved again = to the > > same location but after it was adjusted to match the adjusted stack = pointer > > in the callee does not work correctly in that the restore of the = Frame > > Pointer for the return to the caller will restore the wrong pointer = value. > >=20 > > If the caller then uses r31 without separately also restoring r31 = first then > > it will be addressing the wrong memory on the stack. > >=20 > > The observed/reported code sequence had the 2nd r31 store in the = callee > > after r31 had been adjusted to match the adjusted stack pointer in = the > > callee. > >=20 > > So more than C++ exception handling and debugging is broken for the = reported > > code sequence. >=20 >=20 > Ah, right. I had been under the impression that the back-end would = use two > different save areas, but indeed it does use the same area, just = addressed > slightly differently. The resulting code is then just simply = incorrect. and. . . > Comment # 10 on bug 26856 from Ulrich Weigand > (In reply to comment #7) >=20 >=20 > > The observed behavior for the powerpc (what should be) SVR4 context = is that > > the save/restore logic for CR fields 2, 3, 4 is present but no = .eh_frame > > information is written out for the EH logic to use for CR. >=20 >=20 > Huh, indeed. This is yet another bug, which also affects functions = for the > powerpc (SVR4) ABI in general, not just unwind system routines. >=20 > This seems to be a logic issue here: >=20 > // For SVR4, don't emit a move for the CR spill slot if we = haven't > // spilled CRs. > if (isSVR4ABI && (PPC::CR2 <=3D Reg && Reg <=3D PPC::CR4) > && !MustSaveCR) > continue; >=20 > MustSaveCR is always false for 32-bit, it is only used on 64-bit. = This has the > effect that on 32-bit, we never get any CFI for the CRs. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-toolchain@freebsd.org Fri Mar 11 10:07:45 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0888ACCF50 for ; Fri, 11 Mar 2016 10:07:45 +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 68C48EA1 for ; Fri, 11 Mar 2016 10:07:45 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::a1e6:2917:1004:ab1] (unknown [IPv6:2001:7b8:3a7:0:a1e6:2917:1004:ab1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8FC5C398A4; Fri, 11 Mar 2016 11:07:41 +0100 (CET) Subject: Re: Running Clang 3.7 on Current.... Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BD7D170D-AE49-4C79-ACB9-92202F3983B6"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 (ebbf3ef) From: Dimitry Andric In-Reply-To: <56E28F8A.5000201@digiware.nl> Date: Fri, 11 Mar 2016 11:07:34 +0100 Cc: freebsd-toolchain@freebsd.org Message-Id: <7D7F6AF9-4E33-4BE3-85CD-2A02E3D209B5@FreeBSD.org> References: <56E28F8A.5000201@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: Fri, 11 Mar 2016 10:07:45 -0000 --Apple-Mail=_BD7D170D-AE49-4C79-ACB9-92202F3983B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 Mar 2016, at 10:27, Willem Jan Withagen wrote: >=20 > CURRENT has recently received the upgrade to Clang 3.8. >=20 > Now I run into the problem that some of the tests with Ceph are all of = a > sudden failing.... > Mainly manifesting itself because of access errors thru pointers in > very complex records structs. (Which is almost always in C++ :) ) > Either pointers are 0x0, or to invalid memory. >=20 > This can be attributed to a few things, some of them: > - changes in the Ceph code > Which is possible since I rebased since I started using 3.8. > - Subtle difference in corner cases, and overlaping structs get = written > wrongly. > - A compiler bug > - other issues .... >=20 > Ceph is run thru extensive tests while building, after which there is = another > large QA testset run by the Ceph-team in their openstack with even = more and > complexer tests. So real programming "errors" would be caught in this = process. >=20 > To exclude the compiler I'd like to run a compile/build/test run with = 3.7 > Can I just install the ports 3.7 version without endangering my 3.8 = current > installation. Then it'll just be set 'CC=3Dclang37 C++=3Dclang37++ = make' and > see what comes of it. Yes, that should work without any problems. -Dimitry --Apple-Mail=_BD7D170D-AE49-4C79-ACB9-92202F3983B6 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 iEYEARECAAYFAlbimO0ACgkQsF6jCi4glqMS3ACgkh/91BpelBXOO7i93/cQrBTo cJwAnA8lBXz/NXosL2lgXEhJAQOvNC60 =9fhA -----END PGP SIGNATURE----- --Apple-Mail=_BD7D170D-AE49-4C79-ACB9-92202F3983B6-- From owner-freebsd-toolchain@freebsd.org Fri Mar 11 15:20:02 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 2ED2BACB8B1 for ; Fri, 11 Mar 2016 15:20:02 +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 117E0C9E for ; Fri, 11 Mar 2016 15:20:01 +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 u2BFKPpM001479; Fri, 11 Mar 2016 07:20:32 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) To: Warner Losh Cc: FreeBSD toolchain In-Reply-To: References: , From: "Chris H" Subject: Re: How to insist on only clang, for world/kernel? Date: Fri, 11 Mar 2016 07:20:32 -0800 Content-Type: text/plain; charset=UTF-8; format=fixed MIME-Version: 1.0 Message-id: <779997a4a2f241b39db096bfed5cb84f@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: Fri, 11 Mar 2016 15:20:02 -0000 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 Fri Mar 11 17:16: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 7F250ACB337 for ; Fri, 11 Mar 2016 17:16:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 641B8B2A for ; Fri, 11 Mar 2016 17:16:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 638A9ACB336; Fri, 11 Mar 2016 17:16:35 +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 63077ACB334; Fri, 11 Mar 2016 17:16:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4EAA1B29; Fri, 11 Mar 2016 17:16:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 460D51AAC; Fri, 11 Mar 2016 17:16:35 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 145B31BFBD; Fri, 11 Mar 2016 17:16:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id PhpFIbixRG8H; Fri, 11 Mar 2016 17:16:32 +0000 (UTC) Subject: Re: FAST_DEPEND is now default DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 2D0621BBAF To: "current@FreeBSD.org" , toolchain@FreeBSD.org References: <56E2FC11.5060500@FreeBSD.org> From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <56E2FC6E.8020107@FreeBSD.org> Date: Fri, 11 Mar 2016 09:12:14 -0800 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: <56E2FC11.5060500@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6KVNnivClgRwUdFikMTnKeDaBtuF290Nw" 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, 11 Mar 2016 17:16:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6KVNnivClgRwUdFikMTnKeDaBtuF290Nw Content-Type: multipart/mixed; boundary="bgF7MKEUgku3vp0obW18rl1E7ETCPIALs" From: Bryan Drewery To: "current@FreeBSD.org" , toolchain@FreeBSD.org Message-ID: <56E2FC6E.8020107@FreeBSD.org> Subject: Re: FAST_DEPEND is now default References: <56E2FC11.5060500@FreeBSD.org> In-Reply-To: <56E2FC11.5060500@FreeBSD.org> --bgF7MKEUgku3vp0obW18rl1E7ETCPIALs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/11/2016 9:10 AM, Bryan Drewery wrote: > WITH_FAST_DEPEND is now enabled by default for in-tree and out-of-tree > builds. It no longer runs mkdep(1) during 'make depend', and the > 'make depend' stage can safely be skipped now as it is auto ran > when building 'make all' and will generate all SRCS and DPSRCS before > building anything else. Dependencies are gathered at compile time with= > -MF flags kept in separate .depend files per object file. Users should= > run 'make cleandepend' once if using -DNO_CLEAN to clean out older > stale .depend files. >=20 > The option and mkdep(1) support will be removed in a few weeks. >=20 Sometimes I go too fast. I should mention that this gives 15-35% build time improvements. More information can be see in the initial commit https://svnweb.freebsd.org/base?view=3Drevision&revision=3D290433 --=20 Regards, Bryan Drewery --bgF7MKEUgku3vp0obW18rl1E7ETCPIALs-- --6KVNnivClgRwUdFikMTnKeDaBtuF290Nw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJW4vxuAAoJEDXXcbtuRpfPYmUH/irpr0ElWw0mtxyclrxmVw4d tuXVUdFbFM7b2klRp/C38vBFedOE6nSPWzjLNIpAmQdSKMXaWJ0/Rs9vOgWskXJp 5/G2MhsJ8QGsuQhGHLBlzzI2g9UwoRrRQVQO8OIwmvv8lfXg5pq3flnIrAQFlx+r eBkkazRj1y/3vt1doMCSqVB3MVxfLT4ZGJP/QAojJp/sudLasUM/m901ghxwGpVz 5W/pl357+1cHF4UBA6wsHTFnk1vPt1o87ZqjZtOM6EUXMhSvr9kyapgerLB319yd UINjMsHm13W4/DGs1ZUv1TWXNQAr0r4iNSKyG8D0I1WLIHfF6SL9XjHPwjEeX4w= =fevF -----END PGP SIGNATURE----- --6KVNnivClgRwUdFikMTnKeDaBtuF290Nw-- From owner-freebsd-toolchain@freebsd.org Fri Mar 11 17:16: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 C2ECBACB34C for ; Fri, 11 Mar 2016 17:16:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AAFF0B2F for ; Fri, 11 Mar 2016 17:16:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id AA74BACB346; Fri, 11 Mar 2016 17:16: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 A9F8CACB343; Fri, 11 Mar 2016 17:16:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 973CBB2E; Fri, 11 Mar 2016 17:16:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 903D21AAD; Fri, 11 Mar 2016 17:16:36 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 5D7191BFC2; Fri, 11 Mar 2016 17:16:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id zq0lCFtu09R9; Fri, 11 Mar 2016 17:16:29 +0000 (UTC) To: "current@FreeBSD.org" , toolchain@FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 21B2E1BAC0 From: Bryan Drewery Subject: FAST_DEPEND is now default Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Organization: FreeBSD Message-ID: <56E2FC11.5060500@FreeBSD.org> Date: Fri, 11 Mar 2016 09:10:41 -0800 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FUAOm4wJTwTcT3h1SGu04WdbbksBTrrL1" 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, 11 Mar 2016 17:16:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FUAOm4wJTwTcT3h1SGu04WdbbksBTrrL1 Content-Type: multipart/mixed; boundary="nAQAnxL6BocOALpadGjDaBTNxSnofglB6" From: Bryan Drewery To: "current@FreeBSD.org" , toolchain@FreeBSD.org Message-ID: <56E2FC11.5060500@FreeBSD.org> Subject: FAST_DEPEND is now default --nAQAnxL6BocOALpadGjDaBTNxSnofglB6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable WITH_FAST_DEPEND is now enabled by default for in-tree and out-of-tree builds. It no longer runs mkdep(1) during 'make depend', and the 'make depend' stage can safely be skipped now as it is auto ran when building 'make all' and will generate all SRCS and DPSRCS before building anything else. Dependencies are gathered at compile time with -MF flags kept in separate .depend files per object file. Users should run 'make cleandepend' once if using -DNO_CLEAN to clean out older stale .depend files. The option and mkdep(1) support will be removed in a few weeks. --=20 Regards, Bryan Drewery --nAQAnxL6BocOALpadGjDaBTNxSnofglB6-- --FUAOm4wJTwTcT3h1SGu04WdbbksBTrrL1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJW4vwRAAoJEDXXcbtuRpfPvBQH/Rr9TYcM8214RpN0uty9rNQL o+eRTF1BoIgqrI+jqBJAg+f3N7NxRAFLjB0iaCJihWrYDZbRzHN9IuFzE0evorli n9x2puZt0uW15568MO5UPoIMQbSuLcxUS1ewM/MKDJR7JP+gN6a8clpgpgyzU8kO eMhF3VfqAUddbigu30QDYPn0CQWLW5aUFY9+qk9s4fTiuRtO40eNl7JhAc+w0a+s XbeGp3g6+2mMjrNcpoPj62Xb500xw5Q/YjFbGncrmkF3KIDCtLOpccN3iC9T7WpC FJwkrtFGf4B2V+c7ARnxQTgpjjII57wGbDrITzUq92t5zDZXZhbBIr9QOHbm7Pk= =o8Fk -----END PGP SIGNATURE----- --FUAOm4wJTwTcT3h1SGu04WdbbksBTrrL1-- From owner-freebsd-toolchain@freebsd.org Sat Mar 12 21:59:59 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 EE40FACEF04 for ; Sat, 12 Mar 2016 21:59:59 +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 DE86DC02 for ; Sat, 12 Mar 2016 21:59: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 u2CLxxMK051005 for ; Sat, 12 Mar 2016 21:59: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: Sat, 12 Mar 2016 21:59: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: 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: 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: Sat, 12 Mar 2016 22:00:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207837 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brooks@FreeBSD.org, | |dim@FreeBSD.org --- Comment #5 from Dimitry Andric --- Some bisection shows that this has been fixed by upstream llvm commit r2195= 12 [1], as a fix for LLVM PR 18883. It looks like this fix applies without fu= zz on clang 3.4, and probably also on clang 3.5. I'm currently building stable/9 world with it, to see if it causes any problems, but I don't really expect them. If it works, I will merge it to stable/9. Brooks, we should probably add this fix to both the llvm34 and llvm35 ports. [1] https://github.com/llvm-mirror/llvm/commit/d3aa46a1bc5d195f8399d109a1335337= 8516138b [2] https://llvm.org/bugs/show_bug.cgi?id=3D18883 --=20 You are receiving this mail because: You are on the CC list for the bug.=