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.

General information

Sources

Configuration

Last reviewed up to the Git mirror's 3a930d3fc68785662f5f3f4af02474cb21a62056 (2013-06-06) sources.

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. (Why?)

    • 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 (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. open issue gdb.

    • libgcc

      TODO:

      • config/t-linux
      • config/i386/t-linux
      • config/i386/linux-unwind.h
    • libitm

      TODO:

      • libitm/config/linux
  • hurd/usr

    NATIVE_SYSTEM_HEADER_DIR, 638454a19c1c08f01c10517bc72a114250fc4f33, id:"mcrzkhcbftp.fsf@coign.corp.google.com".

    Debian.

  • libmudflap.

  • -fsplit-stack

    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 [BZ #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 libraries?

  • gcc/ada, gcc/testsuite/ada, gcc/testsuite/gnat.dg, gnattools, libada (not reviewed)

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

    • The Google Go's libgo (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 is working on getting them integrated.

  • [meta-bug] bootstrap bugs for *-gnu*

  • build system: gcc_cv_libc_provides_ssp and NATIVE_SYSTEM_HEADER_DIR

  • -fstack-protector shouldn't use TLS in freestanding mode

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

  • [low] 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 id:"AANLkTinY1Cd4 qO 9euYJN8zev4hdr7 ANpjNG+yGRMn@mail.gmail.com", id:"20110328225532.GE5293@synopsys.com", 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] 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.
    

    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
    

    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. id:"x57jobtqx89w.fsf@frobland.mtv.corp.google.com", id:"x57jd359fkx3.fsf@frobland.mtv.corp.google.com" as well as Debian bug #629866/id:"20110609002620.GA16719@const.famille.thibault.fr". commit 026e608ecebcb2a6193971006a85276307d79b00.

  • libsanitizer (not reviewed)

    A lot of Linux-specific things.

  • libcilkrts

    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.
    

    Debian bug #734973.

  • WCONTINUED

    IRC, OFTC, #debian-hurd, 2014-02-25:

    <gnu_srs> youpi: some gcc-4.9 packages (and source) are needed for
      gnat-4.9 to build: Is it OK to propose this patch:
      http://paste.debian.net/84079/
      --- a/src/gcc/lto_lto.c.orig    2014-02-14 19:22:14.000000000 +0100
      +++ b/src/gcc/lto/lto.c 2014-02-25 20:50:20.000000000 +0100
      @@ -2476,7 +2476,11 @@
         int status;
         do
           {
      +#ifdef __GNU__
      +      int w = waitpid(0, &status, WUNTRACED);
      +#else
             int w = waitpid(0, &status, WUNTRACED | WCONTINUED);
      +#endif
             if (w == -1)
              fatal_error ("waitpid failed");
    <youpi> gnu_srs: rather ifndef WCONTINUED
    

Build

Here's a log of a GCC build run; this is from our Git repository's 2a3496bebfe9d89f11d0b7a591afac55e11d5263 (2013-06-06; 3a930d3fc68785662f5f3f4af02474cb21a62056 (2013-06-06)) sources, 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/gnat-4.8 packages avaible.

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

Analysis

$ toolchain/logs/process gcc build
  • checking if gcc static flag -static works... no

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

  • libgomp

    • libgomp/config/linux, libgomp/config/linux/x86

    seded away in log_build*. TODO.

    • -march=i486 -mtune=i686

    seded 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 (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.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 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.5 h on kepler.SCHWINGE and 3.75 h (check-fixincludes, gcc/check-ada) + 14 h (gcc/check-c) + 4.5 h (gcc/check-c++) + 7.25 h (gcc/check-fortran, gcc/check-java, gcc/check-lto, gcc/check-objc) + 10.25 h (check-intl, [...], check-lto-plugin, check-target) = 39.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.

  • Some are correctly UNSUPPORTED:

    • IFUNC

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

    • SSE2 (sse2_runtime)

      g++.dg/other/i386-1.C, g++.dg/other/pr40446.C, g++.dg/other/pr49133.C, gcc.dg/compat/union-m128-1_main.c, gcc.dg/compat/vector-1a_main.c, gcc.dg/compat/vector-2a_main.c, gcc.dg/pr36584.c, gcc.dg/pr37544.c, gcc.dg/torture/pr16104-1.c, gcc.dg/torture/pr35771-1.c, gcc.dg/torture/pr50444.c, gcc.dg/torture/stackalign/alloca-2.c, gcc.dg/torture/stackalign/alloca-3.c, gcc.dg/torture/stackalign/push-1.c, gcc.dg/torture/stackalign/vararg-3.c, gcc.target/i386/pr39315-2.c, gcc.target/i386/pr39315-4.c, gcc.target/i386/pr44948-2a.c, gcc.target/i386/pr46880.c, gcc.target/i386/pr52736.c, gcc.target/i386/pr54703.c, gcc.target/i386/sse2-extract-1.c, several from gfortran.fortran-torture

    • asan.exp

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

    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, but FAIL as of 769bf18a20ee2540ca7601cdafabd62b18b9751b..be3860ba8df48cca3253da4f02fd2d42d856ce80. TODO.

    -PASS: g++.dg/vect/pr36648.cc -std=c++98 execution test
    -PASS: g++.dg/vect/pr36648.cc -std=c++11 execution test
    

    On kepler.SCHWINGE, executables are generated (and run), on coulomb.SCHWINGE only assembler code is generated. TODO. Likewise for execution tests from gcc.dg/vect and gfortran.dg/vect.

  • 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 coulomb.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]/libmudflap

    spawn [open ...]
    FAIL: libmudflap.cth/pass37-frag.c (-O0) execution test
    FAIL: libmudflap.cth/pass37-frag.c (-O0) output pattern test
    
    
    FAIL: libmudflap.cth/pass37-frag.c (-O0) (rerun 1) execution test
    FAIL: libmudflap.cth/pass37-frag.c (-O0) (rerun 1) output pattern test
    [...]
    

    TODO. Seems like not just timeouts (though, reported before: GCC [BZ #20003]). If GDB is to believed, it seems like confusion between libmudflap and glibc startup (while setting up the signal thread?):

    #0  getenv (name=0x12dabee "LANGUAGE") at getenv.c:81
    #1  0x011b2c78 in guess_category_value (categoryname=<optimized out>, category=<optimized out>) at dcigettext.c:1359
    #2  __dcigettext (domainname=0x12dab1b <_libc_intl_domainname> "libc", msgid1=0x12e1cd8 "Error in unknown error system: ", msgid2=0x0, plural=0, n=0, category=5) at dcigettext.c:575
    #3  0x011b1c53 in __dcgettext (domainname=0x12dab1b <_libc_intl_domainname> "libc", msgid=0x12e1cd8 "Error in unknown error system: ", category=5) at dcgettext.c:53
    #4  0x01203728 in __strerror_r (errnum=-1, buf=0x15ff648 "", buflen=1024) at ../sysdeps/mach/_strerror.c:57
    #5  0x011b0f30 in __assert_perror_fail (errnum=-1, file=0x1133969 "./pthread/cthreads-compat.c", line=45, function=0x1133985 <__PRETTY_FUNCTION__.5356> "cthread_fork") at assert-perr.c:62
    #6  0x011324d4 in cthread_fork (func=0x118b0b0 <_hurd_msgport_receive>, arg=0x0) at ./pthread/cthreads-compat.c:45
    #7  0x01192a96 in _hurdsig_init (intarray=0x102a000, intarraysize=5) at hurdsig.c:1499
    #8  0x0117b9f8 in _hurd_new_proc_init (argv=0x15ffb88, intarray=0x102a000, intarraysize=5) at hurdinit.c:138
    #9  0x0117bfef in _hurd_init (flags=8, argv=0x15ffb88, portarray=0x1029000, portarraysize=6, intarray=0x102a000, intarraysize=5) at hurdinit.c:94
    #10 0x011a47c4 in init1 (argc=1, arg0=0x1025000 "/media/erich/home/thomas/tmp/gcc/hurd/master.build/i686-unknown-gnu0.3/libmudflap/testsuite/pass37-frag.exe") at ../sysdeps/mach/hurd/i386/init-first.c:136
    #11 0x00001ec6 in _dl_start_user () from /lib/ld.so
    

    pthread/cthreads-compat.c:

        38  cthread_t
        39  cthread_fork (cthread_fn_t func, void *arg)
        40  {
        41    pthread_t thread;
        42    int err;
        43
        44    err = pthread_create (&thread, NULL, func, arg);
        45    assert_perror (err);
    
    
    Breakpoint 2, cthread_fork (func=0x118b0b0 <_hurd_msgport_receive>, arg=0x0) at ./pthread/cthreads-compat.c:44
    44        err = pthread_create (&thread, NULL, func, arg);
    (gdb) info threads 
      Id   Target Id         Frame 
    * 4    Thread 17597.16   cthread_fork (func=0x118b0b0 <_hurd_msgport_receive>, arg=0x0) at ./pthread/cthreads-compat.c:44
    (gdb) s
    40      {
    (gdb) 
    44        err = pthread_create (&thread, NULL, func, arg);
    (gdb) 
    
    
    Breakpoint 1, pthread_create (thr=0x15ffa70, attr=0x0, start=0x118b0b0 <_hurd_msgport_receive>, arg=0x0) at ../../../master/libmudflap/mf-hooks3.c:272
    272     {
    (gdb) s
    275       TRACE ("pthread_create\n");
    (gdb) 
    278       si = CALL_REAL (malloc, sizeof (*si));
    (gdb) n
    279       si->user_fn = start;
    (gdb) 
    283       return CALL_REAL (pthread_create, thr, attr, __mf_pthread_spawner, si);
    (gdb) s
    279       si->user_fn = start;
    (gdb) 
    280       si->user_arg = arg;
    (gdb) 
    283       return CALL_REAL (pthread_create, thr, attr, __mf_pthread_spawner, si);
    (gdb) 
    280       si->user_arg = arg;
    (gdb) 
    283       return CALL_REAL (pthread_create, thr, attr, __mf_pthread_spawner, si);
    (gdb) 
    __mf_0fn_pthread_create (thr=thr@entry=0x15ffa70, attr=attr@entry=0x0, start=start@entry=0x1041070 <__mf_pthread_spawner>, arg=arg@entry=0x108e520 <__mf_0fn_bufs+12288>) at ../../../master/libmudflap/mf-hooks3.c:265
    265     }
    (gdb) s
    pthread_create (thr=0x15ffa70, attr=0x0, start=0x118b0b0 <_hurd_msgport_receive>, arg=0x0) at ../../../master/libmudflap/mf-hooks3.c:284
    284     }
    (gdb) s
    cthread_fork (func=0x118b0b0 <_hurd_msgport_receive>, arg=0x0) at ./pthread/cthreads-compat.c:45
    45        assert_perror (err);
    (gdb) s
    __assert_perror_fail (errnum=-1, file=0x1133969 "./pthread/cthreads-compat.c", line=45, function=0x1133985 <__PRETTY_FUNCTION__.5356> "cthread_fork") at assert-perr.c:55
    

    Is this libmudflap/mf-hooks3.c:__mf_0fn_pthread_create, a special bootstrap variant, that indeed just returns -1?

  • [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? id:"200609052027.NAA09861@hpsje.cup.hp.com". 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?). While at it, libmudflap/testsuite/libmudflap.c++/ctors.exp and libmudflap/testsuite/libmudflap.c/externs.exp use hard-coded timeout values in remote_wait calls (also, why don't these use the usual way of running tests?).

  • 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

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.
id:"4FC7791E.6040407@gmail.com"