Re: Need suggestion about bug 68425

[Prasad Ghangal <prasad dot ghangal at gmail dot com>]

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 <lopezibanez@gmail.com> wrote:
> On 19 February 2016 at 19:13, David Malcolm <dmalcolm@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