From nobody Wed Jan 1 23:24:19 2025 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 4YNmBY2jsPz5jNN8 for ; Wed, 01 Jan 2025 23:24:21 +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 "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4YNmBY1PJDz3wjN for ; Wed, 1 Jan 2025 23:24:21 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1735773861; 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=iyYDAn3S2L51PV/TQQR4xqxrOB5focFx3h+4ZYkytuo=; b=lzlyl3BmrBNYjMaGVvU1PO34PmhfjJP2rSqYNqD2N2ljcPYiy+WMakHKx5UhIN0lxICriy BXvPESGEchD9vvDS9w2/c3pCAgGsNizjZIobkGHwS+otbC08Eu6ydLagBWLTLRHR7rT7QS sHbkyO2V75KTHue0luVNq6Sy7VY5g9c2olBBx2plMew5zkUfMhsI7y9iaw96v/jTnTWhvd rRPa/jvYB0KDVJmAeuWDXUnkjAzvwGgtUxRnaXnGBGgkjYJWK1r3sKVoWXqOG3K+S1F0LM D+my5Kt7HeKcV0H3ISydbtlB3XY16IRBYo4tRpHgQhFcj/XLzCqJEpXUXI3zxA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1735773861; a=rsa-sha256; cv=none; b=vBcJPuO2Xth4wNYc7t0iHeyrzjjq3S5jzQDORoamdF1YWb33peab0BLs5pFiD7/YcPZ5fK /gqPIPHdOjdTSyDBct4l4Ao9zUz6AGrDYHAoWB2Qpvup9BaNNKIvzFYt+wZIh5i5t6BKzJ SKRpabFeKbCh2u8lS5532if5pYHPLN6eJcZ7bIoQy2m/bxOgkQOnmDFjNxZ4/JUmfJTua0 LSgt45eglFNrI1T+vB6CuF9NncLwqcCAcgprptdE08hk9fkJd4fi88H2E46fK0Y0b8hUfo blMEtk9tjByWiw+xf9+04iFVXY01Gfuoc7ARGpaLDtFhYHET2BUQno4MHcoZNA== 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 4YNmBY0sc7zl1y for ; Wed, 1 Jan 2025 23:24:21 +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 501NOK2U077318 for ; Wed, 1 Jan 2025 23:24:20 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 501NOKQQ077317 for toolchain@FreeBSD.org; Wed, 1 Jan 2025 23:24:20 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 276170] LLVM bug prevents from enabling PGO optimization for Python 3.11+ Date: Wed, 01 Jan 2025 23:24:19 +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: 14.0-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dim@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: toolchain@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status 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 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: X-BeenThere: freebsd-toolchain@freebsd.org Sender: owner-freebsd-toolchain@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276170 Dimitry Andric changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |In Progress CC| |emaste@freebsd.org --- Comment #44 from Dimitry Andric --- After some more investigation I found the cause, which is (again) the fact = that assertions are _disabled_ on stable and release branches. This particular "error" is occurring in contrib/llvm-project/clang/lib/CodeGen/CodeGenModule.cpp, on line 422: 414 if (CodeGenOpts.hasProfileClangUse()) { 415 auto ReaderOrErr =3D llvm::IndexedInstrProfReader::create( 416 CodeGenOpts.ProfileInstrumentUsePath, *FS, 417 CodeGenOpts.ProfileRemappingFile); 418 // We're checking for profile read errors in CompilerInvocation= , so if 419 // there was an error it should've already been caught. If it hasn't been 420 // somehow, trip an assertion. 421 assert(ReaderOrErr); 422 PGOReader =3D std::move(ReaderOrErr.get()); 423 } llvm::IndexedInstrProfReader::create() returns a llvm::Expected<> instance, which is similar to std::expected: it can contain either a "good" return va= lue, or an error. In some llvm build configurations, when you attempt to use the return value without checking whether it contains an error, you get "Expected must be checked before access or destruction". This occurs even if the Expected<> object contains a valid value, in which case you get "Expected value was= in success state". When llvm is built with assertions (WITH_LLVM_ASSERTIONS, which is on by default on -CURRENT, but not on stable or release branches), the assert() statement on line 421 is calling llvm::Expected<>::operator bool(), which checks whether the contained object is valid, and if so it resets the check= ed state: /// Bool conversion. Returns true if this Error is in a failure state, /// and false if it is in an accept state. If the error is in a Success s= tate /// it will be considered checked. explicit operator bool() { setChecked(getPtr() =3D=3D nullptr); return getPtr() !=3D nullptr; } Then in line 422 the contained object is moved out of the 'ReaderOrErr' variable, into the 'PGOReader' variable. Finally, the 'ReaderOrErr' variabl= e, which is now empty, is destroyed. However, when llvm is built without assertions (WITHOUT_LLVM_ASSERTIONS), t= he assert() statement on line 421 does nothing, and the 'ReaderOrErr' variabl= e is unaffected. Then in line 422, llvm::Expected<>::get() is called: /// Returns a reference to the stored T value. reference get() { assertIsChecked(); return *getStorage(); } The first thing get() does is looking if the Expected<> object was checked,= and if not, it prints "Expected must be checked before access or destruction" and the whole program dies. Finally, assertIsChecked() is only really doing something if the global llvm macro LLVM_ENABLE_ABI_BREAKING_CHECKS is defined: void assertIsChecked() const { #if LLVM_ENABLE_ABI_BREAKING_CHECKS if (LLVM_UNLIKELY(Unchecked)) fatalUncheckedExpected(); #endif } In the upstream build system, LLVM_ENABLE_ABI_BREAKING_CHECKS is typically 0 when assertions are off, and 1 when assertions are on. In the FreeBSD case, this use to always be defined as 1 in lib/clang/include/llvm/Config/abi-breaking.h, until base 1c83996beda7 ("Adj= ust LLVM_ENABLE_ABI_BREAKING_CHECKS depending on NDEBUG"): 15 /* Define to enable checks that alter the LLVM C++ ABI */ 16 #ifdef NDEBUG 17 #define LLVM_ENABLE_ABI_BREAKING_CHECKS 0 18 #else 19 #define LLVM_ENABLE_ABI_BREAKING_CHECKS 1 20 #endif Unfortunately 14.2 does not have this commit, so the combination of MK_LLVM_ASSERTIONS=3Dno and LLVM_ENABLE_ABI_BREAKING_CHECKS=3D1 leads to the scenario describe above: the assert() statement in CodeGenModule.cpp line 4= 21 does nothing, but ReaderOrErr.get() still performs the check and aborts. I merged base 1c83996beda7 to stable/14 in base 86de9cd1f1b5, and to stable= /13 in base 44be5a00bedd, but this is unfortunately not available in 14.2-RELEA= SE or 13.4-RELEASE, so for those releases there isn't much I can do except to = try to roll it into a Erratum. --=20 You are receiving this mail because: You are the assignee for the bug.=