[Bug middle-end/45484] r163660 ICEs gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os at -m32

Andrew Pinski pinskia@gmail.com
Thu Sep 2 05:55:00 GMT 2010



On Sep 1, 2010, at 10:47 PM, "ubizjak at gmail dot com" <gcc-bugzilla@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
>



More information about the Gcc-bugs mailing list