Re: Recent failures on buildfarm member hornet

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: David Rowley <dgrowleyml@gmail.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2020-10-07T22:03:16Z
Lists: pgsql-hackers
I wrote:
> I'm tempted to propose the attached small code rearrangement, which
> might dissuade the compiler from thinking it can get away with this.
> While I concur with your point that an old xlc version might not be
> that exciting, there could be other compilers doing the same thing
> in the future.

After thinking about it a bit more, I'm not even convinced that what
xlc seems to be doing is illegal per C spec.  There are no sequence
points within

    return list_make2(list_concat(directargs, orderedargs),
                      makeInteger(ndirectargs));

and therefore there's an argument to be made that the compiler
doesn't have to care whether any side-effects of list_concat() occur
before or after the evaluation of makeInteger(ndirectargs).
If the potential side-effects of list_concat() can be disregarded
until the end of this statement, then the code change is perfectly legal.

Maybe some very careful language-lawyering could prove differently,
but it's not as open-and-shut as one could wish.  So now I'm thinking
that we need this patch anyway, xlc or not.

			regards, tom lane



Commits

  1. Fix optimization hazard in gram.y's makeOrderedSetArgs(), redux.

  2. Improve pg_list.h's linitial(), lsecond() and co macros