On Wed, Nov 8, 2023 at 10:00 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> On Wed, Nov 8, 2023 at 8:13 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > On 2023-Nov-08, Thomas Munro wrote:
> > > On Wed, Nov 8, 2023 at 4:46 AM Alvaro Herrera <alvherre@alvh.no-ip.org> 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
