public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rob1weld at aol dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug driver/31963] New: The configure option "--enable-stage1-checking" is undocumented (and incorrectly named) Date: Wed, 16 May 2007 18:37:00 -0000 [thread overview] Message-ID: <bug-31963-13830@http.gcc.gnu.org/bugzilla/> (raw) This bug report is listed for the HTB i686-pc-linux-gnu but actually affects ALL platforms. The reason I chose to put this under the "Component" choice "driver" is because there is no choice for "documentation" and it does involve renaming one of the compiler command line options. --- When I compile with "--enable-checking=?" the "checking" is performed on stages 2,3 and the libraries - it is NOT performed on stage 1. When I compile with "--enable-stage1-checking" the "checking" is performed on stage TWO only, and NOT on any other stages (or the libraries). To _actually_ check stage 1 you would need the Operating System's GCC to have been compiled using the checking options - otherwise stage 1 is never checked. Correct ? BUG 1): The configure option "--enable-stage1-checking" is named incorrectly. We need to change the configure script and make it a depreciated or obsoleted option and add an option that is instead called "--enable-stage2-checking" (does the same thing, just correct the name). BUG 2): The configure option "--enable-stage1-checking" (or "--enable-stage2-checking") is not documented. Using grep I find the word in these files: # grep -r stage1-checking gcc-4_2-branch/* gcc-4_2-branch/ChangeLog gcc-4_2-branch/autom4te.cache/output.0 gcc-4_2-branch/configure gcc-4_2-branch/configure.in The file "gccinstall.info" (and any .html DOCs) and the files that create them are the correct location to document this feature - directly under the notes for "--enable-checking". Suggestion 1): Use "--enable-stage2-checking" to enable a few more checks by default. The gccinstall.info file says this for the `--enable-checking' option: The full set of flags available are: "assert", "fold", "gc", "gcac" "misc", "rtl", "rtlflag", "runtime", "tree", and "valgrind". The "rtl", "gcac" and "valgrind" checks are very expensive. (NOTE: See below! "fold" is expensive - DOCs are wrong?) When building from SVN or snapshots we use "assert", "gc", "misc", "rtlflag", "runtime" and "tree". The release versions use only "assert" and "runtime". Thus, according to the DOCs (which do need updating), when we build the SVN we are not using: "fold", "gcac" "rtl", and "valgrind". I suggest that when building the SVN version we could use, (on all stages), the flags "--enable-checking=assert,misc,rtlflag,runtime,tree", and the additional flag (now called) "--enable-stage2-checking=fold,gc,rtl" for better, faster checking. Would we want to add "misc" and "rtlflag" to the release version checks ? The gcac (GC_ALWAYS_COLLECT) flag could probably be left off the list. The file, "gcc-4_2-branch\gcc\config.in" documents checking a little differently (and each type more thoroughly) than the file "gccinstall.info" does. ENABLE_ASSERT_CHECKING - "assert" /* Define if you want assertions enabled. This is a cheap check. */ ENABLE_CHECKING - "misc" /* Define if you want more run-time sanity checks. This one gets a grab bag of miscellaneous but relatively cheap checks. */ ENABLE_FOLD_CHECKING - "fold" /* Define if you want fold checked that it never destructs its argument. This is quite expensive. */ ENABLE_GC_ALWAYS_COLLECT - "gcac" /* Define if you want the garbage collector to operate in maximally paranoid mode, validating the entire heap and collecting garbage at every opportunity. This is extremely expensive. */ ENABLE_GC_CHECKING - "gc" /* Define if you want the garbage collector to do object poisoning and other memory allocation checks. This is quite expensive. */ ENABLE_RTL_CHECKING - "rtl" /* Define if you want all operations on RTL (the basic data structure of the optimizer and back end) to be checked for dynamic type safety at runtime. This is quite expensive. */ ENABLE_RTL_FLAG_CHECKING - "rtlflag" /* Define if you want RTL flag accesses to be checked against the RTL codes that are supported for each access macro. This is relatively cheap. */ ENABLE_RUNTIME_CHECKING - "runtime" /* Define if you want runtime assertions enabled. This is a cheap check. */ ENABLE_TREE_CHECKING - "tree" /* Define if you want all operations on trees (the basic data structure of the front ends) to be checked for dynamic type safety at runtime. This is moderately expensive. The tree browser debugging routines will also be enabled by this option. */ ENABLE_VALGRIND_CHECKING - "valgrind" /* Define if you want to run subprograms and generated programs through valgrind (a memory checker). This is extremely expensive. */ -- Summary: The configure option "--enable-stage1-checking" is undocumented (and incorrectly named) Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31963
next reply other threads:[~2007-05-16 18:37 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-05-16 18:37 rob1weld at aol dot com [this message] 2007-05-16 18:43 ` [Bug bootstrap/31963] " pinskia at gcc dot gnu dot org 2007-05-18 2:55 ` rob1weld at aol dot com 2007-05-18 3:10 ` pinskia at gcc dot gnu dot org 2007-05-18 4:57 ` rob1weld at aol 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-31963-13830@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).