public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-63480-4-c8E6urO6PE@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-63480-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480 --- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- 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: <gcc-bugs-return-463537-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> 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: <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 9386 invoked by uid 48); 8 Oct 2014 09:34:29 -0000 From: "vogt at linux dot vnet.ibm.com" <gcc-bugzilla@gcc.gnu.org> 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: <bug-60406-4-GgwVFL3AQ3@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-60406-4@http.gcc.gnu.org/bugzilla/> References: <bug-60406-4@http.gcc.gnu.org/bugzilla/> 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=60406 --- Comment #23 from Dominik Vogt <vogt at linux dot vnet.ibm.com> --- 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 = retaddr; + g->defer->__retaddr = __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 ‘__go_makefunc_can_recover’ 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 ‘__go_makefunc_can_recover’ 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") == 0) E.g. _Bool __go_can_recover (void *retaddr, _Bool called_by_makefunc_can_recover) { ... 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: <gcc-bugs-return-463538-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> 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: <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 13572 invoked by uid 48); 8 Oct 2014 09:38:21 -0000 From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.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: <bug-63480-4-jHUG8Vlsrc@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-63480-4@http.gcc.gnu.org/bugzilla/> References: <bug-63480-4@http.gcc.gnu.org/bugzilla/> 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=63480 --- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- The C warning is also nicer than the C++ one because it says where the field 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: <gcc-bugs-return-463539-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> 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: <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 17635 invoked by uid 48); 8 Oct 2014 09:43:05 -0000 From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.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: <bug-63473-4-VV9qFOao7c@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-63473-4@http.gcc.gnu.org/bugzilla/> References: <bug-63473-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-10/txt/msg00560.txt.bz2 Content-length: 587 https://gcc.gnu.org/bugzilla/show_bug.cgi?idc473 Tobias Burnus <burnus at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> --- 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 ?].
next prev parent reply other threads:[~2014-10-08 9:28 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-10-08 4:31 [Bug c/63480] New: " josh at joshtriplett dot org 2014-10-08 7:27 ` [Bug c/63480] " mpolacek at gcc dot gnu.org 2014-10-08 9:11 ` mpolacek at gcc dot gnu.org 2014-10-08 9:28 ` manu at gcc dot gnu.org [this message] 2014-10-08 10:13 ` mpolacek at gcc dot gnu.org 2014-10-08 10:13 ` mpolacek at gcc dot gnu.org 2014-10-09 8:26 ` mpolacek at gcc dot gnu.org 2014-10-09 8:27 ` mpolacek at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-63480-4-c8E6urO6PE@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).