[Bug preprocessor/50144] New: cc1plus double free / out of bounds read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50144 Bug #: 50144 Summary: cc1plus double free / out of bounds read Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: edwinto...@gmail.com Created attachment 25066 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25066 x.cpp Lately gcc 4.6.1 has been segfaulting quite often. Not always on the same file, but usually when building ClamAV in 'make distcheck' mode. See below for a double free stacktrace. Running valgrind on the preprocessed file doesn't show anything, but running valgrind on original GCC invocation shows some errors in the preprocessor. Here is a command that reproduces the valgrind error. $ valgrind /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus -quiet x.cpp -E /dev/null The file x.cpp is attached, and has all #include removed and still shows the valgrind error: ==3237== Invalid read of size 8 ==3237==at 0xBFEFE9: ??? (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFF181: _cpp_clean_line (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFFB57: _cpp_get_fresh_line (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC012D1: _cpp_lex_direct (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC02116: _cpp_lex_token (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC04817: cpp_get_token (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC04AAF: cpp_get_token_with_location (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x5AE914: preprocess_file (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x5ACF1A: c_common_init (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x513228: cxx_init (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x7D40AC: toplev_main (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x3C7141EEAC: (below main) (libc-start.c:228) ==3237== Address 0x4ceb0c0 is 7,232 bytes inside a block of size 7,238 alloc'd ==3237==at 0x4A07882: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3237==by 0xC2865C: xrealloc (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBF3E5B: _cpp_convert_input (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFC782: ??? (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFD17A: _cpp_stack_file (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFEA55: cpp_read_main_file (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x5AC72A: c_common_post_options (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x7D3BA2: toplev_main (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x3C7141EEAC: (below main) (libc-start.c:228) ==3237== ==3237== Invalid read of size 8 ==3237==at 0xBFEFD3: ??? (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFF181: _cpp_clean_line (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFFB57: _cpp_get_fresh_line (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC012D1: _cpp_lex_direct (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC02116: _cpp_lex_token (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC04817: cpp_get_token (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xC04AAF: cpp_get_token_with_location (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x5AE914: preprocess_file (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x5ACF1A: c_common_init (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x513228: cxx_init (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x7D40AC: toplev_main (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0x3C7141EEAC: (below main) (libc-start.c:228) ==3237== Address 0x4ceb0c0 is 7,232 bytes inside a block of size 7,238 alloc'd ==3237==at 0x4A07882: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==3237==by 0xC2865C: xrealloc (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBF3E5B: _cpp_convert_input (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus) ==3237==by 0xBFC782: ??? (in /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6/cc1plus)
[Bug preprocessor/50144] cc1plus double free / out of bounds read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50144 --- Comment #1 from Török Edwin edwintorok at gmail dot com 2011-08-21 15:52:33 UTC --- And here is a stacktrace from a local GCC build so you have line numbers: $ valgrind --trace-children=yes /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/xgcc -B/home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc /tmp/x.cpp -E /dev/null ==2671== Memcheck, a memory error detector ==2671== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==2671== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==2671== Command: /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/xgcc -B/home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc /tmp/x.cpp -E ==2671== ==2675== Memcheck, a memory error detector ==2675== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==2675== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==2675== Command: /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/cc1plus -E -quiet -iprefix /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/../lib/gcc/x86_64-linux-gnu/4.6.1/ -isystem /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/include -isystem /home/edwin/gcc-4.6-4.6.1/src/host-x86_64-linux-gnu/gcc/include-fixed -D_GNU_SOURCE /tmp/x.cpp -mtune=generic -march=x86-64 ==2675== ==2675== Invalid read of size 8 ==2675==at 0x11D71C9: search_line_sse2 (lex.c:394) ==2675==by 0x11D7361: _cpp_clean_line (lex.c:666) ==2675==by 0x11D7D37: _cpp_get_fresh_line (lex.c:1887) ==2675==by 0x11D94B1: _cpp_lex_direct (lex.c:1952) ==2675==by 0x11DA2F6: _cpp_lex_token (lex.c:1826) ==2675==by 0x11DC9F7: cpp_get_token (macro.c:1240) ==2675==by 0x11DCC8F: cpp_get_token_with_location (macro.c:1352) ==2675==by 0x6C87A4: preprocess_file (c-ppoutput.c:175) ==2675==by 0x6C6D2B: c_common_init (c-opts.c:1057) ==2675==by 0x5C7668: cxx_init (lex.c:254) ==2675==by 0xA3204C: toplev_main (toplev.c:1742) ==2675==by 0x3C7141EEAC: (below main) (libc-start.c:228) ==2675== Address 0x4cec1f0 is 7,232 bytes inside a block of size 7,238 alloc'd ==2675==at 0x4A07882: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2675==by 0x120070C: xrealloc (xmalloc.c:179) ==2675==by 0x11CC03B: _cpp_convert_input (charset.c:1734) ==2675==by 0x11D4962: read_file (files.c:648) ==2675==by 0x11D535A: _cpp_stack_file (files.c:723) ==2675==by 0x11D6C35: cpp_read_main_file (init.c:570) ==2675==by 0x6C64EA: c_common_post_options (c-opts.c:1016) ==2675==by 0xA31B30: toplev_main (toplev.c:1283) ==2675==by 0x3C7141EEAC: (below main) (libc-start.c:228) ==2675== ==2675== Invalid read of size 8 ==2675==at 0x11D71B3: search_line_sse2 (lex.c:382) ==2675==by 0x11D7361: _cpp_clean_line (lex.c:666) ==2675==by 0x11D7D37: _cpp_get_fresh_line (lex.c:1887) ==2675==by 0x11D94B1: _cpp_lex_direct (lex.c:1952) ==2675==by 0x11DA2F6: _cpp_lex_token (lex.c:1826) ==2675==by 0x11DC9F7: cpp_get_token (macro.c:1240) ==2675==by 0x11DCC8F: cpp_get_token_with_location (macro.c:1352) ==2675==by 0x6C87A4: preprocess_file (c-ppoutput.c:175) ==2675==by 0x6C6D2B: c_common_init (c-opts.c:1057) ==2675==by 0x5C7668: cxx_init (lex.c:254) ==2675==by 0xA3204C: toplev_main (toplev.c:1742) ==2675==by 0x3C7141EEAC: (below main) (libc-start.c:228) ==2675== Address 0x4cec1f0 is 7,232 bytes inside a block of size 7,238 alloc'd ==2675==at 0x4A07882: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2675==by 0x120070C: xrealloc (xmalloc.c:179) ==2675==by 0x11CC03B: _cpp_convert_input (charset.c:1734) ==2675==by 0x11D4962: read_file (files.c:648) ==2675==by 0x11D535A: _cpp_stack_file (files.c:723) ==2675==by 0x11D6C35: cpp_read_main_file (init.c:570) ==2675==by 0x6C64EA: c_common_post_options (c-opts.c:1016) ==2675==by 0xA31B30: toplev_main (toplev.c:1283) ==2675==by 0x3C7141EEAC: (below main) (libc-start.c:228)
[Bug preprocessor/50144] cc1plus double free / out of bounds read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50144 --- Comment #3 from Török Edwin edwintorok at gmail dot com 2011-08-21 16:41:19 UTC --- (In reply to comment #2) The valgrind errors about search_line_sse2 are valgrind bugs rather than gcc bugs. Just ignore them. OK, I'll try to find some other valgrind trace. (In reply to comment #0) CXXMemoryBuiltins.lo *** glibc detected *** /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus: double free or corruption (out): 0x02a0e280 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6[0x3c71472606] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x3c7147733c] /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(ggc_internal_alloc_stat+0x25e)[0x5bb86e] /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(ggc_internal_cleared_alloc_stat+0x16)[0x6c1446] /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(make_node_stat+0x1f)[0x8e1fff] /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(alloc_stmt_list+0x5a)[0x8059ca] /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(push_stmt_list+0x6)[0x5b47f6] /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus[0x550e25] /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus(begin_if_stmt+0x15)[0x551765] begin_if_stmt appears to be part of the parser though, not the preprocessor (I thought if refers to #if, but apparently not). So was this a parser crash?
[Bug preprocessor/50144] cc1plus double free / out of bounds read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50144 Török Edwin edwintorok at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Török Edwin edwintorok at gmail dot com 2011-08-21 19:48:34 UTC --- Nevermind, just did a memtest and it found 1 stuck bit in one of the 4G modules. Going to close this as invalid for now, as I was not able to get any more warnings with valgrind.
[Bug lto/49677] New: GCC 4.6.0 LTO files not compatible with GCC 4.6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49677 Summary: GCC 4.6.0 LTO files not compatible with GCC 4.6.1 Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: edwinto...@gmail.com Created attachment 24714 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24714 test.o Using gcc 4.6.1 to link objects compiled with GCC 4.6.0 -flto produces this error: $ gcc test.o -flto -shared lto1: error: bad value (generic) for -mtls-dialect= switch lto-wrapper: /usr/bin/gcc returned 1 exit status /usr/bin/ld: lto-wrapper failed collect2: ld returned 1 exit status There is no -mtls-dialect=generic flag, (and there wasn't either). Instead there is an -mtune=generic flag: COLLECT_GCC_OPTIONS='-flto' '-shared' '-v' '-mtune=generic' '-march=x86-64' I think 4.6.1 confuses -mtune and -mtls-dialect when loading 4.6.0 LTO objects. Maybe the LTO version should be bumped to make these objects incompatible? Fixing this compile error is possible if: - make clean in all the projects that you link in - ccache -C, ccache -c to delete all cached objects from previous version It'd be better if GCC automatically detected that a certain LTO object file is not compatible, and say which one it is. In any case it'd be useful if there would be a -Wlto-mismatch, that would warn if LTO objects were produced with different GCC versions (.comment section should contain full version), or if the LTO objects and current compiler version are different. gcc -v output: Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-2' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 (Debian 4.6.1-2) I'm attaching the test.o file, because it the bug doesn't reproduce if I compile it again from source with 4.6.1, only if I use the object file compiled by 4.6.0.
[Bug tree-optimization/49618] When building uClibc with GCC 4.6.1 old_atexit is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49618 --- Comment #2 from Török Edwin edwintorok at gmail dot com 2011-07-03 15:07:02 UTC --- (In reply to comment #1) Ouch. I can see where it might be NULL… but in anal-C99 taking a pointer of an object (__dso_handle) can never be a NULL pointer, so GCC might, in a very theoretical sense, be correct in optimising away this check. Does adding -fno-delete-null-pointer-checks to the compile options help? No, with -fno-delete-null-pointer-checks the 'beq' instruction is still deleted. -O1 works though.
[Bug c++/49347] New: G++-4.6 Solaris incorrectly defines _RESTRICT_KYWD to __restrict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49347 Summary: G++-4.6 Solaris incorrectly defines _RESTRICT_KYWD to __restrict Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: edwinto...@gmail.com Host: i386-pc-solaris2.10 Target: i386-pc-solaris2.10 Build: i386-pc-solaris2.10 Created attachment 24477 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24477 x.i G++ 4.6 shows this error, G++ 4.3.3 doesn't: /usr/include/spawn.h:42:14: error: expected ',' or '...' before 'argv' /usr/include/spawn.h:50:14: error: expected ',' or '...' before 'argv' Solaris defines posix_spawn like this: extern int posix_spawn( pid_t *_RESTRICT_KYWD pid, const char *_RESTRICT_KYWD path, const posix_spawn_file_actions_t *file_actions, const posix_spawnattr_t *_RESTRICT_KYWD attrp, char *const argv[_RESTRICT_KYWD], char *const envp[_RESTRICT_KYWD]); With GCC 4.6 I see this in preprocessed file: # 358 /usr/local/lib/gcc/i386-pc-solaris2.10/4.6.0/include-fixed/sys/feature_tests.h 3 4 ... #if (defined(__STDC__) defined(_STDC_C99)) #ifdef __cplusplus #define _RESTRICT_KYWD __restrict #else #define _RESTRICT_KYWD restrict #endif #else #define _RESTRICT_KYWD #endif With 4.3.3 I see this: #if (defined(__STDC__) defined(_STDC_C99)) #define _RESTRICT_KYWD restrict #else #define _RESTRICT_KYWD #endif The system header is: /usr/include/sys/feature_tests.h: #if (defined(__STDC__) defined(_STDC_C99)) #define _RESTRICT_KYWD restrict #else #define _RESTRICT_KYWD #endif Don't know where the #define to __restrict on __cplusplus comes from, but it is wrong. GCC 4.6 is: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-pc-solaris2.10/4.6.0/lto-wrapper Target: i386-pc-solaris2.10 Configured with: /home/chris/apps/compiler/gcc-4.6.0/configure --enable-languages=c,c++ --disable-libgcj --with-as=/usr/local/bin/as --with-gnu-as --with-ld=/usr/local/bin/ld --with-gnu-ld --disable-nls Thread model: posix gcc version 4.6.0 (GCC) GCC 4.3.3 is: Using built-in specs. Target: i386-pc-solaris2.10 Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --exec-prefix=/opt/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib --enable-libada --enable-libssp --enable-objc-gc --enable-threads=posix --enable-stage1-languages=c --enable-languages=ada,c,c++,fortran,java,objc Thread model: posix gcc version 4.3.3 (GCC) To reproduce bug just do this: $ echo #include spawn.h x.cpp $ g++-4.6 x.cpp In file included from x.cpp:1:0: /usr/include/spawn.h:42:14: error: expected ',' or '...' before 'argv' /usr/include/spawn.h:50:14: error: expected ',' or '...' before 'argv' Preprocessed x.i attached. Originally reported for ClamAV: https://wwws.clamav.net/bugzilla/show_bug.cgi?id=2921
[Bug c++/49347] G++-4.6 Solaris incorrectly defines _RESTRICT_KYWD to __restrict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49347 --- Comment #2 from Török Edwin edwintorok at gmail dot com 2011-06-09 18:29:22 UTC --- (In reply to comment #1) (In reply to comment #0) Don't know where the #define to __restrict on __cplusplus comes from, but it is wrong. No, it's correct, see http://gcc.gnu.org/onlinedocs/gcc/Restricted-Pointers.html The bug is that G++ can't parse __restrict in an array parameter: extern int f( char *const envp[__restrict] ); The C front end accepts this, but not the C++ one. Is that planned to be fixed for the next release? If not then as a workaround that fix-includes header could #define _RESTRICY_KYWD to empty.
[Bug c/38037] false uninitialized warnings when using a pointer as a guard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38037 Török Edwin edwintorok at gmail dot com changed: What|Removed |Added CC||nicola at gcc dot gnu.org --- Comment #6 from Török Edwin edwintorok at gmail dot com 2011-05-25 20:00:05 UTC --- (In reply to comment #5) Author: nicola Date: Wed May 25 18:54:40 2011 New Revision: 174221 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174221 Log: In libobjc/: 2011-05-25 Richard Frith-Macdonald r...@gnu.org David Ayers ay...@fsfe.org PR libobjc/38037 Wrong bug number? This is not a libobjc bug...
[Bug target/48789] missed ARM optimization: use LDMIA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48789 --- Comment #3 from Török Edwin edwintorok at gmail dot com 2011-04-27 11:11:02 UTC --- Created attachment 24116 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24116 bench.c
[Bug target/48789] missed ARM optimization: use LDMIA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48789 --- Comment #2 from Török Edwin edwintorok at gmail dot com 2011-04-27 11:10:49 UTC --- Created attachment 24115 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24115 test.S
[Bug target/48789] missed ARM optimization: use LDMIA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48789 --- Comment #1 from Török Edwin edwintorok at gmail dot com 2011-04-27 11:10:35 UTC --- Created attachment 24114 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24114 reverse.c
[Bug target/48789] New: missed ARM optimization: use LDMIA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48789 Summary: missed ARM optimization: use LDMIA Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: edwinto...@gmail.com Host: x86_64-linux-gnu Target: arm-elf Build: x86_64-linux-gnu The attached testcase compiles to larger and slower code than the hand-optimized version, although the C code follows closely the structure of hand-optimized assembly. To reproduce the missed optimization: arm-elf-gcc reverse.c -O3 -mcpu=arm946e-s -msoft-float The reverse_bytes_order_c2 has too many ldr/str instructions, it should use ldmia/stmia as seen in the hand-optimized version (test.S reverse_bytes_order2). Note: without -msoft-float it generates faster code by using VFP instructions, but my CPU doesn't support them, so I have to turn off floating point generation. Attachments: reverse.c: the testcase test.S: the hand-optimized version of the reverse_bytes_order_c2, called reverse_bytes_order2 here (code from CHDK's lib/armutil/) bench.c: a simple benchmark runner to compare gcc's version with the hand optimized one This happens both with 4.6 and 4.5: $ arm-elf-gcc -v Using built-in specs. COLLECT_GCC=../build-dir/arm/toolchain/bin/arm-elf-gcc COLLECT_LTO_WRAPPER=/home/edwin/chdk/build-dir/arm/toolchain/libexec/gcc/arm-elf/4.6.0/lto-wrapper Target: arm-elf Configured with: ../gcc-4.6.0/configure --target=arm-elf --prefix=/home/edwin/chdk/build-dir/arm/toolchain --enable-interwork --enable-multilib --enable-languages=c --with-newlib --with-gmp-include=/home/edwin/chdk/build-dir/build/gmp --with-gmp-lib=/home/edwin/chdk/build-dir/build/gmp/.libs --without-headers --disable-libssp --disable-nls --disable-zlib --disable-libc --disable-libm --disable-intl --disable-hardfloat --disable-threads --with-gnu-as --with-gnu-ld Thread model: single gcc version 4.6.0 (GCC) $ /opt/cfarm/release/4.5.0/bin/gcc -v Using built-in specs. COLLECT_GCC=/opt/cfarm/release/4.5.0/bin/gcc COLLECT_LTO_WRAPPER=/home/guerby/opt/release/4.5.0/bin/../libexec/gcc/armv7l-unknown-linux-gnueabi/4.5.0/lto-wrapper Target: armv7l-unknown-linux-gnueabi Configured with: ../gcc-4.5.0/configure --prefix=/opt/cfarm/release/4.5.0 --enable-languages=c,ada --enable-__cxa_atexit --disable-nls --enable-threads=posix --disable-multilib --with-gmp=/opt/cfarm/gmp-4.2.4 --with-mpfr=/opt/cfarm/mpfr-2.4.2 --with-mpc=/opt/cfarm/mpc-0.8 --with-cpu=cortex-a8 --with-fpu=neon --with-float=softfp --disable-werror Thread model: posix gcc version 4.5.0 (GCC) Some benchmarks (run on gcc33, which would support armv7, but my CPU won't, so I can only use armv5te): base: 0.340810 (hand-optimized assembly) 3: 0.840712 (alternate version) c: 0.379164 (C code, compiled with -O3) c2: 0.395410 (C code, unrolled 8 times as the hand assembly, compiled with -O3) (note: run benchmark as ./a.out; ./a.out; ./a.out. I think there is some frequency scaling causing the first run to be slower) To run benchmark: /opt/cfarm/release/4.5.0/bin/gcc bench.c reverse.c test.S -O3 -mcpu=arm946e-s -msoft-float
[Bug tree-optimization/46763] New: gcc 4.5: missed optimization: copy global to local, prefetch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46763 Summary: gcc 4.5: missed optimization: copy global to local, prefetch Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: edwinto...@gmail.com Created attachment 22601 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22601 gy.i.bz2 I made a simple change to OCaml's GC: copy a global to a local var (and restore before calling external function), and add a prefetchnta. The global optimization is worth ~4% speedup, the prefetchnta alone is ~8% speedup, and both ~10% speedup. I would expect GCC to do this optimization by itself (at least the global to register one). Attached is a testcase to show the missed optimization, the relevant function is sweep_slice (and its manually optimized variants sweep_slice2, ...): $ gcc-4.5 gy.i -O2 -lm $ ./a.out default: 1.325195s ( 100.0%) glob2loc: 1.268875s ( 95.8% +- 1.024%) prefetchnta: 1.207342s ( 91.1% +- 0.4986%) prefetch: 1.277638s ( 96.4% +- 0.1179%) glob2loc+prefetchnta: 1.199906s ( 90.5% +- 0.3629%) default is the original function (sweep_slice), glob2loc is my manual optimization of caml_gc_sweep_hp, prefetchnta and prefetch are __builtin_prefetch added by me (non-temporal prefetch is very good here), the last one is both manual optimizations at once, resulting in a 9.5% speedup. The attached testcase is quite large, because I dumped the sizes of all objects from the GC to have a realistic run of the GC, I also included all functions needed for the GC to run. gcc-4.5 and gcc-4.4 both have this missed optimization, didn't try older ones. BTW OCaml uses just -O -fno-defer-pop to compile, instead of -O2, but using -O or -O2 doesn't make much difference on this testcase, so I used -O2. $ gcc-4.5 -v Using built-in specs. COLLECT_GCC=gcc-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.5.1-11' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.5.1 (Debian 4.5.1-11) CPU: AMD Phenom(tm) II X6 1090T Processor uname -a: Linux debian 2.6.36-phenom #107 SMP PREEMPT Sat Oct 23 10:30:01 EEST 2010 x86_64 GNU/Linux
[Bug rtl-optimization/45678] New: gcc-4.4: crash on vector code with -m32 -msse
This testcase crashes when compiled with gcc 4.4 -m32 -msse -O2, but not when
compiled with 4.3 or 4.5. It doesn't crash when compiled as -m64.
/* compile me with -O2 -msse -m32 */
#include string.h
typedef float v4sf __attribute__ ((vector_size (16)));
int main(void)
{
float m4[4];
v4sf m3;
float m2[4] = {4, 3, 2, 1};
v4sf one2 = {5, 15, 25, 35};
memcpy(m3, m2, sizeof(m2));
m3 = m3 * one2;
memcpy(m4, m3, sizeof(m4));
if (m4[0] != 20)
return 1;
return 0;
}
$ gcc-4.4 bug.c -m32 -O2 -msse
$ ./a.out
Segmentation fault
GDB shows it crashes on the SSE instructions, probably wrong alignment:
Dump of assembler code for function main:
0x080483a0 +0: push %ebp
0x080483a1 +1: mov%esp,%ebp
0x080483a3 +3: sub$0x14,%esp
0x080483a6 +6: movaps 0x80484d0,%xmm0
0x080483ad +13:movl $0x4080,0x4(%esp)
0x080483b5 +21:movl $0x4040,0x8(%esp)
0x080483bd +29:flds 0x80484e0
0x080483c3 +35:movl $0x4000,0xc(%esp)
0x080483cb +43:movl $0x3f80,0x10(%esp)
= 0x080483d3 +51:mulps 0x4(%esp),%xmm0
0x080483d8 +56:movss %xmm0,(%esp)
0x080483dd +61:flds (%esp)
0x080483e0 +64:fucomip %st(1),%st
0x080483e2 +66:fstp %st(0)
0x080483e4 +68:setne %al
0x080483e7 +71:setp %dl
0x080483ea +74:or %edx,%eax
0x080483ec +76:movzbl %al,%eax
0x080483ef +79:leave
0x080483f0 +80:ret
End of assembler dump.
gcc -v output:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.4-14'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 20100909 (prerelease) (Debian 4.4.4-14)
My libc version is this (should it matter):
GNU C Library (Debian EGLIBC 2.11.2-5) stable release version 2.11.2, by Roland
McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.5 20100824 (prerelease).
Compiled on a Linux 2.6.32 system on 2010-09-03.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
http://www.debian.org/Bugs/.
--
Summary: gcc-4.4: crash on vector code with -m32 -msse
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
[Bug tree-optimization/45260] New: g++4.5: -prefetch-loop-arrays internal compiler error: in verify_expr, at tree-cfg.c:2541
See https://wwws.clamav.net/bugzilla/show_bug.cgi?id=2190 $ g++-4.5 -fprefetch-loop-arrays TargetLowering.ii -c -O2 ../../../../clamav-devel/libclamav/c++/llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp: In member function void llvm::TargetLowering::computeRegisterProperties(): ../../../../clamav-devel/libclamav/c++/llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp:608:6: internal compiler error: in verify_expr, at tree-cfg.c:2541 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.5/README.Bugs for instructions. g++-4.4 works: $ g++-4.4 -fprefetch-loop-arrays TargetLowering.ii -c -O2 $ g++-4.5 -v Using built-in specs. COLLECT_GCC=/usr/bin/g++-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.5.1-1' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --program-suffix=-4.5 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --with-plugin-ld=ld.gold --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.5.1 (Debian 4.5.1-1) -- Summary: g++4.5: -prefetch-loop-arrays internal compiler error: in verify_expr, at tree-cfg.c:2541 Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45260
[Bug tree-optimization/45260] g++4.5: -prefetch-loop-arrays internal compiler error: in verify_expr, at tree-cfg.c:2541
--- Comment #1 from edwintorok at gmail dot com 2010-08-11 20:27 --- Created an attachment (id=21457) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21457action=view) TargetLowering.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45260
[Bug c++/43874] New: gcc should warn when 'new' is used on type with alignof greater than 2*sizeof(void*)
See https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1984 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795 http://sourceware.org/bugzilla/show_bug.cgi?id=206 When __alignof(type) is 16 on a 32-bit system, and 'new' returns only 8-byte aligned memory, -ftree-vectorize can cause the code to crash. GCC should at least warn (or even error out) when __alignof(type) alignment_of_new/malloc. Or it could use memalign, to fix this and avoid the crash. Right now it just silently creates code that crashes. -- Summary: gcc should warn when 'new' is used on type with alignof greater than 2*sizeof(void*) Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43874
[Bug tree-optimization/43472] New: gcc -O3: exhausts memory on whetstone.cbe.
gcc -O2 works on this file: gcc whetstone.cbe.c -lm -O2 -fno-strict-aliasing -fno-inline -m64 -fomit-frame-pointer gcc -O3 exhausts memory: gcc whetstone.cbe.c -lm -O3 -fno-strict-aliasing -fno-inline -m64 -fomit-frame-pointer virtual memory exhausted: Cannot allocate memory $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.3-3' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.3 (Debian 4.4.3-3) $ uname -a Linux debian 2.6.33-00175-g2d1299a0 #10 SMP PREEMPT Mon Mar 15 15:42:54 EET 2010 x86_64 GNU/Linux The system has plenty of memory (4G of RAM + even more swap) $ free total used free sharedbuffers cached Mem: 398003213922882587744 0 20492 569508 -/+ buffers/cache: 8022883177744 Swap: 5863704 885085916 -- Summary: gcc -O3: exhausts memory on whetstone.cbe. Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43472
[Bug tree-optimization/43472] gcc -O3: exhausts memory on whetstone.cbe.
--- Comment #1 from edwintorok at gmail dot com 2010-03-21 20:11 --- Created an attachment (id=20155) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20155action=view) whetstone.cbe.c testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43472
[Bug target/43297] [4.4 regression] -O2 -fPIC breaks htmlnorm.c
--- Comment #4 from edwintorok at gmail dot com 2010-03-09 13:01 --- (In reply to comment #3) Please test a more recent version from the 4.4 branch (and trunk if possible). Ok, I found gcc 4.4.3 on gcc200 and it still produces wrong code: $ /opt/cfarm/release/4.4.3/bin/gcc -v Using built-in specs. Target: sparc64-unknown-linux-gnu Configured with: ../gcc-4.4.3/configure --prefix=/opt/cfarm/release/4.4.3 --disable-werror --enable-languages=c,c++,fortran,ada --enable-__cxa_atexit --disable-nls --enable-threads=posix --with-gmp=/opt/cfarm/gmp-4.2.4 --with-mpfr=/opt/cfarm/mpfr-2.4.2 --with-cpu=v8 --disable-multilib Thread model: posix gcc version 4.4.3 (GCC) $ /opt/cfarm/release/4.4.3/bin/gcc -O2 -fPIC hh.c $ ./a.out Aborted It seems to be a problem only when creating 32-bit code, -m64 works fine: $ /opt/cfarm/release/4.4.3-64/bin/gcc -O2 -fPIC -m64 hh.c $./a.out And -m32 aborts of course: $ /opt/cfarm/release/4.4.3-64/bin/gcc -O2 -fPIC -m32 hh.c $./a.out /opt/cfarm/release/4.4.3-64/bin/gcc -v Using built-in specs. Target: sparc64-unknown-linux-gnu Configured with: ../gcc-4.4.3/configure --prefix=/opt/cfarm/release/4.4.3-64 --disable-werror --enable-languages=c,c++,fortran,ada --enable-__cxa_atexit --disable-nls --enable-threads=posix --with-gmp=/opt/cfarm/gmp-4.2.4-64 --with-mpfr=/opt/cfarm/mpfr-2.4.2-64 Thread model: posix gcc version 4.4.3 (GCC) Aborted -- edwintorok at gmail dot com changed: What|Removed |Added Known to fail|4.4.1 |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43297
[Bug tree-optimization/43297] New: [4.3 regression] sparc64 -O2 -fPIC breaks htmlnorm.c
On sparc64 gcc 4.4.1 -O3 -fPIC breaks ClamAV's htmlnorm.c. To reproduce bug: $ /opt/cfarm/release/4.4.1/bin/gcc -O3 -fPIC hh.c $ ./a.out Aborted On the attached testcase -O2 -fPIC breaks too (on ClamAV's htmlnorm only -O3 breaks): $ /opt/cfarm/release/4.4.1/bin/gcc -O2 -fPIC hh.c $ ./a.out Aborted Working flags/compilers: $ /opt/cfarm/release/4.4.1/bin/gcc -O1 -fPIC hh.c $ ./a.out $ /opt/cfarm/release/4.4.1/bin/gcc -O2 hh.c $ ./a.out $ /opt/cfarm/release/4.4.1/bin/gcc -O3 hh.c $ ./a.out $ /opt/cfarm/release/4.3.3/bin/gcc -O3 -fPIC hh.c $ ./a.out $ /opt/cfarm/release/4.3.3/bin/gcc -O2 -fPIC hh.c $ ./a.out $ gcc -O3 -fPIC hh.c $ ./a.out $ gcc -O2 -fPIC hh.c $ ./a.out System: Linux gcc54 2.6.18-6-sparc64 #1 Sat Dec 27 11:05:53 UTC 2008 sparc64 GNU/Linux Buggy compiler version: $ /opt/cfarm/release/4.4.1/bin/gcc -v Using built-in specs. Target: sparc64-unknown-linux-gnu Configured with: ../gcc-4.4.1/configure --enable-languages=all,ada --enable-__cxa_atexit --disable-nls --with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4 --prefix=/opt/cfarm/release/4.4.1 --with-cpu=v8 Thread model: posix gcc version 4.4.1 (GCC) Working compilers: $ /opt/cfarm/release/4.3.3/bin/gcc -v Using built-in specs. Target: sparc64-unknown-linux-gnu Configured with: ../gcc-4.3.3/configure --prefix=/opt/cfarm/release/4.3.3 --enable-__cxa_atexit --disable-nls --enable-threads=posix --with-mpfr=/opt/cfarm/mpfr-2.3.2 --with-cpu=v8 --enable-languages=c,ada Thread model: posix gcc version 4.3.3 (GCC) $ gcc -v Using built-in specs. Target: sparc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-cpu=v8 --enable-checking=release sparc-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) -- Summary: [4.3 regression] sparc64 -O2 -fPIC breaks htmlnorm.c Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: sparc64-unknown-linux-gnu GCC host triplet: sparc64-unknown-linux-gnu GCC target triplet: sparc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43297
[Bug tree-optimization/43297] [4.3 regression] sparc64 -O2 -fPIC breaks htmlnorm.c
--- Comment #1 from edwintorok at gmail dot com 2010-03-08 21:03 --- Created an attachment (id=20046) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20046action=view) testcase Testcase (partially) reduced with delta. Could probably be reduced further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43297
[Bug tree-optimization/43280] New: gcc4.5 -m32 -O2: misoptimizes sha256!
gcc-4.5 -O2 -m32 misoptimizes sha256: $ ~/gcc/install/bin/gcc-4.5 sha256.c -L/home/edwin/gcc/install/lib/gcc/x86_64-unknown-linux-gnu/lib32 -O2 -m32 $ ./a.out sha256 test vector #1 failed sha256 test vector #2 failed sha256 test vector #3 failed Aborted Without -m32 it works: $ ~/gcc/install/bin/gcc-4.5 sha256.c -L/home/edwin/gcc/install/lib/gcc/x86_64-unknown-linux-gnu/lib64 -O2 $ ./a.out $ And -m32 -O1 works too: $ ~/gcc/install/bin/gcc-4.5 sha256.c -L/home/edwin/gcc/install/lib/gcc/x86_64-unknown-linux-gnu/lib32 -O1 -m32 $ ./a.out $ gcc version: ~/gcc/install/bin/gcc-4.5 -v Using built-in specs. COLLECT_GCC=/home/edwin/gcc/install/bin/gcc-4.5 COLLECT_LTO_WRAPPER=/home/edwin/gcc/install/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c --enable-checking=release --enable-ssp --disable-libssp --disable-plugin --disable-libmudflap --with-system-zlib --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex -without-system-libunwind --with-arch-32=i586 --with-tune=generic --with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4 --with-libelf=/opt/cfarm/libelf-0.8.12 --with-mpc=/opt/cfarm/mpc-0.8 --disable-bootstrap : (reconfigured) ../gcc-trunk/configure --prefix=/home/edwin/gcc/install --enable-languages=c --enable-checking=release --enable-ssp --disable-libssp --disable-plugin --disable-libmudflap --with-system-zlib --enable-version-specific-runtime-libs --program-suffix=-4.5 --enable-linux-futex -without-system-libunwind --with-arch-32=i586 --with-tune=generic --with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4 --with-libelf=/opt/cfarm/libelf-0.8.12 --with-mpc=/opt/cfarm/mpc-0.8 --disable-bootstrap Thread model: posix gcc version 4.5.0 20100307 (experimental) (GCC) Bug initially reported against openSUSE 11.3 factory's gcc-4.5, but I reproduced with upstream gcc-4.5 SVN r157262. See https://wwws.clamav.net/bugzilla/show_bug.cgi?id=1862 for the original report. -- Summary: gcc4.5 -m32 -O2: misoptimizes sha256! Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
[Bug tree-optimization/43280] gcc4.5 -m32 -O2: misoptimizes sha256!
--- Comment #1 from edwintorok at gmail dot com 2010-03-07 12:19 --- Created an attachment (id=20038) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20038action=view) sha256.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
[Bug tree-optimization/43280] gcc4.5 -m32 -O2: misoptimizes sha256!
--- Comment #2 from edwintorok at gmail dot com 2010-03-07 12:19 --- Created an attachment (id=20039) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20039action=view) preprocessed sha256.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43280
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #20 from edwintorok at gmail dot com 2010-01-27 12:35 --- Thanks to Jakub for the hints. This is not a bug in libstdc++/gcc: the problem is that fork() is called when we already have threads (due to openmp/libstdc++ parallel mode), and then you can call a limited number of functions before exec(). std::find is called both before and after fork(). This is fine in a default build, but in a parallel mode build, the first std::find spawns threads, which ClamAV doesn't expect. I will just make it a #error if ClamAV is built in libstdc++ parallel mode. -- edwintorok at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #15 from edwintorok at gmail dot com 2010-01-13 20:39 --- (In reply to comment #14) (In reply to comment #13) This code is compiled with -fno-exceptions, could that be a problem? No, that should rather help. Still, it is very difficult to debug this. Is there at least a way to access clamd's stdout and/or stderr? The usual way to debug clamd is by setting 'Foreground yes' in clamd.conf, however the bug doesn't reproduce then. You can however still get stderr/stdout by applying the patch below, and starting clamd like this: $ clamd/clamd -c etc/clamd.conf stdout.log 2stderr.log or even without redirection: $ clamd/clamd -c etc/clamd.conf diff --git a/shared/misc.c b/shared/misc.c index 080d4ec..656dda5 100644 --- a/shared/misc.c +++ b/shared/misc.c @@ -247,7 +247,7 @@ int daemonize(void) int fds[3], i; pid_t pid; - +#if 0 fds[0] = open(/dev/null, O_RDONLY); fds[1] = open(/dev/null, O_WRONLY); fds[2] = open(/dev/null, O_WRONLY); @@ -272,7 +272,7 @@ int daemonize(void) for(i = 0; i = 2; i++) if(fds[i] 2) close(fds[i]); - +#endif pid = fork(); if(pid == -1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #7 from edwintorok at gmail dot com 2010-01-12 12:41 --- (In reply to comment #6) Can I get this thing to run without actually installing it into the system? 5. clamd/clamd -c etc/clamd.conf LibClamAV Error: cl_load(): Can't get status of /usr/local/share/clamav ERROR: Can't get file status Yes, you can specify the path. A minimal example (you can use any path instead of /tmp): $ mkdir /tmp/testdb $ touch /tmp/testdb/foo.pdb $ cat etc/clamd.conf EOF DatabaseDirectory /tmp/testdb LocalSocket /tmp/clamd.socket EOF $ clamd/clamd -c etc/clamd/conf Same for clamdscan (-c etc/clamd.conf) Please enter the GCC version into the Reported against field. Done. What happens for OMP_NUM_THREADS=1? Will test now. I will look thoroughly into the find implementation in the meantime. Ok. -- edwintorok at gmail dot com changed: What|Removed |Added Version|unknown |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #8 from edwintorok at gmail dot com 2010-01-12 12:51 --- (In reply to comment #7) What happens for OMP_NUM_THREADS=1? Will test now. It doesn't hang with OMP_NUM_THREADS=1. It does hang with OMP_NUM_THREADS=2, or with OMP_NUM_THREADS unset. Please enter the GCC version into the Reported against field. I reproduced the issue with gcc version 4.3.2 (Debian 4.3.2-1.1) too. BTW you can also find my build on gcc14 in the compiler farm at /home/edwin/clam/git_test/clamav-devel (should be world readable). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #9 from edwintorok at gmail dot com 2010-01-12 13:35 --- Could this bug be related to this one: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36242#c4 Clamd creates threads using pthread_create, std::find is called from those threads. There are also threads that only poll/dispatch, and never use the STL (hence never uses openmp). However the gcc manual doesn't mention incompatibility between pthread_create and openmp (or libstdc++ parallel mode). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #13 from edwintorok at gmail dot com 2010-01-12 17:54 --- (In reply to comment #12) Thread 1 waits for its colleagues, but where are they gone? Is it possible that an exception is thrown inside find (by means of the value type or the predicate)? I don't fully trust gdb in this case, but it shows that an iterator range of (NULL, NULL) had to be searched. This code is compiled with -fno-exceptions, could that be a problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #4 from edwintorok at gmail dot com 2010-01-12 07:28 --- (In reply to comment #3) Johannes is looking into it, Thanks. certainly reproducing the problem will not be a trivial taks, I'm afraid... If the steps I listed in the bugreport don't work for you just let me know for which step you need more info. You can also ping me on #gcc (oftc.net), or #clamav (freenode.net). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] New: libstdc++ parallel mode deadlocks in barrier
=value optimized out, engine=value optimized out, dboptions=value optimized out, opts=value optimized out) at server-th.c:1265 #24 0x00407b4b in main (argc=value optimized out, argv=value optimized out) at clamd.c:486 (gdb) 9. See that in the thread backtrace one thread is waiting in poll(), other one in gomp_team_barrier_end, and those are only 2 threads. 10. Deadlock System info: $ g++ -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.2-8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.2 (Debian 4.4.2-8) Sorry that I didn't reduce a testcase, a trivial testcase with std::find and pthread doesn't hang. There is also a problem with parallel mode when building LLVM, LLVM's tblgen makes very slow progress when multiple tblgen processes are executing in parallel on a multicore machine (see http://llvm.org/bugs/show_bug.cgi?id=5804) -- Summary: libstdc++ parallel mode deadlocks in barrier Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug libstdc++/42624] libstdc++ parallel mode deadlocks in barrier
--- Comment #1 from edwintorok at gmail dot com 2010-01-05 18:09 --- (In reply to comment #0) $ make -j4 This should have been: make CCLD=g++ -j4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624
[Bug lto/41782] New: lto/gold: -flto -user-linker-plugin dies with internal error in gold
When trying to compile and link the attached not.i with lto the linker dies with this error: /usr/bin/ld: internal error in set_linkonce_size, at ../../gold/layout.h:250 This only occurs if I use -use-linker-plugin, so I think this may be a bug in gcc's gold plugin, so I'm filing this as a gcc bug (but it may also be a bug in gold triggered by lto). To reproduce: $ /home/edwin/inst/bin/g++ -flto -c not.i -o not.o $ /home/edwin/inst/bin/g++ -shared -flto -use-linker-pluginnot.o /usr/bin/ld: internal error in set_linkonce_size, at ../../gold/layout.h:250 collect2: ld returned 1 exit status $ /home/edwin/inst/bin/g++ -v Using built-in specs. COLLECT_GCC=/home/edwin/inst/bin/g++ COLLECT_LTO_WRAPPER=/home/edwin/inst/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-lto --enable-languages=c,c++ --enable-gold : (reconfigured) ../gcc/configure --enable-lto --enable-languages=c,c++ --enable-gold Thread model: posix gcc version 4.5.0 20091020 (experimental) (GCC) $ ld -v GNU gold (GNU Binutils for Debian 2.20) 1.9 -- Summary: lto/gold: -flto -user-linker-plugin dies with internal error in gold Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41782
[Bug lto/41782] lto/gold: -flto -user-linker-plugin dies with internal error in gold
--- Comment #1 from edwintorok at gmail dot com 2009-10-21 11:22 --- Created an attachment (id=18855) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18855action=view) testcase (reduced not.i) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41782
[Bug lto/41761] New: lto1: error: type mismatch in component reference (const with non-const)
$ ~/inst/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/edwin/inst/bin/gcc COLLECT_LTO_WRAPPER=/home/edwin/inst/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-lto --enable-languages=c,c++ --enable-gold Thread model: posix gcc version 4.5.0 20091019 (experimental) (GCC) gcc -flto fails to compile ClamAV when built with --disable-shared, I reduced the problem to these two files: $ /home/edwin/inst/bin/gcc -flto 7z.i -o 7z.o -c $ /home/edwin/inst/bin/gcc -flto 7zIn.i -o 7zIn.o -c $ /home/edwin/inst/bin/gcc 7z.o 7zIn.o -flto -shared -use-linker-plugin In function SzArEx_GetFolderFullPackSize: lto1: error: type mismatch in component reference const struct CSzAr struct CSzAr D.1996_3 = p_2(D)-db.Folders; lto1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /home/edwin/inst/bin/gcc returned 1 exit status /usr/bin/ld: fatal error: lto-wrapper failed collect2: ld returned 1 exit status -- Summary: lto1: error: type mismatch in component reference (const with non-const) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug lto/41761] lto1: error: type mismatch in component reference (const with non-const)
--- Comment #1 from edwintorok at gmail dot com 2009-10-20 07:05 --- Created an attachment (id=18830) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18830action=view) reduced testcase reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug lto/41761] lto1: error: type mismatch in component reference (const with non-const)
--- Comment #7 from edwintorok at gmail dot com 2009-10-20 15:06 --- (In reply to comment #6) Fixed. Thanks, I can now successfully build ClamAV with lto. -- edwintorok at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug lto/41756] New: LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
$ /home/edwin/inst/bin/g++ -v Using built-in specs. COLLECT_GCC=/home/edwin/inst/bin/g++ COLLECT_LTO_WRAPPER=/home/edwin/inst/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-lto --enable-languages=c,c++ --enable-gold Thread model: posix gcc version 4.5.0 20091019 (experimental) (GCC) sh -x script + /home/edwin/inst/bin/g++ -fPIC SourceMgr.i -flto -fno-exceptions -O1 -c -o SourceMgr.o + /home/edwin/inst/bin/g++ -fPIC AsmMatcherEmitter.i -flto -O1 -c -o AsmMatcher.o + /home/edwin/inst/bin/g++ -flto -use-linked-plugin -O1 AsmMatcher.o SourceMgr.o -shared In function EmitIsSubclass: lto1: error: BB 14 can not throw but has an EH edge lto1: error: BB 15 can not throw but has an EH edge lto1: error: BB 16 can not throw but has an EH edge lto1: error: BB 18 can not throw but has an EH edge lto1: error: BB 19 can not throw but has an EH edge lto1: error: BB 20 can not throw but has an EH edge lto1: error: BB 22 can not throw but has an EH edge lto1: error: BB 23 can not throw but has an EH edge lto1: error: BB 25 can not throw but has an EH edge lto1: error: BB 26 can not throw but has an EH edge lto1: error: BB 27 can not throw but has an EH edge lto1: error: BB 30 can not throw but has an EH edge lto1: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /home/edwin/inst/bin/g++ returned 1 exit status collect2: lto-wrapper returned 1 exit status -- Summary: LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug lto/41756] LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
--- Comment #1 from edwintorok at gmail dot com 2009-10-19 16:55 --- Created an attachment (id=18827) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18827action=view) SourceMgr.i preprocessed SourceMgr.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug lto/41756] LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
--- Comment #2 from edwintorok at gmail dot com 2009-10-19 16:56 --- Created an attachment (id=18828) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18828action=view) AsmMatcherEmitter.i.bz2 bzipped preprocessed AsmMatcherEmitter.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug lto/41756] LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
--- Comment #3 from edwintorok at gmail dot com 2009-10-19 16:58 --- ld -v GNU gold (GNU Binutils for Debian 2.20) 1.9 This happens only if I use all of -flto -O1 -use-linker-plugin, not using -O1, or not using -use-linker-plugin hides the bug (and not using -flto too of course). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug lto/41756] LTO: -flto -O1 -use-linker-plugin, linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
--- Comment #4 from edwintorok at gmail dot com 2009-10-19 16:59 --- (In reply to comment #3) ld -v GNU gold (GNU Binutils for Debian 2.20) 1.9 This happens only if I use all of -flto -O1 -use-linker-plugin, not using -O1, or not using -use-linker-plugin hides the bug (and not using -flto too of course). Actually -use-linker-plugin makes no difference -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug middle-end/39891] New: Bogus location given for warning, no warning at real location: dereferencing pointer �anonymous� does break strict-aliasing rules
Compile attached testcase using:
$ g++-4.4 -c -O1 -fstrict-aliasing -Wstrict-aliasing foo.i
foo.i: In function bool foo():
foo.i:8: warning: dereferencing pointer anonymous does break
strict-aliasing rules
foo.i:26: note: initialized from here
Line 8 has this:
7: APSInt operator=(const APSInt RHS) {
8:APInt::operator=(RHS);
Line 26 has this:
26: AdditionalOffset = Val.getInt();
None of these violate the strict aliasing rules.
The only place that could violate the strict aliasing rules in the testcase is
at line 17:
14: void *Data[sizeof(APSInt)];
15: public:
16: APSInt getInt() {
17:return *(APSInt*)(void*)Data;
g++ 4.3.3 doesn't give any warning, neither does g++ 4.2.4.
I think this is a bug because:
- the warning is not given at the place that (possibly) violates the strict
aliasing rules, but at the place where the pointer obtained by violating the
rules is dereferenced.
- removing line 26 silences the warning, and no warning given for getInt or
operator= anymore
Also does the construct at line 17 really violate the aliasing rules?
$ g++-4.4 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.0-1~exp1'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-objc-gc
--with-arch-32=i486 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.0 (Debian 4.4.0-1~exp1)
--
Summary: Bogus location given for warning, no warning at real
location: dereferencing pointer anonymous does break
strict-aliasing rules
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39891
[Bug middle-end/39891] Bogus location given for warning, no warning at real location: dereferencing pointer �anonymous� does break strict-aliasing rules
--- Comment #1 from edwintorok at gmail dot com 2009-04-25 09:39 --- Created an attachment (id=17690) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17690action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39891
[Bug middle-end/39895] New: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
Considering this code:
void dummy(void *x);
union union_t {
unsigned un;
char c;
} __attribute__((packed));
unsigned foo()
{
char x[4];
dummy(x);
return ((union union_t*)x)-un;
}
unsigned bar(char *x)
{
return ((union union_t*)x)-un;
}
With gcc-4.4 -Wstrict-aliasing=1 is the only one that does *not* give a
warning, levels 2 and 3 do give warnings:
$ gcc-4.4 -Wstrict-aliasing p.c -O2 -c
p.c: In function foo:
p.c:11: warning: dereferencing type-punned pointer will break strict-aliasing
rules
$ gcc-4.4 -Wstrict-aliasing=2 p.c -O2 -c
p.c: In function foo:
p.c:11: warning: dereferencing type-punned pointer will break strict-aliasing
rules
$ gcc-4.4 -Wstrict-aliasing=1 p.c -O2 -c
However in the case of gcc-4.3, -Wstrict-aliasing=2 is the only one that gives
warnings, levels 1 and 3 give no warning:
$ gcc-4.3 -Wstrict-aliasing p.c -O2 -c
$ gcc-4.3 -Wstrict-aliasing=2 p.c -O2 -c
p.c: In function foo:
p.c:11: warning: dereferencing type-punned pointer might break strict-aliasing
rules
$ gcc-4.3 -Wstrict-aliasing=1 p.c -O2 -c
According to the gcc manpage -Wstrict-aliasing=3 should have the fewest false
positives and false negatives, yet with gcc-4.4 -Wstrict-aliasing=3 gives a
warning that is not given at -Wstrict-aliasing=1 (the one that is supposed to
have many false positives).
This only happens if 'x' is allocated on the stack, gcc-4.4 is perfectly happy
if it is a char* argument to the function.
I've also tried the 'Casting through a union (1)' described at
http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html
but that too gives warnings by default.
Conclusion is that with gcc-4.4 -O2 -Wall there is no way to read/store from a
stack allocated variable through a union, using a different type member of the
union without raising a warning.
Is there another recommended way in gcc-4.4 to cast from uint8_t* to uint32_t*?
--
Summary: gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3
behaves like -Wstrict-aliasing=2 in gcc-4.3
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895
[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
--- Comment #2 from edwintorok at gmail dot com 2009-04-25 13:49 ---
(In reply to comment #1)
Casting through a union (2)
describes an invalid way of doing type-punning.
There is also a citation from C99 on that page:
An object shall have its stored value accessed only by an lvalue expression
that has one of the following types:
* a type compatible with the effective type of the object,
* a qualified version of a type compatible with the effective type of the
object,
* a type that is the signed or unsigned type corresponding to the effective
type of the object,
* a type that is the signed or unsigned type corresponding to a qualified
version of the effective type of the object,
* an aggregate or union type that includes one of the aforementioned types
among its members (including, recursively, a member of a subaggregate or
contained union), or
* a character type.
I'm casting to a union that has both types as members, why doesn't that fit
under the 5th case in the above quote?
Also there is a warning for foo(), but there is no warning for bar(), but I
think they are exactly the same things wrt to violating or not the aliasing
rules.
The only conforming and portable way is
unsigned bar(char *x)
{
unsigned un;
memcpy (un, x, sizeof (un));
return un;
}
That may be too slow for me, I'll go with a static inline function that takes a
void* instead of a macro that does the cast.
I have no opinion on the different levels of warnings (I think this case
should be unconditionally).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895
[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
--- Comment #4 from edwintorok at gmail dot com 2009-04-25 14:12 --- (In reply to comment #3) The above is properly optimized. Why do you think that an inline function taking void * would fix anything? I can't know if memcpy will be inlined, it may just be a function call on certain systems, with certain compilers. The inline function should be a more portable way of expressing what I need, and it shouldn't cause any bugs with -fstrict-aliasing, since gcc already knows I gave my pointer to a function taking void*, so anything could happen with it, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895
[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
--- Comment #7 from edwintorok at gmail dot com 2009-04-25 14:18 --- (In reply to comment #5) An object shall have its stored value accessed only by an lvalue expression that has one of the following types: * a type compatible with the effective type of the object, * a qualified version of a type compatible with the effective type of the object, * a type that is the signed or unsigned type corresponding to the effective type of the object, * a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object, * an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or * a character type. I'm casting to a union that has both types as members, why doesn't that fit under the 5th case in the above quote? Because it is certainly backwards. Or rather, this refers to a compatible type to the type that was used to store the value, so it doesn't apply to type-punning. Yes, the union has a compatibly type to the one used to store the value (it has a char member), hence the union can be used to access the value. I use a different member to access the value, but isn't that what unions are for? :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895
[Bug middle-end/39895] gcc-4.4 -Wstrict-aliasing and -Wstrict-aliasing=3 behaves like -Wstrict-aliasing=2 in gcc-4.3
--- Comment #9 from edwintorok at gmail dot com 2009-04-25 14:22 ---
(In reply to comment #6)
No, not if it is inlined (and if not you can as well use memcpy).
You can also do (GCC extension)
union union_t {
unsigned un;
char c[4];
};
unsigned bar(char *x)
{
union union_t u;
u.c[0] = x[0];
u.c[1] = x[1];
u.c[2] = x[2];
u.c[3] = x[3];
return u.un;
}
but that will even generate worse code with GCC than the
memcpy (it's even horrible code).
Hmm, looks like the only way out is for me to put #if defined(__GNUC__)
(__GNUC__ 4) || (__GNUC__ == 4 __GNUC_MINOR__ = 4) and use memcpy.
Either that or add a configure rule to add -fno-strict-aliasing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39895
[Bug tree-optimization/39736] signed overflow in loop induction variable: missing warning and wrong code
--- Comment #5 from edwintorok at gmail dot com 2009-04-13 06:56 --- (In reply to comment #4) (In reply to comment #3) But converting from short to int for the argument to printf should behave as if a short value was converted to int, i.e. the int value should be in range -32768 to 32767, right? Usually but not here. Since you compiled with -fstrict-overflow (implicitly via -O2) the compiler can assume your short variables will have proper short values. As an optimisation the compiler could decide to store short variables in wider int variables and to perform short arithmetic using int arithmetic. Since you promised not to cause signed overflow those int variables would always be the proper sign-extension of the corresponding short variables. But your test program does cause signed overflow, so this optimisation changes behaviour. It's still not the compiler's fault. If you deliberately cause signed overflow, do not compile with -fstrict-overflow. Understood. Then this is not wrong code, just a missing warning. (In reply to comment #0) There are 2 bugs here: - no warning is given with -Wstrict-overflow=5, although -fstrict-overflow changes the behaviour of the code This is still a bug: It warns about cases where the compiler optimizes based on the assumption that signed overflow does not occur. - from is of type short, so when sign extended to an int, it should only take values allowed for a short: -32768 to 32767, not all values allowed for an int (like 2253491) This is not a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736
[Bug tree-optimization/39736] signed overflow in loop induction variable: missing warning and wrong code
--- Comment #3 from edwintorok at gmail dot com 2009-04-12 09:32 --- (In reply to comment #2) (In reply to comment #1) There is no undefined behavior here (increment of a short value converts to int, increments then converts back to short, none of which are undefined), so at least the wrong code issue would be the same as bug 35634. It's not undefined, but the conversion from int back to short provokes implementation-defined behaviour when the int value doesn't fit in a short. That makes this test program not strictly conforming. But converting from short to int for the argument to printf should behave as if a short value was converted to int, i.e. the int value should be in range -32768 to 32767, right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736
[Bug tree-optimization/39736] New: signed overflow in loop induction variable: missing warning and wrong code
[This bug was discovered by kantorzs...@yahoo.com]
When compiling the testcase below at -O2, using gcc 4.3.3 instead of an infite
loop, where the variable 'from' takes values from -32768 to 32767,
it goes up way beyond that limit:
$ gcc -O2 tes -Wall -W -Wstrict-overflow=5 ./a.out
0
1
...
2253491
When using -fwrapv, or -fno-strict-overflow 'from' iterates between -32768 and
32767 in an infinite loop, as expected.
There are 2 bugs here:
- no warning is given with -Wstrict-overflow=5, although -fstrict-overflow
changes the behaviour of the code
- from is of type short, so when sign extended to an int, it should only take
values allowed for a short: -32768 to 32767, not all values allowed for an int
(like 2253491)
I think this is a bug, because although signed overflow is undefined behaviour,
that should affect only the value of 'from', which is still of type 'short',
and converting to int should obey the limits for the 'short' type, i.e. use a
sign-extension.
Here is a diff of the assembly, when using -O2, vs -O2 -fno-strict-overflow:
--- x2.s2009-04-11 15:28:01.0 +0300
+++ x2-no-overflow.s2009-04-11 15:27:58.0 +0300
@@ -10,15 +10,16 @@
.LFB13:
pushq %rbx
.LCFI0:
+ xorl%esi, %esi
xorl%ebx, %ebx
.p2align 4,,10
.p2align 3
.L2:
- movl%ebx, %esi
movl$.LC0, %edi
xorl%eax, %eax
- callprintf
addl$1, %ebx
+ callprintf
+ movswl %bx,%esi
jmp .L2
.LFE13:
.size main, .-main
Testcase:
#include stdio.h
int
main ()
{
int until = 40001;
short from = 0;
for (; from until; from++)
printf (%d\n, from);
return 0;
}
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-5'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.3 (Debian 4.3.3-5)
Also reproduced with trunk:
$ ~/gcc_inst/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-static
--prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090408 (experimental) [trunk revision 145769] (GCC)
--
Summary: signed overflow in loop induction variable: missing
warning and wrong code
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736
[Bug rtl-optimization/38854] New: missed optimization with -m32: empty functions shouldn't contain push/mov/pop
Testcase:
void noop(char* foo) {}
For 64-bit it does the right thing:
$ gcc -O2 foo.c -S
Output is:
noop:
.LFB2:
rep
ret
However for 32-bit it has useless extra instructions:
$ gcc -m32 -O2 foo.c -S
noop:
pushl %ebp
movl%esp, %ebp
popl%ebp
ret
The push/mov/pop should be removed.
I tested this with gcc-4.2, 4.3, and 4.4(trunk revision 143382), all produce
same code.
--
Summary: missed optimization with -m32: empty functions shouldn't
contain push/mov/pop
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38854
[Bug rtl-optimization/38854] missed optimization with -m32: empty functions shouldn't contain push/mov/pop
--- Comment #2 from edwintorok at gmail dot com 2009-01-15 09:50 --- (In reply to comment #1) This is the frame-pointer setup code. You can get the same code as x86_64 with -momit-leaf-frame-pointer. Ok. But can't the optimizers see that you push ebp, write something to it, and then pop to it again, and remove that code automatically? At least the movl is a dead store ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38854
[Bug rtl-optimization/38854] missed optimization with -m32: empty functions shouldn't contain push/mov/pop
--- Comment #3 from edwintorok at gmail dot com 2009-01-15 09:51 --- (In reply to comment #2) (In reply to comment #1) This is the frame-pointer setup code. You can get the same code as x86_64 with -momit-leaf-frame-pointer. Ok. But can't the optimizers see that you push ebp, write something to it, and then pop to it again, and remove that code automatically? At least the movl is a dead store ... Or is the prologue/epilogue code special, and not run through such optimizations? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38854
[Bug tree-optimization/38224] libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold
--- Comment #3 from edwintorok at gmail dot com 2008-12-06 08:37 --- This got fixed somewhere between r142405 and r142487, because r142487 has bootstrapped successfully. -- edwintorok at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38224
[Bug c/38408] New: compilation error during bootstrap in fold-const.c using TOT!
Using SVN r142442, my nightly gcc-4.4.0 boostrapper failed: Configured with ../gcc/configure --disable-multilib --disable-static --prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ --enable-checking=assert,df,fold,gc,misc,rtl,rtlflag,runtime,tree /home/edwin/gcc-obj/./prev-gcc/xgcc -B/home/edwin/gcc-obj/./prev-gcc/ -B/home/edwin/gcc_inst//x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber -DCLOOG_PPL_BACKEND ../../gcc/gcc/fold-const.c -o fold-const.o ../../gcc/gcc/fold-const.c:13363: error: dereferencing pointer '__t' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13363: note: initialized from here ../../gcc/gcc/fold-const.c:13377: error: dereferencing pointer 'tmp' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13378: error: dereferencing pointer 'tmp' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13379: error: dereferencing pointer 'tmp' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13380: error: dereferencing pointer 'tmp' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13383: error: dereferencing pointer 'tmp' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13384: error: dereferencing pointer 'tmp' does break strict-aliasing rules ../../gcc/gcc/fold-const.c:13376: note: initialized from here make[3]: *** [fold-const.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 -- Summary: compilation error during bootstrap in fold-const.c using TOT! Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38408
[Bug c/38296] New: documentation: improve documentation of __builtin_constant_p()
Because __builtin_constant_p() is sometimes (ab)used as a static analyzer, the documentation should give more details what is expected to work, and what you should not use it for. (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359) Here is my suggestion, please incorporate it into the gcc 4.4.0 documentation if you consider it appropriate: - __builtin_constant_p() can return 1 even if during the execution of the program it never is a constant for example: the optimizer splits the case when a value is zero and non-zero, and fully expands the zero case, considering the variable is zero. This doesn't mean that during a real execution the value can ever be zero. This can happen for example if the optimizer cannot see that a certain value is impossible. - __builtin_constant_p() is not a static analyzer, as it doesn't offer soundness or completeness guarantees for the analysis it makes - when you write optimized code for the __builtin_constant_p() == 1 case, you should not treat invalid constant values as build time errors, instead you should fall back to using the generic code at runtime (which should handle the invalid cases anyway). The reason is because gcc may constant-propagate/expand a value that may not be reached ever, because of the reasons described above. for example, instead of doing this: __builtin_constant_p(val) ? (VALID(val) ? OPTIMIZED(val) : __build_error()) : generic_case(val) Do this: (__builtin_constant_p(val) VALID(val)) ? OPTIMIZED(val) : generic_case(val); What happens if you don't take the above advice: anytime gcc's optimizer is changed, your code may break -- Summary: documentation: improve documentation of __builtin_constant_p() Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38296
[Bug middle-end/36359] missed optimization in some cases with PRE VRP and other passes combined together
--- Comment #17 from edwintorok at gmail dot com 2008-11-24 18:33 --- Created an attachment (id=16761) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16761action=view) drivers/scsi/sd.c Similar problem with drivers/scsi/sd.c I can compile the attached preprocessed on x86_64 linux: $ gcc-4.3 -c x.i -o x.o -O2 nm -u x.o|grep ilog2 $ ~/gcc_inst/bin/gcc -c x.i -o x.o -O2 nm -u x.o|grep ilog2 U ilog2_NaN IMHO the kernel is abusing gcc as a static analyzer, which gcc is not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug tree-optimization/38224] New: libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold
With SVN r142097, configured with checking enabled: $ ../gcc/configure --disable-multilib --disable-static --prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ --enable-checking=assert,df,fold,gc,misc,rtl,rtlflag,runtime,tree $ source='../../gcc/libdecnumber/bid/host-ieee32.c' object='host-ieee32.o' libtool=no /home/edwin/gcc-obj/./prev-gcc/xgcc -B/home/edwin/gcc-obj/./prev-gcc/ -B/home/edwin/gcc_inst//x86_64-unknown-linux-gnu/bin/ -I../../gcc/libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long -Werror -I../../gcc/libdecnumber -I. -c ../../gcc/libdecnumber/bid/host-ieee32.c ../../gcc/libdecnumber/bid/host-ieee32.c: In function __host_to_ieee_32: ../../gcc/libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38224
[Bug tree-optimization/38224] libdecnumber/bid/host-ieee32.c:50: internal compiler error: fold check: original tree changed by fold
--- Comment #1 from edwintorok at gmail dot com 2008-11-22 08:21 ---
Testcase:
$ /home/edwin/gcc-obj/./prev-gcc/xgcc -B/home/edwin/gcc-obj/./prev-gcc/
-B/home/edwin/gcc_inst//x86_64-unknown-linux-gnu/bin/ -Wfatal-errors -c -O1
testcase-min.i
/* testcase */
typedef unsigned int UINT32;
typedef struct {} decimal32;
void __host_to_ieee_32 (UINT32 in, decimal32 * out)
{
memcpy ((char *) out, (char *) in, 4);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38224
[Bug c/38157] New: -fconserve-stack enabled by default
At both O0 and O3 conserve-stack is enabled. The compiler will attempt to use less stack space, even if that makes the program slower. Doesn't that contradict with -O2 and -O3? gcc_inst/bin/gcc -O0 -Q foo.c --help=optimizers |grep conserve-stack -fconserve-stack [enabled] gcc_inst/bin/gcc -O3 -Q foo.c --help=optimizers |grep conserve-stack -fconserve-stack [enabled] gcc_inst/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --disable-multilib --disable-static --prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ --enable-checking=assert,df,fold,gc,misc,rtl,rtlflag,runtime,tree Thread model: posix gcc version 4.4.0 20081116 (experimental) [trunk revision 141912] (GCC) -- Summary: -fconserve-stack enabled by default Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38157
[Bug c++/38132] New: std::string is faster with -D_GLIBCXX_DEBUG=1 than without
basic_string.tcc contains 'extern template basic_stringchar', which prevents the template from being instantiated, and thus all calls to basic_string methods remain calls even at -O3. If I -D_GLIBCXX_DEBUG=1 _GLIBCXX_EXTERN_TEMPLATE is 0, thus it will no longer contain 'extern template basic_stringchar', so the body of methods will be available, and inlining will be performed. However _GLIBCXX_DEBUG=1 activates debug code, so I would like to be able to get the methods inlined w/o definining debug mode. Can the semantics of 'extern template' be changed [*] in such a way, that *if* the body of some of the methods are suitable for inlining, they will be inlined (and other methods won't get instantiated), and if none of the methods are suitable, the behaviour stays as currently. [*] by introducing a new compiler flag, that can be activated at -O3 (and maybe -O2) at the expense of code size. -- Summary: std::string is faster with -D_GLIBCXX_DEBUG=1 than without Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38132
[Bug c++/38132] std::string is faster with -D_GLIBCXX_DEBUG=1 than without
--- Comment #1 from edwintorok at gmail dot com 2008-11-15 13:56 --- Created an attachment (id=16682) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16682action=view) example to illustrate compile with g++ -O3, I get: real0m0.130s user0m0.100s sys 0m0.028s compile with g++ -D_GLIBCXX_DEBUG=1 -O3 I get: real0m0.080s user0m0.056s sys 0m0.028s If I explicitly instantiate the template, I get similar effect as of defining _GLIBCXX_DEBUG: template class basic_stringchar; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38132
[Bug rtl-optimization/38139] New: --enable-checking=all times out during bootstrap
I tried to build a gcc 4.4.0 with --enable-checking=all but it timed out: $ /home/edwin/gcc-obj/./prev-gcc/xgcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --disable-multilib --disable-static --prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ --enable-checking=all Thread model: posix gcc version 4.4.0 20081115 (experimental) [trunk revision 141891] (GCC) xgcc: Internal error: Killed (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [insn-emit.o] Error 1 make[3]: *** Waiting for unfinished jobs xgcc: Internal error: Killed (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [insn-recog.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 ^it was building insn-emit and insn-recog in parallel, both timed out. I was running it under ulimit with a one hour timeout: ulimit -t 3600 -v 1048576 make -j4 makelog 2makelog2 CPU is Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz, 4GB RAM. I know that --enable-checking=all is very slow, but it should take less than an hour to compile insn-emit.o, shouldn't it? -- Summary: --enable-checking=all times out during bootstrap Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38139
[Bug rtl-optimization/38139] --enable-checking=all times out during bootstrap
-- edwintorok at gmail dot com changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38139
[Bug rtl-optimization/38139] --enable-checking=all times out during bootstrap
--- Comment #2 from edwintorok at gmail dot com 2008-11-15 21:59 --- (In reply to comment #1) Subject: Re: New: --enable-checking=all times out during bootstrap Sent from my iPhone On Nov 15, 2008, at 1:27 PM, edwintorok at gmail dot com [EMAIL PROTECTED] wrote: I tried to build a gcc 4.4.0 with --enable-checking=all but it timed out: Since --enable-checking=all enables gc all the time then yes It will take a long time. Maybe even days. Marking is expensive. Thanks, this is the 'gcac' flag, right? What if I build with assert,df,fold,rtl,misc,tree,gc,rtlflag,runtime, would that build within a reasonable amount of time? And is it worth to build with more checking, than those enabled by default? [i.e. did that expose bugs in the past?] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38139
[Bug c++/38123] New: [4.3 regression] error: incorrect sharing of tree nodes ap-fp_offset = D.2748;
Compiling the attached file with latest g++ from trunk: $ ~/gcc_inst/bin/g++ /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c: In function int main(): /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:84: warning: deprecated conversion from string constant to char* /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:85: warning: deprecated conversion from string constant to char* /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:88: warning: deprecated conversion from string constant to char* /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:89: warning: deprecated conversion from string constant to char* /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:92: warning: deprecated conversion from string constant to char* /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:93: warning: deprecated conversion from string constant to char* /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c: In function void test(char*, __va_list_tag*): /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:96: error: incorrect sharing of tree nodes ap-fp_offset = D.2748; *ap /home/edwin/llvm-svn/llvm-commit/projects/llvm-test/SingleSource/UnitTests/2003-08-11-VaListArg.c:96: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This is: Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --disable-multilib --disable-static --prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ Thread model: posix gcc version 4.4.0 20081114 (experimental) [trunk revision 141857] (GCC) -- Summary: [4.3 regression] error: incorrect sharing of tree nodes ap-fp_offset = D.2748; Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38123
[Bug c++/38123] [4.3 regression] error: incorrect sharing of tree nodes ap-fp_offset = D.2748;
--- Comment #1 from edwintorok at gmail dot com 2008-11-14 20:15 --- Created an attachment (id=16677) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16677action=view) original sourcecode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38123
[Bug c++/38123] [4.3 regression] error: incorrect sharing of tree nodes ap-fp_offset = D.2748;
--- Comment #2 from edwintorok at gmail dot com 2008-11-14 20:18 --- Created an attachment (id=16678) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16678action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38123
[Bug c/38046] New: 'warning: comparison between signed and unsigned' shouldn't be given for equality comparisons
Consider this code:
int foo(int a, unsigned b)
{
return a != b;
}
int bar(int a, unsigned b)
{
return (unsigned)a != b;
}
int foobar(int a, unsigned b)
{
return a != (int)b;
}
$ gcc -O2 -Wall -W foo.c -c
foo.c: In function foo:
foo.c:3: warning: comparison between signed and unsigned integer expressions
The generated code is identical for all 3 functions, so there is no reason
to fix the warning in the code. Rather I think gcc shouldn't warn in this
case at all.
A more realistic example:
#include unistd.h
int foo(int fd, char *buf, size_t n)
{
return (read(fd, buf, n) != n);
}
FWIW, if I change int to 'short int' or 'signed char' (and unsigned
appropriately) I get no warning.
--
Summary: 'warning: comparison between signed and unsigned'
shouldn't be given for equality comparisons
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38046
[Bug c/38046] 'warning: comparison between signed and unsigned' shouldn't be given for equality comparisons
--- Comment #3 from edwintorok at gmail dot com 2008-11-07 17:14 ---
(In reply to comment #2)
Subject: Re: New: 'warning: comparison between signed and
unsigned' shouldn't be given for equality comparisons
On Fri, 7 Nov 2008, edwintorok at gmail dot com wrote:
Consider this code:
int foo(int a, unsigned b)
{
return a != b;
}
$ gcc -O2 -Wall -W foo.c -c
foo.c: In function foo:
foo.c:3: warning: comparison between signed and unsigned integer expressions
Seems correct to me. You could have a == -1 and b == UINT_MAX and they
would compare equal, but it's not at all obvious from the code that this
is the user's intent; and if it is their intent, they can use an explicit
cast.
It would be nice to have a separate warning option for ==, != comparisons, and
another for ,,=,= comparisons.
The problem is that with code that uses read(2) and write(2) you get lots of
warnings, and adding casts is time-consuming and of little benefit.
I'd like to turn -Wsign-compare into -Werror for 'make distcheck' in my
project, but can't do that due to the != comparisons. If I would have a
distinct -W flag for it, I could -Wno-error that.
FWIW, if I change int to 'short int' or 'signed char' (and unsigned
appropriately) I get no warning.
Both short and unsigned short will be promoted to int before the
comparison, so you won't get -1 and USHRT_MAX comparing equal.
Ok
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38046
[Bug c/38037] New: false uninitialized warnings when using a pointer as a guard
With the testcode below I get an uninitialized use warning. There should be no warning since foobar is always assigned when (!bar), and foobar is only used when (!bar). bar is an argument to the function and nothing changes it, and it is not aliased. $ gcc -O2 -Wall -c foo.c foo.c: In function foo: foo.c:6: warning: foobar may be used uninitialized in this function This happens on both 4.3.2 and trunk $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1) $ gcc_inst/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --disable-multilib --disable-static --prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ Thread model: posix gcc version 4.4.0 20081103 (experimental) [trunk revision 141547] (GCC) -- Summary: false uninitialized warnings when using a pointer as a guard Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38037
[Bug c/38037] false uninitialized warnings when using a pointer as a guard
--- Comment #1 from edwintorok at gmail dot com 2008-11-06 20:58 ---
/* testcase
gcc -O2 -Wall -c foo.c */
char *get(void);
int use(const char *);
void foo(const char *bar)
{
char *foobar;
if(!bar)
foobar = get();
if(use(bar))
return;
if(!bar)
free(foobar);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38037
[Bug c/38037] false uninitialized warnings when using a pointer as a guard
--- Comment #2 from edwintorok at gmail dot com 2008-11-06 20:59 ---
/* testcase
* gcc -Wall -O2 -c foo.c
*/
char *get(void);
int use(const char *);
void foo(const char *bar)
{
char *foobar;
if(!bar)
foobar = get();
if(use(bar))
return;
if(!bar)
use(foobar);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38037
[Bug c/38037] false uninitialized warnings when using a pointer as a guard
--- Comment #3 from edwintorok at gmail dot com 2008-11-06 21:01 ---
Same happens if I use int instead of a pointer:
/* testcase */
/* gcc -O2 -Wall -c foo.c */
int get(void);
int use(int);
void foo(int bar)
{
int foobar;
if(!bar)
foobar = get();
if(use(bar))
return;
if(!bar)
use(foobar);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38037
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #17 from edwintorok at gmail dot com 2008-11-03 17:50 --- Thanks. -- edwintorok at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #13 from edwintorok at gmail dot com 2008-10-29 18:48 --- I just noticed that this testcase also fails with -O3 on gcc version 4.1.2 20070626 (Red Hat 4.1.2-14), but works on gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23) -- edwintorok at gmail dot com changed: What|Removed |Added Known to fail||4.1.2 Known to work||4.1.3 4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug c++/37933] New: reference to ... is amibgous: same error shown twice for same line of code
$ cat test.cpp
namespace x {
extern char *foo;
};
using namespace x;
char *foo;
char bar()
{
return *foo;
}
$ g++ test.cpp -fsyntax-only
test.cpp: In function char bar():
test.cpp:8: error: reference to foo is ambiguous
test.cpp:5: error: candidates are: char* foo
test.cpp:2: error: char* x::foo
test.cpp:8: error: reference to foo is ambiguous
test.cpp:5: error: candidates are: char* foo
test.cpp:2: error: char* x::foo
The same error is shown twice.
I think it would be enough to show the error once.
This is with:
$ g++ -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)
Same happens with g++-4.2, and trunk (r141407), g++-4.1 appears to infloop.
--
Summary: reference to ... is amibgous: same error shown twice for
same line of code
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37933
[Bug c++/37934] New: show a warning when a symbol is unused and completely removed from the output file
Consider the testcase below.
$ cat test.cpp
namespace x {
extern const char ** const foo;
extern const char ** const bar;
};
using namespace x;
namespace {
const char* X;
};
const char ** const foo = X;
const char ** const x::bar = X;
$ g++ test.cpp -Wall -Wunused -Wextra -c -o test.o
$ nm test.o | c++filt
b (anonymous namespace)::X
R x::bar
foo is completely removed from the output, and no warning is shown.
It would be useful to show a warning here.
For example in the above testcase I forgot to add the x:: namespace qualifier
to foo (the extern declaration was in a header and I didn't notice it was part
of a namespace).
Since I didn't get any warning, I got a linker error, and had to spend some
time tracing down this typo in my code.
Had I seen a warning from the compiler that 'foo' is not used
and will get removed I would have immediately noticed the absence of the x::
namespace qualifier.
--
Summary: show a warning when a symbol is unused and completely
removed from the output file
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37934
[Bug tree-optimization/37867] New: inconsistent results on -O2 when reading bits from packed struct
Running gcc-4.3 -O2 on PR1386.c I get different results than with -O1.
$ gcc-4.3 -O2 PR1386.c ./a.out
PR1386.c: In function main:
PR1386.c:15: warning: large integer implicitly truncated to unsigned type
PR1386.c:17: warning: large integer implicitly truncated to unsigned type
bad bits: fff0
$ gcc-4.3 -O2 PR1386.c ./a.out
PR1386.c: In function main:
PR1386.c:15: warning: large integer implicitly truncated to unsigned type
PR1386.c:17: warning: large integer implicitly truncated to unsigned type
bad bits: fff0
gcc-4.2 is fine:
$ gcc-4.2 -O2 PR1386.c ./a.out
PR1386.c: In function main:
PR1386.c:15: warning: large integer implicitly truncated to unsigned type
PR1386.c:17: warning: large integer implicitly truncated to unsigned type
bad bits: 0
$ gcc-4.2 -O3 PR1386.c ./a.out
PR1386.c: In function main:
PR1386.c:15: warning: large integer implicitly truncated to unsigned type
PR1386.c:17: warning: large integer implicitly truncated to unsigned type
bad bits: 0
The file is from an LLVM testcase http://llvm.org/bugs/show_bug.cgi?id=1386
#include stdio.h
#include stdint.h
struct X {
unsigned char pad : 4;
uint64_t a : 64;
uint64_t b : 60;
} __attribute__((packed));
int main (void)
{
struct X x;
uint64_t bad_bits;
x.pad = 255;
x.a = -1ULL;
x.b = -1ULL;
bad_bits = ((uint64_t)-1ULL) ^ *(1+(uint64_t *) x);
printf(bad bits: %llx\n, bad_bits);
return bad_bits != 0;
}
--
Summary: inconsistent results on -O2 when reading bits from
packed struct
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37867
[Bug tree-optimization/37867] inconsistent results on -O2 when reading bits from packed struct
--- Comment #1 from edwintorok at gmail dot com 2008-10-18 13:39 --- (In reply to comment #0) Running gcc-4.3 -O2 on PR1386.c I get different results than with -O1. $ gcc-4.3 -O2 PR1386.c ./a.out PR1386.c: In function main: PR1386.c:15: warning: large integer implicitly truncated to unsigned type PR1386.c:17: warning: large integer implicitly truncated to unsigned type bad bits: fff0 $ gcc-4.3 -O1 PR1386.c ./a.out PR1386.c: In function main: PR1386.c:15: warning: large integer implicitly truncated to unsigned type PR1386.c:17: warning: large integer implicitly truncated to unsigned type bad bits: 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37867
[Bug tree-optimization/37867] inconsistent results on -O2 when reading bits from packed struct
--- Comment #4 from edwintorok at gmail dot com 2008-10-18 18:07 --- (In reply to comment #3) Does it work with -fno-strict-aliasing? It doesn't. [EMAIL PROTECTED]:~$ g++ -O2 -fno-strict-aliasing x.c x.c: In function int main(): x.c:15: warning: large integer implicitly truncated to unsigned type x.c:17: warning: large integer implicitly truncated to unsigned type [EMAIL PROTECTED]:~$ ./a.out bad bits: fff0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37867
[Bug tree-optimization/37868] New: code that doesn't breaks TBAA is misoptimized even with -fno-strict-aliasing
+++ This bug was initially created as a clone of Bug #37867 +++ Cloning bug on Chris's request. Running gcc-4.3 -O2 on PR1386.c I get different results than with -O1. $ gcc-4.3 -O1 PR1386.c ./a.out PR1386.c: In function main: PR1386.c:15: warning: large integer implicitly truncated to unsigned type PR1386.c:17: warning: large integer implicitly truncated to unsigned type bad bits: 0 $ gcc-4.3 -O2 PR1386.c ./a.out PR1386.c: In function main: PR1386.c:15: warning: large integer implicitly truncated to unsigned type PR1386.c:17: warning: large integer implicitly truncated to unsigned type bad bits: fff0 $ g++-4.3 -O2 -fno-strict-aliasing x.c x.c: In function int main(): x.c:15: warning: large integer implicitly truncated to unsigned type x.c:17: warning: large integer implicitly truncated to unsigned type [EMAIL PROTECTED]:~$ ./a.out bad bits: fff0 -- Summary: code that doesn't breaks TBAA is misoptimized even with -fno-strict-aliasing Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37868
[Bug tree-optimization/37617] [4.4 Regression] ICE on valid code
--- Comment #7 from edwintorok at gmail dot com 2008-10-01 16:43 --- Thanks, gcc4.4 doesn't crash anymore now. -- edwintorok at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug tree-optimization/37658] New: gcc-4.3 regression: long compile times on source with lots of labels/gotos
Using gcc-4.3 to compile Gauche-0.8.13/src/vm.c with -O2 takes several minutes, this problem doesn't occur with gcc-4.2. $ time /usr/bin/gcc-4.3 -O2 vm.i -c real2m13.341s user2m13.008s sys 0m0.308s $ time /usr/bin/gcc-4.3 -O2 testcase.i -c real2m2.527s user2m2.004s sys 0m0.336s $ time /usr/bin/gcc-4.2 -O2 vm.i -c real0m2.265s user0m2.216s sys 0m0.040s $ gcc-4.3 -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1) $ gcc-4.2 -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.4 (Debian 4.2.4-3) [not sure about the component, it could be the register allocator, because I encountered a spiller error while reducing the testcase] -- Summary: gcc-4.3 regression: long compile times on source with lots of labels/gotos Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37658
[Bug tree-optimization/37658] gcc-4.3 regression: long compile times on source with lots of labels/gotos
--- Comment #1 from edwintorok at gmail dot com 2008-09-27 16:20 --- Created an attachment (id=16415) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16415action=view) testcase time gcc-4.3 -O2 testcase.i -c real2m13.341s user2m13.008s sys 0m0.308s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37658
[Bug rtl-optimization/37659] New: unable to find a register to spill in class �AREG�
While reducing the testcase for PR37658 I found another bug:
$ gcc-4.3 -fschedule-insns testcase.i
...
testcase.i:193: error: unable to find a register to spill in class AREG
testcase.i:193: error: this is the insn:
(insn 17782 17785 17783 1528 testcase.i:189 (parallel [
(set (reg:SI 1 dx [9986])
(div:SI (reg:SI 3 bx [orig:524 D.8216 ] [524])
(reg:SI 1 dx [orig:522 D.8218 ] [522])))
(set (reg:SI 9987)
(mod:SI (reg:SI 3 bx [orig:524 D.8216 ] [524])
(reg:SI 1 dx [orig:522 D.8218 ] [522])))
(clobber (reg:CC 17 flags))
]) 318 {*divmodsi4_nocltd} (expr_list:REG_DEAD (reg:SI 3 bx [orig:524
D.8216 ] [524])
(expr_list:REG_DEAD (reg:SI 1 dx [orig:522 D.8218 ] [522])
(expr_list:REG_UNUSED (reg:SI 9987)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
testcase.i:193: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccA3kPTQ.out file, please attach this to
your bugreport.
This happens with all gcc versions I have here (with slightly different error
message):
$ gcc-4.3 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)
$ gcc-4.2 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.4 (Debian 4.2.4-3)
$ gcc-4.1 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)
--
Summary: unable to find a register to spill in class AREG
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37659
[Bug rtl-optimization/37659] unable to find a register to spill in class �AREG�
--- Comment #1 from edwintorok at gmail dot com 2008-09-27 16:28 --- Created an attachment (id=16416) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16416action=view) file dumped by gcc This is the file dumped by gcc, I am trying to get a reduced testcase using delta, will attach here when I have it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37659
[Bug rtl-optimization/37659] unable to find a register to spill in class �AREG�
--- Comment #2 from edwintorok at gmail dot com 2008-09-27 16:40 ---
Reduced testcase:
/* gcc -fschedule-insns */
int foo(int a, int b) {
return bar(foobar(b) / foobar(a));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37659
[Bug rtl-optimization/37659] unable to find a register to spill in class �AREG�
--- Comment #3 from edwintorok at gmail dot com 2008-09-27 16:43 ---
the error message for the above testcase:
$ gcc-4.3 -fschedule-insns v.i
v.i: In function foo:
v.i:3: error: unable to find a register to spill in class AREG
v.i:3: error: this is the insn:
(insn 17 20 18 2 v.i:2 (parallel [
(set (reg:SI 1 dx [66])
(div:SI (reg:SI 3 bx [orig:61 D.1552 ] [61])
(reg:SI 1 dx [orig:60 D.1553 ] [60])))
(set (reg:SI 67)
(mod:SI (reg:SI 3 bx [orig:61 D.1552 ] [61])
(reg:SI 1 dx [orig:60 D.1553 ] [60])))
(clobber (reg:CC 17 flags))
]) 318 {*divmodsi4_nocltd} (expr_list:REG_DEAD (reg:SI 3 bx [orig:61
D.1552 ] [61])
(expr_list:REG_DEAD (reg:SI 1 dx [orig:60 D.1553 ] [60])
(expr_list:REG_UNUSED (reg:SI 67)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))
v.i:3: confused by earlier errors, bailing out
Preprocessed source stored into /tmp/ccYIfwlr.out file, please attach this to
your bugreport.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37659
[Bug rtl-optimization/37617] New: gcc 4.4 regression: ICE on valid code
I get an ICE using SVN version 140562: ~/gcc_inst/bin/gcc testcase-min.i -O1 testcase-min.i: In function test_token_dval: testcase-min.i:19: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This does not happen with my previous build of gcc 4.4 SVN r140456: $ x86_64-unknown-linux-gnu-gcc-4.4.0 -O1 test.i -c $ $ ~/gcc_inst/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-languages=c --disable-multilib --disable-bootstrap --disable-static --prefix=/home/edwin/gcc_inst/ Thread model: posix gcc version 4.4.0 20080922 (experimental) (GCC) $ x86_64-unknown-linux-gnu-gcc-4.4.0 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-languages=c --disable-multilib Thread model: posix gcc version 4.4.0 20080918 (experimental) (GCC) -- Summary: gcc 4.4 regression: ICE on valid code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug rtl-optimization/37617] gcc 4.4 regression: ICE on valid code
--- Comment #1 from edwintorok at gmail dot com 2008-09-22 20:18 ---
/* testcase compile this with -O1 */
typedef struct TCase TCase;
typedef void (*TFun) (int);
typedef struct Suite Suite;
void _tcase_add_test (TCase * tc, TFun tf, const char *fname, int signal,
int start, int end);
void _fail_unless (int result, const char *file, int line, const char *expr,
...);
enum val_type
{
vtype_undefined, vtype_cstring, vtype_string, vtype_scope, vtype_dval,
vtype_ival
};
typedef struct token
{
union
{
char *string;
double dval;
}
val;
enum val_type vtype;
}
yystype;
static int
vtype_compatible (enum val_type orig, enum val_type req)
{
}
static void
test_token_dval (int _i __attribute__ ((unused)))
{
{
int val = 0.12345;
yystype tok;
do
{
(tok)-val.dval = (val);
}
while (0);
_fail_unless ((vtype_compatible ((tok)-vtype, vtype_string) ? (tok)-
val.string : ((void *) 0)) == ((void *) 0),
../../../trunk/unit_tests/check_jsnorm.c, 150,
Assertion ' TOKEN_GET(tok, string) == NULL ' failed,
token dval-string, ((void *) 0));
}
}
Suite *
test_jsnorm_suite (void)
{
TCase *tc_jsnorm_gperf, *tc_jsnorm_token, *tc_jsnorm_api,
*tc_jsnorm_tokenizer, *tc_jsnorm_bugs, *tc_screnc_infloop;
_tcase_add_test ((tc_jsnorm_token), (test_token_dval),
test_token_dval , (0), 0, 1);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37617
[Bug tree-optimization/37573] New: gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
Compiling the testcase below with -O2 works, and fails with -O3. gcc-4.3 works with both -O2 and -O3. $ x86_64-unknown-linux-gnu-gcc-4.4.0 -O2 testcase-min.i $ ./a.out OK $ x86_64-unknown-linux-gnu-gcc-4.4.0 -O3 testcase-min.i $ ./a.out Failed: /.G#65533;#65533;#65533;#65533;7#65533;#65533;G#65533;#65533;?#65533;?#65533;; $ ./a.out Failed: #65533;G#65533;#65533;#65533;#65533;7 h#65533;G#65533;#65533;3#65533;?#65533; $ gcc-4.3 -O3 testcase-min.i $ ./a.out OK Actually it is -ftree-vectorize that causes the failure: $ x86_64-unknown-linux-gnu-gcc-4.4.0 -O1 -ftree-vectorize testcase-min.i $ ./a.out Failed:#65533;@#65533;#65533;#65533;@ #65533;?#65533;#65533; The output is random garbage with -O3, but should be 'AUTOIT UNICODE SCRIPT'. $ x86_64-unknown-linux-gnu-gcc-4.4.0 --version x86_64-unknown-linux-gnu-gcc-4.4.0 (GCC) 4.4.0 20080918 (experimental) Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gcc-4.4 is a build from svn: $ svn info Path: . URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 140456 Node Kind: directory Schedule: normal Last Changed Author: amacleod Last Changed Rev: 140456 Last Changed Date: 2008-09-18 17:07:35 +0300 (Thu, 18 Sep 2008) $ gcc-4.3 --version gcc-4.3 (Debian 4.3.2-1) 4.3.2 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Summary: gcc-4.4 regression: incorrect code generation with -O1 - ftree-vectorize Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu-gcc-4.4.0 GCC host triplet: x86_64-unknown-linux-gnu-gcc-4.4.0 GCC target triplet: x86_64-unknown-linux-gnu-gcc-4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug tree-optimization/37573] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #1 from edwintorok at gmail dot com 2008-09-18 17:30 ---
Testcase:
extern int printf (__const char *__restrict __format, ...);
extern int strcmp (__const char *__s1, __const char *__s2);
extern int puts (__const char *__s);
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
struct MT
{
uint32_t *next;
uint32_t items;
uint32_t mt[624];
};
static uint8_t
MT_getnext (struct MT *MT)
{
uint32_t r;
if (!--MT-items)
{
uint32_t *mt = MT-mt;
unsigned int i;
MT-next = mt;
for (i = 0; i 227; i++)
mt[i] =
mt[i] ^ mt[i + 1]) 0x7ffe) ^ mt[i]) 1) ^
((0 - (mt[i + 1] 1)) 0x9908b0df) ^ mt[i + 397];
}
r = *(MT-next++);
r ^= (r 11);
r ^= ((r 0xff3a58ad) 7);
r ^= ((r 0xdf8c) 15);
r ^= (r 18);
return (uint8_t) (r 1);
}
static void
MT_decrypt (uint8_t * buf, unsigned int size, uint32_t seed)
{
struct MT MT;
unsigned int i;
uint32_t *mt = MT.mt;
*mt = seed;
for (i = 1; i 624; i++)
mt[i] = i + 0x6c078965 * ((mt[i - 1] 30) ^ mt[i - 1]);
MT.items = 1;
while (size--)
*buf++ ^= MT_getnext (MT);
};
static uint8_t buf[23] = {
0xc0, 0x49, 0x17, 0x32, 0x62, 0x1e, 0x2e, 0xd5, 0x4c, 0x19, 0x28, 0x49,
0x91, 0xe4, 0x72, 0x83, 0x91, 0x3d, 0x93, 0x83, 0xb3, 0x61, 0x38
};
int
main (void)
{
uint32_t s;
s = 23;
MT_decrypt (buf, s, s + 0xa25e);
if (!strcmp (AUTOIT UNICODE SCRIPT, buf))
{
puts (OK);
return 0;
}
else
{
printf (Failed:%s\n, buf);
return 1;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug tree-optimization/37573] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #2 from edwintorok at gmail dot com 2008-09-18 17:31 --- Created an attachment (id=16357) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16357action=view) config.log for gcc 4.4 Some more system info: $ uname -a Linux debian 2.6.26-1-amd64 #1 SMP Wed Sep 10 15:31:12 UTC 2008 x86_64 GNU/Linux $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping: 7 cpu MHz : 2000.000 cache size : 6144 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm bogomips: 5669.97 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping: 7 cpu MHz : 2000.000 cache size : 6144 KB physical id : 0 siblings: 4 core id : 3 cpu cores : 4 apicid : 3 initial apicid : 3 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm bogomips: 5666.05 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping: 7 cpu MHz : 2000.000 cache size : 6144 KB physical id : 0 siblings: 4 core id : 1 cpu cores : 4 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm bogomips: 5666.03 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz stepping: 7 cpu MHz : 2000.000 cache size : 6144 KB physical id : 0 siblings: 4 core id : 2 cpu cores : 4 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm bogomips: 5666.03 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug c/37186] New: -Wno-error=pointer-sign does not work
Doesn't work, it still considers these warnings as errors:
$ gcc-4.3 x.c -c -Wall -Werror -Wno-error=pointer-sign
cc1: warnings being treated as errors
x.c: In function bar:
x.c:4: error: pointer targets in passing argument 1 of foo differ in
signedness
$ gcc-4.3 x.c -c -Wpointer-sign -Werror -Wno-error=pointer-sign
cc1: warnings being treated as errors
x.c: In function bar:
x.c:4: error: pointer targets in passing argument 1 of foo differ in
signedness
This of course works, but I don't see the warning anymore:
$ gcc-4.3 x.c -c -Wall -Werror -Wno-pointer-sign
$ echo $?
0
$ gcc-4.3 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-9'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.1 (Debian 4.3.1-9)
$ cat x.c
int foo(signed char *);
int bar(unsigned char *p)
{
return foo(p);
}
--
Summary: -Wno-error=pointer-sign does not work
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edwintorok at gmail dot com
GCC build triplet: Linux lightspeed2 2.6.26-1-amd64 #1 SMP Fri Aug 8
13:17:41 UTC 2
GCC host triplet: Linux lightspeed2 2.6.26-1-amd64 #1 SMP Fri Aug 8
13:17:41 UTC 2
GCC target triplet: Linux lightspeed2 2.6.26-1-amd64 #1 SMP Fri Aug 8
13:17:41 UTC 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37186
