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

gnugcc at marino dot st gcc-bugzilla@gcc.gnu.org
Mon Apr 14 10:26:00 GMT 2014


--- Comment #6 from John Marino <gnugcc at marino dot st> ---
(In reply to Jonathan Wakely from comment #5)
> 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.

Perhaps, because I was going for what I perceived as my best chance of success,
and from my point of view getting rid of some patches is better than nothing. 
But if the entire target can be supported, that would be ideal.

> > Regarding *all* the patches:
> > frankly I am apprehensive about the process.
> This should be a single patch, sent to both the libstdc++ and gcc-patches
> lists.

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.

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

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

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

They are also trivial / obvious changes so shouldn't be an issue.

> There's no way the files listed above should involve 20 separate
> submissions. I'd guess two or three (not including Ada).
> 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 test results. If you don't
> provide test results, expect to be asked for them.

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.  The perceived barrier is very high.  That's my
problem, but that's why I have hoarded these patches for over two years
(cutting off my nose because I have to keep regenerating them for each release)

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

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)

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

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.

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

Is there a testing farm and could dragonfly x86-64 be added to it?  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.

More information about the Gcc-bugs mailing list