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

Boehm GC

GCC includes an own variant of Boehm GC that is based on an upstream version, but with own patches, etc. This is used for Java. (There are patches (apparently not committed) that GCC itself can use it, too: http://gcc.gnu.org/wiki/Garbage_collection_tuning.)

Patches to GCC's fork should be contributed back to upstream Boehm GC.

tschwinge reviewed (but only briefly for large parts) the differences on 2010-12-08, based on the GCC Git mirror's 8e79e9d43f32c8852f068da91d655297d92ac0f4 (2010-11-29) sources and Boehm GC's CVS HEAD sources from 2010-12-02, converted to Git, correspondingly 1c2455988a8f59a5f83b986b9156f03be395b3b6.

On 2010-11-17, tschwinge reviewed the Debian GCC Boehm GC changes, compared them to the upstream code, and put it into the local hurd/boehm-gc/config_backport branch, planning to submit it to gcc-patches after testing with the GCC testsuite.

  • Check

    • 02e191ba495b4ec87aeb961ff9afdb666287104a

    • ce062771587f6637ce09f79c36e24de691032919

    • a9cc177ef514d6eb39db72c82911fcea2cd70dba

    • 7b8d306d18986cd98808c9ed5d3a696a186dc213

      Looks generally OK.

    • a3a3fd06ae58af9591a95c94245809b0359289ff

      Looks OK.

    • fe5ef4a01870545d0344e670cd528ad096ebab1d

      OK.

Configuration

Last reviewed up to the Git mirror's 3d83581faf4eaf52c1cf52cc0d11cc7dd1264275 (2011-09-05) 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

    • libgomp/configure.tgt

    • libstdc++-v3/configure.host

      abi_baseline_pair etc. setting.

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

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

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

  • libmudflap.

  • Might -fsplit-stack be worthwhile w.r.t. our multithreaded libraries?

    • Also see libgcc/config/i386/morestack.S: comments w.r.t TARGET_THREAD_SPLIT_STACK_OFFSET; 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, but not usable via GCC proper.

    • gcc/config/gnu-user.h defines *SPLIT_STACK* macros -- which aren't valid for us (yet), I think.
  • --enable-languages=[...]

    • GNAT is not yet ported / bootstrapped?

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

    binutils gold

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

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

  • 34618b3190c110b8926cc2b1db4b4eac95451995

    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, testsuite] 5c7992866145620ffd0bc75b4f23298162b2c17f

    check_effective_target_pie should include *-*-gnu*, too.

  • [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__
    

Build

Here's a log of a GCC build run; this is from our Git repository's 93608b32ee627438dbe8a1844254bf8c305c5dc1 (2011-09-05) 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 2>&1 | tee log_build
[...]
$ make 2>&1 | tee log_build_
[...]

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

This takes up around 2.9 GiB, and needs roughly 2.75 h on kepler.SCHWINGE and 13.25 h on coulomb.SCHWINGE.

Analysis

$ diff -wu <(ssh kepler.SCHWINGE 'cd tmp/source/gcc/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' | sed -f open_issues/gcc/log_build-linux.sed) <(ssh coulomb.SCHWINGE 'cd tmp/gcc/ && cat hurd/master.build/log_build* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' | sed -f open_issues/gcc/log_build-hurd.sed) > open_issues/gcc/log_build.diff

log build.diff.

  • checking if gcc static flag -static works... no

    Addressed in Debian glibc.

  • DFP

    Addressed in hurd/decimal_floating_point branch.

    +configure: WARNING: decimal float is not supported for this target, ignored
    

    ... and later on:

    -checking for decimal floating point... bid
    +checking for decimal floating point... configure: WARNING: decimal float is not supported for this target, ignored
    +dpd
    

    ... and later on:

    -checking whether decimal floating point is supported... yes
    +checking whether decimal floating point is supported... no
    +configure: WARNING: decimal float is not supported for this target, ignored
    
    • libstdc++-v3/acinclude.m4: ISO/IEC TR 24733

      -checking for ISO/IEC TR 24733 ... yes
      +checking for ISO/IEC TR 24733 ... no
      
    • --enable-decimal-float, --enable-fixed-point, --with-long-double-128

      configure: WARNING: decimal float is not supported for this target, ignored

      • libgcc/configure.ac might need to be aligned for us to the *linux* cases. As well as at the end of libgcc/config.host. Check.

        checking whether decimal floating point is supported... no
        checking whether fixed-point is supported... no
        
  • host-linux.c vs. host-default.c

  • fixincludes stuff

  • malloc?

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

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

  • libgomp

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

    • -ftls-model=initial-exec -march=i486 -mtune=i686

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

  • RLIMIT_VMEM. Usage kosher?

  • basic_file.cc

    +basic_file.cc: In member function 'std::streamsize std::__basic_file<char>::showmanyc()':
    +basic_file.cc:347:33: warning: enumeral and non-enumeral type in conditional expression [enabled by default]
    
  • 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 ../.././gcc/gthr-default.h:1:0,
    +                 from [...]/hurd/master/libobjc/../gcc/gthr.h:160,
    +                 from [...]/hurd/master/libobjc/thr.c:45:
    +[...]/hurd/master/libobjc/../gcc/gthr-posix.h: In function '__gthread_objc_thread_set_priority':
    +[...]/hurd/master/libobjc/../gcc/gthr-posix.h:389: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 /lib64 /usr/lib64 
    +checking for the default library search path... /lib /usr/lib
    
  • ./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]
    
  • gnu/java/net/natPlainSocketImpl.cc

     libtool: compile:  [...]/hurd/master.build/./gcc/xgcc [...] -c gnu/java/net/natPlainSocketImpl.cc [...]
    +gnu/java/net/natPlainSocketImpl.cc: In member function 'virtual jint gnu::java::net::PlainSocketImpl::available()':
    +gnu/java/net/natPlainSocketImpl.cc:515:27: warning: enumeral and non-enumeral type in conditional expression [enabled by default]
    
  • gnu/java/nio/channels/natFileChannelImpl.cc

     libtool: compile:  [...]/hurd/master.build/./gcc/xgcc [...] -c gnu/java/nio/channels/natFileChannelImpl.cc [...]
    +gnu/java/nio/channels/natFileChannelImpl.cc: In member function 'jint gnu::java::nio::channels::FileChannelImpl::available()':
    +gnu/java/nio/channels/natFileChannelImpl.cc:388:20: warning: enumeral and non-enumeral type in conditional expression [enabled by default]
    
  • 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

Install

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

This takes up around 630 MiB, and needs roughly 4 min on kepler.SCHWINGE and 35 min on coulomb.SCHWINGE.

Analysis

$ diff -wu <(ssh kepler.SCHWINGE 'cd tmp/source/gcc/ && cat hurd/master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' | sed -f open_issues/gcc/log_install-linux.sed) <(ssh coulomb.SCHWINGE 'cd tmp/gcc/ && cat hurd/master.build/log_install | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' | sed -f open_issues/gcc/log_install-hurd.sed) > open_issues/gcc/log_install.diff

log install.diff.

  • libtool: finish: ldconfig is not run for the Hurd.

  • libjvm.la, .libs/libjvm.so, libgij.la, .libs/libgij.so.12.0.0

    -Wl,-Bsymbolic vs. -Wl,-Bsymbolic-functions (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.

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

This needs roughly TODO min on kepler.SCHWINGE and TODO min on coulomb.SCHWINGE.

$ ssh kepler.SCHWINGE 'cd tmp/source/gcc/ && sed < hurd/master.build/gcc/TODO -e "s%\(/media/data\)\?${PWD}%[...]%g"' > open_issues/gcc/sum_linux
$ ssh coulomb.SCHWINGE 'cd tmp/gcc/ && sed < hurd/master.build/gcc/TODO -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > open_issues/gcc/sum_hurd

Comparing the results files, ?sum linux to ?sum hurd:

$ diff -u -F ^Running open_issues/gcc/sum_linux open_issues/gcc/sum_hurd > open_issues/gcc/sum.diff

?sum.diff.

Analysis

TODO.

Specific Languages