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