Re: new buildfarm with gcc & clang "trunk" -Werror? - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: new buildfarm with gcc & clang "trunk" -Werror?
Date
Msg-id alpine.DEB.2.20.1803291546360.11245@lancre
Whole thread Raw
In response to Re: new buildfarm with gcc & clang "trunk" -Werror?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: new buildfarm with gcc & clang "trunk" -Werror?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.


pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: pgsql: Add documentation for the JIT feature.
Next
From: Tomas Vondra
Date:
Subject: Re: Parallel Aggregates for string_agg and array_agg