Re: Recent failures on buildfarm member hornet

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Recent failures on buildfarm member hornet
Date: 2020-10-07 22:03:16
Message-ID: 2398543.1602108196@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2020-10-07 22:12:21 Re: Recent failures on buildfarm member hornet
Previous Message Thomas Munro 2020-10-07 21:51:20 Re: Two fsync related performance issues?