public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "crrodriguez at opensuse dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/61371] cpp: Implement -fno-date-time/-freproducible-dates or similar Date: Fri, 30 May 2014 16:21:00 -0000 [thread overview] Message-ID: <bug-61371-4-FJOQzmQcaK@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-61371-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61371 --- Comment #6 from Cristian Rodríguez <crrodriguez at opensuse dot org> --- (In reply to Manuel López-Ibáñez from comment #5) > (In reply to Cristian Rodríguez from comment #2) > > It would be.. if there wasn't half a ton of packages using -Werror > > In fact, it was committed and the message tells you which option you have to > use to silence the warning: > > manuel@gcc10:~$ ~/test1/210581/build/gcc/cc1 -D__DATE__='bla' test.c -Werror > <command-line>:0:0: error: "__DATE__" redefined > [-Werror=builtin-macro-redefined] > > manuel@gcc10:~$ ~/test1/210581/build/gcc/cc1 -D__DATE__='bla' test.c -Werror > -Wno-error=builtin-macro-redefined > <command-line>:0:0: warning: "__DATE__" redefined [-Wbuiltin-macro-redefined] > > manuel@gcc10:~$ ~/test1/210581/build/gcc/cc1 -D__DATE__='bla' test.c -Werror > -Wno-builtin-macro-redefined > > > Isn't this what you want? -Wno-builtin-macro-redefined silences redefinitions of __FILE__, and __BASE_FILE__.. >From gcc-bugs-return-452877-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 30 16:40:48 2014 Return-Path: <gcc-bugs-return-452877-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 17166 invoked by alias); 30 May 2014 16:40:47 -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 17144 invoked by uid 48); 30 May 2014 16:40:44 -0000 From: "scovich at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/61372] New: Add warning to detect noexcept functions that might throw Date: Fri, 30 May 2014 16:40:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: scovich at gmail dot com X-Bugzilla-Status: UNCONFIRMED 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter Message-ID: <bug-61372-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: 2014-05/txt/msg02569.txt.bz2 Content-length: 5286 https://gcc.gnu.org/bugzilla/show_bug.cgi?ida372 Bug ID: 61372 Summary: Add warning to detect noexcept functions that might throw Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: scovich at gmail dot com The C++11 standard adds the "noexcept" specification that lets the programmer assert that a function does not throw any exceptions (terminating execution if that assertion ever turns out to be false at runtime). Unfortunately, there is currently no reliable way for a programmer to validate, at compile time, her assertion that a function does or does not throw. The closest thing is -Wnoexcept, which detects the (very narrow) case where the following all apply to some function F: 1. F lacks the noexcept declaration or has declared noexcept(false) 2. The compiler has determined that F cannot throw 3. F causes some noexcept operator to evaluate to false Unfortunately, that narrow formulation makes it really hard to validate much of anything (see example and further discussion below). It would be very helpful to have a warning flag which tells the compiler to report cases where a function's noexcept specification contradicts the compiler's analysis of the function body. Perhaps -Wnoexcept-mismatch={1,2,3}? 1 (high priority): functions declared noexcept(true) but which contain expressions that might throw. This validates stated noexcept assumptions, helping to avoid issues like PR #56166. 2 (medium priority): Also report functions declared noexcept(false) that in fact cannot throw (e.g. cases #1 and #2 for -Wnoexcept). This improves the accuracy of noexcept validation, and also improves performance in general (by eliminating unwind handlers). And makes it easier to avoid/fix things like PR #52562. 3 (low priority): Also report functions which lack any noexcept declaration but which cannot throw (similar to -Wsuggest-attribute for const, pure, etc.). This also improves accuracy of noexcept, but the programmer would have to decide whether to make the API change (marking the function noexcept) or whether it's important to retain the ability to throw in the future. Probably none of the above warnings should be enabled by default, but it might make sense to enable -Wnoexcept-mismatch=1 with -Wall and -Wnoexcept-mismatch=2 with -Wextra. To implement the warning, the compiler would make a pass over each function body (after applying most optimizations, especially inlining and dead code elimination). It would then infer a noexcept value by examining all function calls that remain, and compare that result with the function's actual noexcept specification (or lack thereof). No need for any kind of IPA: if a callee lies about its noexcept status, it's the callee's problem. ==========================Workaround using -Wnoexcept ========================== One might try to combine static_assert with noexcept, e.g: // example.cpp //////////////// void might_throw(int); // lacks noexcept void also_might_throw(); // lacks noexcept void never_throw(int a) noexcept(noexcept(might_throw(a)) && noexcept(also_might_throw())) { if (a) might_throw(a); also_might_throw(); } void foo(int a) noexcept(noexcept(might_throw(a))) { might_throw(a); } static_assert(noexcept(foo(0)), "never_throw might throw"); //////////////////////////////// There are two glaring problems with that approach, however: 1. Every expression in the function body must be part of the noexcept clause, effectively replicating the function body in its signature (but without the ability to declare local variables). - Maintaining the noexcept chain across code changes would be tedious and error-prone for all but the smallest and most stable functions (= ie the ones least in need of verification). - Operator overloading means you can't even assume basic expressions like a+b are nothrow. To get complete coverage would require either a very careful analysis (error prone) or cracking the entire function body into an AST atomic expressions (tedious *and* error prone). - Macro expansions would add even more headaches, because they may expand to more than one statement and/or include control flow. 2. The static_assert must choose one set of inputs for each function call it passes to operator noexcept. - An optimizer (especially after inlining and constant propagation) could conceivably report that the function is noexcept for that particular input, when in fact other inputs exist that could cause an exception to be thrown (this does not seem to be the case currently). - There may not be any easy way to come up with a valid input (objects that lack a default constructor, etc.). Using hacks like (*(T*)0) would violate all sorts of compiler/optimizer assumptions and risks breaking the analysis. Another possibility would be to embed multiple static_assert in the function to verify noexcept status for every line of code. That would at least allow to use existing local variables, and resolve most of issue #2, but issue #1 remains. Code readability would take quite a hit, too.
next prev parent reply other threads:[~2014-05-30 16:21 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-61371-4@http.gcc.gnu.org/bugzilla/> 2014-05-30 15:58 ` manu at gcc dot gnu.org 2014-05-30 16:02 ` manu at gcc dot gnu.org 2014-05-30 16:21 ` crrodriguez at opensuse dot org [this message] 2014-06-02 8:16 ` rguenth at gcc dot gnu.org
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-61371-4-FJOQzmQcaK@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).