Re: casting operand to proper type in BlockIdGetBlockNumber
От
Zhihong Yu
Тема
Re: casting operand to proper type in BlockIdGetBlockNumber
Дата
Msg-id
CALNJ-vSbrFGYqijkwue_hOLtUv7DyQV4OE-MCx4rXyEoMPaY8g@mail.gmail.com
Ответ на
Список
Дерево обсуждения
casting operand to proper type in BlockIdGetBlockNumber Zhihong Yu <zyu@yugabyte.com>
Re: casting operand to proper type in BlockIdGetBlockNumber Tom Lane <tgl@sss.pgh.pa.us>
Re: casting operand to proper type in BlockIdGetBlockNumber Zhihong Yu <zyu@yugabyte.com>
Re: casting operand to proper type in BlockIdGetBlockNumber Tom Lane <tgl@sss.pgh.pa.us>
Re: casting operand to proper type in BlockIdGetBlockNumber Zhihong Yu <zyu@yugabyte.com>
Re: casting operand to proper type in BlockIdGetBlockNumber Tom Lane <tgl@sss.pgh.pa.us>
Re: casting operand to proper type in BlockIdGetBlockNumber Andres Freund <andres@anarazel.de>
Re: casting operand to proper type in BlockIdGetBlockNumber Tom Lane <tgl@sss.pgh.pa.us>
Re: casting operand to proper type in BlockIdGetBlockNumber Andres Freund <andres@anarazel.de>
Re: casting operand to proper type in BlockIdGetBlockNumber Tom Lane <tgl@sss.pgh.pa.us>
Re: casting operand to proper type in BlockIdGetBlockNumber Andres Freund <andres@anarazel.de>
Re: casting operand to proper type in BlockIdGetBlockNumber Tom Lane <tgl@sss.pgh.pa.us>
Re: casting operand to proper type in BlockIdGetBlockNumber Andres Freund <andres@anarazel.de>
Re: casting operand to proper type in BlockIdGetBlockNumber Tom Lane <tgl@sss.pgh.pa.us>
Re: casting operand to proper type in BlockIdGetBlockNumber Zhihong Yu <zyu@yugabyte.com>
Re: casting operand to proper type in BlockIdGetBlockNumber Zhihong Yu <zyu@yugabyte.com>
On Thu, Mar 3, 2022 at 9:13 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Zhihong Yu <zyu@yugabyte.com> writes:
> On Thu, Mar 3, 2022 at 8:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Oh, I misread this as a compile-time warning, but it must be from ASAN.
>> Was the test case one of your own, or just our normal regression tests?
> The Jenkins test is ported from contrib/postgres_fdw/sql/postgres_fdw.sql -
> so theoretically PG would see the same error for clang12 on Alma.
Hmph. I tried enabling -fsanitize=undefined here, and I get some
complaints about passing null pointers to memcmp and the like, but
nothing about this shift (tested with clang 12.0.1 on RHEL8 as well
as clang 13.0.0 on Fedora 35). What compiler switches are being
used exactly?
regards, tom lane
Hi,
This is from (internal Jenkins) build log:
CMAKE_C_FLAGS -Werror -fno-strict-aliasing -Wall -msse4.2 -Winvalid-pch -pthread -DBOOST_BIND_NO_PLACEHOLDERS -DBOOST_UUID_RANDOM_PROVIDER_FORCE_POSIX -DROCKSDB_PLATFORM_POSIX -DBOOST_ERROR_CODE_HEADER_ONLY -march=ivybridge -mcx16 -DYB_COMPILER_TYPE=clang12 -DYB_COMPILER_VERSION=12.0.1 -DROCKSDB_LIB_IO_POSIX -DSNAPPY -DLZ4 -DZLIB -mno-avx -mno-bmi -mno-bmi2 -mno-fma -D__STDC_FORMAT_MACROS -Wno-deprecated-declarations -DGFLAGS=gflags -Werror=enum-compare -Werror=switch -Werror=return-type -Werror=string-plus-int -Werror=return-stack-address -Werror=implicit-fallthrough -D_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS -Wthread-safety-analysis -Wshorten-64-to-32 -ggdb -O1 -fno-omit-frame-pointer -DFASTDEBUG -Wno-ambiguous-member-template -Wimplicit-fallthrough -Qunused-arguments -stdlib=libc++ -D_GLIBCXX_EXTERN_TEMPLATE=0 -nostdinc++ -stdlib=libc++ -D_GLIBCXX_EXTERN_TEMPLATE=0 -nostdinc++ -shared-libasan -fsanitize=address -DADDRESS_SANITIZER -fsanitize=undefined -fno-sanitize-recover=all -fno-sanitize=alignment,vptr -fsanitize-recover=float-cast-overflow -fsanitize-blacklist=... -fPIC
I would suggest trying out the build on Alma Linux.
FYI
В списке pgsql-hackers по дате отправления
От: Bruce Momjian
Дата:
От: Andres Freund
Дата:
