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:22:04Z
Lists: pgsql-hackers
Noah Misch <noah@leadboat.com> writes: > On Wed, Oct 07, 2020 at 06:03:16PM -0400, Tom Lane wrote: >> 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)); > There is, however, a sequence point between list_length(directargs) and > list_concat(), and the problem arises because xlc reorders those two. It's > true that makeInteger() could run before or after list_concat(), but that > alone would not have been a problem. Yeah, that is the theory on which the existing code is built, specifically that the list_length fetch must occur before list_concat runs. What I am wondering about is a more aggressive interpretation of "sequence point", namely that the compiler is free to disregard exactly when list_concat's side-effects occur between this statement's sequence points. I'm not sure that the C spec allows that interpretation, but I'm not sure it doesn't, either. 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