From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id 28ABE385C41F for ; Thu, 29 Jul 2021 08:26:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 28ABE385C41F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-wr1-x436.google.com with SMTP id d8so5835156wrm.4 for ; Thu, 29 Jul 2021 01:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=W1itAHNSYO52Hwb9svLyJeUvLuNFm4XsxY2qIZOxf2E=; b=RVauuuI7+P5JoWagXLorqZ03oTcQWdJezvRpWN98diIVxUjWAYun2OoHcjc4lDDyEm MWd6sYmU0z1srmwWVxctSMSy8tluKe/sryQvcMIKFwe4Hq71HgfkJ5ReiJ40ySVngBMv pVWjdObkGxPdi2PaHD3YTNMgFt/KZ1TK4m/l3hnQk+lcDsvEcKwhUStjP6QZ7DGGxBhg xIg9yCGrM3RpsPph5OBYsKoZLUHAKGvSPi5r/Vkt/2gcow/Z9EDyYVqBheiyemfdBBOv IWIbG8nB8gMSQs/B+98HQQ3v9ndoiaivFvH/MWtOj9wAh31JMtKxddRDgUWVV4h/ho63 HhhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=W1itAHNSYO52Hwb9svLyJeUvLuNFm4XsxY2qIZOxf2E=; b=aXAs+UeUJZvMBHkhiEpx1D4jgQoSBzUuesUfrM9Zl+bnjehPfzBe1DkohY57LjGm7O IoX8AXGP8SVVEg7HG99ysPPCPZXoWx7jeBUGDW3Ekd7Ht5dFqisnu21Z2UhIaargRVt6 L/GCPjBQUBh5hQ95Wo7OpJVy0YuIiEgzT9Bp9oi5FW4q4/sHeSykCsEO4j/WokGx5cwZ lwGUQFn3SWapcWXGAh5sTNIczQmGzOW7oKpT3whRNoG5AP7+jv5bbNuJNDjsP/p7Z/SV n1BYGVOnz4MZ/YCfCgIKFjTgOL3+1SLc7Z/UkU2mr0TkongfZXG2jG2aQ74m0ZudYLg6 2+qg== X-Gm-Message-State: AOAM532FpgbqQkYTucAakn0QkA9T+ZWJ2Dnw2h09AaYxauAWRokwRTIC wWemqpTR38QrGH14RJGMuzAnHA== X-Google-Smtp-Source: ABdhPJxty9TMNOdhiY4WjCd8AvDyMsIT+afz61TzAkVhwK589VeXVYJk3KGyK830lizQfh5uToKWqA== X-Received: by 2002:a5d:444e:: with SMTP id x14mr3421813wrr.385.1627547191100; Thu, 29 Jul 2021 01:26:31 -0700 (PDT) Received: from localhost (host86-161-16-194.range86-161.btcentralplus.com. [86.161.16.194]) by smtp.gmail.com with ESMTPSA id a8sm2439382wmj.8.2021.07.29.01.26.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 29 Jul 2021 01:26:30 -0700 (PDT) Date: Thu, 29 Jul 2021 09:26:29 +0100 From: Andrew Burgess To: Martin Sebor Cc: Jan-Benedict Glaw , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 0/13] v2 warning control by group and location (PR 74765) Message-ID: <20210729082629.GB2037754@embecosm.com> References: <92db3776-af59-fa20-483b-aa67b17d0751@gmail.com> <47d06c821a53f5bd2246f0fca2c9a693bff6b882.camel@redhat.com> <3a5ea83c-0d91-d123-f537-f8f1223df890@gmail.com> <20210717203641.dywmatkfj5gwon6u@lug-owl.de> <20210728111411.GA2037754@embecosm.com> <04d6b95a-2dcb-b8c2-3899-5ab48199534c@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04d6b95a-2dcb-b8c2-3899-5ab48199534c@gmail.com> X-Operating-System: Linux/5.8.18-100.fc31.x86_64 (x86_64) X-Uptime: 09:24:32 up 1 day, 14:31, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_ASCII_DIVIDERS, KAM_SHORT, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 08:26:34 -0000 * Martin Sebor [2021-07-28 10:16:59 -0600]: > On 7/28/21 5:14 AM, Andrew Burgess wrote: > > * Martin Sebor via Gcc-patches [2021-07-19 09:08:35 -0600]: > > > > > On 7/17/21 2:36 PM, Jan-Benedict Glaw wrote: > > > > Hi Martin! > > > > > > > > On Fri, 2021-06-04 15:27:04 -0600, Martin Sebor wrote: > > > > > This is a revised patch series to add warning control by group and > > > > > location, updated based on feedback on the initial series. > > > > [...] > > > > > > > > My automated checking (in this case: Using Debian's "gcc-snapshot" > > > > package) indicates that between versions 1:20210527-1 and > > > > 1:20210630-1, building GDB breaks. Your patch is a likely candidate. > > > > It's a case where a method asks for a nonnull argument and later on > > > > checks for NULLness again. The build log is currently available at > > > > (http://wolf.lug-owl.de:8080/jobs/gdb-vax-linux/5), though obviously > > > > breaks for any target: > > > > > > > > configure --target=vax-linux --prefix=/tmp/gdb-vax-linux > > > > make all-gdb > > > > > > > > [...] > > > > [all 2021-07-16 19:19:25] CXX compile/compile.o > > > > [all 2021-07-16 19:19:30] In file included from ./../gdbsupport/common-defs.h:126, > > > > [all 2021-07-16 19:19:30] from ./defs.h:28, > > > > [all 2021-07-16 19:19:30] from compile/compile.c:20: > > > > [all 2021-07-16 19:19:30] ./../gdbsupport/gdb_unlinker.h: In constructor 'gdb::unlinker::unlinker(const char*)': > > > > [all 2021-07-16 19:19:30] ./../gdbsupport/gdb_assert.h:35:4: error: 'nonnull' argument 'filename' compared to NULL [-Werror=nonnull-compare] > > > > [all 2021-07-16 19:19:30] 35 | ((void) ((expr) ? 0 : \ > > > > [all 2021-07-16 19:19:30] | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > [all 2021-07-16 19:19:30] 36 | (gdb_assert_fail (#expr, __FILE__, __LINE__, FUNCTION_NAME), 0))) > > > > [all 2021-07-16 19:19:30] | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > [all 2021-07-16 19:19:30] ./../gdbsupport/gdb_unlinker.h:38:5: note: in expansion of macro 'gdb_assert' > > > > [all 2021-07-16 19:19:30] 38 | gdb_assert (filename != NULL); > > > > [all 2021-07-16 19:19:30] | ^~~~~~~~~~ > > > > [all 2021-07-16 19:19:31] cc1plus: all warnings being treated as errors > > > > [all 2021-07-16 19:19:31] make[1]: *** [Makefile:1641: compile/compile.o] Error 1 > > > > [all 2021-07-16 19:19:31] make[1]: Leaving directory '/var/lib/laminar/run/gdb-vax-linux/5/binutils-gdb/gdb' > > > > [all 2021-07-16 19:19:31] make: *** [Makefile:11410: all-gdb] Error 2 > > > > > > > > > > > > Code is this: > > > > > > > > 31 class unlinker > > > > 32 { > > > > 33 public: > > > > 34 > > > > 35 unlinker (const char *filename) ATTRIBUTE_NONNULL (2) > > > > 36 : m_filename (filename) > > > > 37 { > > > > 38 gdb_assert (filename != NULL); > > > > 39 } > > > > > > > > I'm quite undecided whether this is bad behavior of GCC or bad coding > > > > style in Binutils/GDB, or both. > > > > > > A warning should be expected in this case. Before the recent GCC > > > change it was inadvertently suppressed in gdb_assert macros by its > > > operand being enclosed in parentheses. > > > > This issue was just posted to the GDB list, and I wanted to clarify my > > understanding a bit. > > > > I believe that (at least by default) adding the nonnull attribute > > allows GCC to assume (in the above case) that filename will not be > > NULL and generate code accordingly. > > > > Additionally, passing an explicit NULL (i.e. 'unlinker obj (NULL)') > > would cause a compile time error. > > > > But, there's nothing to actually stop a NULL being passed due to, say, > > a logic bug in the program. So, something like this would compile > > fine: > > > > extern const char *ptr; > > unlinker obj (ptr); > > > > And in a separate compilation unit: > > > > const char *ptr = NULL; > > > > Obviously, the run time behaviour of such a program would be > > undefined. > > > > Given the above then, it doesn't seem crazy to want to do something > > like the above, that is, add an assert to catch a logic bug in the > > program. > > > > Is there an approved mechanism through which I can tell GCC that I > > really do want to do a comparison to NULL, without any warning, and > > without the check being optimised out? > Thanks for your feedback. > The manual says -fno-delete-null-pointer-checks is supposed to > prevent the removal of the null function argument test so I'd > expect adding attribute optimize ("no-delete-null-pointer-checks") > to the definition of the function to have that effect but in my > testing it didn't work (and didn't give a warning for the two > attributes on the same declarataion). That seems worth filing > a bug for. I've since been pointed at this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100404 Comment #3 of which discusses exactly this issue. Thanks, Andrew