Thread: 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