On Wed, Nov 8, 2023 at 10:00 AM Thomas Munro <[email protected]> wrote: > On Wed, Nov 8, 2023 at 8:13 AM Alvaro Herrera <[email protected]> wrote: > > On 2023-Nov-08, Thomas Munro wrote: > > > On Wed, Nov 8, 2023 at 4:46 AM Alvaro Herrera <[email protected]> > > > wrote: > > > > On 2023-Aug-25, Daniel Westermann (DWE) wrote: > > > > > > > > Yeah, I get this one too. I thought commit 37d5babb5cfa ("jit: Support > > > > opaque pointers in LLVM 16.") was going to silence it, but I was quite > > > > mistaken. I gave that code a quick look and could not understand what > > > > it was complaining about. Is it a bug in the LLVM headers? > > > > > > I found the commit where they fixed that in 15+: > > > > > > https://github.com/llvm/llvm-project/commit/1d9086bf054c2e734940620d02d4451156b424e6 > > > > > > They don't seem to back-patch fixes, generally. > > > > Ah yeah, I can silence the warning by patching that file locally.
I was looking into buildfarm warnings today and noticed this one again on 'hawk'. My C++ is a little rusty but I wanted to know if anything could actually break because of this, and I'm not seeing it. I'm not a lawyer but I'm not sure that "used" is even true in this statement: "member ‘llvm::ModuleSummaryIndex::Alloc’ is used uninitialize" ... considering that StringSaver's constructor just binds a reference. There can surely be no doubt about its address. With that suspicion I checked a few compilers and noticed that GCC 14 stopped emitting the warning! Then I found my way to: https://github.com/gcc-mirror/gcc/commit/b83f3cd3ff765fb82344b848b8a128763b7a4233
