diff options
| author | https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14 <diana@web> | 2015-02-16 20:08:03 +0100 |
|---|---|---|
| committer | GNU Hurd web pages engine <web-hurd@gnu.org> | 2015-02-16 20:08:03 +0100 |
| commit | 95878586ec7611791f4001a4ee17abf943fae3c1 (patch) | |
| tree | 847cf658ab3c3208a296202194b16a6550b243cf /open_issues/gcc.mdwn | |
| parent | 8063426bf7848411b0ef3626d57be8cb4826715e (diff) | |
rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn
Diffstat (limited to 'open_issues/gcc.mdwn')
| -rw-r--r-- | open_issues/gcc.mdwn | 1354 |
1 files changed, 0 insertions, 1354 deletions
diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn deleted file mode 100644 index a2a67632..00000000 --- a/open_issues/gcc.mdwn +++ /dev/null @@ -1,1354 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 -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]] - - -# Configuration - -<!-- - -git checkout reviewed -git diff --patience --stat=$COLUMNS,$COLUMNS --patch --src-prefix=./ --dst-prefix=./ --find-renames --ignore-space-change ..upstream/master | awk '/^diff/ { c = $0; } /^@@/ { print c; } { print; }' | less --i -/^---.*/([^.]*|.*\.texi.*|[^/]*gnu[^/]*)$|hurd|linux|nacl|nptl|glibc|gs: - ---> - -Last reviewed up to the [[Git mirror's 3a930d3fc68785662f5f3f4af02474cb21a62056 -(2013-06-06) 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` - - * `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]] ([[!taglink - 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. [[!taglink 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`, - [[!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]]. - - * [`-fsplit-stack`](http://nickclifton.livejournal.com/6889.html) - - 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_PR 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|multithreading]] libraries? - - * `gcc/ada`, `gcc/testsuite/ada`, `gcc/testsuite/gnat.dg`, `gnattools`, - `libada` (not reviewed) - - * [[Ada (GNAT)|GNAT]] support is work in progress. - - * `gcc/go`, `gcc/testsuite/go.test`, `libgo` (not reviewed) - - * The [[Google Go's libgo|gccgo]] (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|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) - - * 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] [[toolchain/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 [[!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`. - - 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] [[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__ - - 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. - - [[!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 - - [[!message-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. [[!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"]]. commit - 026e608ecebcb2a6193971006a85276307d79b00. - - * [[`libsanitizer`|_san]] (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. - - [[!debbug 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|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-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. - -<!-- - - $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && make -k check 2>&1 | tee log_test - ---> - - -## Analysis - - $ toolchain/logs/process gcc build - - * [[`checking if gcc static flag -static - works... no`|glibc_madvise_vs_static_linking]] - - 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` - - `sed`ed away in `log_build*`. TODO. - - * `-march=i486 -mtune=i686` - - `sed`ed 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 ([[!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. - - * `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`|_san]] - - * 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_PR - 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? [[!message-id - "200609052027.NAA09861@hpsje.cup.hp.com"]]. [[!message-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 - -[[!message-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. - -##### [[!message-id "4FC7791E.6040407@gmail.com"]] |