Created attachment 32572 [details] List of 172 libstdc++ tests that should target *-*-dragonfly* The attached file is a list of 172 libstdc++ tests that have dg-options target of *-*-freebsd*. They should also list *-*-dragonfly* It should be a simply matter of substituting enmass "*-*-freebsd*" with "*-*-freebsd* *-*-dragonfly*" using perl -pi -e or similar technique. A giant patchset could be provided upon request if "perl -pie" isn't good enough.
(Changing component to libstdc++ so it's on my radar) Could we get some testresults posted to the gcc-testresults list? Preferably both with and without this change. I'd prefer not to add it to the target selector if we aren't getting fairly regular test results, so we can see if the tests are actually passing.
hmmm, that would imply that all the dragonfly patches that we've been carrying for years (including ada patches) would need to go in first. DragonFly does not, and has never, built out of the box. It's not possible to have an automated test robot until support is added. I could have a before -and- after run, but that's a one off comparison. I've been carrying these patches since 4.6 (actually a lot more, this is only a small subset).
(In reply to John Marino from comment #2) > hmmm, that would imply that all the dragonfly patches that we've been > carrying for years (including ada patches) would need to go in first. I don't see why ada patches make any difference to libstdc++ test results (just build with --enable-languages=c++ if necessary) > DragonFly does not, and has never, built out of the box. It's not possible > to have an automated test robot until support is added. I could have a > before -and- after run, but that's a one off comparison. We're unlikely to accept testsuite patches for a target that doesn't even build. A one-off set of results would be a lot better than none! > I've been carrying these patches since 4.6 (actually a lot more, this is > only a small subset). Please submit the rest of them then :-) I'm definitely in favour of supporting dragonfly, but tweaking the testsuite to make tests pass for a target that noone else can build (because other necessary patches are missing) is low priority.
For the matter of this particular PR, NetBSD is also a target so it's not a big stretch to imagine it's needed for all the BSD targets (and it is). Plus there's really no downside if the target isn't really recognized, other than dejagnu clutter. Regarding *all* the patches: frankly I am apprehensive about the process. For libc++: +++ libstdc++-v3/config/locale/dragonfly/c_locale.cc (new) +++ libstdc++-v3/config/locale/dragonfly/ctype_members.cc (new) +++ libstdc++-v3/config/os/bsd/dragonfly/ctype_base.h (new) +++ libstdc++-v3/config/os/bsd/dragonfly/ctype_configure_char.cc (new) +++ libstdc++-v3/config/os/bsd/dragonfly/ctype_inline.h (new) +++ libstdc++-v3/config/os/bsd/dragonfly/os_defines.h (new) +++ libstdc++-v3/acinclude.m4 +++ libstdc++-v3/configure +++ libstdc++-v3/configure.host for base/c: +++ gcc/config/dragonfly-stdint.h (new) +++ gcc/config/dragonfly.h (new) +++ gcc/config/dragonfly.opt (new) +++ gcc/config/i386/dragonfly.h (new) +++ gcc/ginclude/stddef.h +++ include/libiberty.h +++ libgcc/crtstuff.c +++ libgcc/enable-execute-stack-freebsd.c +++ libgcc/unwind-dw2-fde-dip.c +++ libgcc/config/i386/dragonfly-unwind.h +++ gcc/config.gcc +++ gcc/configure +++ gcc/Makefile.in +++ libgcc/config.host +++ libcilkrts/runtime/os-unix.c +++ libitm/configure.tgt for ada (all BSD, not just DragonFly) +++ gcc/ada/a-exetim-posix.adb +++ gcc/ada/a-intnam-dragonfly.ads +++ gcc/ada/a-intnam-netbsd.ads (BSD) +++ gcc/ada/a-intnam-openbsd.ads (BSD) +++ gcc/ada/adaint.c +++ gcc/ada/cio.c +++ gcc/ada/cstreams.c +++ gcc/ada/env.c +++ gcc/ada/g-comlin.adb +++ gcc/ada/g-expect.adb +++ gcc/ada/g-socthi-bsd.adb +++ gcc/ada/g-socthi-netbsd.adb +++ gcc/ada/g-socthi-netbsd6.ads +++ gcc/ada/g-trasym-bsd.adb +++ gcc/ada/gnatchop.adb +++ gcc/ada/gnatlink.adb +++ gcc/ada/gsocket.h +++ gcc/ada/init.c +++ gcc/ada/initialize.c +++ gcc/ada/link.c +++ gcc/ada/make.adb +++ gcc/ada/mlib-prj.adb +++ gcc/ada/mlib-utl.adb +++ gcc/ada/prj-makr.adb +++ gcc/ada/s-osinte-dragonfly.adb +++ gcc/ada/s-osinte-dragonfly.ads +++ gcc/ada/s-osinte-freebsd.adb +++ gcc/ada/s-osinte-freebsd32.ads +++ gcc/ada/s-osinte-freebsd64.ads +++ gcc/ada/s-osinte-netbsd.adb +++ gcc/ada/s-osinte-netbsd.ads +++ gcc/ada/s-osinte-netbsd6.ads +++ gcc/ada/s-osinte-openbsd.adb +++ gcc/ada/s-osinte-openbsd.ads +++ gcc/ada/s-osprim-bsd32.adb +++ gcc/ada/s-osprim-bsd64.adb +++ gcc/ada/s-osprim-bsdn6.adb +++ gcc/ada/socket.c +++ gcc/ada/sysdep.c +++ gcc/ada/system-dragonfly-x86.ads +++ gcc/ada/system-dragonfly-x86_64.ads +++ gcc/ada/system-netbsd-x86.ads +++ gcc/ada/system-netbsd-x86_64.ads +++ gcc/ada/system-openbsd-x86.ads +++ gcc/ada/system-openbsd-x86_64.ads +++ gcc/ada/terminals.c +++ gcc/ada/traceback_symbolic.c +++ gcc/ada/tracebak.c +++ gcc/ada/gcc-interface/Make-lang.in +++ gcc/ada/gcc-interface/Makefile.in +++ gnattools/configure.ac +++ gnattools/configure It's pretty reasonable to leave off Ada as a separate effort, but c/c++/base should all be handled at the same time. I really need somebody "on the inside" to help me with these. I don't see this as 20 separate submissions but rather as a package. Who would that person be? Would you be that person? FWIW, I do have copyright assignment on file with FSF so there's no issue about copyright. I just need a way to fast-track these. And there's other patches too like the FreeBSD unwinder support. Hopefully the sheer number makes my apprehension clear.
(In reply to John Marino from comment #4) > For the matter of this particular PR, NetBSD is also a target so it's not a > big stretch to imagine it's needed for all the BSD targets (and it is). > Plus there's really no downside if the target isn't really recognized, other > than dejagnu clutter. 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. > Regarding *all* the patches: > frankly I am apprehensive about the process. > > For libc++: > +++ libstdc++-v3/config/locale/dragonfly/c_locale.cc (new) > +++ libstdc++-v3/config/locale/dragonfly/ctype_members.cc (new) > +++ libstdc++-v3/config/os/bsd/dragonfly/ctype_base.h (new) > +++ libstdc++-v3/config/os/bsd/dragonfly/ctype_configure_char.cc (new) > +++ libstdc++-v3/config/os/bsd/dragonfly/ctype_inline.h (new) > +++ libstdc++-v3/config/os/bsd/dragonfly/os_defines.h (new) > +++ libstdc++-v3/acinclude.m4 > +++ libstdc++-v3/configure > +++ libstdc++-v3/configure.host This should be a single patch, sent to both the libstdc++ and gcc-patches lists. > for base/c: > +++ gcc/config/dragonfly-stdint.h (new) > +++ gcc/config/dragonfly.h (new) > +++ gcc/config/dragonfly.opt (new) > +++ gcc/config/i386/dragonfly.h (new) > +++ gcc/ginclude/stddef.h > +++ include/libiberty.h > +++ libgcc/crtstuff.c > +++ libgcc/enable-execute-stack-freebsd.c > +++ libgcc/unwind-dw2-fde-dip.c > +++ libgcc/config/i386/dragonfly-unwind.h > +++ gcc/config.gcc > +++ gcc/configure > +++ gcc/Makefile.in > +++ libgcc/config.host 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. > +++ 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). > It's pretty reasonable to leave off Ada as a separate effort, but c/c++/base > should all be handled at the same time. I really need somebody "on the > inside" to help me with these. I don't see this as 20 separate submissions There'ss no way the files listed above should involve 20 separate submissions. I'd guess two or three (not including Ada). > but rather as a package. Who would that person be? Would you be that > person? 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 testresults. If you don't provide testresults, expect to be asked for them. Until then this is speculation and fixing failing tests is premature, because they all fail until the compiler can be built. > FWIW, I do have copyright assignment on file with FSF so there's no issue Great. > about copyright. I just need a way to fast-track these. And there's other > patches too like the FreeBSD unwinder support. > > Hopefully the sheer number makes my apprehension clear. 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. 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.
(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.
(In reply to John Marino from comment #6) > 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) But this is something that everybody has to do! It is a trade-off, does it take more effort to keep the patches up-to-date or to get them approved? You should expect reviewers to ask for changes. That is the whole point of having a review process. 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. 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 It is also essential that you submit your port in a way that makes it easy for reviewers to know what they are supposed to look at. See a good example: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00278.html > 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. http://gcc.gnu.org/wiki/CompileFarm I am not sure what are the requirements for a tertiary platform, but surely they are very loose once accepted: The port has to be basically unmaintained to get removed.
(In reply to Manuel López-Ibáñez from comment #7) > But this is something that everybody has to do! It is a trade-off, does it > take more effort to keep the patches up-to-date or to get them approved? The answer is obvious - it's less effort to keep the patches up-to-date. at least, that's my perception based on observation but not first-hand experience. (I'm not trying to start anything, I'm just being honest about *my* perceptions.) > You should expect reviewers to ask for changes. That is the whole point of > having a review process. Sure, that's reasonable. > 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. > 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. > It is also essential that you submit your port in a way that makes it easy > for reviewers to know what they are supposed to look at. See a good example: > http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00278.html okay, thanks for providing that example. > > 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. > > http://gcc.gnu.org/wiki/CompileFarm > > I am not sure what are the requirements for a tertiary platform, but surely > they are very loose once accepted: The port has to be basically unmaintained > to get removed. understood. DF should be easy to keep maintained once it's in. 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).
> > > 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).
(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.
(In reply to Manuel López-Ibáñez from comment #9) > > Because I interpret a full bootstrap to mean every major platform that gcc > > supports. That would be impossible for the majority of contributors, who don't have access to most of the targets. > > What does "bootstrap" mean? Just a standard build with > > --disable-boostrap flag not used? Yes. > > I can test the dragonfly platform, but I > > can't test every variety of linux, solaris, etc. for potential effects. Noone is asking for that. > 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. That is definitely not a requirement. Most of the changes needed should be restricted to target-specific code, so the requirements for the change are pretty low. At worst it will probably only affect FreeBSD and any issues can be solved. If you don't care enough to post a few emails showing test results then noone is going to be interested in supporting your target. See the contrib/test_summary script in the source tree which makes it very simple to do. You could have done it in the time it's taken to explain why you're reluctant to send your patches :-)
DragonFly support is in trunk now so this needs doing.
Author: redi Date: Fri May 23 10:19:20 2014 New Revision: 210849 URL: http://gcc.gnu.org/viewcvs?rev=210849&root=gcc&view=rev Log: PR libstdc++/60793 * testsuite/*: Use 's/\*-\*-freebsd\* /&*-*-dragonfly* /' to add dragonfly target selector to all tests that run on freebsd. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/17_intro/headers/c++1998/stdc++.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++1998/stdc++_multiple_inclusion.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++.cc trunk/libstdc++-v3/testsuite/17_intro/headers/c++200x/stdc++_multiple_inclusion.cc trunk/libstdc++-v3/testsuite/18_support/pthread_guard.cc trunk/libstdc++-v3/testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc trunk/libstdc++-v3/testsuite/20_util/shared_ptr/thread/mutex_weaktoshared.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/pthread18185.cc trunk/libstdc++-v3/testsuite/21_strings/basic_string/pthread4.cc trunk/libstdc++-v3/testsuite/22_locale/locale/cons/12658_thread-1.cc trunk/libstdc++-v3/testsuite/22_locale/locale/cons/12658_thread-2.cc trunk/libstdc++-v3/testsuite/23_containers/list/pthread1.cc trunk/libstdc++-v3/testsuite/23_containers/list/pthread5.cc trunk/libstdc++-v3/testsuite/23_containers/map/pthread6.cc trunk/libstdc++-v3/testsuite/23_containers/vector/debug/multithreaded_swap.cc trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/c_math_dynamic.cc trunk/libstdc++-v3/testsuite/27_io/basic_ofstream/pthread2.cc trunk/libstdc++-v3/testsuite/27_io/basic_ostringstream/pthread3.cc trunk/libstdc++-v3/testsuite/30_threads/async/42819.cc trunk/libstdc++-v3/testsuite/30_threads/async/49668.cc trunk/libstdc++-v3/testsuite/30_threads/async/54297.cc trunk/libstdc++-v3/testsuite/30_threads/async/any.cc trunk/libstdc++-v3/testsuite/30_threads/async/async.cc trunk/libstdc++-v3/testsuite/30_threads/async/launch.cc trunk/libstdc++-v3/testsuite/30_threads/async/sync.cc trunk/libstdc++-v3/testsuite/30_threads/call_once/39909.cc trunk/libstdc++-v3/testsuite/30_threads/call_once/49668.cc trunk/libstdc++-v3/testsuite/30_threads/call_once/60497.cc trunk/libstdc++-v3/testsuite/30_threads/call_once/call_once1.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable/cons/1.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable/members/1.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable/members/2.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable/members/53841.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable/native_handle/typesizes.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/50862.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/53830.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/cons/1.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/members/1.cc trunk/libstdc++-v3/testsuite/30_threads/condition_variable_any/members/2.cc trunk/libstdc++-v3/testsuite/30_threads/future/cons/move.cc trunk/libstdc++-v3/testsuite/30_threads/future/members/45133.cc trunk/libstdc++-v3/testsuite/30_threads/future/members/get.cc trunk/libstdc++-v3/testsuite/30_threads/future/members/get2.cc trunk/libstdc++-v3/testsuite/30_threads/future/members/share.cc trunk/libstdc++-v3/testsuite/30_threads/future/members/valid.cc trunk/libstdc++-v3/testsuite/30_threads/future/members/wait.cc trunk/libstdc++-v3/testsuite/30_threads/future/members/wait_for.cc trunk/libstdc++-v3/testsuite/30_threads/future/members/wait_until.cc trunk/libstdc++-v3/testsuite/30_threads/lock/1.cc trunk/libstdc++-v3/testsuite/30_threads/lock/2.cc trunk/libstdc++-v3/testsuite/30_threads/lock/3.cc trunk/libstdc++-v3/testsuite/30_threads/lock/4.cc trunk/libstdc++-v3/testsuite/30_threads/mutex/cons/1.cc trunk/libstdc++-v3/testsuite/30_threads/mutex/dest/destructor_locked.cc trunk/libstdc++-v3/testsuite/30_threads/mutex/lock/1.cc trunk/libstdc++-v3/testsuite/30_threads/mutex/native_handle/1.cc trunk/libstdc++-v3/testsuite/30_threads/mutex/native_handle/typesizes.cc trunk/libstdc++-v3/testsuite/30_threads/mutex/try_lock/1.cc trunk/libstdc++-v3/testsuite/30_threads/mutex/try_lock/2.cc trunk/libstdc++-v3/testsuite/30_threads/mutex/unlock/1.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/49668.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/60564.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/1.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/2.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/3.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/56492.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/alloc.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/move.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/move_assign.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/get_future.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/get_future2.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke2.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke3.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke4.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/invoke5.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/reset.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/reset2.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/swap.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/members/valid.cc trunk/libstdc++-v3/testsuite/30_threads/promise/60966.cc trunk/libstdc++-v3/testsuite/30_threads/promise/cons/1.cc trunk/libstdc++-v3/testsuite/30_threads/promise/cons/alloc.cc trunk/libstdc++-v3/testsuite/30_threads/promise/cons/move.cc trunk/libstdc++-v3/testsuite/30_threads/promise/cons/move_assign.cc trunk/libstdc++-v3/testsuite/30_threads/promise/members/get_future.cc trunk/libstdc++-v3/testsuite/30_threads/promise/members/get_future2.cc trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_exception.cc trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_exception2.cc trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_value.cc trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_value2.cc trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_value3.cc trunk/libstdc++-v3/testsuite/30_threads/promise/members/swap.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/cons/1.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/dest/destructor_locked.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/lock/1.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/native_handle/1.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/native_handle/typesizes.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/1.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/try_lock/2.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_mutex/unlock/1.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/cons/1.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/dest/destructor_locked.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/lock/1.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/lock/2.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/native_handle/1.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/native_handle/typesizes.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock/1.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock/2.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/1.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/2.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_for/3.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_until/1.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/try_lock_until/2.cc trunk/libstdc++-v3/testsuite/30_threads/recursive_timed_mutex/unlock/1.cc trunk/libstdc++-v3/testsuite/30_threads/shared_future/cons/move.cc trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/45133.cc trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/get.cc trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/get2.cc trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/valid.cc trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/wait.cc trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/wait_for.cc trunk/libstdc++-v3/testsuite/30_threads/shared_future/members/wait_until.cc trunk/libstdc++-v3/testsuite/30_threads/shared_lock/cons/1.cc trunk/libstdc++-v3/testsuite/30_threads/shared_lock/cons/2.cc trunk/libstdc++-v3/testsuite/30_threads/shared_lock/cons/3.cc trunk/libstdc++-v3/testsuite/30_threads/shared_lock/cons/4.cc trunk/libstdc++-v3/testsuite/30_threads/shared_lock/cons/5.cc trunk/libstdc++-v3/testsuite/30_threads/shared_lock/cons/6.cc trunk/libstdc++-v3/testsuite/30_threads/shared_lock/locking/1.cc trunk/libstdc++-v3/testsuite/30_threads/shared_lock/locking/2.cc trunk/libstdc++-v3/testsuite/30_threads/shared_lock/locking/3.cc trunk/libstdc++-v3/testsuite/30_threads/shared_lock/locking/4.cc trunk/libstdc++-v3/testsuite/30_threads/shared_lock/modifiers/1.cc trunk/libstdc++-v3/testsuite/30_threads/shared_lock/modifiers/2.cc trunk/libstdc++-v3/testsuite/30_threads/shared_timed_mutex/cons/1.cc trunk/libstdc++-v3/testsuite/30_threads/shared_timed_mutex/try_lock/1.cc trunk/libstdc++-v3/testsuite/30_threads/shared_timed_mutex/try_lock/2.cc trunk/libstdc++-v3/testsuite/30_threads/this_thread/1.cc trunk/libstdc++-v3/testsuite/30_threads/this_thread/2.cc trunk/libstdc++-v3/testsuite/30_threads/this_thread/3.cc trunk/libstdc++-v3/testsuite/30_threads/this_thread/4.cc trunk/libstdc++-v3/testsuite/30_threads/thread/cons/1.cc trunk/libstdc++-v3/testsuite/30_threads/thread/cons/2.cc trunk/libstdc++-v3/testsuite/30_threads/thread/cons/3.cc trunk/libstdc++-v3/testsuite/30_threads/thread/cons/4.cc trunk/libstdc++-v3/testsuite/30_threads/thread/cons/49668.cc trunk/libstdc++-v3/testsuite/30_threads/thread/cons/5.cc trunk/libstdc++-v3/testsuite/30_threads/thread/cons/6.cc trunk/libstdc++-v3/testsuite/30_threads/thread/cons/7.cc trunk/libstdc++-v3/testsuite/30_threads/thread/cons/8.cc trunk/libstdc++-v3/testsuite/30_threads/thread/cons/9.cc trunk/libstdc++-v3/testsuite/30_threads/thread/cons/moveable.cc trunk/libstdc++-v3/testsuite/30_threads/thread/members/1.cc trunk/libstdc++-v3/testsuite/30_threads/thread/members/2.cc trunk/libstdc++-v3/testsuite/30_threads/thread/members/3.cc trunk/libstdc++-v3/testsuite/30_threads/thread/members/4.cc trunk/libstdc++-v3/testsuite/30_threads/thread/members/5.cc trunk/libstdc++-v3/testsuite/30_threads/thread/members/hardware_concurrency.cc trunk/libstdc++-v3/testsuite/30_threads/thread/native_handle/cancel.cc trunk/libstdc++-v3/testsuite/30_threads/thread/swap/1.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/cons/1.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/dest/destructor_locked.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/lock/1.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/native_handle/1.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/native_handle/typesizes.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock/1.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock/2.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_for/1.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_for/2.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_for/3.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_until/1.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_until/2.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_until/57641.cc trunk/libstdc++-v3/testsuite/30_threads/timed_mutex/unlock/1.cc trunk/libstdc++-v3/testsuite/30_threads/try_lock/1.cc trunk/libstdc++-v3/testsuite/30_threads/try_lock/2.cc trunk/libstdc++-v3/testsuite/30_threads/try_lock/3.cc trunk/libstdc++-v3/testsuite/30_threads/try_lock/4.cc trunk/libstdc++-v3/testsuite/30_threads/unique_lock/cons/1.cc trunk/libstdc++-v3/testsuite/30_threads/unique_lock/cons/2.cc trunk/libstdc++-v3/testsuite/30_threads/unique_lock/cons/3.cc trunk/libstdc++-v3/testsuite/30_threads/unique_lock/cons/4.cc trunk/libstdc++-v3/testsuite/30_threads/unique_lock/cons/5.cc trunk/libstdc++-v3/testsuite/30_threads/unique_lock/cons/6.cc trunk/libstdc++-v3/testsuite/30_threads/unique_lock/locking/1.cc trunk/libstdc++-v3/testsuite/30_threads/unique_lock/locking/2.cc trunk/libstdc++-v3/testsuite/30_threads/unique_lock/locking/3.cc trunk/libstdc++-v3/testsuite/30_threads/unique_lock/locking/4.cc trunk/libstdc++-v3/testsuite/30_threads/unique_lock/modifiers/1.cc trunk/libstdc++-v3/testsuite/30_threads/unique_lock/modifiers/2.cc trunk/libstdc++-v3/testsuite/ext/rope/pthread7-rope.cc trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/thread/default_weaktoshared.cc trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/thread/mutex_weaktoshared.cc
Before: https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg01994.html After: https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg02139.html