Re: gcc 13 warnings

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: gcc 13 warnings
Дата
Msg-id 501f7d61-5423-fb23-9010-d37bcac1f845@enterprisedb.com
обсуждение исходный текст
Ответ на Re: gcc 13 warnings  (Andres Freund <andres@anarazel.de>)
Ответы Re: gcc 13 warnings  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: gcc 13 warnings  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 16.03.23 19:11, Andres Freund wrote:
> On 2023-03-16 13:54:29 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> On 2023-03-16 12:10:27 -0400, Tom Lane wrote:
>>>> It wouldn't be entirely surprising if meson is selecting some -W
>>>> switches that the configure script doesn't ... but I don't know
>>>> where to check or change that.
>>
>>> I think it's just that meson defaults to -O3 (fwiw, I see substantial gains of
>>> that over -O2).  I see such warnings with autoconf as well if I make it use
>>> -O3.
>>
>> Oh, interesting.  Should we try to standardize the two build systems
>> on the same -O level, and if so which one?
> 
> I'm on the fence on this one (and posed it as a question before). O3 does
> result in higher performance for me, but it also does take longer to build,
> and increases the numbers of warnings.
> 
> So I just elected to leave it at the default for meson.

AFAICT, the default for meson is buildtype=debug, which is -O0.  The -O3 
comes from meson.build setting buildtype=release.

I think a good compromise would be buildtype=debugoptimized, which is 
-O2 with debug symbols, which also sort of matches the default in the 
autoconf world.

(https://mesonbuild.com/Builtin-options.html#details-for-buildtype)

At least during the transition phase I would prefer having the same 
default optimization level in both build systems, mainly because of how 
this affects warnings.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: Re: [PoC] Improve dead tuple storage for lazy vacuum
Следующее
От: Jehan-Guillaume de Rorthais
Дата:
Сообщение: Re: Memory leak from ExecutorState context?