From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104024 invoked by alias); 24 Jul 2015 18:47:13 -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 103993 invoked by uid 48); 24 Jul 2015 18:47:10 -0000 From: "kkylheku at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/36587] Feature: add warning for constructor call with discarded return. Date: Fri, 24 Jul 2015 18:47: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.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: kkylheku at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: 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: 2015-07/txt/msg02158.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D36587 --- Comment #11 from Kaz Kylheku --- (In reply to Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez from comment #10) > (In reply to Kaz Kylheku from comment #1) > > Created attachment 15798 [details] > > Implements -Wunused-objects warning for C++. >=20 > Patches need to be properly tested and submitted. See > https://gcc.gnu.org/wiki/GettingStarted#Basics: > _Contributing_to_GCC_in_10_easy_steps >=20 > The few people that have the power to approve patches are very busy and t= hey > very rarely read bugzilla. The bug database has an "enhancement" type, so obviously, it is to be used = for submitting enhancements. Why would you duplicate effort by implementing a different process for tracking submissions? In June 2008, when I submitted this, here is how the above Wiki page looked: https://gcc.gnu.org/wiki/GettingStarted?action=3Drecall&rev=3D19 There is no mention of any special process at that time. Please "grandfather" old submissions that were posted to Bugzilla before the special submission process was described in the Wiki. >Patches attached to bugzilla are usually understood as proof-of-concept or= work-in-progress, not actual submissions. I deployed that change to large team of developers, and the toolchain with = that change went to customers also. The warning caught problems that were fixed = and didn't appear to break anything. So yes, actual submission. Today, I no longer care about upstreaming code to OSS projects because of p= rima donna attitudes like this. It's just too much effort dealing with the barri= ers. In my own projects, I accept good patches, even if they are written on a grease-stained napkin. If I lead by example, maybe others will follow. >>From gcc-bugs-return-493269-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 24 18:58:31 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 4705 invoked by alias); 24 Jul 2015 18:58:31 -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 3880 invoked by uid 48); 24 Jul 2015 18:58:27 -0000 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/55035] reload1.c:3766:41: error:=?UTF-8?Q?=20=E2=80=98orig=5Fdup?=[0]=?UTF-8?Q?=E2=80=99=20may=20be=20used=20uninitialized=20in=20this=20function=20?=(for fr30, microblaze, moxie, rl78) Date: Fri, 24 Jul 2015 18:58:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 4.8.0 X-Bugzilla-Keywords: build, diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: 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 blocked 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: 2015-07/txt/msg02159.txt.bz2 Content-length: 1517 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55035 Jeffrey A. Law changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at redhat dot com Blocks| |19794 --- Comment #6 from Jeffrey A. Law --- Per this discussion: https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01996.html It's believed the reduced testcase in c#5 is an invalid reduction. A cursory review of the code in c#4 indicates that testcase is a valid reduction. We ought to be able to determine that the writes inside the two inner loops do not clobber recog_data.n_dups and thus the first and last loops iterate over the same space and every read of orig_dup[] in the last loop will have had a value set in the first loop. There's almost certainly a hideously complex missed jump threading opportunity in here. Conceptually it'd be exposed by duplicating the two inner loops, one duplicate would be reached when n_dups is zero the other when n_dups is nonzero after the first loop. The first duplicate will bypass the last loop the second duplicate would execute the final loop. The net result of all that copying and cfg transformations should in theory make the false positive warning go away. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794 [Bug 19794] [meta-bug] Jump threading related bugs