[Bug c/63480] New: -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)

[Bug c/63480] New: -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)

[josh at joshtriplett dot org]

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

            Bug ID: 63480
           Summary: -Wmissing-field-initializers should not warn about
                    intentionally empty initializers (or that should be a
                    separate option)
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: josh at joshtriplett dot org

-Wmissing-field-initializers warns if a positional initializer does not
initialize all fields.  However, it does so even if the initializer is {},
which is a common idiom to initialize the entire structure to zero.  Please
consider not warning in that specific case.  If anyone actually *wants* GCC to
warn in that case, perhaps that could go in a separate -Wempty-initializer.

Alternatively, if people *really* want -Wmissing-field-initializers to warn
about {}, could we have some other warning option that only warns about missing
field initializers with non-empty initializers?

[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-10-08
                 CC|                            |mpolacek at gcc dot gnu.org
     Ever confirmed|0                           |1

[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
In C++ we don't warn for { }.  OTOH, C++ warns for { 0 } - I think it should
not.

[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)

[manu at gcc dot gnu.org]

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 ?].

[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Also note PR39589, a request for -Wmissing-field-initializers=2, but it's not
as trivial as it seems.

[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |5.0

[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Thu Oct  9 08:25:50 2014
New Revision: 216031

URL: https://gcc.gnu.org/viewcvs?rev=216031&root=gcc&view=rev
Log:
    PR c/63480
    * c-typeck.c (pop_init_level): Don't warn about initializing
    with { }.

    * gcc.dg/pr63480.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/pr63480.c
Modified:
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-typeck.c
    trunk/gcc/testsuite/ChangeLog

[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #8 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed.