From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31821 invoked by alias); 14 Apr 2014 11:39:05 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 31772 invoked by uid 48); 14 Apr 2014 11:38:59 -0000 From: "gnugcc at marino dot st" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/60793] Add target *-*-dragonfly* to dg-options on 172 libstdc++ tests Date: Mon, 14 Apr 2014 11:39:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: gnugcc at marino dot st X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-04/txt/msg01003.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60793 --- Comment #8 from John Marino --- (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez from comment #7)=20 > 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 experie= nce. (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 v= ery > few reviewers and they are doing also 99% of the work, so they miss patch= es > all the time.=20 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 exam= ple: > 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? Fra= nkly > > 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. >=20 > http://gcc.gnu.org/wiki/CompileFarm >=20 > I am not sure what are the requirements for a tertiary platform, but sure= ly > they are very loose once accepted: The port has to be basically unmaintai= ned > 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 fal= lout that shows on DF test reports only? It looks like I would qualify esp. giv= en 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: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-04/txt/msg01004.txt.bz2 Content-length: 733 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60819 --- Comment #14 from Richard Biener --- Author: rguenth Date: Mon Apr 14 11:49:42 2014 New Revision: 209365 URL: http://gcc.gnu.org/viewcvs?rev=209365&root=gcc&view=rev Log: 2014-04-14 Richard Biener Marc Glisse 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