Re: Add "-Wimplicit-fallthrough" to default flags (was Re: pgsql: Support FETCH FIRST WITH TIES)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add "-Wimplicit-fallthrough" to default flags (was Re: pgsql: Support FETCH FIRST WITH TIES)
Date: 2020-05-12 20:59:15
Message-ID: 6590.1589317155@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> I ended up using level 4 and dialling back to 3 for zic.c only
> (different make trickery though).

Meh ... if we're going to use level 4, I'm inclined to just change zic.c
to match. It's not like we're using the upstream code verbatim anyway.
We could easily add s/fallthrough/FALLTHROUGH/ to the conversion recipe.

> I get no warnings with this (gcc 8), but ccache seems to save warnings
> in one run so that they can be thrown in a later one. I'm not sure what
> to make of that, but ccache -d proved that beyond reasonable doubt and
> ccache -clear got rid of the lot.

Sounds like a ccache bug: maybe it's not accounting for different
fallthrough warning levels. ccache knows a *ton* about gcc options,
so I'd not be surprised if it's doing something special with this one.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2020-05-12 21:12:51 Re: Add "-Wimplicit-fallthrough" to default flags (was Re: pgsql: Support FETCH FIRST WITH TIES)
Previous Message Alvaro Herrera 2020-05-12 20:25:24 Re: Add "-Wimplicit-fallthrough" to default flags (was Re: pgsql: Support FETCH FIRST WITH TIES)

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-05-12 21:12:51 Re: Add "-Wimplicit-fallthrough" to default flags (was Re: pgsql: Support FETCH FIRST WITH TIES)
Previous Message Tom Lane 2020-05-12 20:54:39 Re: Our naming of wait events is a disaster.