path: root/open_issues/gcc.mdwn

[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014
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 diff --patience --stat=$COLUMNS,$COLUMNS --patch --src-prefix=./ --dst-prefix=./ --word-diff --color --find-renames --ignore-space-change ..upstream/trunk | awk '/^(\x1b\[[0-9]+m)?diff/ { c = " " $0; } /^(\x1b\[[0-9]+m)?@@/ { print c; } { print; }' | less
-i
/^---.*/([^.]*|.*\.texi.*|[^/]*gnu[^/]*|libgo/go/(net/sock_bsd\.go|syscall/exec_bsd\.go|syscall/libcall_posix\.go))$|hurd|linux|nacl|nptl|glibc($|[^x]|x[^x]|x$)|gs:|dg-runtest

-->

Last reviewed up to the [[Git mirror's d3faa4b6d102b09a5ea17bbf81590f215b42fbc4
(2014-09-26) 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`

      * `libstdc++-v3`

          * `configure.host`

            `abi_baseline_pair` etc. setting.  `config/abi/post/*-linux-gnu`.
            TODO.

          * `config/os/gnu-linux`

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

      * `gcc/acinclude.m4`:`gcc_GAS_FLAGS`: always pass `--32` to assembler for
        x86 Linux.  Probably we should just do the same, see `*-*-linux*`
        comment in [[!message-id "87zjrjcasc.fsf@schwinge.name"]].

      * `lib-prefix.m4` (present twice in GCC sources) contains one remaining
        `linux`-only case.

      * `libjava`

        TODO:

            classpath/include/jni_md-x86-linux-gnu.h

        See below (`log_build`).

            Makefile.am:## _GNU_SOURCE defined for some Linux builds.  It doesn't hurt to
            Makefile.am:## always define it.  Some systems, including Linux, need
            Makefile.am:# certain linuxthread functions get linked:
            Makefile.am:## This is specific to Linux/{Free,Net,Open}BSD/Hurd and perhaps few others.
            Makefile.am:  $(mkinstalldirs) $(DESTDIR)$(SDK_INCLUDE_DIR)/linux; \
            Makefile.am:      $(DESTDIR)$(SDK_INCLUDE_DIR)/linux); \
            Makefile.am:      $(DESTDIR)$(SDK_INCLUDE_DIR)/linux/$$headername.h; \
            classpath/NEWS:  the epoll notification mechanism on Linux 2.6.
            classpath/config.rpath:    linux* | k*bsd*-gnu)
            classpath/config.rpath:    gnu* | linux* | k*bsd*-gnu)
            classpath/config.rpath:  linux*oldld* | linux*aout* | linux*coff*)
            classpath/config.rpath:  linux* | k*bsd*-gnu)
            classpath/configure.ac:    *linux*)
            classpath/configure.ac:    target_os=linux-gnu 
            classpath/configure.ac:    AC_MSG_WARN(no, using x86-linux-gnu)
            classpath/doc/cp-vmintegration.texinfo:has been primarily tested against Linux and lacks garbage collections, a
            classpath/doc/cp-vmintegration.texinfo:Linux and Windows 2000.  As of June, 2004, it does not appear that ORP
            classpath/doc/cp-vmintegration.texinfo:This is a free Java Virtual Machine that is being developed on GNU/Linux
            classpath/doc/cp-vmintegration.texinfo:Runs on the x86 and PowerPC architectures, on the AIX, Linux, and Mac
            classpath/gnu/classpath/SystemProperties.java:        && "Linux".equals(defaultProperties.get("os.name")))
            classpath/gnu/java/nio/EpollSelectorImpl.java: * notification mechanism on GNU/Linux.
            classpath/java/io/File.java:   * <strong>Implementation note</strong>: Unlike the RI, on Linux and UNIX
            classpath/java/net/MimeTypeMapper.java:        // On Linux this usually means /etc/mime.types.
            classpath/ltcf-cxx.sh:  linux*)
            classpath/ltcf-cxx.sh:    linux*)
            classpath/ltconfig:# Transform linux* to *-*-linux-gnu*, to support old configure scripts.
            classpath/ltconfig:linux-gnu*) ;;
            classpath/ltconfig:linux*) host=`echo $host | sed 's/^\(.*-.*-linux\)\(.*\)$/\1-gnu\2/'`
            classpath/ltconfig:  version_type=linux
            classpath/ltconfig:  version_type=linux
            classpath/ltconfig:  version_type=linux
            classpath/ltconfig:  version_type=linux
            classpath/ltconfig:  version_type=linux
            classpath/ltconfig:    version_type=linux
            classpath/ltconfig:# No shared lib support for Linux oldld, aout, or coff.
            classpath/ltconfig:linux-gnuoldld* | linux-gnuaout* | linux-gnucoff*)
            classpath/ltconfig:# This must be Linux ELF.
            classpath/ltconfig:linux-gnu*)
            classpath/ltconfig:  version_type=linux
            classpath/ltconfig:  # powerpc, because MkLinux only supported shared libraries with the
            classpath/ltconfig:  # most powerpc-linux boxes support dynamic linking these days and
            classpath/ltconfig:  # assume the GNU/Linux dynamic linker is in use.
            classpath/ltconfig:  dynamic_linker='GNU/Linux ld.so'
            classpath/ltconfig:  version_type=linux
            classpath/ltconfig:  version_type=linux
            classpath/ltconfig:  version_type=linux
            classpath/ltconfig:  version_type=linux
            classpath/ltconfig:  dynamic_linker='GNU/Linux ld.so'
            classpath/ltconfig:  version_type=linux
            classpath/ltconfig:  version_type=linux
            classpath/ltconfig:    version_type=linux
            classpath/ltmain.sh:#         compiler flags:		$LTCFLAGS
            classpath/ltmain.sh:	  *-*-linux*)
            classpath/ltmain.sh:	  darwin|linux|osf|windows|none)
            classpath/ltmain.sh:	  # Like Linux, but with the current version available in
            classpath/ltmain.sh:	linux)
            classpath/m4/lib-link.m4:              dnl   2. if it's /usr/local/include and we are using GCC on Linux,
            classpath/m4/lib-link.m4:                      linux* | gnu* | k*bsd*-gnu) haveit=yes;;
            classpath/m4/lib-link.m4:                    dnl   2. if it's /usr/local/lib and we are using GCC on Linux,
            classpath/m4/lib-link.m4:                            linux* | gnu* | k*bsd*-gnu) haveit=yes;;
            classpath/m4/lib-prefix.m4:    dnl   3. if it's /usr/local/include and we are using GCC on Linux,
            classpath/m4/lib-prefix.m4:              linux* | gnu* | k*bsd*-gnu) haveit=yes;;
            classpath/m4/lib-prefix.m4:            CPPFLAGS="${CPPFLAGS}${CPPFLAGS:+ }-I$additional_includedir"
            classpath/m4/lib-prefix.m4:    dnl   3. if it's /usr/local/lib and we are using GCC on Linux,
            classpath/m4/lib-prefix.m4:              linux*) haveit=yes;;
            classpath/m4/lib-prefix.m4:            LDFLAGS="${LDFLAGS}${LDFLAGS:+ }-L$additional_libdir"
            classpath/m4/lib-prefix.m4:  dnl On glibc systems, the current practice is that on a system supporting
            classpath/native/jni/java-net/javanet.c:      /* Not writable on Linux */
            classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c: * vector based read call (currently readv on Linux).
            classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c: * vector based read call (currently readv on Linux).
            classpath/vm/reference/java/lang/VMProcess.java:  // Linux use a process-per-thread model, which means the same thread

            configure.ac:     *-*-linux*)
            configure.ac: AC_DEFINE(LINUX_THREADS, 1, [Define if using POSIX threads on Linux.])
            include/config.h.in:/* Define if using POSIX threads on Linux. */
            include/config.h.in:#undef LINUX_THREADS
            include/posix-threads.h:# ifdef LOCK_DEBUG /* Assumes Linuxthreads */
            include/posix-threads.h:#ifndef LINUX_THREADS
            include/posix-threads.h:// pthread_mutex_destroy does nothing on Linux and it is a win to avoid
            include/posix-threads.h:#endif /* LINUX_THREADS */
            include/posix-threads.h:      // For linux_threads this is really a pointer to its thread data
            include/posix-threads.h:// E.g. on X86 Linux, pthread_self() is too slow for our purpose.
            include/posix-threads.h:// This code should probably go away when Linux/X86 starts using a
            posix-threads.cc:#if defined(LINUX_THREADS) || defined(FREEBSD_THREADS)
            posix-threads.cc:  // LinuxThreads (prior to glibc 2.1) usurps both SIGUSR1 and SIGUSR2.
            posix-threads.cc:#else /* LINUX_THREADS */
            posix-threads.cc:#endif /* LINUX_THREADS */
            posix-threads.cc:      // In older glibc's (prior to 2.1.3), the cond_wait functions may 
            posix-threads.cc:  // glibc 2.1.3 doesn't set the value of `thread' until after start_routine

            configure.ac:      # We can save a little space at runtime if the mutex has m_count
            configure.ac:      # or __m_count.  This is a nice hack for Linux.
            configure.ac:      AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <pthread.h>]], [[
            configure.ac:          extern pthread_mutex_t *mutex; int q = mutex->m_count;

        Makes sense to implement in our [[/libpthread]] ([[!taglink
        open_issue_libpthread]])?

            configure.ac: i?86-*-linux*)
            configure.ac:    SIGNAL_HANDLER=include/i386-signal.h
            configure.ac:    SIGNAL_HANDLER_AUX=include/x86_64-signal.h
            include/i386-signal.h:// on an i386 based Linux system.
            include/i386-signal.h:   directly rather than via glibc.  The sigaction structure that the
            include/i386-signal.h: * called _directly_ by the kernel, because linuxthreads wraps signal
            include/i386-signal.h: * handler to a linuxthreads wrapper, we will lose the PC adjustment
            include/i386-signal.h: * Also, there may not be any unwind info in the linuxthreads

            configure.ac:      *-linux*)
            configure.ac:        host_os=linux;;

            configure.host:  i[34567]86*-linux* | \
            configure.host:  	can_unwind_signal=yes
            configure.host:	libgcj_ld_symbolic='-Wl,-Bsymbolic'
            configure.host:	if test x$slow_pthread_self = xyes \
            configure.host:       [...]
            configure.host:  i[34567]86*-kfreebsd*-gnu | x86_64*-kfreebsd*-gnu)
            configure.host:        libgcj_ld_symbolic='-Wl,-Bsymbolic'
            configure.host:        slow_pthread_self=

            java/lang/natObject.cc:// What follows currenly assumes a Linux-like platform.
            java/lang/natObject.cc:// Some of it specifically assumes X86 or IA64 Linux, though that
            java/lang/natObject.cc:#   define INVALID_THREAD_ID 0  // Works for Linux?
            java/lang/natObject.cc:  const unsigned MIN_SLEEP_USECS = 2001; // Shorter times spin under Linux.
            java/lang/natVMClassLoader.cc:      // a module named (eg, on Linux) `lib-gnu-pkg-quux.so', followed

            libltdl/acinclude.m4:x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
            libltdl/acinclude.m4:        x86_64-*linux*)
            libltdl/acinclude.m4:        ppc64-*linux*|powerpc64-*linux*)
            libltdl/acinclude.m4:          LD="${LD-ld} -m elf32ppclinux"
            libltdl/acinclude.m4:        s390x-*linux*)
            libltdl/acinclude.m4:        sparc64-*linux*)
            libltdl/acinclude.m4:        x86_64-*linux*)
            libltdl/acinclude.m4:        ppc*-*linux*|powerpc*-*linux*)
            libltdl/acinclude.m4:        s390*-*linux*)
            libltdl/acinclude.m4:        sparc*-*linux*)
            libltdl/acinclude.m4:    # Under GNU Hurd, this test is not required because there is
            libltdl/acinclude.m4:  version_type=linux
            libltdl/acinclude.m4:  version_type=linux
            libltdl/acinclude.m4:  version_type=linux
            libltdl/acinclude.m4:  version_type=linux
            libltdl/acinclude.m4:  version_type=linux
            libltdl/acinclude.m4:  version_type=linux
            libltdl/acinclude.m4:		version_type=linux
            libltdl/acinclude.m4:# No shared lib support for Linux oldld, aout, or coff.
            libltdl/acinclude.m4:linux*oldld* | linux*aout* | linux*coff*)
            libltdl/acinclude.m4:# This must be Linux ELF.
            libltdl/acinclude.m4:linux*)
            libltdl/acinclude.m4:  version_type=linux
            libltdl/acinclude.m4:  # powerpc, because MkLinux only supported shared libraries with the
            libltdl/acinclude.m4:  # most powerpc-linux boxes support dynamic linking these days and
            libltdl/acinclude.m4:  # assume the GNU/Linux dynamic linker is in use.
            libltdl/acinclude.m4:  dynamic_linker='GNU/Linux ld.so'
            libltdl/acinclude.m4:  version_type=linux
            libltdl/acinclude.m4:  version_type=linux
            libltdl/acinclude.m4:  version_type=linux
            libltdl/acinclude.m4:  version_type=linux
            libltdl/acinclude.m4:  version_type=linux
            libltdl/acinclude.m4:    version_type=linux
            libltdl/acinclude.m4:  version_type=linux
            libltdl/acinclude.m4:# This must be Linux ELF.
            libltdl/acinclude.m4:linux*)
            libltdl/acinclude.m4:  linux*)
            libltdl/acinclude.m4:linux*)
            libltdl/acinclude.m4:      linux*)
            libltdl/acinclude.m4:	    # Linux and Compaq Tru64 Unix objects are PIC.
            libltdl/acinclude.m4:	    # Linux and Compaq Tru64 Unix objects are PIC.
            libltdl/acinclude.m4:    linux*)
            libltdl/acinclude.m4:    linux*)
            libltdl/acinclude.m4:  gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu)
            libltdl/acinclude.m4:    # GNU and its variants, using gnu ld.so (Glibc)
            libltdl/ltmain.sh:	  darwin|linux|osf|windows)
            libltdl/ltmain.sh:	  # Like Linux, but with the current version available in
            libltdl/ltmain.sh:	linux)
            shlibpath.m4:  version_type=linux
            shlibpath.m4:  version_type=linux
            shlibpath.m4:  version_type=linux
            shlibpath.m4:  version_type=linux
            shlibpath.m4:  version_type=linux
            shlibpath.m4:		version_type=linux
            shlibpath.m4:# No shared lib support for Linux oldld, aout, or coff.
            shlibpath.m4:linux*oldld* | linux*aout* | linux*coff*)
            shlibpath.m4:# This must be Linux ELF.
            shlibpath.m4:linux*|k*bsd*-gnu)
            shlibpath.m4:  version_type=linux
            shlibpath.m4:  # powerpc, because MkLinux only supported shared libraries with the
            shlibpath.m4:  # most powerpc-linux boxes support dynamic linking these days and
            shlibpath.m4:  # assume the GNU/Linux dynamic linker is in use.
            shlibpath.m4:  dynamic_linker='GNU/Linux ld.so'
            shlibpath.m4:  version_type=linux
            shlibpath.m4:  version_type=linux
            shlibpath.m4:  version_type=linux
            shlibpath.m4:  version_type=linux
            shlibpath.m4:    version_type=linux
            shlibpath.m4:  version_type=linux

            testsuite/lib/libjava.exp:    if { [regexp "linux" $target_triplet] } {

        Adds `-specs=libgcj-test.spec`, which is created by `configure`.  *This
        spec file is read by gcj when linking.  It is only used by the testing
        harnesses (in libjava and gdb).*  TODO.  [[!taglink open_issue_gdb]].

      * `libgcc`

          * `config/t-linux`
          * `config/i386/t-linux`

        TODO, rename to `t-gnu-user`.

          * `config/i386/linux-unwind.h`

        TODO, probably needs porting, if we need this.
        [[!GCC_PR 57851 desc="[patch] unwinding via signal trampoline for
        kfreebsd*-gnu"]].

      * `libitm`

        TODO:

          * `libitm/config/linux`

  * `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"]].

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

        #define TARGET_CAN_SPLIT_STACK
        #define TARGET_THREAD_SPLIT_STACK_OFFSET 0x30

        libgcc/config/i386/morestack.S
        libgcc/config/i386/t-stack-i386
        libgcc/config/t-stack
        libgcc/generic-morestack-thread.c
        libgcc/generic-morestack.c
        libgcc/generic-morestack.h
        libgcc/config/i386/morestack.S:	cmpl	%gs:0x30,%eax		# See if we have enough space.
        libgcc/config/i386/morestack.S:	# gcc/config/i386/linux.h.
        libgcc/config/i386/morestack.S:	movl	%eax,%gs:0x30		# Save the new stack boundary.
        libgcc/config/i386/morestack.S:	movl	%eax,%gs:0x30		# Save the new stack boundary.
        libgcc/config/i386/morestack.S:	movl	%ecx,%gs:0x30		# Save new stack boundary.
        libgcc/config/i386/morestack.S:	# gcc/config/i386/linux64.h.
        libgcc/config/i386/morestack.S:	movl	%eax,%gs:0x30
        libgcc/config/i386/morestack.S:	movl	%gs:0x30,%eax
        libgcc/config/i386/morestack.S:	movl	%eax,%gs:0x30
        libgcc/generic-morestack-thread.c:   can build glibc.  */
        libgcc/generic-morestack-thread.c:   not be necessary if glibc supports -fsplit-stack directly.  */
        libgcc/generic-morestack.c:   can build glibc.  */
        libgcc/generic-morestack.c:     since stack splitting only works on GNU/Linux anyhow.  */
        libgcc/generic-morestack.c:#if defined(__GLIBC__) && defined(__linux__)
        libgcc/generic-morestack.c:  /* In glibc, the first two real time signals are used by the NPTL

    IRC, freenode, #hurd, 2014-01-10:

        <gnu_srs1> Hi, I assume gcc -fsplit-stack is not yet supported?
        <braunr> gnu_srs1:
          https://lists.gnu.org/archive/html/bug-hurd/2013-06/msg00100.html
        <gnu_srs1> braunr: That's exactly where the problem is:
          src/libgcc/generic-morestack.c:814:__morestack_load_mmap
        <gnu_srs1> no return value recorded
        <gnu_srs1> creating a call: page = mmap ((void*)0x0, 0, 4, 2, -1, 0);,
          returning EINVAL
        <braunr> lenght of 0 ?
        <gnu_srs1> yes, __morestack_current_segment, is zero
        <braunr> mmap is expected to return einval if the requested mapping has
          a size of 0 ..
        <braunr> i don't know what split stack is, but i remember it's a
          problem for the hurd
        <gnu_srs1> sorry, the address is zero from the above, and the length in
          the call is zero too
        <braunr> yes that's what i understood
        <braunr> and i'm telling you it's normal
        <braunr> the size is invalid
        <gnu_srs1> libgcc/generic-morestack.c:  mmap
          (__morestack_current_segment, 0, PROT_READ, MAP_ANONYMOUS, -1, 0);
        <braunr> well this is wrong
        <gnu_srs1> and the error code stays, not being reset in subsequent
          calls
        <gnu_srs1> causing an error later on
        <braunr> as roland says in
          https://lists.gnu.org/archive/html/bug-hurd/2013-06/msg00102.html, it
          should be possible to support split-stack now that we have tls
        <gnu_srs1> as thomas reported
        <braunr> i don't see the relation between split-stack and the mmap
          invocation
        <gnu_srs1> tls s in 2.17-97, right? that's the one I tried
        <braunr> tls is there, but not split stack support
        <braunr> and libpthread still has bugs related to changing the stack
          apparently
        <braunr> fixed upstream but not yet in debian packages
        <braunr> unless you want to try with the thread destruction packages
        <braunr> not sure it will change much though

      * 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.

      * Also see [[!sourceware_PR 10686]], glibc commit
        ecbf434213c0333d81706074e4d107ac45011635 `Reserve new TLS field for x86
        and x86_64` (`__private_ss`).

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

  * `gcc/ada` (not all reviewed)

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

  * `gcc/go`, `gcc/testsuite/go.test`, `libgo` (not reviewed)

      * 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.

  * 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.

  * [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"]].

    IRC, freenode, #hurd, 2014-01-08:

        <gnu_srs> How come __GLIBC__ is defined in gcc for kFreeBSD and not
          GNU? They sometimes use that instead of __FreeBSD_kernel__
        <pochu> it's defined by libc's /usr/include/features.h
        <gnu_srs> pochu: __GLIBC__ is defined in features.h both for GNU and
          kFreeBSD, but only in gcc/cpp for kFreeBSD: touch foo.h;gcc -E -dM
          foo.h|grep GLIBC
        <pochu> gnu_srs: #include <stdlib.h>
        <gnu_srs> pochu: they both include <features.h>
        <pochu> gnu_srs: I get __GLIBC__ defined if I include features.h
        <pochu> with an empty file (as suggested by your `touch foo.h') I don't
          get it defined, whether on hurd or linux, but I think that's expected
        <gnu_srs> pochu: might be so but it is not pre-defined in CPP, as it is
          for kFreeBSD.
        <gnu_srs> I think it should not be defined, or it should be defined by
          all three: GNU,.kFreeBSD and Linux
        <gnu_srs> an anomaly, something for tschwinge
        <braunr> https://lists.debian.org/debian-bsd/2012/11/msg00016.html
        <gnu_srs> braunr: good finding, I assume nothing has happened since
          then?
        <braunr> not likely

  * [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.

  * [[`libsanitizer`|_san]] (not reviewed)

    A lot of Linux-specific things.

  * 30f690e026ecdf99c68e777a48562b58afe37f43 `TARGET_LIBC_HAS_FUNCTION`.  Where
    is `targetm` set?  All TARGET_C99_FUNCTIONS and TARGET_HAS_SINCOS gone?

  * `libvtv`

      * Disabled in `configure.tgt`.

      * `libvtv/vtv_rts.cc`: `if (strcmp (info->dlpi_name, "linux-vdso.so.1")
        == 0)` -- not a problem for us, but...

      * `libvtv/vtv_rts.cc`: `/proc/self/exe` usage, `PATH_MAX`.

  * ./libgomp/testsuite/libgomp.c/affinity-1.c Linux usage

  * `libcilkrts`

    Disabled for Hurd.

    libcilkrts/Makefile.am:

        +# If we're building on Linux, use the Linux version script
        +if LINUX_LINKER_SCRIPT
        +    libcilkrts_la_LDFLAGS += -Wl,--version-script,$(srcdir)/runtime/linux-symbols.ver
        +endif

    libcilkrts/configure.ac:

        +# We have linker scripts for appropriate operating systems
        +linux_linker_script=no
        +case "${host}" in
        +    *-*-linux*)
        +        linux_linker_script=yes
        +        ;;
        +esac
        +AM_CONDITIONAL(LINUX_LINKER_SCRIPT, test "$linux_linker_script" = "yes")

    libcilkrts/runtime/cilk_malloc.c:

        +#if defined _WIN32 || defined _WIN64 || defined __linux__
        +#include <malloc.h>
        +#define HAS_MEMALIGN 1
        +#endif

    libcilkrts/runtime/config/x86/cilk-abi-vla.c:

        +#if defined(__x86_64)
        +    // For Intel64 linux & MACH ABI, all the parameters were passed in
        +    // register, so top of the stack frame above the return address
        +    // is just the size of the return address plus
        +    // distance_from_sp_to_alloca_area on the chance that the alloca
        +    // area isn't at the very bottom of the calling functions stack.
        +#elif defined(__MACH__)
        +    // For ia32 MACH, parameter size is always a mutliple of 16
        +    // bytes to keep the stack 16 byte aligned.  So we need to round
        +    // number of parameters up to multiple of 4.
        +    param_size = 8 * sizeof(char *);
        +#else
        +    // For both windows Intel64 ABI, and the IA32 windows and
        +    // linux ABIs, space is reserved on the stack for all these
        +    // parameters.  param_size is 5 * size of a stack slot.
        +    param_size = 5 * sizeof(char *);
        +#endif

        +#if defined(__x86_64)
        +            // For Intel64 linux & MACH ABI, all the parameters were passed in
        +            // register, so top of the stack frame above the return address
        +            // is just the size of the return address plus
        +            // distance_from_sp_to_alloca_area on the chance that the alloca
        +            // area isn't at the very bottom of the calling functions stack.
        +#elif defined(__MACH__)
        +            // For ia32 MACH, parameter size is always a mutliple of 16
        +            // bytes to keep the stack 16 byte aligned.  So we need to round
        +            // number of parameters up to multiple of 4.
        +            param_size = 8 * sizeof(char *);
        +#else
        +            // For both windows Intel64 ABI, and the IA32 windows and
        +            // linux ABIs, space is reserved on the stack for all these
        +            // parameters.  param_size is 5 * size of a stack slot.
        +            param_size = 6 * sizeof(char *);
        +#endif

    libcilkrts/runtime/os-unix.c:

        +#ifdef __linux__
        +    // define _GNU_SOURCE before *any* #include.
        +    // Even <stdint.h> will break later #includes if this macro is not
        +    // already defined when it is #included.
        +#   define _GNU_SOURCE
        +#endif

        +#if defined __linux__
        +#   include <sys/sysinfo.h>
        +#   include <sys/syscall.h>

    Syscall usage outside __linux__?

    Will run into:

        +#else
        +#error "Unknown architecture"

    libcilkrts/runtime/sysdep-unix.c:

        +#ifdef __linux__
        +    // define _GNU_SOURCE before *any* #include.
        +    // Even <stdint.h> will break later #includes if this macro is not
        +    // already defined when it is #included.
        +#   define _GNU_SOURCE
        +#endif

        +#ifdef __linux__
        +#   include <sys/resource.h>
        +#   include <sys/sysinfo.h>
        +#endif

        +#if defined( __linux__) || defined(__VXWORKS__)
        +    pthread_t tid = *(pthread_t *)thread_id;
        +    if (i < 0 || i > g->total_workers)
        +        return 0;
        +    return g->sysdep->threads[i] == tid;
        +#else
        +    // Needs to be implemented
        +    return 0;
        +#endif

    IRC, freenode, #hurd, 2014-01-10:

        <youpi> bwaarf, libcilkrts in gcc-4.9
        <p2-mate> libcilkrts?
        <youpi> the runtime for the cilk language I guess
        <tschwinge> Yes.  That most likely needs disabling for us.
        <tschwinge> I'll hve a look eventually.
        <tschwinge> As soon as I get
          <http://news.gmane.org/find-root.php?message_id=%3C87wqjjo5kx.fsf%40kepler.schwinge.homeip.net%3E>
          resolved, actually.

    [[!debbug 734973]].  gcc-4.9/debian/patches/libcilkrts-targets.diff

  * Debian GCC 48594516135e34a726cafe3863a4dc661bbd61a4 `boehm-gc: use
    anonymous mmap instead of brk also on hurd-*.`.  [[!debbug 753791]].


# Build

Here's a log of a GCC build run; this is from our [[Git repository's
f91948d1bd857c81bb2cea688457b84fa3ce6b84 (2014-09-26;
d3faa4b6d102b09a5ea17bbf81590f215b42fbc4 (2014-09-26))
sources|source_repositories/gcc]], run on kepler.SCHWINGE and laplace.SCHWINGE.

    $ export LC_ALL=C
    $ (cd ../master/ && contrib/gcc_update --touch)
    $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.9 CXX=g++-4.9 --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.

This takes up around 4 GiB, and runs for [[4 h 48 min|performance#measure]] on
kepler.SCHWINGE and [[5 h 10 min|performance#measure]] on laplace.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.

  * `gcc/config/host-linux.c` vs. `host-default.c`

      * `gcc/config/x-linux`

  * *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-*-*`.

    2004-08-03, PR target/16570, id:20040802163509.GA18487@lucon.org

  * `libgomp`

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

    `sed`ed away in `log_build*`.  TODO.

      * `-march=i486 -mtune=i686`

    `sed`ed away in `log_build*`.  This comes from `libgomp/configure.tgt`,
    where this is added to `XCFLAGS` for `i[456]86-*-linux*` only.  TODO?

  * 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
    laplace.SCHWINGE a GCJ one.
    2013-12-01: Yes: uninstalled OpenJDK on kepler.SCHWINGE, and it changed to
    `JAR=jar`.
    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.


# Install

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

This takes up around 1.1 GiB, and runs for [[3 min|performance#measure]] on
kepler.SCHWINGE and [[13 min|performance#measure]] on laplace.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"]].


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

This runs for [[10 h 46 min|performance#measure]] on kepler.SCHWINGE and [[18 h
10 min|performance#measure]] on laplace.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.

  * Some are correctly UNSUPPORTED:

      * [[IFUNC]]

        Also multiversioning, `g++.dg/ext/mv*`, for example (several of which
        started FAILing (ICE) on kepler.SCHWINGE).

      * [[`asan.exp`|_san]]

      * missing profiling C library (`-lc_p`)

        `g++.old-deja/g++.law/profile1.C`, `gcc.dg/20021014-1.c`,
        `gcc.dg/nest.c`, `gcc.dg/nested-func-4.c`, `gcc.dg/pr32450.c`,
        `gcc.dg/pr43643.c`

      * other C libraries

        `gcc.target/i386/long-double-64-2.c`,
        `gcc.target/i386/long-double-80-3.c`

  * `gcc`

        spawn [open ...]
        FAIL: gcc.dg/split-2.c execution test

        FAIL: gcc.dg/split-5.c execution test

    TODO.

        xgcc: internal compiler error: Aborted (program cc1)
        libbacktrace could not find executable to open
        Please submit a full bug report, [...]
        FAIL: largefile.c  -O0 -g -I. -Dwith_PCH (internal compiler error)
        [...]

    TODO.

  * `g++`

        spawn [open ...]
        terminate called after throwing an instance of 'int'
        FAIL: g++.dg/eh/sighandle.C -std=gnu++98 execution test

        FAIL: g++.dg/eh/sighandle.C -std=gnu++11 execution test

    TODO.

        spawn [open ...]
        FAIL: g++.dg/cdce3.C -std=gnu++98 execution test

        FAIL: g++.dg/cdce3.C -std=gnu++11 execution test

    TODO.

  * `gcc`, `g++`

        FAIL: gcc.dg/cleanup-10.c execution test
        FAIL: gcc.dg/cleanup-11.c execution test
        FAIL: gcc.dg/cleanup-8.c execution test
        FAIL: gcc.dg/cleanup-9.c execution test
        FAIL: g++.dg/ext/cleanup-10.C -std=gnu++98 execution test
        FAIL: g++.dg/ext/cleanup-10.C -std=gnu++11 execution test
        FAIL: g++.dg/ext/cleanup-11.C -std=gnu++98 execution test
        FAIL: g++.dg/ext/cleanup-11.C -std=gnu++11 execution test
        FAIL: g++.dg/ext/cleanup-8.C -std=gnu++98 execution test
        FAIL: g++.dg/ext/cleanup-8.C -std=gnu++11 execution test
        FAIL: g++.dg/ext/cleanup-9.C -std=gnu++98 execution test
        FAIL: g++.dg/ext/cleanup-9.C -std=gnu++11 execution test

    TODO.

        spawn [open ...]
        gdb: took too long to attach
        testcase [...]/gcc/testsuite/gcc.dg/guality/guality.exp completed in 16 seconds

        spawn [open ...]
        gdb: took too long to attach
        testcase [...]/gcc/testsuite/g++.dg/guality/guality.exp completed in 20 seconds

    TODO.  The gfortran ones worked fine.

  * `[ARCH]/libgomp`

    As of dcdba5abca23716daa6aeb5c92f367e0978e4539 (2013-05-27;
    0479dc77cf50ee78769b55563051cf72d39b3d60 (2013-05-27)), plus
    `id:"87txlnlg0z.fsf@kepler.schwinge.homeip.net"`, about a dozen of them
    (but different ones per each run) FAIL on laplace.SCHWINGE:

        spawn [open ...]
        
        Program aborted. Backtrace:
        #0  0x1042523
        #1  0x1043D6F
        #2  0x10F9BC7
        FAIL: libgomp.fortran/lib1.f90  -O1  execution test

    All have basically the same backtrace.  TODO.

  * `[ARCH]/libjava`

        spawn [open ...]
        Exception in thread "main" java.io.IOException: Invalid argument
           at gnu.java.nio.channels.FileChannelImpl.write(natFileChannelImpl.cc:202)
           at java.io.FileOutputStream.write(libgcj.so.14)
           at java.io.DataOutputStream.write(libgcj.so.14)
           at java.io.RandomAccessFile.write(libgcj.so.14)
           at LargeFile.main(LargeFile.exe)
        FAIL: LargeFile execution - source compiled test
        UNTESTED: LargeFile output - source compiled test

        FAIL: LargeFile -findirect-dispatch execution - source compiled test
        UNTESTED: LargeFile -findirect-dispatch output - source compiled test
        FAIL: LargeFile -O3 execution - source compiled test
        UNTESTED: LargeFile -O3 output - source compiled test
        FAIL: LargeFile -O3 -findirect-dispatch execution - source compiled test
        UNTESTED: LargeFile -O3 -findirect-dispatch output - source compiled test

    TODO.

        spawn [open ...]
        1
        FAIL: Throw_2 execution - source compiled test
        UNTESTED: Throw_2 output - source compiled test

        FAIL: Throw_2 -findirect-dispatch execution - source compiled test
        UNTESTED: Throw_2 -findirect-dispatch output - source compiled test
        FAIL: Throw_2 -O3 execution - source compiled test
        UNTESTED: Throw_2 -O3 output - source compiled test
        FAIL: Throw_2 -O3 -findirect-dispatch execution - source compiled test
        UNTESTED: Throw_2 -O3 -findirect-dispatch output - source compiled test

    TODO.

  * `[ARCH]/libstdc++-v3`

        FAIL: libstdc++-abi/abi_check

    TODO.

        $ readelf --symbols --wide i686-unknown-gnu0.3/./libstdc++-v3/src/.libs/libstdc++.so | grep pthread_mutex
          1065: 00000000     0 FUNC    WEAK   DEFAULT  UND pthread_mutex_unlock@GLIBC_2.13_DEBIAN_31 (37)
          2515: 00000000     0 FUNC    WEAK   DEFAULT  UND pthread_mutex_lock@GLIBC_2.13_DEBIAN_31 (37)
          2978: 00068430    15 FUNC    GLOBAL DEFAULT   11 _ZNSt12__basic_fileIcEC2EP15__pthread_mutex@@GLIBCXX_3.4
          3790: 00068430    15 FUNC    GLOBAL DEFAULT   11 _ZNSt12__basic_fileIcEC1EP15__pthread_mutex@@GLIBCXX_3.4
          2085: 00000000     0 FUNC    WEAK   DEFAULT  UND pthread_mutex_unlock@@GLIBC_2.13_DEBIAN_31
          3535: 00000000     0 FUNC    WEAK   DEFAULT  UND pthread_mutex_lock@@GLIBC_2.13_DEBIAN_31
          3998: 00068430    15 FUNC    GLOBAL DEFAULT   11 _ZNSt12__basic_fileIcEC2EP15__pthread_mutex
          4810: 00068430    15 FUNC    GLOBAL DEFAULT   11 _ZNSt12__basic_fileIcEC1EP15__pthread_mutex

    `_ZNSt12__basic_fileIcEC1EP15__pthread_mutex`
    (`std::__basic_file<char>::__basic_file(__pthread_mutex*)`), but
    `_ZNSt12__basic_fileIcEC2EP15pthread_mutex_t`
    (`std::__basic_file<char>::__basic_file(pthread_mutex_t*)`) is expected.

        FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
        FAIL: 27_io/basic_filebuf/close/char/4879.cc execution test
        FAIL: 27_io/basic_filebuf/close/char/9964.cc execution test
        FAIL: 27_io/basic_filebuf/imbue/char/13171-2.cc execution test
        FAIL: 27_io/basic_filebuf/imbue/wchar_t/14975-2.cc execution test
        WARNING: program timed out.
        FAIL: 27_io/basic_filebuf/open/char/9507.cc execution test
        FAIL: 27_io/basic_filebuf/seekoff/char/26777.cc execution test
        WARNING: program timed out.
        FAIL: 27_io/basic_filebuf/showmanyc/char/9533-1.cc execution test
        FAIL: 27_io/basic_filebuf/underflow/char/10097.cc execution test
        FAIL: 27_io/objects/char/7.cc execution test
        FAIL: 27_io/objects/char/9661-1.cc execution test
        FAIL: 27_io/objects/wchar_t/7.cc execution test
        FAIL: 27_io/objects/wchar_t/9661-1.cc execution test
        FAIL: 30_threads/async/42819.cc execution test
        FAIL: 30_threads/async/49668.cc execution test
        FAIL: 30_threads/async/54297.cc execution test
        FAIL: 30_threads/async/any.cc execution test
        FAIL: 30_threads/async/async.cc execution test
        FAIL: 30_threads/async/sync.cc execution test
        FAIL: 30_threads/call_once/39909.cc execution test
        FAIL: 30_threads/call_once/49668.cc execution test
        FAIL: 30_threads/call_once/call_once1.cc execution test
        FAIL: 30_threads/condition_variable/54185.cc execution test
        FAIL: 30_threads/condition_variable_any/50862.cc execution test
        FAIL: 30_threads/condition_variable_any/53830.cc execution test
        FAIL: 30_threads/future/members/45133.cc execution test
        FAIL: 30_threads/future/members/get.cc execution test
        FAIL: 30_threads/future/members/get2.cc execution test
        FAIL: 30_threads/future/members/share.cc execution test
        FAIL: 30_threads/future/members/valid.cc execution test
        FAIL: 30_threads/future/members/wait.cc execution test
        FAIL: 30_threads/future/members/wait_for.cc execution test
        FAIL: 30_threads/future/members/wait_until.cc execution test
        FAIL: 30_threads/lock/2.cc execution test
        FAIL: 30_threads/lock/4.cc execution test
        FAIL: 30_threads/mutex/try_lock/2.cc execution test
        FAIL: 30_threads/packaged_task/49668.cc execution test
        FAIL: 30_threads/packaged_task/cons/3.cc execution test
        FAIL: 30_threads/packaged_task/cons/alloc.cc execution test
        FAIL: 30_threads/packaged_task/members/get_future.cc execution test
        FAIL: 30_threads/packaged_task/members/invoke.cc execution test
        FAIL: 30_threads/packaged_task/members/invoke2.cc execution test
        FAIL: 30_threads/packaged_task/members/invoke3.cc execution test
        FAIL: 30_threads/packaged_task/members/invoke4.cc execution test
        FAIL: 30_threads/packaged_task/members/invoke5.cc execution test
        FAIL: 30_threads/packaged_task/members/reset2.cc execution test
        FAIL: 30_threads/promise/cons/alloc.cc execution test
        FAIL: 30_threads/promise/cons/move.cc execution test
        FAIL: 30_threads/promise/cons/move_assign.cc execution test
        FAIL: 30_threads/promise/members/get_future.cc execution test
        FAIL: 30_threads/promise/members/set_exception.cc execution test
        FAIL: 30_threads/promise/members/set_exception2.cc execution test
        FAIL: 30_threads/promise/members/set_value.cc execution test
        FAIL: 30_threads/promise/members/set_value2.cc execution test
        FAIL: 30_threads/promise/members/set_value3.cc execution test
        FAIL: 30_threads/promise/members/swap.cc execution test
        FAIL: 30_threads/shared_future/members/get.cc execution test
        FAIL: 30_threads/shared_future/members/get2.cc execution test
        FAIL: 30_threads/shared_future/members/valid.cc execution test
        FAIL: 30_threads/shared_future/members/wait.cc execution test
        FAIL: 30_threads/shared_future/members/wait_for.cc execution test
        FAIL: 30_threads/shared_future/members/wait_until.cc execution test
        FAIL: 30_threads/this_thread/3.cc execution test
        FAIL: 30_threads/this_thread/4.cc execution test
        FAIL: 30_threads/thread/cons/2.cc execution test
        FAIL: 30_threads/thread/cons/3.cc execution test
        FAIL: 30_threads/thread/cons/4.cc execution test
        FAIL: 30_threads/thread/cons/49668.cc execution test
        FAIL: 30_threads/thread/cons/5.cc execution test
        FAIL: 30_threads/thread/cons/6.cc execution test
        FAIL: 30_threads/thread/cons/7.cc execution test
        FAIL: 30_threads/thread/cons/8.cc execution test
        FAIL: 30_threads/thread/cons/9.cc execution test
        FAIL: 30_threads/thread/cons/moveable.cc execution test
        FAIL: 30_threads/thread/members/1.cc execution test
        FAIL: 30_threads/thread/members/2.cc execution test
        FAIL: 30_threads/thread/members/3.cc execution test
        FAIL: 30_threads/thread/native_handle/cancel.cc execution test
        FAIL: 30_threads/thread/swap/1.cc execution test
        FAIL: 30_threads/timed_mutex/try_lock/2.cc execution test
        FAIL: 30_threads/timed_mutex/try_lock_for/3.cc execution test
        FAIL: 30_threads/timed_mutex/try_lock_until/2.cc execution test
        FAIL: 30_threads/try_lock/2.cc execution test
        FAIL: 30_threads/try_lock/4.cc execution test

    TODO.  Perhaps just timeouts?  [[!message-id
    "200609052027.NAA09861@hpsje.cup.hp.com"]].  [[!message-id
    "1227217275.6205.6.camel@janis-laptop"]].  If needed, can re-implement in
    GCC DejaGnu's `remote.exp:remote_wait` to get rid of (that is, ignore) its
    `timeout` parameter which, in DejaGnu code, is often invoked with a
    hard-coded value (that we may want to override) (or is that what
    `gcc/testsuite/lib/timeout.exp:standard_wait` is for?).

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


## 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"]]