path: root/open_issues/gcc.mdwn

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

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

[[!tag open_issue_gcc]]

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

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

[[!toc levels=2]]


# [[General information|/gcc]]


# [[Sources|source_repositories/gcc]]


## 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|source_repositories/GCC]] and Boehm GC's CVS HEAD sources from
2010-12-02, converted to [[Git, correspondingly
1c2455988a8f59a5f83b986b9156f03be395b3b6|source_repositories/boehm_gc]].

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.


# Configuration

Last reviewed up to the [[Git mirror's 6678cb4ef6c7d8d9232249b5d722a0d6dfd328b5
(2011-07-22) sources|source_repositories/gcc]].

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

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

      * `configure.ac`

      * `libgomp/configure.tgt`

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

        `abi_baseline_pair` etc. setting.

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

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

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

  * [[`libmudflap`|libmudflap]].

  * Might [`-fsplit-stack`](http://nickclifton.livejournal.com/6889.html) 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-build-with-cxx`

  * `--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|tschwinge]] is working
    on getting them integrated.

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

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

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

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


# Build

  * Waiting: ef3c41c78d877ac478ddaac3942243f9bd0844f3 switches to g++.

Here's a log of a GCC build run; this is from our [[Git repository's
09ba3e78c07654e08c8bef82761dbbb26d3c00c9 (2011-07-18)
sources|source_repositories/gcc]], run on kepler.SCHWINGE and coulomb.SCHWINGE.

    $ export LC_ALL=C
    $ (cd ../master/ && contrib/gcc_update --touch)
    $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build
    [...]
    $ LIBRARY_PATH=$(echo /usr/lib/i386*-gnu) make 2>&1 | tee log_build_
    [...]

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

Setting `LIBRARY_PATH` is needed until [[!debbug 629819]] is resolved.

This takes up around 2.3 GiB, and needs roughly 2.75 h on kepler.SCHWINGE, and
11 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`|glibc_madvise_vs_static_linking]]

    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](http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00315.html) 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

  * *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 ([[!taglink open_issue_hurd]])?

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

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


# Install

    $ LIBRARY_PATH=$(echo /usr/lib/i386*-gnu) make install 2>&1 | tee log_install
    [...]

Setting `LIBRARY_PATH` is needed until [[!debbug 629819]] is resolved.

This takes up around 0.6 GiB, 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>

    $ LIBRARY_PATH=$(echo /usr/lib/i386*-gnu) make -k check 2>&1 | tee log_check
    [...]

Setting `LIBRARY_PATH` is needed until [[!debbug 629819]] is resolved.

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


## Analysis


# Specific Languages

  * [[GNAT]]

  * [[gccgo]]