Thread: new buildfarm with gcc & clang "trunk" -Werror?

Dear devs,

I've been running buildfarm members moonjelly and seawasp which use gcc & 
clang weekly recompiled trunk versions to build postgres branch HEAD for 
about 6 months

These helped uncover bugs in both gcc & clang, which were reported and 
fixed, so there is a benefit on this side.

These compilations currently fail with -Werror. "gcc trunk" generates 44 
warnings about snprintf-related possible truncations, anc "clang trunk" 
generates 68 warnings about undeclared strl* functions.

Would the project feel appropriate to:

  - fix these warnings (other than putting -Wno-format-truncation or
    similar workarounds...).

  - add permanent gcc/clang trunk beasts with -Werror
    (if so, I'd suggest cannonball & seanettle for the names).

The rational is that postgres will need to be compilable with future 
versions of these compilers, eventually, so the earlier issues are 
detected the better. Also, warnings help detect latent bugs.

However these beasts would be more unstable than others, eg start failing 
when a new warning is added. They are somehow already unstable though, as 
every few month postgres compilation would fail because of a new bug in 
the compilers.

-- 
Fabien.

Hi,

On 2018-03-28 10:06:31 +0200, Fabien COELHO wrote:
> Would the project feel appropriate to:
> 
>  - fix these warnings (other than putting -Wno-format-truncation or
>    similar workarounds...).

Yes, at least for warnings that aren't entirely bogus (see clang's
-Weverything for an extreme example of a lot of bogus stuff).


>  - add permanent gcc/clang trunk beasts with -Werror
>    (if so, I'd suggest cannonball & seanettle for the names).

I'm inclined to think that's too noisy.

Greetings,

Andres Freund

On 3/28/18 04:06, Fabien COELHO wrote:
> Would the project feel appropriate to:
> 
>   - fix these warnings (other than putting -Wno-format-truncation or
>     similar workarounds...).

I've been tracking gcc-8, and I have a patch ready, but these things
change a bit with every compiler snapshot, so I'm waiting until things
settle down.

>   - add permanent gcc/clang trunk beasts with -Werror
>     (if so, I'd suggest cannonball & seanettle for the names).

I would not like that.  The build farm success should ideally be a
function of correct PostgreSQL code, not external factors.  If an
in-progress compiler does funny things, what are we supposed to do about
that?

Generally, fixing up PostgreSQL for a new compiler release isn't a major
effort and can be done briefly before the release of the compiler.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Hello Peter,

>>   - fix these warnings (other than putting -Wno-format-truncation or
>>     similar workarounds...).
>
> I've been tracking gcc-8, and I have a patch ready, but these things
> change a bit with every compiler snapshot, so I'm waiting until things
> settle down.

Ok, so I will not submit anything for gcc. I'll look at clang, though.

>>   - add permanent gcc/clang trunk beasts with -Werror
>>     (if so, I'd suggest cannonball & seanettle for the names).
>
> I would not like that.  The build farm success should ideally be a
> function of correct PostgreSQL code, not external factors.  If an
> in-progress compiler does funny things, what are we supposed to do about
> that?

That happens infrequently, commits in gcc & clang are supposed not to 
break the compiler, just like with postgres:-) When it happens (3 times in 
6 months), I just report a bug on the compiler side, which is usually 
fixed in under one week.

> Generally, fixing up PostgreSQL for a new compiler release isn't a major
> effort and can be done briefly before the release of the compiler.

Sure.

So I understand that a -Werror beast is somehow not desirable.

-- 
Fabien.

Fabien COELHO <coelho@cri.ensmp.fr> writes:
> So I understand that a -Werror beast is somehow not desirable.

Not at this point; I for one would simply ignore it.  *After* we
have decided what project policy for this class of warnings is
going to be, it might be valuable to have such a critter.  But
that's not decided yet, and I'm not at all sure that "fix every
such warning" is going to be the decision.  We might well decide
these are mostly nannyism and add a -Wno-xxx flag instead.

In the meantime, I think we already have an animal running git trunk
without -Werror; if not, feel free to create one.

            regards, tom lane