From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26317 invoked by alias); 14 Apr 2014 13:55:55 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 25994 invoked by uid 48); 14 Apr 2014 13:55:47 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/60793] Add target *-*-dragonfly* to dg-options on 172 libstdc++ tests Date: Mon, 14 Apr 2014 13:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-04/txt/msg01016.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60793 --- Comment #10 from Jonathan Wakely --- (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.