From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 354613858439 for ; Tue, 19 Jul 2022 09:14:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 354613858439 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-662-rxRv4I28MkyZ0uAr2RC91A-1; Tue, 19 Jul 2022 05:14:28 -0400 X-MC-Unique: rxRv4I28MkyZ0uAr2RC91A-1 Received: by mail-wr1-f70.google.com with SMTP id k26-20020adfb35a000000b0021d6c3b9363so2371917wrd.1 for ; Tue, 19 Jul 2022 02:14:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=CQ4Bj99F/590w1UPNf3vJfd7Obpdkm8OoTkKd82mEHI=; b=IM1JPdif18Szhryzf9kbrT2/14s8dPtVIZU7oU2I82lHzPmfbfGUc2uI8eUDS6G2FN 4iQjhI//37c/JnbD+X8XyVNY3s2SDFtvYnFmGPFl3ZRVMNszq7vpF3AnCfj6fnwbFzfS lS7SGWPQtFOJejlycxqd85vVXZT5uHseMm0G0cv0vuMcKFz46vw7mERtK7QkuUuy9b6x cCFvpSTdogILYhXL1ZQd78mT0zT/C7HJZI0m2VDgEHPMHaeR9Dd5v9nDEUyIN1ejM198 KJ3S1IO3j/untdpgW6JgNjMiPENoGXqKKJCmnG8melwDAA/Gggc1TgcKms1g6HZTYUhr GOgQ== X-Gm-Message-State: AJIora9AvQ/QbfALYuqJ6j/5PC7dcNM7++CHPu/V2Vye12qofv/rWu0X i4ZGVXLCvy/6VKVM6FqJCAqXYLyNNIkCc0YPz27kqEXx0tDdXzk7U6e6uE4sLpopPVE4kuMEqXO MogZj9Et6u/y+VSRbY6PeQw== X-Received: by 2002:a5d:5887:0:b0:21d:bb2f:eee5 with SMTP id n7-20020a5d5887000000b0021dbb2feee5mr25766228wrf.288.1658222066938; Tue, 19 Jul 2022 02:14:26 -0700 (PDT) X-Google-Smtp-Source: AGRyM1squ15h813d4rxtqp+t2hTxhaGtWZbMcuLBIFlgwaTMDuDIhsEFTY5ddktOsjMnt39TUpKd5A== X-Received: by 2002:a5d:5887:0:b0:21d:bb2f:eee5 with SMTP id n7-20020a5d5887000000b0021dbb2feee5mr25766218wrf.288.1658222066730; Tue, 19 Jul 2022 02:14:26 -0700 (PDT) Received: from localhost (15.72.115.87.dyn.plus.net. [87.115.72.15]) by smtp.gmail.com with ESMTPSA id g5-20020a5d4885000000b0021dff3cf67asm7790107wrq.10.2022.07.19.02.14.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Jul 2022 02:14:26 -0700 (PDT) From: Andrew Burgess To: "Willgerodt, Felix" , Bruno Larsen , "gdb-patches@sourceware.org" Subject: RE: [PATCH 1/1] gdb, testsuite: Adapt gdb.base/callfuncs.exp for new clang warnings. In-Reply-To: References: <20220608071717.3953324-1-felix.willgerodt@intel.com> <871quisfs6.fsf@redhat.com> Date: Tue, 19 Jul 2022 10:14:25 +0100 Message-ID: <87lespqxam.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, 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 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2022 09:14:37 -0000 "Willgerodt, Felix via Gdb-patches" writes: >> -----Original Message----- >> From: Andrew Burgess >> Sent: Montag, 18. Juli 2022 15:37 >> To: Willgerodt, Felix ; Bruno Larsen >> ; gdb-patches@sourceware.org >> Subject: RE: [PATCH 1/1] gdb, testsuite: Adapt gdb.base/callfuncs.exp for >> new clang warnings. >> >> "Willgerodt, Felix via Gdb-patches" writes: >> >> >> -----Original Message----- >> >> From: Bruno Larsen >> >> Sent: Mittwoch, 8. Juni 2022 14:59 >> >> To: Willgerodt, Felix ; gdb- >> >> patches@sourceware.org >> >> Subject: Re: [PATCH 1/1] gdb, testsuite: Adapt gdb.base/callfuncs.exp for >> >> new clang warnings. >> >> >> >> >> >> On 6/8/22 04:17, Felix Willgerodt via Gdb-patches wrote: >> >> > This patch fixes two issues with callfuncs.exp, which are both related >> >> > to new Clang warnings: >> >> >> >> Hi Felix! >> >> >> >> Thanks for this! >> >> >> >> > >> >> > 1) Clang 15.0.0 added a new warning for deprecated non-prototype >> >> functions: >> >> > https://reviews.llvm.org/D122895 >> >> > Callfuncs.exp is impacted and won't run due to new warnings: >> >> > >> >> > callfuncs.c:339:5: warning: a function declaration without a prototype is >> >> > deprecated in all versions of C and is not supported in C2x >> >> > [-Wdeprecated-non-prototype] >> >> > int t_float_values (float_arg1, float_arg2) >> >> > >> >> > This patch disables those warnings with -Wno-deprecated-non- >> prototype. >> >> > Removing the test for deprecated syntax would also be an option. But I >> will >> >> > leave that for others to decide. >> >> >> >> I like your solution with -Wno-deprecated-non-prototype. >> >> >> >> I think it is important (at least for now) to keep this test, since we have to >> >> support very old setups. >> >> >> >> > >> >> > 2) The other new warnings are about comparing a define with floats and >> >> doubles: >> >> > >> >> > callfuncs.c:518:1: warning: floating-point comparison is always true; >> >> constant >> >> > cannot be represented exactly in type 'float' [-Wliteral-range] >> >> > DEF_FUNC_VALUES_3(fc, float, crealf, cimagf) >> >> > >> >> > This can be fixed by making the define a float. >> >> >> >> Genuine question, would this not cause a problem for the times where >> the >> >> parameters are doubles and DELTA is a float? If it isn't a problem, I'm fine >> >> with this. >> >> >> > >> > I was wondering about that as well, but it still passes with GCC, clang and >> Intel >> > compilers and there are no compiler warnings about it. >> > I couldn't really figure it out if it would actually a problem somewhere. I >> could only >> > test on linux x86 though. My best guess was, as it is the "smaller precision" >> the >> > compiler will do the right thing. >> >> Indeed, my understanding of type promotion is that the compiler will >> promote the float argument to double or long double as needed. >> >> But then, prior to this patch, when DELTA was just (0.001), and would be >> considered a double, I would have expected, in any comparison between a >> float and DELTA, for the float to be converted to double, so I don't >> really understand that part of the original patch. >> >> Thanks, >> Andrew > > Thanks for your input. > What I didn't quite realize when writing the patch, is that float literals without > suffix are of type double. I double checked the ISO C11 draft and it is mentioned > there as well. > > So to me this is likely a compiler bug. Or did I miss anything? I did wonder the same, but I don't claim to be an expert on language details. I don't have immediate access to clang 15, but it might be interesting to try and reduce the test program down to just that error/warning case, and see if the code makes sense. Thanks, Andrew