From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id 2A6573858D33 for ; Thu, 16 Feb 2023 13:47:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2A6573858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jguk.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jguk.org Received: by mail-wr1-x431.google.com with SMTP id a2so1899849wrd.6 for ; Thu, 16 Feb 2023 05:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id:from :to:cc:subject:date:message-id:reply-to; bh=A59nDS2GZ5nHJM/NEVyz3DpKI0aFExu2qnK+dPWM7HA=; b=giVrSwfuUfUcyhp3rtV5edXQzRylcWFOyIfeuvL+E8h91UVy3Ccr4APITbHZsU1HeE mD1FeoTQeHjVGCTROcmlNZLe7Kx3DLZiKkwyfLnGXDptZ8QlWFo268hiHCPdTvl5Gm9P A3CocnjleFM7noQPvdKKd+qug4Vm96mUyEG/PCik9skXkDaInYAYmrjkTU3pyFeEa0Zh RsnXTfQuzS4HQFYitmERI65wOgBjQASzt+QDUJdYpD9KqIOdVRVUUcwf46/wd66wGigA 5k/pJu6Kdh76cljvRBorp7QRNDj6XLtozHGgAPvTdu8CeKilapmCNE8liDrVdDwVhP9J Y5og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=A59nDS2GZ5nHJM/NEVyz3DpKI0aFExu2qnK+dPWM7HA=; b=ass9HYfesJ2Q2zfhJCLT9Ycl5YS5snsCTR2EFeBlA3Eht6nzU3SyvvdDvugN6ymvw9 7Aq9DW1OcoZU8nUZW80Kn0V2BGvhW/HCyDxiOz6G0K+pQNdin6HxMxrhusLAUMa3gZHb NBom3EMwuxoeB5GlmGWJD9mXpYb5IKnQagBd3e7K9tIGag3y6RqD80T+b8X1wcfCGEZY 2IQ+Ei5quFQ9CfL1kvY+EGCNXaQfFY4mV0M0RkOz+XUt45o/B0mj+iG3wDjnpc2kuInb BFtE0u6OYMyrQRVJBrj8uQt/t7+jTSyec8wP6msCVrs53lT3fvKmG7B3IZRQ4owp5pTZ 6MZg== X-Gm-Message-State: AO0yUKUBPI3Ee/YoFSYIh7NgThTw1i5Fjec51/b+DgsDNMDmZszNlHEI FYW9dn5NQghBXBqe6WtRmV1W9+5klNOqPRwo X-Google-Smtp-Source: AK7set90fvy40ptQgFKY8aeKMjXH5Uz8XO6zwSLhCXvkHhLeroRsBI+2T3OthP4bDY8FWhvR8800CA== X-Received: by 2002:a5d:6747:0:b0:2c5:9a0d:70a2 with SMTP id l7-20020a5d6747000000b002c59a0d70a2mr782366wrw.16.1676555235877; Thu, 16 Feb 2023 05:47:15 -0800 (PST) Received: from [192.168.0.12] (cpc87345-slou4-2-0-cust172.17-4.cable.virginm.net. [81.101.252.173]) by smtp.gmail.com with ESMTPSA id p5-20020adfce05000000b0027cb20605e3sm1549682wrn.105.2023.02.16.05.47.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Feb 2023 05:47:15 -0800 (PST) Message-ID: Date: Thu, 16 Feb 2023 13:47:14 +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 To: Richard Earnshaw , gcc-help References: <03717f06-9818-0c2a-6625-429887c55a17@jguk.org> <6bad0ce4-667f-0705-fc40-c40c9e8dec8f@jguk.org> <421dc812-63b4-29bf-f4cb-2eb312aab199@foss.arm.com> Content-Language: en-GB From: Jonny Grant In-Reply-To: <421dc812-63b4-29bf-f4cb-2eb312aab199@foss.arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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: On 15/02/2023 15:27, Richard Earnshaw wrote: > > > On 15/02/2023 15:10, Jonny Grant wrote: >> Thank you for your quick reply Richard. >> >> On 15/02/2023 14:30, Richard Earnshaw wrote: >>> >>> >>> On 15/02/2023 14:18, Jonny Grant wrote: >>>> Hi >>>> Has GCC considered an improvement to "compile out" from the builtin printf the strings? That being to change it to just be something like puts("file /app/example.cpp:4") >>>> I had a look, but couldn't find it being asked before. >>>> >>>> This is just a short example to demonstrate. >>>> It would be useful to see the exact string in the debugger "file /app/example.cpp:4", also it saves a few lines of asm. >>>> >>>> https://godbolt.org/z/aKz3o6aPd >>>> >>>> >>>> int main() >>>> { >>>>       __builtin_printf("file %s:%d", __FILE__, __LINE__); >>>> } >>>> >>>> >>>> .LC0: >>>>           .string "/app/example.cpp" >>>> .LC1: >>>>           .string "file %s:%d" >>>> main: >>>>           subq    $8, %rsp >>>>           movl    $4, %edx >>>>           movl    $.LC0, %esi >>>>           xorl    %eax, %eax >>>>           movl    $.LC1, %edi >>>>           call    printf >>>>           xorl    %eax, %eax >>>>           addq    $8, %rsp >>>>           ret >>> >>> We already do when the printf contains simply the format string and no additional arguments. >>> >>> 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. >> > > No, __builtin_printf is really just an internal hook that is used to handle optimisations of printf - if you look at your assembly output you'll see it is translated back to printf for the C library to handle. ok I see. I changed the example to take off the end "\n" and it goes back to printf (otherwise it is puts() ) https://godbolt.org/z/W46esaWKd > >>> - does it cause string bloat (what if there were 30 or so such statements in your program all identical except for the line number)? >> >> That's probably what I am expecting, to see those 30 different formatted strings. >> >>> - does it even happen often enough to be worth adding (and maintaining) support?  Nothing comes for free in a compiler and the optimisations have to be worth-while in the real world. >>> >>> R. >> >> You're completely right, it could bloat the file with strings. >> >> I can do some with multi-line literals, to get "file /app/example.cpp compiled Feb 15 2023" >> __FILE__ and __DATE__ worked ok. >> >> but it didn't like me putting __PRETTY_FUNCTION__ in the middle. Maybe I'm missing something obvious. Likewise I can't use __builtin_LINE() as that is a function rather than a string. Maybe __PRETTY_FUNCTION__ and __FUNCTION__ are calls to  __builtin_FUNCTION(). >> >> int main() >> { >>      const char * s = "file " \ >>          __FILE__ \ >>          " compiled " \ >>          __DATE__ \ >>          "\n"; >> >>      __builtin_printf("%s", s); >>      __builtin_printf("%s\n", __PRETTY_FUNCTION__);  // didn't work when I put in the middle. >> > > That's because __func__, __FUNCTION__ and __PRETTY_FUNCTION__ are not string literals but implicitly declared identifies containing a constant string literal as the initializer - you can't therefore combine them with string literals by simple concatenation.  See > > https://gcc.gnu.org/onlinedocs/gcc/Function-Names.html > > which clearly states this. > Ok, thank you for the link, I understand it wouldn't support simple concatenation of __func__ etc the way __DATE__ works. I remembered I could convert macro arguments in into a string constant. So could get the __LINE__ which is enough with the file name into one string with GCC. #define xto_str(s) to_str(s) #define to_str(s) #s int main() { const char * s = __FILE__ ":" xto_str(__LINE__); __builtin_printf(s); } .LC0: .string "/app/example.cpp:6" main: subq $8, %rsp movl $.LC0, %edi xorl %eax, %eax call printf xorl %eax, %eax addq $8, %rsp ret