From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=dZw7=BA=schemamania.org=jklowden@sourceware.org>
Received: from mail.schemamania.org (rrcs-50-75-19-234.nys.biz.rr.com [50.75.19.234])
	by sourceware.org (Postfix) with ESMTP id 2F797385B53E
	for <gcc@gcc.gnu.org>; Thu, 11 May 2023 15:30:19 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F797385B53E
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=schemamania.org
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=schemamania.org
Received: from oak.schemamania.org (localhost [IPv6:::1])
	by mail.schemamania.org (Postfix) with ESMTP id D2CCD256FADC
	for <gcc@gcc.gnu.org>; Thu, 11 May 2023 06:49:39 -0400 (EDT)
Date: Thu, 11 May 2023 06:49:39 -0400
From: "James K. Lowden" <jklowden@schemamania.org>
To: David Brown via Gcc <gcc@gcc.gnu.org>
Subject: Re: More C type errors by default for GCC 14
Message-Id: <20230511064939.8e78f6eb2ac1e471dd7588a3@schemamania.org>
In-Reply-To: <u3ftgv$sof$1@ciao.gmane.io>
References: <877cth66qb.fsf@oldenburg.str.redhat.com>
	<CAGWvnykoEtT0BQtuN70DN6tWohtf=Mm7SW55psZvVmj3OvKUEg@mail.gmail.com>
	<CAH6eHdS5=AED+7MSe0prr8CZ-sYqnD159OjhTp9=R-a0aBZ3qw@mail.gmail.com>
	<20230509102201.6aa2a7d14fdb2f1e7abff449@killthe.net>
	<87r0rp5uf8.fsf@aarsen.me>
	<83ttwla1ep.fsf@gnu.org>
	<CAH6eHdS-7USHzX3rPJaR66sEdjG+-nHp7mDb0gD7ceBnp+Fmpg@mail.gmail.com>
	<83lehx9vix.fsf@gnu.org>
	<ZFqZ25xKm4w4IkqF@tucnak>
	<83fs859unu.fsf@gnu.org>
	<CAGWvny=xi++Ghyo2Ez5MJdYy5h3yH16gVpviKC99Ufu_bUmdYQ@mail.gmail.com>
	<u3ftgv$sof$1@ciao.gmane.io>
X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.28; x86_64--netbsd)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06,KAM_DMARC_STATUS,KAM_NUMSUBJECT,NICE_REPLY_A,RDNS_DYNAMIC,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gcc.gcc.gnu.org>

On Wed, 10 May 2023 13:00:46 +0200
David Brown via Gcc <gcc@gcc.gnu.org> wrote:

> or that function calls always act as a 
> memory barrier.

Hi David, [off list]

Could you tell me more about that, and where I could read about it?  

I've only been using C since 1985, so just a beginner, I guess. ;-)
As a  matter of C semantics, I can't see how a function call could be
anything but a memory barrier.  The arguments have to be resolved before
the function is called, else there's no value to provide.  And the
function has to determine its return value prior to returning.  

I can imagine in the face of multithreading that things become murky,
but that's the nature of multithreading as commonly implemented.  It's
outside C semantics.  

I'm genuinely curious what it is your referring to, in case my
understanding is out of date.  

--jkl