On Mon, Jul 25, 2022 at 10:18 AM Tom Lane wrote:
> I wrote:
> > I think what's happening is just that this build configuration
> > eats stack extravagantly.
>
> That's definitely it, but I don't entirely see why. Here are a
> couple of major offenders though:
Interesting. I wonder where we can
I wrote:
> I think what's happening is just that this build configuration
> eats stack extravagantly.
That's definitely it, but I don't entirely see why. Here are a
couple of major offenders though:
(gdb) x/8i ExecInterpExpr
0x11a5530 : push %rbp
0x11a5531 :mov%rsp,%rbp
0
Thomas Munro writes:
> On Mon, Jul 25, 2022 at 8:59 AM Justin Pryzby wrote:
>> I found that -fsanitize causes the test to fail, going back to REL_10_STABLE,
>> for any clang in:
> Yeah I've seen this too... it'd be good to figure out how to fix it:
> https://www.postgresql.org/message-id/CA%2BhU
On Mon, Jul 25, 2022 at 8:59 AM Justin Pryzby wrote:
> I found that -fsanitize causes the test to fail, going back to REL_10_STABLE,
> for any clang in:
>
> 1:11.1.0-6
> 1:12.0.1-19ubuntu3
> 1:13.0.1-2ubuntu2
> 1:14.0.0-1ubuntu1
>
> | time ./configure --enable-cassert --enable-debug --enable-tap-t
I found that -fsanitize causes the test to fail, going back to REL_10_STABLE,
for any clang in:
1:11.1.0-6
1:12.0.1-19ubuntu3
1:13.0.1-2ubuntu2
1:14.0.0-1ubuntu1
| time ./configure --enable-cassert --enable-debug --enable-tap-tests
--with-CC=clang-13 CFLAGS='-fsanitize=undefined'
| time { make -
