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

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

[gnugcc at marino dot st]

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

            Bug ID: 60793
           Summary: Add target *-*-dragonfly* to dg-options on 172
                    libstdc++ tests
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gnugcc at marino dot st

Created attachment 32572
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32572&action=edit
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.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|testsuite                   |libstdc++

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.

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

[gnugcc at marino dot st]

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

--- Comment #2 from John Marino <gnugcc at marino dot st> ---
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).

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

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.

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

[gnugcc at marino dot st]

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

--- Comment #4 from John Marino <gnugcc at marino dot st> ---
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.

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

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.

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

[gnugcc at marino dot st]

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.

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

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(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.
>From gcc-bugs-return-448982-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 14 11:21:48 2014
Return-Path: <gcc-bugs-return-448982-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20682 invoked by alias); 14 Apr 2014 11:21:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20646 invoked by uid 48); 14 Apr 2014 11:21:44 -0000
From: "a.h.jaffe at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60821] gcc 4.8 on MacOS fails depending on -arch order
Date: Mon, 14 Apr 2014 11:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: a.h.jaffe at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60821-4-bHa7znsx0v@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60821-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60821-4@http.gcc.gnu.org/bugzilla/>
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/msg01002.txt.bz2
Content-length: 799

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`821

--- Comment #6 from a.h.jaffe at gmail dot com ---
Thanks for the comprehensive info. It would certainly be nice to get the
driverdriver into the main code-base.

However, one thing still puzzles me:

> 5. We do accept -arch on x86:  -arch i386 gets mapped => -m32 and -arch
> x86_64 -> -m64.  The last one you place on the c/l will be in force (and
> there's NO support for the ppc equivalent at present).

This doesn't quite make sense given my experience:

  I have a 64-bit Mavericks machine, and compiled using MacPorts with
+universal. All of "-arch i386", "-arch x86_64" and "-arch x86_64 -arch i386"
seem to succeed, but "-arch i386 -arch x86_64" fails. According to the above,
the latter should have the  same behaviour as "-arch x86_64"

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

[gnugcc at marino dot st]

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

--- Comment #8 from John Marino <gnugcc at marino dot st> ---
(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).
>From gcc-bugs-return-448984-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 14 11:50:22 2014
Return-Path: <gcc-bugs-return-448984-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4463 invoked by alias); 14 Apr 2014 11:50:22 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4408 invoked by uid 55); 14 Apr 2014 11:50:18 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/60819] dse1 removing not-dead insn (aliasing issue?)
Date: Mon, 14 Apr 2014 11:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
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: <bug-60819-4-2iLlJMzdVM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60819-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60819-4@http.gcc.gnu.org/bugzilla/>
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/msg01004.txt.bz2
Content-length: 733

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`819

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Mon Apr 14 11:49:42 2014
New Revision: 209365

URL: http://gcc.gnu.org/viewcvs?rev 9365&root=gcc&view=rev
Log:
2014-04-14  Richard Biener  <rguenther@suse.de>
    Marc Glisse  <marc.glisse@inria.fr>

    PR c/60819
    c-family/
    * c-common.c (convert_vector_to_pointer_for_subscript): Properly
    apply may-alias the scalar pointer type when applicable.

    * gcc.target/i386/vec-may_alias.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.target/i386/vec-may_alias.c
Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/testsuite/ChangeLog

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

[manu at gcc dot gnu.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).
>From gcc-bugs-return-448988-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 14 12:11:41 2014
Return-Path: <gcc-bugs-return-448988-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18251 invoked by alias); 14 Apr 2014 12:11:41 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 18200 invoked by uid 48); 14 Apr 2014 12:11:38 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/50459] alignof doesn't work on plain old constant, works with expressions containing it
Date: Mon, 14 Apr 2014 12:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.6.1
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-50459-4-xBzzSiDS0A@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-50459-4@http.gcc.gnu.org/bugzilla/>
References: <bug-50459-4@http.gcc.gnu.org/bugzilla/>
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/msg01008.txt.bz2
Content-length: 337

http://gcc.gnu.org/bugzilla/show_bug.cgi?idP459

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
Creating a function definitely makes sense, I should have done it when I
touched the default_conversion calls. Do you think your function could also
handle the call to default_conversion (with the tests that protect it)?

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

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.

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

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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 :-)
>From gcc-bugs-return-448999-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Apr 14 14:09:12 2014
Return-Path: <gcc-bugs-return-448999-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10009 invoked by alias); 14 Apr 2014 14:09:10 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9946 invoked by uid 48); 14 Apr 2014 14:09:04 -0000
From: "nightstrike at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/36750] -Wmissing-field-initializers relaxation request
Date: Mon, 14 Apr 2014 14:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.1.2
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: nightstrike at gmail dot com
X-Bugzilla-Status: RESOLVED
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: cc
Message-ID: <bug-36750-4-0svwA4x7zZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-36750-4@http.gcc.gnu.org/bugzilla/>
References: <bug-36750-4@http.gcc.gnu.org/bugzilla/>
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/msg01019.txt.bz2
Content-length: 413

http://gcc.gnu.org/bugzilla/show_bug.cgi?id6750

nightstrike <nightstrike at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nightstrike at gmail dot com

--- Comment #6 from nightstrike <nightstrike at gmail dot com> ---
This is still an issue in C++

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-05-21
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
   Target Milestone|---                         |4.10.0
     Ever confirmed|0                           |1

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
DragonFly support is in trunk now so this needs doing.

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

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
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

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Before:
https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg01994.html
After:
https://gcc.gnu.org/ml/gcc-testresults/2014-05/msg02139.html