[Bug libstdc++/60793] Add target *-*-dragonfly* to dg-options on 172 libstdc++ tests

["redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to John Marino from comment #4)
> For the matter of this particular PR, NetBSD is also a target so it's not a
> big stretch to imagine it's needed for all the BSD targets (and it is). 
> Plus there's really no downside if the target isn't really recognized, other
> than dejagnu clutter.

It's not that I don't believe you that it's needed, it's that we want to avoid
that clutter for a target that doesn't even build. You're trying to do this
backwards.

> Regarding *all* the patches:
> frankly I am apprehensive about the process.
> 
> For libc++:
> +++ libstdc++-v3/config/locale/dragonfly/c_locale.cc (new)
> +++ libstdc++-v3/config/locale/dragonfly/ctype_members.cc (new)
> +++ libstdc++-v3/config/os/bsd/dragonfly/ctype_base.h (new)
> +++ libstdc++-v3/config/os/bsd/dragonfly/ctype_configure_char.cc (new)
> +++ libstdc++-v3/config/os/bsd/dragonfly/ctype_inline.h (new)
> +++ libstdc++-v3/config/os/bsd/dragonfly/os_defines.h (new)
> +++ libstdc++-v3/acinclude.m4
> +++ libstdc++-v3/configure
> +++ libstdc++-v3/configure.host

This should be a single patch, sent to both the libstdc++ and gcc-patches
lists.

> for base/c:
> +++ gcc/config/dragonfly-stdint.h (new)
> +++ gcc/config/dragonfly.h (new)
> +++ gcc/config/dragonfly.opt (new)
> +++ gcc/config/i386/dragonfly.h (new)
> +++ gcc/ginclude/stddef.h
> +++ include/libiberty.h
> +++ libgcc/crtstuff.c
> +++ libgcc/enable-execute-stack-freebsd.c
> +++ libgcc/unwind-dw2-fde-dip.c
> +++ libgcc/config/i386/dragonfly-unwind.h
> +++ gcc/config.gcc
> +++ gcc/configure
> +++ gcc/Makefile.in
> +++ libgcc/config.host

I would expect these can be a single patch, or two or three related patches at
most. If you're not sure, post a single patch to the gcc-patches list for
review. If the relevant maintainers don't like it you'll be asked to split it
up.

> +++ libcilkrts/runtime/os-unix.c
> +++ libitm/configure.tgt

These are optional libraries, so tests can be run after configuring with e.g.
--disable-libitm until the patches are in (but they're probably small enough
changes that just including them with the rest of the gcc and libgcc changes
would be ok for a global reviewer to approve).

> It's pretty reasonable to leave off Ada as a separate effort, but c/c++/base
> should all be handled at the same time.  I really need somebody "on the
> inside" to help me with these.  I don't see this as 20 separate submissions

There'ss no way the files listed above should involve 20 separate submissions.
I'd guess two or three (not including Ada).

> but rather as a package.  Who would that person be?  Would you be that
> person?

I can help, but I don't really see what the problem is. Post the patches for
review and see what the relevant maintainers say. If you want to show that the
patches are correct, post before and after testresults. If you don't provide
testresults, expect to be asked for them.

Until then this is speculation and fixing failing tests is premature, because
they all fail until the compiler can be built.

> FWIW, I do have copyright assignment on file with FSF so there's no issue

Great.

> about copyright.  I just need a way to fast-track these.  And there's other
> patches too like the FreeBSD unwinder support.
> 
> Hopefully the sheer number makes my apprehension clear.

It's stage 1, now is the perfect  time to add support for a new target, but to
do that you need to post the patches, and preferably test results.

By asking for your patches to be accepted upstream you're asking the GCC
community to support your target. That's fine, and we welcome new targets, but
if noone runs tests for the target then we have no way of knowing if the
support still works, and it will eventually get removed again. Tests are
essential.