This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Need suggestion about bug 68425


On 21 February 2016 at 12:32, Prasad Ghangal <prasad.ghangal@gmail.com> wrote:
> 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, ...)
You can't just forward arguments to pedwarn() from pedwarn_init() that way.
You will need to wrap them in va_list.
Perhaps write a version of pedwarn() taking va_list or replicate body of
pedwarn() in pedwarn_init()
>  {
>    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 ?
It would be nice if we can avoid warning multiple times.
It appears to me the warning is emitted multiple times because
process_init_element is called from c_parser_initval, which is called from
c_parser_initelt, which is called in a loop from c_parser_braced_init.
I attached an untested patch that prevents multiple warnings.

eg:
void foo(void)
{
  int a[2] = { 1, 2, 3, 4, 5 };
}

c-test.c: In function 'foo':
c-test.c:3:22: warning: excess elements in array initializer
   int a[2] = { 1, 2, 3, 4, 5 };
                            ^
c-test.c:3:22: note: (near initialization for 'a')

It uses a flag (warn_extra_init) to see if warning for extra initializer
has already been emitted. Perhaps you can try modifying it to emit
array sizes. There could also be a better way to avoid multiple warnings.

Thanks,
Prathamesh
>
>
>
> 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

Attachment: foo.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]