From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6764 invoked by alias); 8 Oct 2014 09:28:09 -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 6727 invoked by uid 48); 8 Oct 2014 09:28:05 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option) Date: Wed, 08 Oct 2014 09:28: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: manu 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: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-10/txt/msg00557.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D63480 --- Comment #4 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- Found it: PR61489 I think warning for {0} is on purpose, since one cannot tell if the struct originally had one field and now it has two. But I don't really agree with = it. I think it is too noisy. >>From gcc-bugs-return-463537-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 09:34:33 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 9450 invoked by alias); 8 Oct 2014 09:34:32 -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 9386 invoked by uid 48); 8 Oct 2014 09:34:29 -0000 From: "vogt at linux dot vnet.ibm.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug go/60406] recover.go: test13reflect2 test failure Date: Wed, 08 Oct 2014 09:34:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: go X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vogt at linux dot vnet.ibm.com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ian at airs dot com 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-10/txt/msg00558.txt.bz2 Content-length: 2429 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60406 --- Comment #23 from Dominik Vogt --- Regarding the new patch: 1) We need to call __builtin_extract_return_address(retaddr) in __go_set_defer_retaddr() too. (On s390 (31 bit) this is necessary to remove the most significant bit of the address which indicates the addressing mode= .) I.e. --snip-- - g->defer->__retaddr =3D retaddr; + g->defer->__retaddr =3D __builtin_extract_return_addr (retaddr); --snip-- 2) The new patch does not compile for me: -- In file included from ../../../libgo/runtime/go-check-interface.c:8:0: ../../../libgo/runtime/go-panic.h:43:13: error: conflicting types for =E2=80=98__go_makefunc_can_recover=E2=80=99 extern void __go_makefunc_can_recover (void *retaddr); ^ In file included from ../../../libgo/runtime/go-check-interface.c:7:0: ../../../libgo/runtime/runtime.h:845:9: note: previous declaration of =E2=80=98__go_makefunc_can_recover=E2=80=99 was here void __go_makefunc_can_recover (const void *); ^ -- In runtime.h, __go_makefunc_can_recover still has a "const" argument: --snip-- -void __go_makefunc_can_recover (const void *); +void __go_makefunc_can_recover (void *); --snip-- 3) Couldn't this be written more efficiently by passing a flag? + /* If we are called from __go_makefunc_can_recover, then we need to + look one level higher. */ + if (locs[0].function.len > 0 + && __builtin_strcmp ((const char *) locs[0].function.str, + "__go_makefunc_can_recover") =3D=3D 0) E.g. _Bool __go_can_recover (void *retaddr, _Bool called_by_makefunc_can_recov= er) { ... if (called_by_makefunc_can_recover) { do something } else { do something else } ... } 4) With the suggested changes from 1 and 2 above: s390x (64 bit): * PASS: test/recover.go * the test from #4 in my earlier posting works as expected * my private defer/recover/panic testsuite works as expected s390 (31 bit): * PASS: test/recover.go * the test from #4 in my earlier posting works as expected * my private defer/recover/panic testsuite works as expected 5) I find the assumption in the loop at the end of __go_can_recover() that = if a caller's name begins with "__go_" that means the panic can be recovered, a = bit hairy. Even if it is with the current libgo, an unrelated change elsewhere could break this logic. >>From gcc-bugs-return-463538-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 09:38:26 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 13630 invoked by alias); 8 Oct 2014 09:38:25 -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 13572 invoked by uid 48); 8 Oct 2014 09:38:21 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option) Date: Wed, 08 Oct 2014 09:38: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: unknown X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: manu 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: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-10/txt/msg00559.txt.bz2 Content-length: 370 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D63480 --- Comment #5 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- The C warning is also nicer than the C++ one because it says where the fiel= d is declared. It also only mentions one missing field per declaration, whereas = the C++ warning mentions all, which is terribly noisy and repetitive. >>From gcc-bugs-return-463539-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 08 09:43:14 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 17689 invoked by alias); 8 Oct 2014 09:43:14 -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 17635 invoked by uid 48); 8 Oct 2014 09:43:05 -0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/63473] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments. Date: Wed, 08 Oct 2014 09:43:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.8.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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-10/txt/msg00560.txt.bz2 Content-length: 587 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473 Tobias Burnus changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- It's probably related (but not identical) to not deallocating allocatable-scalars function results after their use [PR55603] and not finalizing function results (after their value has been used) [PR37336 ?].