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
-
Fix optimization hazard in gram.y's makeOrderedSetArgs(), redux.
- abfce4e46870 9.5.24 landed
- eb48619d01d7 9.6.20 landed
- 9f3d3fb8702b 10.15 landed
- e3868c7d59d4 11.10 landed
- 8b231d975328 12.5 landed
- dc14aa038e20 13.1 landed
- 8d2a01ae12cd 14.0 landed
-
Improve pg_list.h's linitial(), lsecond() and co macros
- cc99baa43e0e 14.0 cited