[Bug driver/31963] New: The configure option "--enable-stage1-checking" is undocumented (and incorrectly named)

[Bug driver/31963] New: The configure option "--enable-stage1-checking" is undocumented (and incorrectly named)

[rob1weld at aol dot com]

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

[Bug bootstrap/31963] The configure option "--enable-stage1-checking" is undocumented (and incorrectly named)

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-05-16 19:43 -------
> When I compile with "--enable-checking=?" the "checking" is performed on
> stages 2,3 and the libraries - it is NOT performed on stage 1.

I filed a bug about this while back and it was fixed, see PR 29544.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31963

[Bug bootstrap/31963] The configure option "--enable-stage1-checking" is undocumented (and incorrectly named)

[rob1weld at aol dot com]

------- Comment #2 from rob1weld at aol dot com  2007-05-18 03:54 -------
I just read 29544 (against 4.2.0) - as you would say: "what was your (x)gcc -v
?".

I used
"--enable-stage1-checking=assert,fold,gc,gcac,misc,rtl,rtlflag,runtime,tree"
and got these test results:
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00812.html


I create a log of the build using "make 2>&1 | tee made_1_log.txt" here is the
line from the log for the _same_ file you made (the file occurs 3 times):


Line 2361:

gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H -I. -I.
-I/root/downloads/gcc-4_2-branch/gcc -I/root/downloads/gcc-4_2-branch/gcc/.
-I/root/downloads/gcc-4_2-branch/gcc/../include -I./../intl
-I/root/downloads/gcc-4_2-branch/gcc/../libcpp/include 
-I/root/downloads/gcc-4_2-branch/gcc/../libdecnumber -I../libdecnumber   
/root/downloads/gcc-4_2-branch/gcc/tree-ssa.c -o tree-ssa.o


Line 5802:

/opt/gcc-4_2-build/./prev-gcc/xgcc -B/opt/gcc-4_2-build/./prev-gcc/
-B/usr/i686-pc-linux-gnu/bin/ -c   -O2 -g -fomit-frame-pointer -DIN_GCC   -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wmissing-format-attribute    -DHAVE_CONFIG_H -I. -I.
-I/root/downloads/gcc-4_2-branch/gcc -I/root/downloads/gcc-4_2-branch/gcc/.
-I/root/downloads/gcc-4_2-branch/gcc/../include -I./../intl
-I/root/downloads/gcc-4_2-branch/gcc/../libcpp/include 
-I/root/downloads/gcc-4_2-branch/gcc/../libdecnumber -I../libdecnumber   
/root/downloads/gcc-4_2-branch/gcc/tree-ssa.c -o tree-ssa.o


Line 9311 of my 'make log' is identical to Line 5802, so I won't repeat it.


If I type "# grep --color=always _CHECKING made_1_log.txt" I can only see
(shortened):

make "DESTDIR=" "RPATH_ENVVAR=LD_LIBRARY_PATH"
"TARGET_SUBDIR=i686-pc-linux-gnu" ...... "STAGE1_CFLAGS=-g
-fkeep-inline-functions"
"STAGE1_CHECKING=--enable-checking=assert,fold,gc,gcac,misc,rtl,rtlflag,runtime,tree"
"STAGE1_LANGUAGES=c,ada" ......

No place in the file does "-DENABLE_CHECKING -DENABLE_ASSERT_CHECKING" occur.


Despite the "mechanics of it" (how it _really_ should work) when I built it
yesterday stage1 was fast, stage2 was slow (but OK - especially since I used
EVERY checking (except valgrind)), and stage3 was fast - the libraries were
quick too. 

It took ~ 32 hours to build. Documented many bugs (which either have been or
will be filed). See URL above.


If I type this, I see:

#cd /opt/gcc-4_2-build
# grep -r --color=always ENABLE_CHECKING *    
gcc/Makefile:STAGE1_CHECKING_CFLAGS = -DENABLE_CHECKING
-DENABLE_ASSERT_CHECKING
gcc/auto-host.h:/* #undef ENABLE_CHECKING */
Binary file gcc/build/genconditions.o matches
Binary file gcc/build/genconditions matches
gcc/build/gencondmd.c:#undef ENABLE_CHECKING
Binary file gcc/build/genextract.o matches
Binary file gcc/build/genextract matches
gcc/insn-extract.c:#ifdef ENABLE_CHECKING


According to the above my "genconditions" and "genextract" execs have the text
fragment "ENABLE_CHECKING" in them. After 20 minutes of grep running I see
nothing else come up in my build directory. But it might have been overwritten.


Back in 4.1.1 the Makefile created directories that looked like this:
...
drwxr-xr-x+ 14 HP_Administrator None      0 May 13 16:09 stage1-gcc
drwxr-xr-x+  2 HP_Administrator None      0 May 13 15:46 stage1-intl
drwxr-xr-x+  4 HP_Administrator None      0 May 13 15:53 stage1-libcpp
drwxr-xr-x+  2 HP_Administrator None      0 May 13 15:54 stage1-libdecnumber
drwxr-xr-x+  3 HP_Administrator None      0 May 13 15:49 stage1-libiberty
drwxr-xr-x+  2 HP_Administrator None      0 May 13 15:52 stage1-zlib
drwxr-xr-x+ 14 HP_Administrator None      0 May 13 18:41 stage2-gcc
drwxr-xr-x+  2 HP_Administrator None      0 May 13 16:14 stage2-intl
drwxr-xr-x+  4 HP_Administrator None      0 May 13 16:52 stage2-libcpp
drwxr-xr-x+  2 HP_Administrator None      0 May 13 16:55 stage2-libdecnumber
drwxr-xr-x+  3 HP_Administrator None      0 May 13 16:41 stage2-libiberty
drwxr-xr-x+  2 HP_Administrator None      0 May 13 16:44 stage2-zlib
drwxr-xr-x+ 14 HP_Administrator None      0 May 13 21:43 stage3-gcc
drwxr-xr-x+  2 HP_Administrator None      0 May 13 18:45 stage3-intl
drwxr-xr-x+  4 HP_Administrator None      0 May 13 19:14 stage3-libcpp
drwxr-xr-x+  2 HP_Administrator None      0 May 13 19:18 stage3-libdecnumber
drwxr-xr-x+  3 HP_Administrator None      0 May 13 19:04 stage3-libiberty
drwxr-xr-x+  2 HP_Administrator None      0 May 16 21:50 stage3-zlib
-rw-r--r--   1 HP_Administrator None      7 May 14 19:53 stage_current
... (that is from 4.2.0 i686-pc-cygwin)


But, now, with 4.2.0 and 4.2.1 Linux builds create directories that look like:
...
drwxr-xr-x 14 root root   12288 May 16 18:15 prev-gcc
drwxr-xr-x  2 root root    1024 May 15 13:53 prev-i686-pc-linux-gnu
drwxr-xr-x  2 root root    1024 May 16 19:38 prev-intl
drwxr-xr-x  4 root root    1024 May 15 14:33 prev-libcpp
drwxr-xr-x  2 root root    1024 May 15 14:35 prev-libdecnumber
drwxr-xr-x  4 root root    2048 May 15 14:19 prev-libiberty
drwxr-xr-x  2 root root    1024 May 15 14:23 prev-zlib
-rwxr-xr-x  1 root root    8020 May 17 10:58 return_fl2.exe
-rw-r--r--  1 root root      13 May 15 12:56 serdep.tmp
drwxr-xr-x 14 root root   11264 May 15 13:53 stage1-gcc
drwxr-xr-x  2 root root    1024 May 15 12:56 stage1-i686-pc-linux-gnu
drwxr-xr-x  2 root root    1024 May 16 19:38 stage1-intl
drwxr-xr-x  4 root root    1024 May 15 13:01 stage1-libcpp
drwxr-xr-x  2 root root    1024 May 15 13:01 stage1-libdecnumber
drwxr-xr-x  4 root root    2048 May 15 12:59 stage1-libiberty
drwxr-xr-x  2 root root    1024 May 15 13:00 stage1-zlib
-rw-r--r--  1 root root       7 May 16 19:38 stage_current
...

Since we don't preserve each stage but instead overwrite it (on the
i686-pc-linux-gnu target) I don't have all my seperate stages so I can check
each one.

It _used_ to be a ./configure option to build "small" to save HD space but now
it seems that it is a default.

Since I _usually_ build for Cygwin and alter my Makefile by hand in accordance
with this procedure: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30341 I didn't
notice when the build changed from three _seperate_ stages (+ libs) to three
_overwriting_ stages (occupying 'two positions') (+ libs).

When I build for the target i686-pc-linux-gnu I simply type:
./run_configure.sh    (feeds my huge list of options to ./configure)
make

I don't edit the Makefile or fiddle with anything (that doesn't get a bug
report) - that way I can build GCC the way that many of the maintainers do and
"speak your language". It helps to see how it works on Linux to get my Cygwin
compiles working.


All I know is that stage 2 was slow and the rest was FAST.

I did save directory listings of each stage as it completed if you'd like to
view the build times for the files to verify that ONLY stage TWO was slow and
that all other portions built FAST.

Even if it is NOT supposed to work like that; it is GREAT because using
"--enable-checking=all" is NOT usable / practical.


To "really" get (pseudo) stage ONE checking would we need a FOUR stage build?
- First stage builds GCC using "-DENABLE_CHECKING -DENABLE_ASSERT_CHECKING"
- Second stage builds XGCC using the "checker-gcc" to create a "checking-xgcc"
- Third stage builds the rest of the languages (IE:
non-"STAGE1_LANGUAGES=c,ada")
- Fourth stage builds the final xgcc to create the ".compare" file and build
the ./i686-pc-linux-gnu/libraries


Whatever the situation is: confusion / problem / "correct operation, but
wrongly named" I am CERTAIN that stage2 builds SLOW, and the rest is FAST.

Next time I build for Linux (in a week or two) I will try the Cygwin Makefile
hack on the Linux build to preserve all the three seperate directories and then
I can check if it is fixed and where it breaks.

Do you want my "made_1_log.txt" it is 7 megs long.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31963

[Bug bootstrap/31963] The configure option "--enable-stage1-checking" is undocumented (and incorrectly named)

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2007-05-18 04:10 -------
I have no idea what you are talking about overwritting.  In 4.1 and before the
subdirectory gcc's makefile handled bootstrap (staging). In 4.2 and above, the
toplevel makefile handles bootstrap.  So that means we can configure the gcc
subdirectory differently for the two different stages which is exactly what
happens with --enable-stage1-checking=*.  When stage1 is configured, the
toplevel makefile passes down the --enable-checking=x for what
--enable-stage1-checking= says to do (defaults to yes).  So you will not see a
-DENABLE_CHECKING on the command line when compiling stage1 at all.  You will
see in stage1-gcc (when the build finishes if you don't use make
bootstrap-lean) in auto-host.h, a define for ENABLE_CHECKING.  This option is
really only useful for disable checking for stage1 when you are short on
resources (memory/time).

Plus configure is setup correctly to enable more checking for stage1.  Also
this is the help from configure:
choose additional checking for stage1 of the compiler.

Which is exactly what it does.  It means enable checking in the product of
stage1 (the stage1 compiler) which is a good description I think.  It means
compiling stage2 is going to be slower if you enable all checking for stage1.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31963

[Bug bootstrap/31963] The configure option "--enable-stage1-checking" is undocumented (and incorrectly named)

[rob1weld at aol dot com]

------- Comment #4 from rob1weld at aol dot com  2007-05-18 05:57 -------
>> ------- Comment #3 From Andrew Pinski 2007-05-18 04:10 [reply] ------- 
>> I have no idea what you are talking about overwritting. 

In the 4.1.1 AND 4.2.0/1 configure file we have:
--enable-bootstrap[=lean]     Enable bootstrapping [no]

In the 4.1.1 AND 4.2.0/1 gcc/doc/gccinstall.info file we have:
   If you are short on disk space you might consider `make
bootstrap-lean' instead.  This is identical to `make bootstrap' except
that object files from the stage1 and stage2 of the 3-stage bootstrap
of the compiler are deleted as soon as they are no longer needed.

The DOCs are the same but the way the stages build are different. See my "ls
-l" above. 


- The 4.1.1   Makefile _leaves_ all the stages _after_ the make is finished.
--- We end up with "stage1-gcc", "stage2-gcc" and "stage3-gcc" (and the other
directories).


- The 4.2.0/1 Makefile  _moves_ all the stages _after_ each stage - this is
"_similar_" to a "lean" bootstrap but instead of "rm" (deleting is the word
used in the info DOCs above) the stages are moved (overwrite the prior stage)
by shuffling the links.

--- We end up with "gcc", and "prev-gcc" (and the other directories) - We have
fewer directories - IE: no intermediates to examine.


>>>> ------- Comment #3 From Andrew Pinski 2007-05-18 04:10 [reply] ------- 
>> So that means we can configure the gcc subdirectory differently for the two different stages which is exactly what happens with --enable-stage1-checking=*.  When stage1 is configured, the toplevel makefile passes down the --enable-checking=x for what --enable-stage1-checking= says to do (defaults to yes).  So you will not see a -DENABLE_CHECKING on the command line when compiling stage1 at all.  You will see in stage1-gcc (when the build finishes if you don't use make bootstrap-lean) in auto-host.h, a define for ENABLE_CHECKING.  This option is really only useful for disable checking for stage1 when you are short on resources (memory/time).


I used "make" to make gcc - I saved the whole log of the make when I typed:
"make 2>&1 | tee made_1_log.txt"

I also saved "ls -l" 's  of each stage of the build to compare how long it took
to compile with the "--enable-stage1-checking=..." option fed _directly_ to
./configure and the "--enable-checking" option NOT given to ./configure .


When I previously used "--enable-checking" it took way too long, the worst part
was the libjava libraries (since they have PICs and use @lists).

I tried using "--enable-stage1-checking" instead of using "--enable-checking"
with _every_ possible check (except valgrind) - It was "quite fast".


>> ------- Comment #3 From Andrew Pinski 2007-05-18 04:10 [reply] ------- 
>> Plus configure is setup correctly to enable more checking for stage1.  Also
>> this is the help from configure:
>> choose additional checking for stage1 of the compiler.
>> 
>> Which is exactly what it does.  It means enable checking in the product of
>> stage1 (the stage1 compiler) which is a good description I think.  It means
>> compiling stage2 is going to be slower if you enable all checking for stage1.

When we use the command "./configure --enable-stage1-checking=all" we are
building the stage1 compiler with the operating system's gcc which (most
likely) was NOT compiled with "*-checking=all" -- _IF_ the OS's gcc compiler
_was_ compiled with checking then when we used the OS's gcc to compile we would
get additional checks made on the OS's gcc output (whether we configured the
SVN we are building to have checking or not).

If our OS has only gcc-3.3 installed and we want to build GCC 4.2.0/1 the
_first_ stage will not be built with the features available in gcc4.

When we make bootstrap and use "gcc/xgcc" during the _second_ (and subsequent)
stages we _DO_ use gcc4 and _if_ we turned on "the use of checking" then the
gcc built in stage1 (which then gets called gcc/xgcc in stage2) will build
stage TWO with checking - stage ONE is only built with checking _IF_ the OS's
gcc was built with checking (sometimes scoundrels build and release binaries
with --disable-checking).



So the stage ONE compiler we build has the ABILITY to check stage TWO (and
later stages depending if we use "--enable-checking" or
"--enable-stage1-checking" - but it does not have itself checked (there is no
stage ONE checking)


Similarly I can use gcc-3.3 to build GCC-5.0.0-branch (maybe) and I can build
gcc5 with every command line option and feature _supported_ by gcc3 - if I
configure GCC5 to use gomp the FIRST stage of GCC5 is not going to have gomp.

If I built GCC5 with GCC4 (and configured GCC4 using --enable-libgomp) then
stage ONE of GCC5 _could_ be built with gomp.


You say the DOCs say:
choose additional checking for stage1 of the compiler.

If I tell you "the FIRST time you come to my restraunt I will give you a free
meal" does that mean you need to come a second time to get the meal ?

If I tell you "the SECOND time you come to my restraunt I will give you a free
meal" does that mean you need to come a FIRST time prior to coming a SECOND
time - or can you just skip the first time and come the second time right away?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31963

[Bug bootstrap/31963] The configure option "--enable-stage1-checking" is undocumented (and incorrectly named)

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31963

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-28 02:46:48 UTC ---
Here is what the docs say about this option:
@item --disable-stage1-checking
@itemx --enable-stage1-checking
@itemx --enable-stage1-checking=@var{list}
If no @option{--enable-checking} option is specified the stage1
compiler will be built with @samp{yes} checking enabled, otherwise
the stage1 checking flags are the same as specified by
@option{--enable-checking}.  To build the stage1 compiler with
different checking options use @option{--enable-stage1-checking}.
The list of checking options is the same as for @option{--enable-checking}.
If your system is too slow or too small to bootstrap a released compiler
with checking for stage1 enabled, you can use @samp{--disable-stage1-checking}
to disable checking for the stage1 compiler.

--- CUT ---
Lets look at it a different way than using restaurants but rather offspring
since that is what is really happening here.

We have a parent (the current system GCC), a child (stage1), a grand-child
(stage2) and a great-grand-child (stage3).

Basically --enable-stage1-checking saying is the child a boy or a girl.
--enable-checking is saying is the grand-child and the great-grand-child a boy
or a girl.  Does this make sense now of why this option is named what is named?