From nobody Sat May 28 21:35:55 2022 X-Original-To: toolchain@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D44871B5B2B3 for ; Sat, 28 May 2022 21:35:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4L9ZjR2pPgz3C5S for ; Sat, 28 May 2022 21:35:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 3D2D316930 for ; Sat, 28 May 2022 21:35:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 24SLZtXF051066 for ; Sat, 28 May 2022 21:35:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 24SLZtmK051065 for toolchain@FreeBSD.org; Sat, 28 May 2022 21:35:55 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 264318] base clang 14.0.3 crash on i386 compiling PuTTY 0.77 Date: Sat, 28 May 2022 21:35:55 +0000 X-Bugzilla-Reason: CC 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, toolchain X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dim@FreeBSD.org X-Bugzilla-Flags: 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 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org MIME-Version: 1.0 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1653773755; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ES7XHilChWtHBJBSmIlqqpNfv9/WT3yKFwH6URFvE2o=; b=rkNna4h/gA7nXqapjByosWRLA5fxcXeF/zgkO1pD4jTNcjc6KR4a4Z++/ZUheDk0lMQqRz KpfhhDBxKn3Sut35l+NW29Av9nxSeGcStCNScozEKApqsZ7QD4pEErQlhh9x1pjdykCaeP P8L10WxdpgNaA3lFKcEHR9VK1nvXrB4EkMRjZroZ43dVdubKgkKJxf4TMPX1tPuc/fcEOy /nC3CT4jwnGgVzT3ulQLQudFO2VLGESUjkoAZwv8sYTMdbtYFxKzIQnaxQOlwJKtqXEX/G 2LsSmCBMX2vUNIcCrJG5FItrB7Z6711k9WUSATova3Csyu/7QCNYEtQ6sqhniQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1653773755; a=rsa-sha256; cv=none; b=S5WBWh3YohKQpofnD3Fcx8otH80hJDFX7q1J/CyP9cAjX96D+D1jiZZjyc5xVSDokvk+ge auFWbfcIDd2Y7T/bA4sR6obB0t6qMxQpqSkkj1Yp5NbtZcwTL5HmaobOKcBfcaSIqzcTq7 FnsCX92vvYI9l0AV9HyGMiaKW8Nzb1fLsAXzJxlTgLk+zfkssgzo6aaaOvmUpJ+W0qmADx DQl+MTv6nRtSEuFFb+dPOPUG7NTuPA9OOB2zNbTyjTmaD77XASD75XZ6cO8lIGoUO0Q/5y ZVi4D7UL+qxi9s6K8d6rNv/x86eB2OfPCOeVk+VIxSbpEcOubxwkqQRyOaKE3Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264318 --- Comment #2 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D6a5eebc190ab98de98ed7977cbdee3218= 758376e commit 6a5eebc190ab98de98ed7977cbdee3218758376e Author: Dimitry Andric AuthorDate: 2022-05-28 21:26:37 +0000 Commit: Dimitry Andric CommitDate: 2022-05-28 21:26:37 +0000 Apply clang fix for assertion failure building putty 0.77 on i386 Merge commit 45084eab5e63 from llvm git (by Arthur Eubanks): [clang] Fix some clang->llvm type cache invalidation issues Take the following as an example struct z { z (*p)(); }; z f(); When we attempt to get the LLVM type of f, we recurse into z. z itself has a function pointer with the same type as f. Given the recursion, Clang simply treats z::p as a pointer to an empty struct `{}*`. The LLVM type of f is as expected. So we have two different potential LLVM types for a given Clang type. If we store one of those into the cache, when we access the cache with a different context (e.g. we are/aren't recursing on z) we may get an incorrect result. There is s= ome attempt to clear the cache in these cases, but it doesn't seem to han= dle all cases. This change makes it so we only use the cache when we are not in any sort of function context, i.e. `noRecordsBeingLaidOut() && FunctionsBeingProcessed.empty()`, which are the cases where we may decide to choose a different LLVM type for a given Clang type. LLVM types for builtin types are never recursive so they're always ok. This allows us to clear the type cache less often (as seen with the removal of one of the calls to `TypeCache.clear()`). We still need to clear it when we use a placeholder type then replace it later with the final type and other dependent types need to be recalculated. I've added a check that the cached type matches what we compute. It triggered in this test case without the fix. It's currently not check-clang clean so it's not on by default for something like expens= ive checks builds. This change uncovered another issue where the LLVM types for an argum= ent and its local temporary don't match. For example in type-cache-3, when expanding z::dc's argument into a temporary alloca, we ConvertType() = the type of z::p which is `void ({}*)*`, which doesn't match the alloca G= EP type of `{}*`. No noticeable compile time changes: =20=20=20=20=20 https://llvm-compile-time-tracker.com/compare.php?from=3D3918dd6b8acf8c5886= b9921138312d1c638b2937&to=3D50bdec9836ed40e38ece0657f3058e730adffc4c&stat= =3Dinstructions Fixes #53465. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D118744 PR: 264318 Reported by: mandree MFC after: 3 days contrib/llvm-project/clang/lib/CodeGen/CGBuilder.h | 5 ++- contrib/llvm-project/clang/lib/CodeGen/CGCall.cpp | 18 ++++++-- .../clang/lib/CodeGen/CodeGenTypes.cpp | 52 ++++++++++++++++++= ---- 3 files changed, 60 insertions(+), 15 deletions(-) --=20 You are receiving this mail because: You are on the CC list for the bug.=