Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kQHfg-0001cn-RC for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Oct 2020 22:12:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kQHff-0006nw-Lw for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Oct 2020 22:12:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kQHff-0006nj-F3 for pgsql-hackers@lists.postgresql.org; Wed, 07 Oct 2020 22:12:27 +0000 Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kQHfd-0007HD-Lx for pgsql-hackers@lists.postgresql.org; Wed, 07 Oct 2020 22:12:27 +0000 Received: by mail-pg1-x534.google.com with SMTP id u24so2513590pgi.1 for ; Wed, 07 Oct 2020 15:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=igSAqiYOsh5sk62h11MRG5XLJ9CdnCj3+zVHwgVr3+4=; b=JqF7SuEYJnWDUUe2ON8TUS8cPfPUr90m2tdOXL90ur9vr0x+qpImFQXRiQLE4THadZ IsdjCK3wuo9aGcH7TMY+0LHKdso5+WnMxtpo1hEC+PHHNP15wetVMVWTrWq5/3YRVdKn GCBQLh9Kkvl0ZChdFqCoYG81stvGXIhLQH2Sg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=igSAqiYOsh5sk62h11MRG5XLJ9CdnCj3+zVHwgVr3+4=; b=SWCD5oq6O39gJwL2bZ6imSHtVkuoWatIe5iRNVwW0PThkSEZPO7COeX3t+ovyQZd9T E4G8lcz9vAXlSH0wJ2H9+0Hs5nEYJ9+4ND1Dwhi3y12wSQx6m4DRBduCVVaPIaT2dcM3 2r44nFk2HIh63v9O3N96zXwgu/juyMgZT6iQOI51nGFE9iZ4kuG2VkKteED1Hz+QoXd6 1XkmTRWPWdXEYUqNiIvwQ1MzEDumYy65DLkSAc892MpoauGDDDt1kcGFloGUD7/ZjC0J /Y9Eb77/VSp6/R1bBryF/ZgHl+TNRg2UcQkGr7ziIHtDzndjl9BLaIiFKavEQ0S7BhfN jQlQ== X-Gm-Message-State: AOAM533e74DgzjQZsW3JAlvkkTyRxbiLW/YcF0f3njC2Xwh9Bi1dUx30 zZVNJbZR7Ml5o9xbuuHjTfE2CA== X-Google-Smtp-Source: ABdhPJzU3r9vQpuXrdOCap+It2o4eFo3btPoENW7XlSga8MzLbJ9edvafsfYGZpJ/FBLpcvHqSv9rA== X-Received: by 2002:a17:90a:aa18:: with SMTP id k24mr4622691pjq.231.1602108743843; Wed, 07 Oct 2020 15:12:23 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::43]) by smtp.gmail.com with ESMTPSA id g13sm4448628pfu.186.2020.10.07.15.12.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Oct 2020 15:12:23 -0700 (PDT) Date: Wed, 7 Oct 2020 15:12:21 -0700 From: Noah Misch To: Tom Lane Cc: David Rowley , PostgreSQL Developers Subject: Re: Recent failures on buildfarm member hornet Message-ID: <20201007221221.GC1498955@rfd.leadboat.com> References: <1830491.1601944935@sss.pgh.pa.us> <20201007014507.GB1422897@rfd.leadboat.com> <2040113.1602035809@sss.pgh.pa.us> <20201007021941.GD1422897@rfd.leadboat.com> <2233910.1602090798@sss.pgh.pa.us> <20201007212056.GB1498955@rfd.leadboat.com> <2397925.1602107299@sss.pgh.pa.us> <2398543.1602108196@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2398543.1602108196@sss.pgh.pa.us> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Oct 07, 2020 at 06:03:16PM -0400, Tom Lane wrote: > 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. That patch does get hornet's -O2 build to again pass "make check". It doesn't harm the code, so we may as well use it. > > 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)); 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.