path: root/open_issues/gcc.mdwn

[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013 Free
Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_gcc]]

Here's what's to be done for maintaining GCC.

Apart from the target-specific configuration machinery, there shouldn't be any
major differences within GCC between the GNU/Hurd and GNU/Linux ports, for
example.  Especially all the compiler magic is all the same.

[[!toc levels=2]]


# [[General information|/gcc]]


# [[Sources|source_repositories/gcc]]


# Configuration

<!--

git checkout reviewed
git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..upstream/trunk
-i
/^commit |^merge:|^---$|hurd|linux|nacl|nptl|glibc|gs:

-->

Last reviewed up to the [[Git mirror's 71cfadefb994de9249449fb7e71be012b6264a3f
(2013-02-17) sources|source_repositories/gcc]].

<http://gcc.gnu.org/install/configure.html> has documentation for the
`configure` switches.

  * Configure fragments that have `*linux*` cases might/should often contain
    those for us (and GNU/k*BSD) as well.

      * `configure.ac`

      * `libgomp/configure.tgt`

      * `libstdc++-v3/configure.host`

        `abi_baseline_pair` etc. setting.

      * `libstdc++-v3/config/os/gnu-linux/*`

        Is used for all GNU systems, as per `libstdc++-v3/configure.host`.
        Should rename to `gnu-user` to reflect this?

      * `gcc/acinclude.m4`:`gcc_GAS_FLAGS`: always pass `--32` to assembler for
        x86 Linux.  (Why?)

  * `hurd/usr`

    `NATIVE_SYSTEM_HEADER_DIR`, `638454a19c1c08f01c10517bc72a114250fc4f33`,
    [[!message-id "mcrzkhcbftp.fsf@coign.corp.google.com"]].

    Debian.

      * Eventually: get rid of this special-casing.  [[!message-id
        "gckk1s$e0b$1@ger.gmane.org"]].

  * [[`libmudflap`|libmudflap]].

  * [`-fsplit-stack`](http://nickclifton.livejournal.com/6889.html)

      * Also see `libgcc/config/i386/morestack.S`: comments w.r.t
        `TARGET_THREAD_SPLIT_STACK_OFFSET`/`%gs:0x30` usage; likely needs
        porting.

      * As per `libgcc/config/i386/t-stack-i386`, the former file is only used
        for `-fsplit-stack` support -- which is currently enabled for us in
        `libgcc/config.host`.

      * `gcc/config/gnu-user.h` defines `*SPLIT_STACK*` macros -- which aren't
        valid for us (yet), I think.

      * Might `-fsplit-stack` be useful for us with respect to our
        [[multithreaded|multithreading]] libraries?

  * `--enable-languages=[...]`

      * [[Ada (GNAT)|GNAT]] support is work in progress.

      * The [[Google Go's libgo|gccgo]] (introduced in
        e440a3286bc89368b8d3a8fd6accd47191790bf2 (2010-12-03)) needs
        OS configuration / support.

  * `--enable-frame-pointer`

    `gcc/configure.ac`: `enable_frame_pointer=no`

  * `--with-dwarf2`?

  * `--enable-werror`

  * `--enable-checking`

  * `--enable-linker-build-id`

  * `--enable-gnu-unique-object`

  * `--enable-lto`

  * `--enable-indirect-function`

    [[IFUNC]]

  * <http://gcc.gnu.org/ml/gcc/2007-11/msg00289.html>,
    <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00672.html>

      * `gcc/config/t-linux` should be named `gcc/config/t-gnu-user` or
        similar.  Likewise for `gcc/config/i386/t-linux`.

  * Debian's GCC package has Hurd-specific patches.  Some have been forwarded
    upstream (and have been ignored).  [[Thomas_Schwinge|tschwinge]] is working
    on getting them integrated.

  * [\[meta-bug\] bootstrap bugs for
    \*-gnu\*](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824)

  * [build system: gcc\_cv\_libc\_provides\_ssp and
    NATIVE\_SYSTEM\_HEADER\_DIR](http://gcc.gnu.org/ml/gcc/2008-10/msg00130.html)

  * [-fstack-protector shouldn't use TLS in freestanding
    mode](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838)

      * See also commit bf1c0af128f33bd342636c4afeaa8f3a8a7cf8ca (reverted in
        commit a204f0622242865ffea889bd698bc7c7bd236bd1), commit
        05c1aa95e6c37b3b281d749c76c673392941a031.

  * Check before/after Joseph changes.  (Should be fine.)

  * 34618b3190c110b8926cc2b1db4b4eac95451995 »config-list.mk«

    What's this used for?  (Check ML.)  Ask to include i686-pc-gnu (once it is
    buildable out of the box)?  See also
    73905b5de0d9a086f22ded7638bb1c0ae1b91326.

  * Various testsuite bits should include `*-*-gnu*`, too.

  * [low] [[toolchain/cross-gnu]] toolchain bootstrap vs. `fenv.h` in libgcc's
    libbid:

        [...]/xgcc [...] -DIN_LIBGCC2 -fbuilding-libgcc [...] -Dinhibit_libc [...] -o bid_decimal_globals.o [...] -c [...]/libgcc/config/libbid/bid_decimal_globals.c
        [...]/libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h: No such file or directory
        compilation terminated.
        make[1]: *** [bid_decimal_globals.o] Error 1
        make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/i686-pc-gnu/libgcc'
        make: *** [all-target-libgcc] Error 2

    See threads at [[!message-id
    "AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]],
    [[!message-id "20110328225532.GE5293@synopsys.com"]], [[!message-id
    "4D52D522.1040804@gmail.com"]].  Can simply configure the first GCC with
    `--disable-decimal-float`.

    Alternatively, can we use `#ifndef inhibit_libc` for this (these?) file(s)?
    See `generic-nonstrack.c`, for example.  The latter (and also
    `generic-morestack-thread.c`) also has a nice explanation of `inhibit_libc`
    which could be centralized at one place, for example definition of
    `inhibit_libc`.

  * [low] [[toolchain/cross-gnu]]

        The directory that should contain system headers does not exist:
          /media/boole-data/thomas/tmp/gnu-0/sys_root/usr/include
        make[2]: *** [stmp-fixinc] Error 1
        make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/gcc'
        make[1]: *** [all-gcc] Error 2
        make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj'

    `mkdir` the directory for now, but what is really going on?  GCC has *use
    `/usr/include` patch*, but glibc still installs into `/include/`?

  * `__GLIBC__`

    IRC, freenode, #hurd, 2012-01-05:

        <civodul> on GNU/kFreeBSD, it's GCC that defines __GLIBC__, funny
        <youpi> ??
        <youpi> not from features.h ?
        <civodul> in gcc/config/kfreebsd-gnu.h
        <civodul> :-)
        <pinotree> correct, it's enabled in gcc's config
        <pinotree> i discovered that after banging my head on the wall trying
          to find out why some stuff wasn't compiling even after kfreebsd
          porting patches adding preprocessors checks for __GLIBC__

    GNU/kFreeBSD and GNU/kNetBSD: commit
    6396cc37141180db4d2c8f73cab4f5977d8a1e19 (2004-06-24, r83577),
    GNU/kOpenSolaris: commit 3bef40126fb1633018fce47828df0fa9f65f110c
    (2009-01-29, r143768).  See also GDB commits
    fda1b24c62843f81d31de2af57b1ed9c55f1e348 and
    1acb4f4ff73d20850a7524fc939d2651be75f47b, and binutils commits
    e3081899be7570eb90ccfd5d767950d3a62871ee,
    127c4d4a4fe65bd17ea64db1be7f3c93d393afcb,
    47dbf5b634b955c2db1221715d15751e1281546a, and
    ad2be7e8b846f4cd67fa1e032f98d5dc1cdb6b8d.

    IRC, freenode, #hurd, 2012-05-25:

        <gnu_srs> Hi, looks like __GLIBC__ is not defined by default for GNU?
        <gnu_srs> touch foo.h; cpp -dM foo.h|grep LIBC: empty
        <braunr> gnu_srs: well, this only tells your the compiler defaults
        <tschwinge> gnu_srs: See the email I just sent.

    [[!message-id "87396od3ej.fsf@schwinge.name"]]

        <braunr> __GLIBC__ would probably be introduced by a glibc header
        <gnu_srs> tschwinge: I saw your email. I wonder if features.h is
          included in the kFreeBSD build of webkit.
        <gnu_srs> It is defined in their build, but not in the Hurd build.
        <pinotree> gcc on kfreebsd unconditionally defines __GLIBC__
        <pinotree> (a bit stupid choice imho, but hardly something that could
          be changed now...)
        <braunr> :/
        <braunr> personally i don't consider this only "a bit" stupid, as
          kfreebsd is one of the various efforts pushing towards portability
        <braunr> and using such hacks actually hinders portability ...
        <pinotree> yeah don't tell me, i can remember at least half dozen of
          occasions when a code wouldn't have been compiling at all on other
          glibc platforms otherwise
        <pinotree> sure, i have nothing against kfreebsd's efforts, but making
          gcc define something which is proper of the libc used is stupid
        <braunr> it is
        <pinotree> i spotted changes like:
        <pinotree> -#ifdef __linux
        <pinotree> +#if defined(__linux__) || defined(__GLIBC__)
        <pinotree> and wondered why they wouldn't work at all for us... and
          then realized there were no #include in that file before that
          preprocessor check
        <tschwinge> This is even in upstream GCC gcc/config/kfreebsd-gnu.h:
        <tschwinge> #define GNU_USER_TARGET_OS_CPP_BUILTINS()               \
        <tschwinge>   do                                            \
        <tschwinge>     {                                           \
        <tschwinge>         builtin_define ("__FreeBSD_kernel__");  \
        <tschwinge>         builtin_define ("__GLIBC__");           \
        <tschwinge>         builtin_define_std ("unix");            \
        <tschwinge>         builtin_assert ("system=unix");         \
        <tschwinge>         builtin_assert ("system=posix");        \
        <tschwinge>     }                                           \
        <tschwinge>   while (0)
        <tschwinge> I might raise this upstream at some point.
        <pinotree> tschwinge: i could guess the change was proposed by the
          kfreebsd people, so asking them before at d-bsd@d.o would be a start
        <tschwinge> pinotree: Ack.
        <pinotree> especially that they would need to fix stuff afterwards
        <pinotree> imho we could propose them the change, and if they agree put
          that as local patch to debian's gcc4.6/.7 after wheezy, so there is
          plenty of time for them to fix stuff
        <pinotree> what should be done first is, however, find out why that
          define has been added to gcc

    [[!message-id "201211061305.02565.pino@debian.org"]].

  * [low] Does `-mcpu=native` etc. work?  (For example,
    2ae1f0cc764e998bfc684d662aba0497e8723e52.)

  * transactional memory, 4c0315d05fa0f707875686abc4f91f7a979a7c7b

      * `config/mmap.m4`

      * In `libitm/config/`, is the generic stuff (`tls.h`, etc.) enough for
        us?

      * f29a2041f32773464e226a83f41762c2e9cf658e
        (e53a96c2136f7cdff4699475fea41afeed9dece3)

    Testresults same as for GNU/Linux.

  * [high] 3efc00f6f17778172d3fa7ac737fa1473b3b4d5a, `Check __GLIBC__ when
    using __SIGRTMIN`.  GCC PR52390.  Fixed by
    8d2259c83f94c082ad8a00b5d00bb639ce24efce.

  * 15ac1e637ad0cb92bf7629205c617ea847a4b810 `Build 64-bit libffi multilib for
    i?86-linux`.

  * `libstdc++`: uses `_GLIBCXX_HAVE_TLS`, but where is this defined?  Supposed
    to come from `config/tls.m4:GCC_CHECK_TLS`?

  * `libgcc/gthr-posix.h:__gthread_active_p` -- is this suitable for us?  This
    is used in libgcc for ObjC wrapper stuff and similar in libstdc++.
    C.f. [[!message-id "x57jobtqx89w.fsf@frobland.mtv.corp.google.com"]],
    [[!message-id "x57jd359fkx3.fsf@frobland.mtv.corp.google.com"]] as well as
    [[!debbug 629866]]/[[!message-id
    "20110609002620.GA16719@const.famille.thibault.fr"]].  commit
    026e608ecebcb2a6193971006a85276307d79b00.

  * 549e2197b118efb2d947aaa15d445b05c1b5ed62 `Import the asan runtime library
    into GCC tree`.  Linux-specific things:
    `ASAN_USE_ALIAS_ATTRIBUTE_FOR_INDEX`, `ASAN_LINUX`, `ASAN_POSIX`,
    `libsanitizer/asan/asan_linux.cc`,
    `libsanitizer/asan/asan_malloc_linux.cc`,
    `libsanitizer/asan/asan_posix.cc`,
    `libsanitizer/interception/interception.h`,
    `libsanitizer/interception/interception_linux.cc`,
    `libsanitizer/interception/interception_linux.h`,
    `libsanitizer/sanitizer_common/sanitizer_allocator.cc`,
    `libsanitizer/sanitizer_common/sanitizer_linux.cc`,
    `libsanitizer/sanitizer_common/sanitizer_posix.cc`,
    `libsanitizer/sanitizer_common/sanitizer_procmaps.h`,
    `libsanitizer/sanitizer_common/sanitizer_symbolizer_linux.cc`.
    4afab99bf0fe2d6905a9fa9d6ab886ca102312df `Enable libsanitizer just on x86
    linux for now`.  492e75a7336b4dbfe38207ea3abf8d5bd72376a9 `Move
    libsanitizer configure logic to subdirectory`.
    6aea389d84c2172668af5f108e2b17e131120d0b `Add STATIC_LIBASAN_LIBS for
    -static-libasan`.  Further commits later on.

      * 9cf754572854d9d9cd43c277eb7afb12e4911358 `Import tsan runtime from
        llvm`.  Linux-specific things: `libsanitizer/tsan/tsan_platform.h`,
        `libsanitizer/tsan/tsan_platform_linux.cc`,
        `libsanitizer/tsan/tsan_symbolize_addr2line_linux.cc`.
        a96132f29aa3dfe94141a87537f62ea73ce0fc19 `Set TSAN_SUPPORTED=yes for
        x86_64/i686-linux for 64-bit multilib`.  Further commits later on.


# Build

Here's a log of a GCC build run; this is from our [[Git repository's
06a4535f69cf9613943fd12f97fe94e471dedcce (2013-02-18;
71cfadefb994de9249449fb7e71be012b6264a3f (2013-02-17))
sources|source_repositories/gcc]], run on kepler.SCHWINGE and coulomb.SCHWINGE.

    $ export LC_ALL=C
    $ (cd ../master/ && contrib/gcc_update --touch)
    $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 --enable-languages=all,ada 2>&1 | tee log_build
    [...]
    $ make 2>&1 | tee log_build_
    [...]

Different hosts may default to different shells and compiler versions; thus
harmonized.

We're stuck with GCC 4.6 until there are Debian *gnat-4.7* packages avaible.

This takes up around 3.5 GiB, and needs roughly 3.25 h on kepler.SCHWINGE and
14.25 h on coulomb.SCHWINGE.

<!--

    $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && make -k check 2>&1 | tee log_test

-->


## Analysis

    $ toolchain/logs/process gcc build

  * [[`checking if gcc static flag -static
    works... no`|glibc_madvise_vs_static_linking]]

    Addressed in Debian glibc.

  * `host-linux.c` vs. `host-default.c`

  * *fixincludes* stuff

  * malloc?

        -cat ../../hurd/gcc/config/i386/pmm_malloc.h > mm_malloc.h
        +cat ../../hurd/gcc/config/i386/gmm_malloc.h > mm_malloc.h

    Comes from `gcc/config.gcc`: `i386/t-pmm_malloc` vs. `i386/t-gmm_malloc`
    for `i[34567]86-*-linux*` vs. `i[34567]86-*-*`.

  * *libgomp*

      * `libgomp/config/linux/`, `libgomp/config/linux/x86`

    `sed`ed away.

      * `-ftls-model=initial-exec -march=i486 -mtune=i686`

    `sed`ed away.

  * Missing `EOWNERDEAD`, `ENOTRECOVERABLE`.  What're they used for?

  * `RLIMIT_VMEM`.  Usage kosher?

  * `libtool: link: ar rc .libs/libstdc++.a [...]`

    Just different order of object files, or another problem?  TODO

  * `libobjc/encoding.c`:

         libtool: compile:  [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/encoding.c -c [...]
        +[...]/hurd/master/libobjc/encoding.c:128:1: warning: '_darwin_rs6000_special_round_type_align' defined but not used [-Wunused-function]

  * `libobjc/thr.c`: `gcc/gthr-posix.h`

         libtool: compile:  [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/thr.c -c [...]
        +In file included from [...]/hurd/master/libobjc/../libgcc/gthr.h:142:0,
        +                 from [...]/hurd/master/libobjc/thr.c:45:
        +../libgcc/gthr-default.h: In function '__gthread_objc_thread_set_priority':
        +../libgcc/gthr-default.h:388:41: warning: unused parameter 'priority' [-Wunused-parameter]

  * `/proc/self/*`

        -checking for /proc/self/exe... yes
        -checking for /proc/self/maps... yes
        +checking for /proc/self/exe... no
        +checking for /proc/self/maps... no

  * GCJ: `java-signal.h`, `java-signal-aux.h`

        -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal.h
        -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal-aux.h
        +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal.h
        +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal-aux.h

  * GCJ: `jni_md.h`

        -checking jni_md.h support... yes
        +checking jni_md.h support... configure: WARNING: no

  * *default library search path*

        -checking for the default library search path... /lib /usr/lib /lib/i386-linux-gnu /usr/lib/i386-linux-gnu /lib/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/local/lib
        +checking for the default library search path... /lib /usr/lib

    [[binutils]] issue?  Should be aligned by Samuel's binutils patch.

  * `./classpath/[...]/*.properties`

    Just different order of files, or another problem?

  * `libjava/gnu/gcj/util/natGCInfo.cc`

         libtool: compile:  [...]/hurd/master.build/./gcc/xgcc [...] -c ../../../master/libjava/gnu/gcj/util/natGCInfo.cc [...]
        +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:440:1: warning: unused parameter 'name' [-Wunused-parameter]
        +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:446:1: warning: unused parameter 'name' [-Wunused-parameter]
        +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:452:1: warning: unused parameter 'name' [-Wunused-parameter]

  * `libgcj.la`

    Just different order of object files, or another problem?

    Is there a pattern that GNU/Hurd hands out the files alphabetically sorted
    where it wouldn't need to ([[!taglink open_issue_hurd]])?

  * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0`

    `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions`

  * `jar`

         make[2]: Entering directory `[...]/hurd/master.build/[ARCH]/libjava'
        -: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=[...]/hurd/master.build/[ARCH]/libjava/scripts/jar" DO=all multi-do
        +: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=jar" DO=all multi-do

    Probably because kepler.SCHWINGE has an OpenJDK `/usr/bin/jar`, and
    coulomb.SCHWINGE a GCJ one.

    There are other instances of this in the following.

  * `value-unwind.h`

        -DEFINES='' HEADERS='../../../master/libgcc/config/i386/value-unwind.h' \
        +DEFINES='' HEADERS='' \
                        ../../../master/libgcc/mkheader.sh > tmp-libgcc_tm.h

    Comes from `gcc/config.gcc`: for `i[34567]86-*-linux*`
    vs. `i[34567]86-*-*`, but apparently is important only for *x86_64* anyway.

  * `soft-fp` prototypes

         ../../../master/libgcc/soft-fp/eqtf2.c:34:9: warning: no previous prototype for '__eqtf2' [-Wmissing-prototypes]
        +../../../master/libgcc/soft-fp/eqtf2.c:50:1: warning: no previous prototype for '__netf2' [-Wmissing-prototypes]

         ../../../master/libgcc/soft-fp/getf2.c:34:9: warning: no previous prototype for '__getf2' [-Wmissing-prototypes]
        +../../../master/libgcc/soft-fp/getf2.c:50:1: warning: no previous prototype for '__gttf2' [-Wmissing-prototypes]

         ../../../master/libgcc/soft-fp/letf2.c:34:9: warning: no previous prototype for '__letf2' [-Wmissing-prototypes]
        +../../../master/libgcc/soft-fp/letf2.c:50:1: warning: no previous prototype for '__lttf2' [-Wmissing-prototypes]

  * `libatomic` on GNU/Linux compiles several more files than on GNU/Hurd.  Is
    that correct?  Probably futex support.

  * 2e2db3f92b534460c68c2f9ae64455884424beb6..3336556d2cb32f46322922a83015f760cfb79d8f

    Both GNU/Linux and GNU/Hurd:

        -checking assembler for rep and lock prefix... yes
        +checking assembler for rep and lock prefix... no

    TODO.


# Install

    $ make install 2>&1 | tee log_install
    [...]

This takes up around 1 GiB, and needs roughly 5 min on kepler.SCHWINGE and 37
min on coulomb.SCHWINGE.


## Analysis

    $ toolchain/logs/process gcc install

  * `libtool: finish`: `ldconfig` is not run for the Hurd.

    [[libtool]].

  * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0`

    `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` (as above)

  * `jar`: as above.


# Testsuite

<http://gcc.gnu.org/install/test.html>

Testing on GNU/Hurd is blocked on
[[fork_mach_port_mod_refs_ekern_urefs_owerflow]].

TODO.  On GNU/Hurd, it is advisable to reboot after having built and installed
GCC, before running the testsuite, as otherwise there seems to be a tendency
that the system crashes during the `gcc.c-torture/compile/limits-structnest.c`
tests, which are rather memory hungry, see [[!message-id
"87bol6aixd.fsf@schwinge.name"]].  Likewise, it also seems advisable to add
further reboots in between, that is, separate `make check`'s `check-host` into
several separate runs, and then one for `check-target` (see
`[build]/Makefile:do-check`, `[build]/gcc/Makefile:CHECK_TARGETS`), as
otherwise there seems to be a tendency for the system crashing sooner or later.
(Running `check-host` accumulates to something like 44 hours worth of
forking/execing of GCC and testcases.)  On GNU/Linux we run it in one go, so
that we'll catch any fundamental rearrangements of/additions to the testsuites.

kepler.SCHWINGE:

    $ make -k check 2>&1 | tee log_test
    [...]

coulomb.SCHWINGE:

    $ awk '/^maybe-check-target/ { next; }; /^maybe-check-[^:]*:./ { print; };' < Makefile
    maybe-check-fixincludes: check-fixincludes
    maybe-check-gcc: check-gcc
    maybe-check-intl: check-intl
    maybe-check-libbacktrace: check-libbacktrace
    maybe-check-libcpp: check-libcpp
    maybe-check-libdecnumber: check-libdecnumber
    maybe-check-libiberty: check-libiberty
    maybe-check-zlib: check-zlib
    maybe-check-gnattools: check-gnattools
    maybe-check-lto-plugin: check-lto-plugin
    $ grep ^CHECK_TARGETS gcc/Makefile
    CHECK_TARGETS =  check-ada check-c check-c++ check-fortran check-java check-lto check-objc

    $ export LC_ALL=C

    [reboot]
    $ make -k check-fixincludes 2>&1 | tee log_test_1_check-fixincludes
    [...]
    $ make -k -C gcc check-ada 2>&1 | tee log_test_2_gcc_check-ada
    [...]
    [reboot]
    $ make -k -C gcc check-c 2>&1 | tee log_test_2_gcc_check-c
    [...]
    [reboot]
    $ make -k -C gcc check-c++ 2>&1 | tee log_test_2_gcc_check-c++
    [...]
    [reboot]
    $ make -k -C gcc check-fortran check-java check-lto check-objc 2>&1 | tee log_test_2_gcc_check-fortran,check-java,check-lto,check-objc
    [...]
    [reboot]
    $ make -k check-intl check-libbacktrace check-libcpp check-libdecnumber check-libiberty check-zlib check-gnattools check-lto-plugin 2>&1 | tee log_test_3
    [...]
    $ make -k check-target 2>&1 | tee log_test_4_check-target
    [...]

This needs roughly 7 h on kepler.SCHWINGE and 3.5 h (`check-fixincludes`,
`gcc/check-ada`) + 13 h (`gcc/check-c`) + 4.25 h (`gcc/check-c++`) + 5.75 h
(`gcc/check-fortran`, `gcc/check-java`, `gcc/check-lto`, `gcc/check-objc`) +
9.25 h (`check-intl`, [...], `check-lto-plugin`, `check-target`) = 35.75 h on
coulomb.SCHWINGE.


## Analysis

    $ toolchain/logs/process gcc test

  * PTYs

    Occasionally tests FAIL due to:

        spawn -open -1 failed, 1 5, The system has no more ptys.  Ask your system administrator to create more.

    TODO.

  * As of b401cb7ed15602d244a6807835b0b9d740a302a8 (2012-11-26;
    769bf18a20ee2540ca7601cdafabd62b18b9751b (2012-10-01)), all
    `gcc.dg/guality` and `g++.dg/guality` and a few more are no longer tested
    on coulomb.SCHWINGE and kepler.SCHWINGE.

  * As of b401cb7ed15602d244a6807835b0b9d740a302a8 (2012-11-26;
    769bf18a20ee2540ca7601cdafabd62b18b9751b (2012-10-01)), there are
    regressions (FAILs) in libgomp execution tests on coulomb.SCHWINGE.

  * 769bf18a20ee2540ca7601cdafabd62b18b9751b..be3860ba8df48cca3253da4f02fd2d42d856ce80

    On GNU/Hurd:

         Running [...]/hurd/master/gcc/testsuite/g++.dg/tls/tls.exp ...
        +FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test
        +FAIL: g++.dg/tls/thread_local3g.C -std=gnu++11 execution test
        +FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test
        +FAIL: g++.dg/tls/thread_local4g.C -std=gnu++11 execution test
        +FAIL: g++.dg/tls/thread_local5.C -std=gnu++11 execution test
        +FAIL: g++.dg/tls/thread_local5g.C -std=gnu++11 execution test

    They used to PASS.

  * What is `gcc/testsuite/gcc.test-framework/test-framework.exp` and should we
    define `CHECK_TEST_FRAMEWORK` to run these tests?

  * TODO


## Enhancements


### `contrib/testsuite-management/`, `contrib/regression/`

  * 35a27ee8c4b349fea44fd1fadc9614ab3cc9d578 `Add an xfail manifest for
    x86_64-unknown-linux-gnu to trunk.`


### Parallel Testing

[[!message-id "20110331070322.GI11563@sunsite.ms.mff.cuni.cz"]].


### Distributed Testing


#### IRC, OFTC, #gcc, 2012-05-31

    <dnovillo> jsm28: in your mentor testing, you have the source and build
      tree available for make check?  or it's a pure installed-tree test?
    <jsm28> dnovillo: Source tree, install tree, no build tree.
    <dnovillo> jsm28: so, you run make check on top of the source tree or copy
      the */testsuite trees to a testing area?
    <jsm28> Create a site.exp and do runtest in a temporary directory.  runtest
      is pointed to the source tree to find sources.
    <jsm28> For cross testing for GNU/Linux targets, the temporary directory is
      mounted at the same path on host and target.
    <dnovillo> jsm28: thanks.  i guess i'll have to find the slice of the
      source tree i need to copy.
    <dnovillo> jsm28: for libstdc++ do you write a different site.exp? 
    <dnovillo> i noticed that it generates a different site,exp there.
    <jsm28> The site.exp is mostly the same for all testsuites (so includes
      settings that only some testsuites use).
    <dnovillo> ok, thanks.
    <dnovillo> and when you say "pointed to the source tree" you mean "set
      srcdir /path/to/top/of/gcc" ?
    <dnovillo> (in site.exp)
    <jsm28> The GDB testsuite requires that you run the GDB testsuite's
      configure script in the temporary directory where you will run runtest.
      I don't think any GCC testsuites we use have requirements like that.
    <jsm28> dnovillo: --srcdir option to runtest.
    <dnovillo> ah, yes.
    <jsm28> (and --tool, --target_board etc.)
    <dnovillo> right
    <dnovillo> since i'm distributing the tests. i want each node to only do a
      bunch of files.  this means that i either use 'tool.exp=file-pattern' or
      simply copy the subset of files i want tool.exp to find.
    <dnovillo> i chose the second approach, but that breaks in a handful of
      cases that need files from other sub-directories.
    <dnovillo> like g++.dg gcc.dg using stuff from c-c++-common.
    <dnovillo> for libstdc++, the possibilities for splitting are enormous as
      it has many directories.
    <dnovillo> but i'm not setting it right.  runtest runs without even trying
      to test anything.
    <dnovillo> i'm not having it pick up the right driver.
    <jsm28> Probably all .exp files should be copied to anywhere running
      testsuites, since some read .exp files from other directories.
    <dnovillo> jsm28: that could be it too.  it's irritating that libstdc++
      does not even error out.  runtest just does nothing and returns 0.

##### IRC, OFTC, #gcc, 2012-06-06

    <dnovillo> any libstdc++ maintainer around?
    <dnovillo> or, does anyone know when the testsuite/data files are copied
      into the running testsuite/ dir?
    <dnovillo> seems to be done in advance by make.

##### [[!message-id "4FC7791E.6040407@gmail.com"]]