Bug 64709 - [5 Regression] Bogus -Wmissing-field-initializers warning
Summary: [5 Regression] Bogus -Wmissing-field-initializers warning
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 5.0
: P3 normal
Target Milestone: 5.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-21 12:30 UTC by Marek Polacek
Modified: 2015-01-29 21:03 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-01-21 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marek Polacek 2015-01-21 12:30:35 UTC
$ ./cc1 -quiet q.c -Wmissing-field-initializers
q.c: In function ‘foo’:
q.c:5:10: warning: missing initializer for field ‘b’ of ‘struct S’ [-Wmissing-field-initializers]
   struct S s[] = { { 1, 2 }, { 0 } };
          ^
q.c:1:19: note: ‘b’ declared here
 struct S { int a, b; };
                   ^
$ cat q.c
struct S { int a, b; };
void
foo (void)
{
  struct S s[] = { { 1, 2 }, { 0 } };
}

Started with r211289.
Comment 1 Marek Polacek 2015-01-21 12:31:54 UTC
We shouldn't warn on { 0 }.
Comment 2 Jakub Jelinek 2015-01-21 13:15:39 UTC
I wonder if that might not be undesirable in some cases, perhaps allow the users to choose?  -Wmissing-field-initializers == -Wmissing-field-initializers=1 (enabled in -Wall or where) would do what you suggest, -Wmissing-field-initializers=2 would warn even for this?
Comment 3 Marek Polacek 2015-01-21 13:28:16 UTC
Maybe.  There's an RFE for -Wmissing-field-initializers=2 in PR39589, though that speaks about allowing the warning with designated initializers.
Comment 4 Marek Polacek 2015-01-21 14:09:48 UTC
BTW, untested patch (dg.exp passes).  

diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index f39dfdd..53d1a16 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -7556,20 +7556,28 @@ pop_init_level (location_t loc, int implicit,
 	}
     }
 
-  /* Initialization with { } counts as zeroinit.  */
-  if (vec_safe_length (constructor_elements) == 0)
-    constructor_zeroinit = 1;
-  /* If the constructor has more than one element, it can't be { 0 }.  */
-  else if (vec_safe_length (constructor_elements) != 1)
-    constructor_zeroinit = 0;
+  switch (vec_safe_length (constructor_elements))
+    {
+    case 0:
+      /* Initialization with { } counts as zeroinit.  */
+      constructor_zeroinit = 1;
+      break;
+    case 1:
+      /* This might be zeroinit as well.  */
+      if (integer_zerop ((*constructor_elements)[0].value))
+	constructor_zeroinit = 1;
+      break;
+    default:
+      /* If the constructor has more than one element, it can't be { 0 }.  */
+      constructor_zeroinit = 0;
+      break;
+    }
 
   /* Warn when some structs are initialized with direct aggregation.  */
   if (!implicit && found_missing_braces && warn_missing_braces
       && !constructor_zeroinit)
-    {
-      warning_init (loc, OPT_Wmissing_braces,
-		    "missing braces around initializer");
-    }
+    warning_init (loc, OPT_Wmissing_braces,
+		  "missing braces around initializer");
 
   /* Warn when some struct elements are implicitly initialized to zero.  */
   if (warn_missing_field_initializers
Comment 5 Jakub Jelinek 2015-01-21 14:15:43 UTC
What value will constructor_zeroinit have if it has a single element which is not integer_zerop?  Should we set it to 0 in that case?
Comment 6 Marek Polacek 2015-01-29 21:02:55 UTC
Author: mpolacek
Date: Thu Jan 29 21:02:21 2015
New Revision: 220263

URL: https://gcc.gnu.org/viewcvs?rev=220263&root=gcc&view=rev
Log:
	PR c/64709
	* c-typeck.c (pop_init_level): If constructor_elements has
	exactly one element with integer_zerop value, set constructor_zeroinit
	to 1.  Remove braces around warning_init call.

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

Added:
    trunk/gcc/testsuite/gcc.dg/pr64709.c
Modified:
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-typeck.c
    trunk/gcc/testsuite/ChangeLog
Comment 7 Marek Polacek 2015-01-29 21:03:06 UTC
Fixed.