From owner-freebsd-toolchain@freebsd.org Sat May 11 09:57:34 2019 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B16B15970BD for ; Sat, 11 May 2019 09:57:34 +0000 (UTC) (envelope-from bugzilla-noreply@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 31A11831A3 for ; Sat, 11 May 2019 09:57:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id E6A9015970B7; Sat, 11 May 2019 09:57:33 +0000 (UTC) Delivered-To: toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2A0C15970B6 for ; Sat, 11 May 2019 09:57:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C9488319C for ; Sat, 11 May 2019 09:57: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 mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id A3952CA67 for ; Sat, 11 May 2019 09:57:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x4B9vWWB048981 for ; Sat, 11 May 2019 09:57:32 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x4B9vWA7048980 for toolchain@FreeBSD.org; Sat, 11 May 2019 09:57:32 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 237074] multimedia/vlc: 3.0.* fails to build on armv6 due to Clang crash Date: Sat, 11 May 2019 09:57:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash 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: toolchain@FreeBSD.org X-Bugzilla-Flags: mfc-stable11? mfc-stable12? 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.29 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, 11 May 2019 09:57:34 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D237074 --- Comment #8 from commit-hook@freebsd.org --- A commit references this bug: Author: dim Date: Sat May 11 09:57:00 UTC 2019 New revision: 347486 URL: https://svnweb.freebsd.org/changeset/base/347486 Log: MFC r347243: Pull in r360099 from upstream llvm trunk (by Eli Friedman): [ARM] Glue register copies to tail calls. This generally follows what other targets do. I don't completely understand why the special case for tail calls existed in the first place; even when the code was committed in r105413, call lowering didn't work in the way described in the comments. Stack protector lowering breaks if the register copies are not glued to a tail call: we have to insert the stack protector check before the tail call, and we choose the location based on the assumption that all physical register dependencies of a tail call are adjacent to the tail call. (See FindSplitPointForStackProtector.) This is sort of fragile, but I don't see any reason to break that assumption. I'm guessing nobody has seen this before just because it's hard to convince the scheduler to actually schedule the code in a way that breaks; even without the glue, the only computation that could actually be scheduled after the register copies is the computation of the call address, and the scheduler usually prefers to schedule that before the copies anyway. Fixes https://bugs.llvm.org/show_bug.cgi?id=3D41417 Differential Revision: https://reviews.llvm.org/D60427 This should fix several instances of "Bad machine code: Using an undefined physical register", when compiling ports such as multimedia/vlc, audio/alsa-lib and devel/avro-c for armv6, with -fstack-protector-strong. Reported by: jbeich PR: 237074, 237783, 237784 Changes: _U stable/11/ stable/11/contrib/llvm/lib/Target/ARM/ARMISelLowering.cpp _U stable/12/ stable/12/contrib/llvm/lib/Target/ARM/ARMISelLowering.cpp --=20 You are receiving this mail because: You are the assignee for the bug.=