From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id E90D4385840F for ; Wed, 15 Feb 2023 16:42:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E90D4385840F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=foss.arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1BF3C1042; Wed, 15 Feb 2023 08:43:08 -0800 (PST) Received: from [10.57.52.9] (unknown [10.57.52.9]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C08713F881; Wed, 15 Feb 2023 08:42:24 -0800 (PST) Message-ID: <3f282ee2-5bd3-9af7-3399-9fc388229e4d@foss.arm.com> Date: Wed, 15 Feb 2023 16:42:23 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: Could __builtin_printf parameters be optimized when being compiled Content-Language: en-GB To: Segher Boessenkool , Jonny Grant Cc: gcc-help References: <03717f06-9818-0c2a-6625-429887c55a17@jguk.org> <6bad0ce4-667f-0705-fc40-c40c9e8dec8f@jguk.org> <20230215154936.GG25951@gate.crashing.org> From: Richard Earnshaw In-Reply-To: <20230215154936.GG25951@gate.crashing.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3488.1 required=5.0 tests=BAYES_00,BODY_8BITS,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 15/02/2023 15:49, Segher Boessenkool wrote: > On Wed, Feb 15, 2023 at 03:10:15PM +0000, Jonny Grant wrote: >> On 15/02/2023 14:30, Richard Earnshaw wrote: >>>> int main() >>>> { >>>>      __builtin_printf("file %s:%d", __FILE__, __LINE__); >>>> } > > Note that the format needs to end in "\n" if you want this to be > converted to a puts() call. Without it it strangely doesn't seem to > be optimised, although fprintf() is converted to fwrite() in such cases. > This could be done for printf() as well: you are guaranteed to have > access to stdout as well, at least if you use printf() instead of the > builtin (I'm not sure if we do then). Well it should do, but unless you've #included stdio.h (which you should have done, but not every program is 100% conforming) you might not have a definition of it and the compiler can't know how to magic up a correct definition of it for your system (c89 said that stdin/out/err are macros, so they might expand to almost anything - in freebsd, for example they expand to __stdp). > >>> I guess it might be possible to handle cases where all the arguments are constant, but even that has its problems, eg: >>> >>> - can we guarantee identical output to the platform printf? >> >> That's a good question. I was using __builtin_printf so that should be GCC I expect. > > Not every printf() implementation has exactly the same output in all > cases. > > Another practically important consideration is what it does to i18n. > You really need to leave the format string unmodified for that to be > able to work. > > > Segher R.