Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path - Mailing list pgsql-hackers

From David Rowley
Subject Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path
Date
Msg-id CAApHDvoPrnqDdEnOxdX_BZScdUFydsNC4XvDKyFnZ+P+KaKNgw@mail.gmail.com
Whole thread Raw
In response to Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 25 Nov 2020 at 04:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> walleye's been failing since this patchset went in:
>
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=walleye&dt=2020-11-24%2000%3A25%3A31
>
> ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute-Wimplicit-fallthrough=3 -Wcast-function-type -Wformat-security -fno-strict-aliasing -fwrapv
-fexcess-precision=standard-Wno-format-truncation -Wno-stringop-truncation -g -O2 -I../../../src/include
-I./src/include/port/win32-I/c/msys/local/include  -I/c/Python35/include -I/c/OpenSSL-Win64/include
-I/c/msys/local/include"-I../../../src/include/port/win32" -DWIN32_STACK_RLIMIT=4194304 -DBUILDING_DLL  -c -o
autovacuum.oautovacuum.c 
> C:\\Users\\BUILDE~1.SER\\AppData\\Local\\Temp\\cc4HR3xZ.s: Assembler messages:
> C:\\Users\\BUILDE~1.SER\\AppData\\Local\\Temp\\cc4HR3xZ.s:5900: Error: .seh_savexmm offset is negative
> make[3]: *** [autovacuum.o] Error 1
>
> I have no idea what to make of that, but it looks more like a compiler bug
> than anything else.

That's about the best I could come up with too when looking at that
yesterday.  The message gives me the impression that it might be
related to code arrangement. It does seem to be the assembler that's
complaining.

I wondered if #if !defined(__MINGW32__) && !defined(__MINGW64__) would
be the correct fix for it... aka, just define the new
pg_attribute_(hot|cold) macros to empty on MinGW.

David



pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: mark/restore failures on unsorted merge joins
Next
From: Tom Lane
Date:
Subject: Re: mark/restore failures on unsorted merge joins