I was working on PR68425,
my untested patch :
diff --git a/trunk/gcc/c/c-typeck.c b/trunk/gcc/c/c-typeck.c
--- a/trunk/gcc/c/c-typeck.c (revision 232768)
+++ b/trunk/gcc/c/c-typeck.c (working copy)
@@ -5856,7 +5856,7 @@
component name is taken from the spelling stack. */
static void
-pedwarn_init (location_t location, int opt, const char *gmsgid)
+pedwarn_init (location_t location, int opt, const char *gmsgid, ...)
{
char *ofwhat;
bool warned;
@@ -9269,8 +9269,10 @@
&& (tree_int_cst_lt (constructor_max_index, constructor_index)
|| integer_all_onesp (constructor_max_index)))
{
- pedwarn_init (loc, 0,
- "excess elements in array initializer");
+ pedwarn_init (loc, 0, "excess elements in array initializer "
+ "(%lu elements, expected %lu)",
+ tree_to_uhwi (constructor_index) + 1,
+ tree_to_uhwi (constructor_max_index) + 1);
break;
}
for test case:
const int array[2] = { 1, 2, 3};
const int array1[3] = { 1, 2, 3 ,6};
const int array2[4] = { 1, 2, 3 ,6 ,89};
const int array3[5] = { 1, 2, 3 ,6 ,89 ,193};
It gives :
68425.c: In function ‘main’:
68425.c:3:34: warning: excess elements in array initializer (3
elements, expected 2)
const int array[2] = { 1, 2, 3};
^
68425.c:3:34: note: (near initialization for ‘array’)
68425.c:4:38: warning: excess elements in array initializer (4
elements, expected 3)
const int array1[3] = { 1, 2, 3 ,6};
^
68425.c:4:38: note: (near initialization for ‘array1’)
68425.c:5:41: warning: excess elements in array initializer (5
elements, expected 4)
const int array2[4] = { 1, 2, 3 ,6 ,89};
^~
68425.c:5:41: note: (near initialization for ‘array2’)
68425.c:6:45: warning: excess elements in array initializer (6
elements, expected 5)
const int array3[5] = { 1, 2, 3 ,6 ,89 ,193};
^~~
68425.c:6:45: note: (near initialization for ‘array3’)
Which is as described on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68425
But as we discussed in this thread,
for test case like :
int array[3] = { 1, 2, 3 ,6 ,89 ,193};
It gives:
68425_1.c: In function ‘main’:
68425_1.c:3:31: warning: excess elements in array initializer (4
elements, expected 3)
int array[3] = { 1, 2, 3 ,6 ,89 ,193};
^
68425_1.c:3:31: note: (near initialization for ‘array’)
68425_1.c:3:34: warning: excess elements in array initializer (4
elements, expected 3)
int array[3] = { 1, 2, 3 ,6 ,89 ,193};
^~
68425_1.c:3:34: note: (near initialization for ‘array’)
68425_1.c:3:38: warning: excess elements in array initializer (4
elements, expected 3)
int array[3] = { 1, 2, 3 ,6 ,89 ,193};
^~~
68425_1.c:3:38: note: (near initialization for ‘array’)
Should I submit the patch ?
On 20 February 2016 at 01:20, Manuel López-Ibáñez <lopeziba...@gmail.com> wrote:
> On 19 February 2016 at 19:13, David Malcolm <dmalc...@redhat.com> wrote:
>>> 68425.c:3:34: warning: excess elements in array initializer (6
>>> elements,
>>> expected 2)
>>> const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
>>> ^~~~~~~~~~~~~
>>
>> Yes, that would be ideal. Unfortunately, not every tree expression
>> node has a location stored for it, so implementing the underlined range
>> might be tricky to do. (in particular, INTEGER_CST doesn't. I hope to
>> look into that for gcc 7, perhaps with a wrapper node to provide
>> locations for expr nodes that don't have them).
>
> Do you think that would be better than storing the locations in the
> parent expression? That is, instead of adding extra wrapper nodes,
> with all those tree nodes wasting space just to provide a location,
> add extra location slots to every tree that may have an operand. Or
> perhaps you are thinking about adding some lighter wrapper which is
> just a loc+tree* or something like that.
>
> In the case above (for C), struct constructor_stack could keep track
> of token locations passed by the parser (all tokens have locations,
> but those locations are not saved in all trees). In fact, I see that
> there is already a lot of location passing in the corresponding code,
> but probably all of them refer to input_location or some such.
>
> Cheers,
>
> Manuel.
--
Thanks and Regards,
Prasad Ghangal
