From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <matz@suse.de>
Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d])
	by sourceware.org (Postfix) with ESMTPS id 23E25395A44D
	for <gcc@gcc.gnu.org>; Wed, 16 Nov 2022 15:01:42 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 23E25395A44D
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de
Received: from relay2.suse.de (relay2.suse.de [149.44.160.134])
	by smtp-out2.suse.de (Postfix) with ESMTP id 010EA1F94F;
	Wed, 16 Nov 2022 15:01:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
	t=1668610901; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=7wCmXFF4g66Ev+Cj4py2SK/2u8oJ6dZGbpe5lxs6lRE=;
	b=hQF0X4+IBYvUaKxYs9v95VbSPIjQokhMqJ9+L1ff3/jXHY8nn0j0o+dA68YvdPGyw2hIgM
	dWWYBptpy+1XVRD44dMex2UIy5dgd6sR992a81eWNP2S4n5Y4CIyRC8l5ulN0F2jeluv6k
	5sv9Bp6bGFV2oGb4B/IxIbFoIEO90lk=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
	s=susede2_ed25519; t=1668610901;
	h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=7wCmXFF4g66Ev+Cj4py2SK/2u8oJ6dZGbpe5lxs6lRE=;
	b=TwXEFM/3cQBJau5VCDi8uuQ5+j+Aejf3j4vjpqx2CImVQCtF+t0lMLmTUodEAC8SPLl2Bn
	1EbEiAwCYBj56VDw==
Received: from wotan.suse.de (wotan.suse.de [10.160.0.1])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by relay2.suse.de (Postfix) with ESMTPS id D4B342C141;
	Wed, 16 Nov 2022 15:01:40 +0000 (UTC)
Received: by wotan.suse.de (Postfix, from userid 10510)
	id C941864AC; Wed, 16 Nov 2022 15:01:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
	by wotan.suse.de (Postfix) with ESMTP id C7C3162AE;
	Wed, 16 Nov 2022 15:01:40 +0000 (UTC)
Date: Wed, 16 Nov 2022 15:01:40 +0000 (UTC)
From: Michael Matz <matz@suse.de>
To: Alexander Monakov <amonakov@ispras.ru>
cc: Paul Eggert <eggert@cs.ucla.edu>, Jonathan Wakely <jwakely.gcc@gmail.com>, 
    Aaron Ballman <aaron@aaronballman.com>, Zack Weinberg <zack@owlfolio.org>, 
    c-std-porting@lists.linux.dev, autoconf@gnu.org, gcc@gcc.gnu.org, 
    cfe-commits@lists.llvm.org, Gnulib bugs <bug-gnulib@gnu.org>
Subject: Re: How can Autoconf help with the transition to stricter compilation
 defaults?
In-Reply-To: <27264d94-9496-d7ef-6716-f43db86f38e2@ispras.ru>
Message-ID: <alpine.LSU.2.20.2211161445070.5466@wotan.suse.de>
References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> <CAAt6xTt75qBzQKt7_0ZPGaOBGnbDsuM8j_owRYzjc21n7NMqDQ@mail.gmail.com> <251923e7-57be-1611-be10-49c3067adf0d@cs.ucla.edu> <CAAt6xTuM=SykGGRYy9zSohEbgC+RoROYYiQ5wgNv-7knoaNJXw@mail.gmail.com>
 <7ef0ce03-d908-649a-a6ee-89fea374d2b1@cs.ucla.edu> <CAAt6xTsju9UwBJiNJabwOxZC7BXNyydkQDQv=A-7gB6w8nq5=w@mail.gmail.com> <f38000ed-6b9e-8703-6620-e5f52da9c5a2@cs.ucla.edu> <CAH6eHdS-N51Yi4wwQ1U4tM==JyJ3-OZX4ZuawJd+_UMsuZUXSg@mail.gmail.com>
 <9cb106e9-16ff-65ec-6a44-6567c77521dc@cs.ucla.edu> <CAH6eHdTnMwkJi1fqo715KwJq1BsM9M=EkP4T1FMY0Kj9kf=8nQ@mail.gmail.com> <06a5d2cd-44eb-7404-17f3-ff64dd505427@cs.ucla.edu> <alpine.LSU.2.20.2211161418020.5466@wotan.suse.de>
 <27264d94-9496-d7ef-6716-f43db86f38e2@ispras.ru>
User-Agent: Alpine 2.20 (LSU 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP 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>

Hey,

On Wed, 16 Nov 2022, Alexander Monakov wrote:

> > The idea is so obvious that I'm probably missing something, why autoconf 
> > can't use that idiom instead.  But perhaps the (historic?) reasons why it 
> > couldn't be used are gone now?
> 
> Ironically, modern GCC and LLVM optimize '&foobar != 0' to '1' even at -O0,
> and thus no symbol reference remains in the resulting assembly.

Err, right, *head-->table*.
Playing with volatile should help:

char foobar(void);
char (* volatile ptr)(void);
int main(void) {
    ptr = foobar;
    return ptr != 0;
}


Ciao,
Michael.