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

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

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

--- Comment #9 from Manuel LÃpez-IbÃÃez <manu at gcc dot gnu.org> ---
> 
> > And for sure you will need to ping the patches several times, there are very
> > few reviewers and they are doing also 99% of the work, so they miss patches
> > all the time. 
> 
> Well, while this is the reality of the situation, it's not reasonable.  The
> threat of pinging several times per patch set when it could be several sets
> of patches is actually why other things have taken priority.  I don't what
> the solution is; I guess I was hoping the system would fix itself but it
> doesn't sound like that's happened yet.
> 

It might not be reasonable, but it is the reality, and no fix in sight. :(

> > Also, I think you will need to do a full bootstrap+testsuite, why wouldn't
> > you be able to do that? If you don't have a machine powerful enough, you may
> > contact the compile farm to install Dragonfly on a virtual machine:
> > http://gcc.gnu.org/wiki/CompileFarm
> 
> Because I interpret a full bootstrap to mean every major platform that gcc
> supports.  What does "bootstrap" mean?  Just a standard build with
> --disable-boostrap flag not used?  I can test the dragonfly platform, but I
> can't test every variety of linux, solaris, etc. for potential effects.

http://gcc.gnu.org/contribute.html#testing

Yes, it is exactly not using --disable-bootstrap. I am not sure what are the
requirements for a new OS port, but I doubt you need to test every major
platform. Perhaps you can ask that in the gcc@ mailing list.

> Does that means it's just a matter of requesting a virtual machine on the
> compile farm and having an assigned responsible to respond to potential
> fallout that shows on DF test reports only?  It looks like I would qualify
> esp. given I have commit access to three separate BSD projects (DragonFly,
> FreeBSD, and NetBSD).

I would suggest you start by posting testresults to gcc-testresults (see bottom
of http://gcc.gnu.org/install/test.html), then divide the patches
appropriately, then simply submitting like the example above. If there is
anything else you need to do, somebody will tell you. If you don't get an
answer in two weeks, ping the patch. Yes pinging is annoying. On the other
hand, it takes no effort to do it (just a quick reply, perhaps editing the
subject to mention PING, bonus point if you give a link to the original patch
in the mailing list archives).