------- Comment #2 from giecrilj at stegny dot 2a dot pl  2010-08-27 20:58 
-------
#9  0x0000000000442a5e in digest_init_r (type=0x7ffff618ac00,
init=0x7ffff617c4c0, nested=1 '\001') at ../../gcc/cp/typeck2.c:785
785                     permerror (input_location, "initializer-string for
array of chars is too long");
(gdb) l
780                   /* In C it is ok to subtract 1 from the length of the
string
781                      because it's ok to ignore the terminating null char
that is
782                      counted in the length of the constant, but in C++ this
would
783                      be invalid.  */
784                   if (size < TREE_STRING_LENGTH (init))
785                     permerror (input_location, "initializer-string for
array of chars is too long");
786                 }
787               return init;
788             }
789         }

Symbol "input_location" is static storage.
The function digest_init_r does not modify it in any way.  It is an oblique
index (601), to be resolved by linemap_lookup in line_table.  If my
investigation is correct, in this particular case it would be
1 + 601 >> 7 == line 5

This particular value is assigned by the function
cp_lexer_set_source_position_from_token, specifically from token->location.

The stack:

#0  cp_lexer_consume_token (lexer=0x7ffff617c340) at ../../gcc/cp/parser.c:662
#1  0x00000000004647f7 in cp_parser_braced_list (parser=0x7ffff7e84730,
non_constant_p=0x7fffffffdb9e "") at ../../gcc/cp/parser.c:14692
#2  0x000000000046b07c in cp_parser_init_declarator (parser=0x7ffff7e84730,
decl_specifiers=0x7fffffffdbf0, checks=<value optimized out>, 
    function_definition_allowed_p=<value optimized out>, member_p=0 '\000',
declares_class_or_enum=<value optimized out>,                 
    function_definition_p=0x7fffffffdc5f "") at ../../gcc/cp/parser.c:12893     
The function cp_parser_init_declarator later calls cp_finish_decl
(./../gcc/cp/parser.c:12929), which is where the error is reported.  The error
reporting code incorrectly assumes that the offending line is stored in the
global input_location, which at the moment corresponds to the location of the
closing brace.  However, it seems that after the init tree has been
constructed, the tokens are gone, and so is line number information.

In conclusion, I think the easiest way to fix this problem (and perhaps other
similar ones) would be to add line number information from the original tokens
to the init tree.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431

Reply via email to