diff options
Diffstat (limited to 'open_issues/gcc.mdwn')
| -rw-r--r-- | open_issues/gcc.mdwn | 531 |
1 files changed, 509 insertions, 22 deletions
diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn index 76832165..d9940716 100644 --- a/open_issues/gcc.mdwn +++ b/open_issues/gcc.mdwn @@ -1,20 +1,131 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!tag open_issue_porting open_issue_gcc fixed_in_debian]] +[[!tag open_issue_gcc]] -For GCC trunk: +Here's what's to be done for maintaining GCC. -Debian package has patches (for 4.3). Some have been forwarded upstream. (And -have been ignored.) [[Thomas_Schwinge|tschwinge]] is working on getting them -integrated. +Apart from the target-specific configuration machinery, there shouldn't be any +major differences within GCC between the GNU/Hurd and GNU/Linux ports, for +example. Especially all the compiler magic is all the same. + +[[!toc levels=2]] + + +# [[General information|/gcc]] + + +# [[Sources|source_repositories/gcc]] + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc ..upstream/trunk +-i +/^commit |^---$|hurd|linux|nptl|glibc + +--> + +Last reviewed up to the [[Git mirror's dfed30bca14de84e0446cc02f5a27407dbfdc3e1 +(2012-06-11) 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-user` to reflect this? + + * `gcc/acinclude.m4`:`gcc_GAS_FLAGS`: always pass `--32` to assembler for + x86 Linux. (Why?) + + * `hurd/usr` + + `NATIVE_SYSTEM_HEADER_DIR`, `638454a19c1c08f01c10517bc72a114250fc4f33`, + [[!message-id "mcrzkhcbftp.fsf@coign.corp.google.com"]]. + + Debian. + + * Eventually: get rid of this special-casing. [[!message-id + "gckk1s$e0b$1@ger.gmane.org"]]. + + * [[`libmudflap`|libmudflap]]. + + * Might [`-fsplit-stack`](http://nickclifton.livejournal.com/6889.html) be + worthwhile w.r.t. our [[multithreaded|multithreading]] 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|tschwinge]] is working + on getting them integrated. * [\[meta-bug\] bootstrap bugs for \*-gnu\*](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824) @@ -25,26 +136,402 @@ integrated. * [-fstack-protector shouldn't use TLS in freestanding mode](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838) - * [Tool chain configuration: GNU/\* sharing stuff with - GNU/Linux](http://gcc.gnu.org/ml/gcc/2007-11/msg00289.html) + * 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. -Additionally: + * Various testsuite bits should include `*-*-gnu*`, too. - * Configure fragments that have `*linux*` cases might/should often contain - those for us (and GNU/k*BSD) as well. + * [low] [[toolchain/cross-gnu]] toolchain bootstrap vs. `fenv.h` in libgcc's + libbid: - * `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. + [...]/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 - checking whether decimal floating point is supported... no - checking whether fixed-point is supported... no + See threads at [[!message-id + "AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]], + [[!message-id "20110328225532.GE5293@synopsys.com"]], [[!message-id + "4D52D522.1040804@gmail.com"]]. Can simply configure the first GCC with + `--disable-decimal-float`. - * `libgomp/configure.tgt` + 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`. - * [[`libmudflap`|libmudflap]]. + * [low] [[toolchain/cross-gnu]] + + The directory that should contain system headers does not exist: + /media/boole-data/thomas/tmp/gnu-0/sys_root/usr/include + make[2]: *** [stmp-fixinc] Error 1 + make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/gcc' + make[1]: *** [all-gcc] Error 2 + make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj' + + `mkdir` the directory for now, but what is really going on? GCC has *use + `/usr/include` patch*, but glibc still installs into `/include/`? + + * `__GLIBC__` + + IRC, freenode, #hurd, 2012-01-05: + + <civodul> on GNU/kFreeBSD, it's GCC that defines __GLIBC__, funny + <youpi> ?? + <youpi> not from features.h ? + <civodul> in gcc/config/kfreebsd-gnu.h + <civodul> :-) + <pinotree> correct, it's enabled in gcc's config + <pinotree> i discovered that after banging my head on the wall trying + to find out why some stuff wasn't compiling even after kfreebsd + porting patches adding preprocessors checks for __GLIBC__ + + IRC, freenode, #hurd, 2012-05-25: + + <gnu_srs> Hi, looks like __GLIBC__ is not defined by default for GNU? + <gnu_srs> touch foo.h; cpp -dM foo.h|grep LIBC: empty + <braunr> gnu_srs: well, this only tells your the compiler defaults + <tschwinge> gnu_srs: See the email I just sent. + + [[!message-id "87396od3ej.fsf@schwinge.name"]] + + <braunr> __GLIBC__ would probably be introduced by a glibc header + <gnu_srs> tschwinge: I saw your email. I wonder if features.h is + included in the kFreeBSD build of webkit. + <gnu_srs> It is defined in their build, but not in the Hurd build. + <pinotree> gcc on kfreebsd unconditionally defines __GLIBC__ + <pinotree> (a bit stupid choice imho, but hardly something that could + be changed now...) + <braunr> :/ + <braunr> personally i don't consider this only "a bit" stupid, as + kfreebsd is one of the various efforts pushing towards portability + <braunr> and using such hacks actually hinders portability ... + <pinotree> yeah don't tell me, i can remember at least half dozen of + occasions when a code wouldn't have been compiling at all on other + glibc platforms otherwise + <pinotree> sure, i have nothing against kfreebsd's efforts, but making + gcc define something which is proper of the libc used is stupid + <braunr> it is + <pinotree> i spotted changes like: + <pinotree> -#ifdef __linux + <pinotree> +#if defined(__linux__) || defined(__GLIBC__) + <pinotree> and wondered why they wouldn't work at all for us... and + then realized there were no #include in that file before that + preprocessor check + <tschwinge> This is even in upstream GCC gcc/config/kfreebsd-gnu.h: + <tschwinge> #define GNU_USER_TARGET_OS_CPP_BUILTINS() \ + <tschwinge> do \ + <tschwinge> { \ + <tschwinge> builtin_define ("__FreeBSD_kernel__"); \ + <tschwinge> builtin_define ("__GLIBC__"); \ + <tschwinge> builtin_define_std ("unix"); \ + <tschwinge> builtin_assert ("system=unix"); \ + <tschwinge> builtin_assert ("system=posix"); \ + <tschwinge> } \ + <tschwinge> while (0) + <tschwinge> I might raise this upstream at some point. + <pinotree> tschwinge: i could guess the change was proposed by the + kfreebsd people, so asking them before at d-bsd@d.o would be a start + <tschwinge> pinotree: Ack. + <pinotree> especially that they would need to fix stuff afterwards + <pinotree> imho we could propose them the change, and if they agree put + that as local patch to debian's gcc4.6/.7 after wheezy, so there is + plenty of time for them to fix stuff + <pinotree> what should be done first is, however, find out why that + define has been added to gcc + + * [low] Does `-mcpu=native` etc. work? (For example, + 2ae1f0cc764e998bfc684d662aba0497e8723e52.) + + * transactional memory, 4c0315d05fa0f707875686abc4f91f7a979a7c7b + + * `config/mmap.m4` + + * In `libitm/config/`, is the generic stuff (`tls.h`, etc.) enough for + us? + + * f29a2041f32773464e226a83f41762c2e9cf658e + (e53a96c2136f7cdff4699475fea41afeed9dece3) + + Testresults same as for GNU/Linux. + + * [high] 3efc00f6f17778172d3fa7ac737fa1473b3b4d5a, `Check __GLIBC__ when + using __SIGRTMIN`. GCC PR52390. Fixed by + 8d2259c83f94c082ad8a00b5d00bb639ce24efce. + + * 15ac1e637ad0cb92bf7629205c617ea847a4b810 `Build 64-bit libffi multilib for + i?86-linux`. + + * `libstdc++`: uses `_GLIBCXX_HAVE_TLS`, but where is this defined? Supposed + to come from `config/tls.m4:GCC_CHECK_TLS`? + + * `libgcc/gthr-posix.h:__gthread_active_p` -- is this suitable for us? This + is used in libgcc for ObjC wrapper stuff and similar in libstdc++. + C.f. [[!message-id "x57jobtqx89w.fsf@frobland.mtv.corp.google.com"]], + [[!message-id "x57jd359fkx3.fsf@frobland.mtv.corp.google.com"]] as well as + [[!debbug 629866]]/[[!message-id + "20110609002620.GA16719@const.famille.thibault.fr"]]. + + +# Build + +Here's a log of a GCC build run; this is from our [[Git repository's +2e2db3f92b534460c68c2f9ae64455884424beb6 (2012-06-15; 2012-06-06) +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 --enable-build-with-cxx --enable-languages=all,ada 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +harmonized. + +This takes up around 3.1 GiB, and needs roughly 3.0 h on kepler.SCHWINGE and +12.75 h on coulomb.SCHWINGE. + +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && make -k RUNTESTFLAGS=-v check 2>&1 | tee log_check + +--> + + +## Analysis + + $ toolchain/logs/process gcc build + + * [[`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 + + 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` + + `sed`ed away. + + * `-ftls-model=initial-exec -march=i486 -mtune=i686` + + `sed`ed away. + + * 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 /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] + + * `libgcj.la` + + Just different order of object files, or another problem? + + Is there a pattern that GNU/Hurd hands out the files alphabetically sorted + where it wouldn't need to ([[!taglink open_issue_hurd]])? + + * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0` + + `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` + + * `jar` + + make[2]: Entering directory `[...]/hurd/master.build/[ARCH]/libjava' + -: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=[...]/hurd/master.build/[ARCH]/libjava/scripts/jar" DO=all multi-do + +: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=jar" DO=all multi-do + + Probably because kepler.SCHWINGE has an OpenJDK `/usr/bin/jar`, and + coulomb.SCHWINGE a GCJ one. + + There are other instances of this in the following. + + * *default library search path* + + -checking for the default library search path... /lib /usr/lib /lib/[MULTIARCH] /usr/lib/[MULTIARCH] /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 + + Should be aligned by Samuel's binutils patch. + + * `value-unwind.h` + + -DEFINES='' HEADERS='../../../master/libgcc/config/i386/value-unwind.h' \ + +DEFINES='' HEADERS='' \ + ../../../master/libgcc/mkheader.sh > tmp-libgcc_tm.h + + Comes from `gcc/config.gcc`: for `i[34567]86-*-linux*` + vs. `i[34567]86-*-*`, but apparently is important only for *x86_64* anyway. + + * `soft-fp` prototypes + + ../../../master/libgcc/soft-fp/eqtf2.c:34:9: warning: no previous prototype for '__eqtf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/eqtf2.c:50:1: warning: no previous prototype for '__netf2' [-Wmissing-prototypes] + + ../../../master/libgcc/soft-fp/getf2.c:34:9: warning: no previous prototype for '__getf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/getf2.c:50:1: warning: no previous prototype for '__gttf2' [-Wmissing-prototypes] + + ../../../master/libgcc/soft-fp/letf2.c:34:9: warning: no previous prototype for '__letf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/letf2.c:50:1: warning: no previous prototype for '__lttf2' [-Wmissing-prototypes] + + * `libatomic` on GNU/Linux compiles several more files than on GNU/Hurd. Is + that correct? Probably futex support. + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around 850 MiB, and needs roughly 4 min on kepler.SCHWINGE and 45 +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. Can use parallel testing, see [[!message-id +"20110331070322.GI11563@sunsite.ms.mff.cuni.cz"]]. + + $ make -k RUNTESTFLAGS=-v check 2>&1 | tee log_check + [...] + +This needs roughly 6.5 h on kepler.SCHWINGE and 50.25 h on coulomb.SCHWINGE. + + +## Analysis + + $ toolchain/logs/process gcc test + +TODO. + + +# Specific Languages + + * [[GNAT]] - * [[C++]]. + * [[gccgo]] |