From nobody Tue May 31 15:56:45 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 454C81B677A0 for ; Tue, 31 May 2022 15:56:46 +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 4LCH2j1Cg4z4gnS for ; Tue, 31 May 2022 15:56:45 +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 01859694A for ; Tue, 31 May 2022 15:56:45 +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 24VFuisg001159 for ; Tue, 31 May 2022 15:56:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 24VFuibm001158 for toolchain@FreeBSD.org; Tue, 31 May 2022 15:56:44 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] security/putty-nogtk: Crashes base clang 14.0.3 on i386 Date: Tue, 31 May 2022 15:56:45 +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 Some People 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: mfc-stable13? 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 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=1654012605; 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=S7dX5nPbRqQ1i0KRtdeq0laqcRdh5vxQScs7x8u7uGA=; b=VgSV5a8ys7NNCZLXgagNaeTeHE6IiaVUF+cjkz+f96l5LIY8g/6qwqLSuCT89zigu/2p+D SbKmG+rOaO5sqiW1GVlsopi5YHbu8goSlsSUuGpJdqQrca4xZnyZiSHPZW51HITY1hwBl7 KJhi77Q9RRhdq3UTymIGS+1xRBbD6xG7gGSNpycEgfnaV4bfVrmW9ufUkiLm/8Kqm4fmPb MxdsoagENid0K/rP3MqGS6qer7dcfSYVpAiEa79hhX14Muwp1zsMlRUvQ2DY1KO3KR6hwO drBdf7RdX3GhhQPUuDy7R7hAKOzLVXc5elr+oEBK4e1QvHaQhDHirOBd8bPNwg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654012605; a=rsa-sha256; cv=none; b=TtbnZ3rfEu0a0O8/bNl6nv1RXnxMDlM9EezSadnjVXgCJ5sKWX08MlVD3C+c6ABhSQiYGw po+sFQP3mt2aJkr5w7LaYY62h+a/NLPOT2i6ONgOOhUzAnq4zo8f0CJ3UBkzB1UTDFsExJ EsArqYMBjQQJ9Hdy6QHo5hfMyPZWxZFnfnEI47KKeI7wc1bPtev8Qo3t/Rvel/2UP/AVYf rqJaBKzwlq9lAiWWhSOiF1WZG50xbWML69zfHDmUbnlmUNl/1QKa1UX8omlZIUNmj3+tHx v3Ip9Sv+gcRijfsGv6OFlCZAQPen8X/wOwWOYJahGpaEtH1Y9frZt1HUcebhvw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264318 --- Comment #4 from commit-hook@FreeBSD.org --- A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D9ac7261611ad130fcfae0da803e2e85c1= b9c73f1 commit 9ac7261611ad130fcfae0da803e2e85c1b9c73f1 Author: Dimitry Andric AuthorDate: 2022-05-28 21:26:37 +0000 Commit: Dimitry Andric CommitDate: 2022-05-31 13:17:17 +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 (cherry picked from commit 6a5eebc190ab98de98ed7977cbdee3218758376e) 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.=