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.

<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

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.

<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

<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

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

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:

TODO. Seems like not just timeouts (though, reported before: GCC [BZ #20003]). If GDB is to believed, it seems like confusion between
libmudflap and glibc startup (while setting up the signal thread?):

TODO. Perhaps just timeouts? id:"200609052027.NAA09861@hpsje.cup.hp.com". id:"1227217275.6205.6.camel@janis-laptop". If needed, can re-implement in
GCC DejaGnu's remote.exp:remote_wait to get rid of (that is, ignore) its
timeout parameter which, in DejaGnu code, is often invoked with a
hard-coded value (that we may want to override) (or is that what
gcc/testsuite/lib/timeout.exp:standard_wait is for?). While at it,
libmudflap/testsuite/libmudflap.c++/ctors.exp and
libmudflap/testsuite/libmudflap.c/externs.exp use hard-coded timeout
values in remote_wait calls (also, why don't these use the usual way of
running tests?).

What is gcc/testsuite/gcc.test-framework/test-framework.exp and should we
define CHECK_TEST_FRAMEWORK to run these tests?

Enhancements

contrib/testsuite-management/, contrib/regression/

35a27ee8c4b349fea44fd1fadc9614ab3cc9d578 Add an xfail manifest for
x86_64-unknown-linux-gnu to trunk.

Parallel Testing

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.

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.