Re: pg_verify_checksums and -fno-strict-aliasing

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_verify_checksums and -fno-strict-aliasing
Дата
Msg-id 25968.1535663968@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_verify_checksums and -fno-strict-aliasing  (Michael Banck <michael.banck@credativ.de>)
Ответы Re: pg_verify_checksums and -fno-strict-aliasing
Список pgsql-hackers
Michael Banck <michael.banck@credativ.de> writes:
> Could well be I'm doing something wrong, so it would be cool if somebody
> could reproduce this first. In principle, it should be enough to run
> 'make clean && make CLFAGS=-O2' in the src/bin/pg_verify_checksums
> subdirectory in order to get a broken executable.

I can reproduce it on my Fedora 28 machine (gcc 8.1.1) by compiling
pg_verify_checksums with all the normal flags except -fno-strict-aliasing.
I don't see any warning, not even with -Wstrict-aliasing=2 :-(, but the
generated code malfunctions as Michael describes.  As best I can tell,
the problem is in the inlined code from checksum_impl.h rather than
in pg_verify_checksums.c itself.  I think what is happening is gcc
is concluding that it can optimize away the code that temporarily
sets the page's checksum field to zero.

Although, as Alvaro mentioned upthread, there's basically no hope of
getting away from -fno-strict-aliasing for Postgres-at-large, I think it'd
be a good thing if we could get checksum_impl.h to not depend on it.  The
whole point of that header, according to its own self-description, is to
export the checksum calculation for use by external programs --- and we
can't really control what compiler flags will be used by those.  The fact
that Michael even ran into this problem seems to be an instance of that.

So, I've been fooling around trying to get it to work without
-fno-strict-aliasing, but with little luck so far.

            regards, tom lane


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

Предыдущее
От: Michael Banck
Дата:
Сообщение: Re: pg_verify_checksums and -fno-strict-aliasing
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 10.5 but not 10.4: backend startup during reindex system: could not read block 0 in file "base/16400/..": read only 0 of 8192 bytes