Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nK2eu-0003mJ-S7 for pgsql-committers@arkaria.postgresql.org; Tue, 15 Feb 2022 18:34:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nK2et-0002Qz-Mm for pgsql-committers@arkaria.postgresql.org; Tue, 15 Feb 2022 18:34:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nK2et-0002Qq-Fk for pgsql-committers@lists.postgresql.org; Tue, 15 Feb 2022 18:34:39 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nK2er-0007fd-7w; Tue, 15 Feb 2022 18:34:39 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 21FIYTGl3155482; Tue, 15 Feb 2022 13:34:29 -0500 From: Tom Lane To: Thomas Munro cc: Alvaro Herrera , Fabien COELHO , Thomas Munro , pgsql-committers Subject: Re: pgsql: Track LLVM 15 changes. In-reply-to: References: <202202142122.eqz4mu2ecfes@alvherre.pgsql> Comments: In-reply-to Thomas Munro message dated "Tue, 15 Feb 2022 11:15:24 +1300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3155480.1644950069.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Feb 2022 13:34:29 -0500 Message-ID: <3155481.1644950069@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Thomas Munro writes: > This really depends on *their* release cycle, not ours. Hmm. Well, > if we had a buildfarm animal that ran their latest release branch as > recently discussed, not their main branch, then we could say "if that > machine is failing, but seawasp is passing, now is the time to > back-patch all the 'Track LLVM X' patches; if seawasp is failing, we > should urgently look into why". I'm willing to set such an animal up, > but Fabien or Andres may want to... A bit of shell scripting to peek > at their branches or look for their RC1 tag or something like that > depending on what we decide is the right trigger point. Although seawasp isn't actually failing at the moment, it's emitting a boatload of deprecation warnings, eg In file included from llvmjit_deform.c:27: ../../../../src/include/jit/llvmjit_emit.h:112:23: warning: 'LLVMBuildStru= ctGEP' is deprecated: Use LLVMBuildStructGEP2 instead to support opaque po= inters [-Wdeprecated-declarations] LLVMValueRef v_ptr =3D LLVMBuildStructGEP(b, v, idx, ""); ^ /home/fabien/clgtk/include/llvm-c/Core.h:3908:1: note: 'LLVMBuildStructGEP= ' has been explicitly marked deprecated here LLVM_ATTRIBUTE_C_DEPRECATED( ^ Is that on anyone's radar to clean up? regards, tom lane