------- Comment #11 from pinskia at gmail dot com 2010-09-02 05:55 ------- Subject: Re: r163660 ICEs gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os at -m32
On Sep 1, 2010, at 10:47 PM, "ubizjak at gmail dot com" <gcc-bugzi...@gcc.gnu.org > wrote: > > > ------- Comment #10 from ubizjak at gmail dot com 2010-09-02 05:47 > ------- > (In reply to comment #8) > >> Since this doesn't backtrace in gdb, I recompiled dwarf2out.c with >> the patch... > > You should use bigger hammer. > > Try valgrind using following procedure: > > a) Create a preprocessed source > "~/gcc-build/gcc/xgcc -B ~/gcc-build/gcc -Os -S -save-temps > sprintf-chk.c" > > b) fire up valgrind: > "valgrind ~/gcc-build/gcc/cc1 -Os -quiet sprintf-chk.i" > > ==3664== Memcheck, a memory error detector > ==3664== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et > al. > ==3664== Using Valgrind-3.5.0 and LibVEX; rerun with -h for > copyright info > ==3664== Command: /home/uros/gcc-build/gcc/cc1 -Os -quiet sprintf- > chk.i > ==3664== > ==3664== Invalid read of size 8 > ==3664== at 0xC71730: search_line_sse2 (lex.c:394) > ==3664== by 0xC71919: _cpp_clean_line (lex.c:665) > ==3664== by 0xC72317: _cpp_get_fresh_line (lex.c:1878) > ==3664== by 0xC73AA1: _cpp_lex_direct (lex.c:1943) > ==3664== by 0xC74896: _cpp_lex_token (lex.c:1817) > ==3664== by 0xC76FC7: cpp_get_token (macro.c:1240) > ==3664== by 0xC7727F: cpp_get_token_with_location (macro.c:1352) > ==3664== by 0x51684C: c_lex_with_flags (c-lex.c:302) > ==3664== by 0x4CFAA7: c_lex_one_token (c-parser.c:204) > ==3664== by 0x4DC468: c_parser_compound_statement_nostart (c- > parser.c:320) > ==3664== by 0x4DEA18: c_parser_compound_statement (c-parser.c:3545) > ==3664== by 0x4DBDC2: c_parser_declaration_or_fndef (c-parser.c: > 1375) > ==3664== Address 0x5331f50 is 5,808 bytes inside a block of size > 5,815 alloc'd > ==3664== at 0x4A05255: realloc (vg_replace_malloc.c:476) > ==3664== by 0xC9ADAC: xrealloc (xmalloc.c:179) > ==3664== by 0xC6659F: _cpp_convert_input (charset.c:1734) > ==3664== by 0xC6EFA2: read_file (files.c:648) > ==3664== by 0xC6F9CA: _cpp_stack_file (files.c:723) > ==3664== by 0xC71190: cpp_read_main_file (init.c:570) > ==3664== by 0x51B58A: c_common_post_options (c-opts.c:1124) > ==3664== by 0x7DACA4: toplev_main (toplev.c:1826) > ==3664== by 0x369861EC5C: (below main) (in /lib64/libc-2.12.so) > ==3664== > ==3664== Invalid read of size 8 > ==3664== at 0xC71723: search_line_sse2 (lex.c:382) > ==3664== by 0xC71919: _cpp_clean_line (lex.c:665) > ==3664== by 0xC72317: _cpp_get_fresh_line (lex.c:1878) > ==3664== by 0xC73AA1: _cpp_lex_direct (lex.c:1943) > ==3664== by 0xC74896: _cpp_lex_token (lex.c:1817) > ==3664== by 0xC76FC7: cpp_get_token (macro.c:1240) > ==3664== by 0xC7727F: cpp_get_token_with_location (macro.c:1352) > ==3664== by 0x51684C: c_lex_with_flags (c-lex.c:302) > ==3664== by 0x4CFAA7: c_lex_one_token (c-parser.c:204) > ==3664== by 0x4DC468: c_parser_compound_statement_nostart (c- > parser.c:320) > ==3664== by 0x4DEA18: c_parser_compound_statement (c-parser.c:3545) > ==3664== by 0x4DBDC2: c_parser_declaration_or_fndef (c-parser.c: > 1375) > ==3664== Address 0x5331f50 is 5,808 bytes inside a block of size > 5,815 alloc'd > ==3664== at 0x4A05255: realloc (vg_replace_malloc.c:476) > ==3664== by 0xC9ADAC: xrealloc (xmalloc.c:179) > ==3664== by 0xC6659F: _cpp_convert_input (charset.c:1734) > ==3664== by 0xC6EFA2: read_file (files.c:648) > ==3664== by 0xC6F9CA: _cpp_stack_file (files.c:723) > ==3664== by 0xC71190: cpp_read_main_file (init.c:570) > ==3664== by 0x51B58A: c_common_post_options (c-opts.c:1124) > ==3664== by 0x7DACA4: toplev_main (toplev.c:1826) > ==3664== by 0x369861EC5C: (below main) (in /lib64/libc-2.12.so) > ==3664== > > ==3680== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 6 from > 6) > > Woo-hoo? Actually those can be safely ignored. The loads will not cross page boundaries and then the code does not depend on the extra parts if the buffer has correctly a null character at the end. So it is a non bug that valgrind picks up but does not know how to handle when processing strings with vector instructions. > > > -- > > ubizjak at gmail dot com changed: > > What |Removed |Added > --- > --- > ---------------------------------------------------------------------- > Status|UNCONFIRMED |NEW > Ever Confirmed|0 |1 > Last reconfirmed|0000-00-00 00:00:00 |2010-09-02 05:47:57 > date| | > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45484 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45484
