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


             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: link
Be 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).