Re: longjmp clobber warnings are utterly broken in modern gcc

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: longjmp clobber warnings are utterly broken in modern gcc
Дата
Msg-id 20150126110317.GB9916@awork2.anarazel.de
обсуждение исходный текст
Ответ на longjmp clobber warnings are utterly broken in modern gcc  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: longjmp clobber warnings are utterly broken in modern gcc  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Unsafe coding in ReorderBufferCommit()
Следующее
От: Andres Freund
Дата:
Сообщение: Re: longjmp clobber warnings are utterly broken in modern gcc