Re: jsonapi: scary new warnings with LTO enabled - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: jsonapi: scary new warnings with LTO enabled
Date
Msg-id 0A596D8B-24F3-408F-B89B-B42014B00A05@yesql.se
Whole thread Raw
In response to Re: jsonapi: scary new warnings with LTO enabled  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: jsonapi: scary new warnings with LTO enabled
List pgsql-hackers
> On 17 Apr 2025, at 01:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Jacob Champion <jacob.champion@enterprisedb.com> writes:
>> On Wed, Apr 16, 2025 at 4:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Looking through all of the callers of freeJsonLexContext, quite
>>> a lot of them use local JsonLexContext structs, and probably some
>>> of them are more performance-critical than these.  So that raises
>>> the question of why are we seeing warnings for only these call
>>> sites?
>
>> Yeah, I had the same question...
>
> After making another pass through the callers of freeJsonLexContext,
> I observe that the warnings appear in callers that use a local
> variable *and* contain goto statements.  So I'm betting that the
> presence of goto's causes the LTO optimizer to pull in its horns
> quite a bit and thereby fail to detect the flag correlation.

That seems plausible given the selective warnings.

>>> Maybe there is a more elegant way to suppress them.
>
>> Can we brute-force ignore this particular warning site with a #pragma
>> (suggested in [1])?
>
> That's surely not elegant :-(.  However, I don't especially want to
> rewrite away the goto's in these callers ...

Agreed, moving to heap allocated structures for these callsites seem much
better. Something like the attached should be enough I think?

--
Daniel Gustafsson


Attachment

pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Missing comma in libpq.sgml
Next
From: Rahila Syed
Date:
Subject: Re: Align memory context level numbering in pg_log_backend_memory_contexts()