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
Build
1. Analysis
Install
1. Analysis
Testsuite
1. Analysis
2. Enhancements

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.
- Eventually: get rid of this special-casing. id:"gckk1s$e0b$1@ger.gmane.org".
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)
- Ada (GNAT) support is work in progress.
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

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

A lot of the failures are due to gcc's unwind support not knowing about signal trampoline on GNU/Hurd, this is a TODO.

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

General information

Sources

Configuration

Build

Analysis

Install

Analysis

Testsuite

Analysis

Enhancements

contrib/testsuite-management/, contrib/regression/

Parallel Testing

Distributed Testing

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

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

id:"4FC7791E.6040407@gmail.com"

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

`id:"4FC7791E.6040407@gmail.com"`