From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id BEC723858D35 for ; Wed, 15 Feb 2023 15:10:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BEC723858D35 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-wm1-x32b.google.com with SMTP id n33so7553280wms.0 for ; Wed, 15 Feb 2023 07:10:18 -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:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=mBUBOfA/U3xB0yQ6NB1Ds3kkCGYHL0hZ9H5iqJ5EZtw=; b=FFPkmbPB717xaOI6x9z+75TyD53i9mQyRJCTRuQUpecz5JaC0JAayo3NCYQ9hPnivd doKesLa1sqEn9iuFMiiQn/n/EFEGsalw2h32mc+Nhjh9apuRU51KjtSh4VoYSGZoyBdF vp9jdkk7QTDdVrCJQfgbTGEYAv75QbGu5KC2blDJfRM2FSHH9DRwbkLGu6onfBqseErG y3OHAVe9eFPXEMxcsGAnyr5b+won3woyy6Bx/7mLRzTocNXGxrVvweE+3zc+7QXK3Lmz w3DvRxjy3bTj1ysQSMydcR7nS10LaePOup0YRpvfXIrnwaZc1t/AUc1T3PKxNlnXSTgJ +l6A== 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:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mBUBOfA/U3xB0yQ6NB1Ds3kkCGYHL0hZ9H5iqJ5EZtw=; b=ywbrlH3OIqlb20cyvfVpC5icbMPNdncDlcRYtuDk2m9Ie3CiG4tZlh9seEKsTZuJWx wOqG7RuxhtGvxeMWlKVSZAwb6poUQEXKM/jbngLTajgBLLgh5HgKZn9Vp0LYGTmzdhdp FEXloddE/0Zi5ujQWCn04RCnL6FVzdmlhmMDZ7I8hXjWc6QKxF+qmXAL3TmL1IgsUfgU g1EPRY4QCwI+wfKBDBGpYt7S90bGdvevZ/FX0czycB5XlEJH+T6vnlcyMUS30YDejk6Q S0WENsjEfZZz8sMGMhn7G1D+YJHBNnlRTgf2ssSx0tGcpfUycMvab925GW7oJl705BIs a6YQ== X-Gm-Message-State: AO0yUKVLUZqqr/qJw9G74TurdOB1jZ4HRKxHiriJTCTmHwQtSsnGB0l8 IsEB5SlNf4TWkb0KH9oMbH1z5w== X-Google-Smtp-Source: AK7set/4tO6mDA741XldybHnbHLCurTZvpSZbICq4Ho/zvSs7BNQDDNPG+gwjGAoiJDTfp4EzWiiIg== X-Received: by 2002:a05:600c:331b:b0:3e2:6c6:31ae with SMTP id q27-20020a05600c331b00b003e206c631aemr716169wmp.20.1676473816793; Wed, 15 Feb 2023 07:10:16 -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 o3-20020a05600c510300b003e2059c7978sm2089134wms.36.2023.02.15.07.10.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Feb 2023 07:10:16 -0800 (PST) Message-ID: <6bad0ce4-667f-0705-fc40-c40c9e8dec8f@jguk.org> Date: Wed, 15 Feb 2023 15:10:15 +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: Richard Earnshaw , gcc-help References: <03717f06-9818-0c2a-6625-429887c55a17@jguk.org> From: Jonny Grant In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: 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. > - 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. https://godbolt.org/z/xso9soWaf Regards Jonny