tadarida vs REL_12_STABLE
Hi,
On 2020-Apr-13, I wrote to buildfarm-admins:
As skate and snapper are increasingly difficult to keep alive and
building on debian sparc, and as there aren't many sparc animals
in general, I've set up four new debian sparc64 animals, two on
stretch and two on buster.All four animals are already successfully building all current
branches, just not submitting results yet.
It turns out I'd missed one failure:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=tadarida&br=REL_12_STABLE
Only tadarida fails the sequence regression test, and only
for REL_12_STABLE. It fails with -O2 and -O1 but succeeds with -O0.
Other than that, all branches for all four animals succeed:
mussurana | Debian | 9 Stretch | gcc | 6 | with cassert
tadarida | Debian | 9 Stretch | gcc | 6 | without cassert
ibisbill | Debian | 10 Buster | gcc | 8 | with cassert
kittiwake | Debian | 10 Buster | gcc | 8 | without cassert
Both mussurana and tadarida are Stretch 9.12 with gcc 6.3.0-18+deb9u1.
There is no newer gcc source pkg for stretch or for stretch-backports.
Should I keep the -O0 flag for REL_12_STABLE for tadarida?
Thanks,
Tom
"Tom Turelinckx" <pgbf@twiska.com> writes:
It turns out I'd missed one failure:
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=tadarida&br=REL_12_STABLE
Only tadarida fails the sequence regression test, and only
for REL_12_STABLE. It fails with -O2 and -O1 but succeeds with -O0.
Yeah, I saw that. The failure mode is really pretty odd:
CREATE SEQUENCE sequence_test9 AS integer INCREMENT BY -1;
+ERROR: MINVALUE (-9223372036854775808) is out of range for sequence data type integer
It's not difficult to see where things must be going wrong: sequence.c,
around line 1490 in HEAD, must be choosing to set the sequence's seqmin
to PG_INT64_MIN instead of PG_INT32_MIN as it should. But that code is
exactly the same from HEAD back to v11 (and probably further, though
I didn't look).
The next two failures are the same thing for smallint, and the rest is
just fallout from the sequence-creation failures. So that's one extremely
specific codegen bug in the whole test suite. I wonder if it's related to
the branch-delay-slot codegen bug we identified for sparc32 awhile back.
Not sure what to tell you, other than that it's darn odd that this only
fails in v12. But I don't have much faith that "use -O0 in v12 only"
is going to be a long-term answer.
regards, tom lane