public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/64877] strange warning message from -Waddress Date: Sat, 31 Jan 2015 16:05:00 -0000 [thread overview] Message-ID: <bug-64877-4-YIJCZZ7G2k@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-64877-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64877 Manuel López-Ibáñez <manu at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2015-01-31 CC| |paolo.carlini at oracle dot com Version|unknown |5.0 Ever confirmed|0 |1 --- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Tom Tromey from comment #3) > Oops, had the wrong gcc in $PATH. > That test case does warn: > > pokyo. g++ -std=c++11 -c -Wall -Waddress -O2 x.cc > x.cc: In instantiation of ‘S<Derived>::S() [with Derived = T]’: > x.cc:19:8: required from here > x.cc:9:29: warning: the address of ‘void S<Derived>::Unwrap() [with Derived > = T]’ will never be NULL [-Waddress] > if (&S<Derived>::Unwrap != &Derived::Unwrap) > ^ > > > I think I would expect a warning on the second assert, but not the first. We hit this code in cp/typeck.c /* We generate: (op0.pfn == op1.pfn && (!op0.pfn || op0.delta == op1.delta)) The reason for the `!op0.pfn' bit is that a NULL pointer-to-member is any member with a zero PFN; the DELTA field is unspecified. */ e1 = cp_build_binary_op (location, EQ_EXPR, delta0, delta1, complain); e2 = cp_build_binary_op (location, EQ_EXPR, pfn0, build_zero_cst (TREE_TYPE (pfn0)), complain); e1 = cp_build_binary_op (location, TRUTH_ORIF_EXPR, e1, e2, complain); thus, the !op0.pfn triggers the warning. It may be enough to pass tf_none instead of complain for the two compiler-generated expressions. Alternatively, since we know pfn0 cannot be NULL, do not generate this check. It seems quite wasteful to go through the huge cp_build_binary_op just to build something that will get optimized out. Not working on this, but it seems feasible to fix. If it is a regression, you may even convince someone to approve it for GCC 5. >From gcc-bugs-return-475632-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jan 31 16:09:42 2015 Return-Path: <gcc-bugs-return-475632-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 10634 invoked by alias); 31 Jan 2015 16:09:42 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 10583 invoked by uid 48); 31 Jan 2015 16:09:37 -0000 From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/64877] strange warning message from -Waddress Date: Sat, 31 Jan 2015 16:09:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-64877-4-MbRtXqLjx8@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-64877-4@http.gcc.gnu.org/bugzilla/> References: <bug-64877-4@http.gcc.gnu.org/bugzilla/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-01/txt/msg03626.txt.bz2 Content-length: 1298 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64877 --- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- And just for the sake of completion, the warning we trigger is: else if (((code0 == POINTER_TYPE || TYPE_PTRDATAMEM_P (type0)) && null_ptr_cst_p (op1)) /* Handle, eg, (void*)0 (c++/43906), and more. */ || (code0 == POINTER_TYPE && TYPE_PTR_P (type1) && integer_zerop (op1))) { if (TYPE_PTR_P (type1)) result_type = composite_pointer_type (type0, type1, op0, op1, CPO_COMPARISON, complain); else result_type = type0; if (TREE_CODE (op0) == ADDR_EXPR B => && decl_with_nonnull_addr_p (TREE_OPERAND (op0, 0))) { if ((complain & tf_warning) && c_inhibit_evaluation_warnings == 0) warning (OPT_Waddress, "the address of %qD will never be NULL", TREE_OPERAND (op0, 0)); } } It could be enough to test decl_with_nonnull_addr_p (TREE_OPERAND (op0, 0)) to avoid building !op0.pfn when not needed. >From gcc-bugs-return-475633-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jan 31 16:14:53 2015 Return-Path: <gcc-bugs-return-475633-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 14253 invoked by alias); 31 Jan 2015 16:14:53 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 14208 invoked by uid 48); 31 Jan 2015 16:14:49 -0000 From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/64791] Generic lambda fails to implicitly capture `const` variable Date: Sat, 31 Jan 2015 16:14:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.9.2 X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: paolo.carlini at oracle dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-64791-4-m8y6JpzYMz@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-64791-4@http.gcc.gnu.org/bugzilla/> References: <bug-64791-4@http.gcc.gnu.org/bugzilla/> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-01/txt/msg03627.txt.bz2 Content-length: 387 https://gcc.gnu.org/bugzilla/show_bug.cgi?idd791 --- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> --- Weird, I tried on my machine yesterday's r220267 and same result, no warning (with -std=gnu++1z -Wall -Wextra). I guess that before closing this bug we need either to figure out what's special about that web page or another report that things are actually fine.
next prev parent reply other threads:[~2015-01-31 16:05 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-01-30 16:56 [Bug c++/64877] New: " tromey at gcc dot gnu.org 2015-01-30 18:16 ` [Bug c++/64877] " manu at gcc dot gnu.org 2015-01-30 18:38 ` tromey at gcc dot gnu.org 2015-01-31 16:05 ` manu at gcc dot gnu.org [this message] 2015-01-31 17:38 ` [Bug c++/64877] [5 Regression] " paolo.carlini at oracle dot com 2015-02-03 17:22 ` paolo at gcc dot gnu.org 2015-02-03 17:23 ` paolo.carlini at oracle dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-64877-4-YIJCZZ7G2k@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).