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 1kQI3A-0002TD-Tu for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Oct 2020 22:36:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kQI39-0005nD-SW for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Oct 2020 22:36:43 +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 1kQI39-0005n6-Lk for pgsql-hackers@lists.postgresql.org; Wed, 07 Oct 2020 22:36:43 +0000 Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kQI37-0007Sz-Qj for pgsql-hackers@lists.postgresql.org; Wed, 07 Oct 2020 22:36:43 +0000 Received: by mail-pl1-x62f.google.com with SMTP id c6so1760446plr.9 for ; Wed, 07 Oct 2020 15:36:41 -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=MsqXl471Htcj84r3TLmAfMP7HS1gnFQVMKWLdre4ufU=; b=LVz4V2uYklCn/Y2cTGxeT42LtUPhcyKbVZ9F4APJ8WDQkjLm+/G/a1JuoUMeG3Ubvr PFta+pIB69ANBk8vW0brgmAWTpIZ7GHobd0XLGPNKe6kd4TGoFaOxPVdiSZDfQaR0xl+ 1+vzIFtpK1c1431SXCYGqNm28Wl/Z8owjB/H4= 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=MsqXl471Htcj84r3TLmAfMP7HS1gnFQVMKWLdre4ufU=; b=s6sgYIPlMtBR8uooK6rWApKuVjH4PNtpNP6DAq0E8RxKwwUN9io/T+IEA1aSm4sbkZ aa5Cu8QZlqv1oG7A7Tf3BWEQpRbAHiE9OdhL/izGFsNYgnDmHFNrm14YyuJbfjNT8w09 LbGHjug/FwN0fjkXBHpCXxXNfb1HumUynlQrw4iacTfeCvy63MfL0sl2z6JMVNJMp8Ye BENZCbU+V0kZKbDiWCYcSOZCxOTY6CWD1q9OD14O7kHzsFuQZGhK6rc6b0KB5ne9R5za vacCjbRkonv3n7rm6HVIVy2pKXVtAxQj6b0/HsyANwTpIIIoUov9SuImBVS6vyiPzvmW ySjQ== X-Gm-Message-State: AOAM531bdWHySLO1dRyNER0FQJSeKGbw/KbPvHvI4OuIUPsc2S9vXga3 bMD4bn97tFDXUJzGaHUb7q+njA== X-Google-Smtp-Source: ABdhPJygBzEEA0t++e8zb/zULQMKauDGVWdrXKCI7cJMSjmIZb4KENh28aLu8907LS+IDmWrCpsKXA== X-Received: by 2002:a17:902:ba8c:b029:d2:aa93:c8b4 with SMTP id k12-20020a170902ba8cb02900d2aa93c8b4mr4990212pls.80.1602110199601; Wed, 07 Oct 2020 15:36:39 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::43]) by smtp.gmail.com with ESMTPSA id y12sm4532944pga.53.2020.10.07.15.36.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Oct 2020 15:36:39 -0700 (PDT) Date: Wed, 7 Oct 2020 15:36:36 -0700 From: Noah Misch To: Tom Lane Cc: David Rowley , PostgreSQL Developers Subject: Re: Recent failures on buildfarm member hornet Message-ID: <20201007223636.GD1498955@rfd.leadboat.com> References: <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> <20201007221221.GC1498955@rfd.leadboat.com> <2399356.1602109324@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2399356.1602109324@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:22:04PM -0400, Tom Lane wrote: > Noah Misch 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. C does not allow that, because the list_length() happens in a different "full expression" (different statement): ndirectargs = list_length(directargs);/* noah adds: a sequence point is here */ return list_make2(list_concat(directargs, orderedargs), makeInteger(ndirectargs)); A compiler may implement like this: ndirectargs = list_length(directargs); a := list_concat(directargs, orderedargs); b := makeInteger(ndirectargs); return list_make2(a, b); Or this: ndirectargs = list_length(directargs); b := makeInteger(ndirectargs); a := list_concat(directargs, orderedargs); return list_make2(a, b); But not like this: a := list_concat(directargs, orderedargs); ndirectargs = list_length(directargs); b := makeInteger(ndirectargs); return list_make2(a, b);