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

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to John Marino from comment #6)
> I was too indirect.  My apprehension is that I'm afraid I'll generate a
> bunch of patches that will just be ignored / not evaluated, and then bitrot.
> There's a reputation for that, and the more files that get touched, the more
> likely that is to happen.  Hence my impression I need a "champion" for the
> cause.

You don't need a champion, you need to provide tests results. That is what it
takes to show that the support works, and if you keep providing them fairly
regularly (once a month is OK) then it shows whether support is bitrotting or
not.

The bottom line is that if no dragonfly users care enough to provide test
results then the GCC project won't care enough to maintain upstream dragonfly
support.

I've spent some time improving NetBSD and FreeBSD support, so I'll try to
install a dragonfly VM this week. Feel free to CC me on your patch submissions,
but I haven't used BSD for anything serious for many years and so am not in a
position to take ownership of target support.

> which ironically puts it back in the partial support zone (assuming not all
> patches are accepted) that you want to avoid.

I'm not suggesting you'll be asking to split it up so some patches can be not
accepted, just split it up to make it tractable for the relevant maintainers to
review.

Post a single patch. If the relevant maintainers suggest to split it up and get
pieces reviewed separately then do that. Patches for new targets are unlikely
to just get rejected, but you might be asked to improve them before they are
accepted.

> I've had copyright assignment for years but haven't submitted anything
> substantial because of my limited time and worry that I'll have to chase the
> patches and hound and beg and then do some kind of full bootstrap testing
> that I'm not prepared to do.

Any patches to the base gcc and libgcc directories do need to be bootstrapped
and tested before submission, that's not unreasonable!

> well - i see that from your POV but from my POV the compiler can be built
> with external patches and this fixes the testsuite.  (although I can work
> around it with a file list and sed)

If it can only be built with external patches then it's reasonable that it can
only be tested with external patches.

I am not going to accept patches to the libstdc++ testsuite for a target that
doesn't build. Period. That change would not benefit the GCC project.

> is it logical to run a libstdc++ testsuite on a new target that we know will
> fail?  In other words, do you really want take gcc 4.10, add the c++ and gcc
> base patches, run the testsuite, then add these libsdc++ changes and run the
> suite again just to prove they really are needed?  I can of of course, just
> seems like a hoop.

A single test run (for everything, not just libstdc++) with all your patches
applied would be an improvement, currently we have no results at all.

Getting your patches accepted would be significantly easier if you can give the
URL of a testresults email showing that after applying your patches the
compiler looks healthy (just make sure the email is clear that it's using
patched sources).

> Is there a testing farm and could dragonfly x86-64 be added to it?

No, but see http://gcc.gnu.org/wiki/CompileFarm

It might be possible to run a dragonfly VM on gcc76, see that page for how to
request new systems.

>  Frankly
> I don't care about the i386 platform which will go away at some point, the
> sooner the better.  In not, you would expect a weekly cron to attempt to
> build gcc and mail the results in automatically?  That could be done
> probably.

All we care about is getting the emails to the gcc-testsresults list, if you
want to set up a cronjob to do it, great.