Re: longjmp clobber warnings are utterly broken in modern gcc - Mailing list pgsql-hackers

From Andres Freund
Subject Re: longjmp clobber warnings are utterly broken in modern gcc
Date
Msg-id 20150126110317.GB9916@awork2.anarazel.de
Whole thread Raw
In response to longjmp clobber warnings are utterly broken in modern gcc  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: longjmp clobber warnings are utterly broken in modern gcc
List pgsql-hackers
Hi,

On 2015-01-25 14:02:47 -0500, Tom Lane wrote:
> I've been looking for other instances of the problem Mark Wilding
> pointed out, about missing "volatile" markers on variables that
> are modified in PG_TRY blocks and then used in the PG_CATCH stanzas.
> There definitely are some.  Current gcc versions do not warn about that.
> 
> If you turn on -Wclobbered, you don't always get warnings about the
> variables that are problematic, and you do get warnings about variables
> that are perfectly safe.  (This is evidently why that option is not on
> by default: it's *useless*, or even counterproductive if it gives you
> false confidence that the compiler is protecting you.)

I've observed that too. IIUC the warnings are generated by observing
what register spilling does - which unfortunately seems to mean that the
more complex a function gets the less useful the clobber warnings get
because there's more spilling going on, generating pointless warnings.

I think it's actually not a recent regression - in the past a lot of
spurious instances of these warnings have been fixed by simply tacking
on volatile on variables that didn't actually need it.

> I tested this on gcc 4.4.7 (current on RHEL6), and gcc 4.8.3 (current
> on Fedora 20); they behave the same.  Even if this were fixed in
> bleeding-edge gcc, we'd definitely still need the "volatile" marker
> to get non-broken code compiled on most current platforms.

It's not fixed (both in the correct warning and not needing anymore sense) at least for
gcc (Debian 20150119-1) 5.0.0 20150119 (experimental) [trunk revision 219863]

> This is scary as hell.  I intend to go around and manually audit
> every single PG_TRY in the current source code, but that is obviously
> not a long-term solution.  Anybody have an idea about how we might
> get trustworthy mechanical detection of this type of situation?

Not really, except convincing gcc to fix the inaccurate detection. Given
that there've been bugs open about this (IIRC one from you even) for
years I'm not holding my breath.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Unsafe coding in ReorderBufferCommit()
Next
From: Andres Freund
Date:
Subject: Re: longjmp clobber warnings are utterly broken in modern gcc