http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793
--- 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.
