[Bug c++/43196] New: [4.5 regression] ICE in dwarf2out_frame_debug_expr
Using built-in specs. COLLECT_GCC=i686-pc-mingw32-g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-mingw32/4.5.0/lto-wrapper.exe Target: i686-pc-mingw32 Configured with: ./configure --prefix=/usr --enable-win32-registry --enable-threads=win32 --enable-languages=c,c++ --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --target=i686-pc-mingw32 --enable-shared --enable-interpreter --disable-sjlj-exceptions Thread model: win32 gcc version 4.5.0 20100227 (experimental) (GCC) COLLECT_GCC_OPTIONS='-c' '-g' '-include' '/tmp/baseclasses/mingw_dshow.h' '-w' '-mstackrealign' '-fexceptions' '-mthreads' '-mtune=core2' '-march=core2' '-msse4.1' '-mfpmath=sse' '-O4' '-finline-functions' '-falign-functions' '-falign-jumps' '-falign-labels' '-fthread-jumps' '-fmerge-constants' '-fstrict-overflow' '-falign-loops' '-D_ATL_NO_DEBUG_CRT' '-D_M_IX86' '-I/tmp/mssdk/dx' '-I/tmp/mssdk' '-I/usr/include/mingw' '-Isrc' '-I/tmp/baseclasses' '-Isrc/settings' '-Isrc/dialog' '-Isrc/imgFilters' '-Isrc/codecs' '-Isrc/convert' '-Isrc/subtitles' '-Isrc/settings/filters' '-Isrc/mplayer' '-Isrc/audioFilters' '-Isrc/ffmpeg' '-Isrc/muxers' '-Isrc/acm' '-Isrc/filters' '-Isrc/xiph' '-Isrc/codecs/theora/enc' '-DNDEBUG' '-DWIN32' '-D_CRT_NONSTDC_NO_WARNINGS' '-D_WINDOWS' '-DARCH_IS_32BIT' '-DARCH_IS_IA32' '-o' 'src/imgFilters/avisynth/TimgFilterAvisynth.o' '-save-temps' '-v' '-shared-libgcc' /usr/libexec/gcc/i686-pc-mingw32/4.5.0/cc1plus.exe -E -quiet -v -I/tmp/mssdk/dx -I/tmp/mssdk -I/usr/include/mingw -Isrc -I/tmp/baseclasses -Isrc/settings -Isrc/dialog -Isrc/imgFilters -Isrc/codecs -Isrc/convert -Isrc/subtitles -Isrc/settings/filters -Isrc/mplayer -Isrc/audioFilters -Isrc/ffmpeg -Isrc/muxers -Isrc/acm -Isrc/filters -Isrc/xiph -Isrc/codecs/theora/enc -D_MT -D_ATL_NO_DEBUG_CRT -D_M_IX86 -DNDEBUG -DWIN32 -D_CRT_NONSTDC_NO_WARNINGS -D_WINDOWS -DARCH_IS_32BIT -DARCH_IS_IA32 -include /tmp/baseclasses/mingw_dshow.h src/imgFilters/avisynth/TimgFilterAvisynth.cpp -mstackrealign -mthreads -mtune=core2 -march=core2 -msse4.1 -mfpmath=sse -w -fexceptions -finline-functions -falign-functions -falign-jumps -falign-labels -fthread-jumps -fmerge-constants -fstrict-overflow -falign-loops -g -fworking-directory -O4 -fpch-preprocess -o TimgFilterAvisynth.ii ignoring nonexistent directory /usr/lib/gcc/i686-pc-mingw32/4.5.0/../../../../i686-pc-mingw32/sys-include ignoring duplicate directory /usr/include/mingw as it is a non-system directory that duplicates a system directory #include ... search starts here: #include ... search starts here: /tmp/mssdk/dx /tmp/mssdk src /tmp/baseclasses src/settings src/dialog src/imgFilters src/codecs src/convert src/subtitles src/settings/filters src/mplayer src/audioFilters src/ffmpeg src/muxers src/acm src/filters src/xiph src/codecs/theora/enc /usr/lib/gcc/i686-pc-mingw32/4.5.0/../../../../i686-pc-mingw32/include/c++/4.5.0 /usr/lib/gcc/i686-pc-mingw32/4.5.0/../../../../i686-pc-mingw32/include/c++/4.5.0/i686-pc-mingw32 /usr/lib/gcc/i686-pc-mingw32/4.5.0/../../../../i686-pc-mingw32/include/c++/4.5.0/backward /usr/lib/gcc/i686-pc-mingw32/4.5.0/include /usr/lib/gcc/i686-pc-mingw32/4.5.0/include-fixed /usr/lib/gcc/i686-pc-mingw32/4.5.0/../../../../i686-pc-mingw32/include End of search list. COLLECT_GCC_OPTIONS='-c' '-g' '-include' '/tmp/baseclasses/mingw_dshow.h' '-w' '-mstackrealign' '-fexceptions' '-mthreads' '-mtune=core2' '-march=core2' '-msse4.1' '-mfpmath=sse' '-O4' '-finline-functions' '-falign-functions' '-falign-jumps' '-falign-labels' '-fthread-jumps' '-fmerge-constants' '-fstrict-overflow' '-falign-loops' '-D_ATL_NO_DEBUG_CRT' '-D_M_IX86' '-I/tmp/mssdk/dx' '-I/tmp/mssdk' '-I/usr/include/mingw' '-Isrc' '-I/tmp/baseclasses' '-Isrc/settings' '-Isrc/dialog' '-Isrc/imgFilters' '-Isrc/codecs' '-Isrc/convert' '-Isrc/subtitles' '-Isrc/settings/filters' '-Isrc/mplayer' '-Isrc/audioFilters' '-Isrc/ffmpeg' '-Isrc/muxers' '-Isrc/acm' '-Isrc/filters' '-Isrc/xiph' '-Isrc/codecs/theora/enc' '-DNDEBUG' '-DWIN32' '-D_CRT_NONSTDC_NO_WARNINGS' '-D_WINDOWS' '-DARCH_IS_32BIT' '-DARCH_IS_IA32' '-o' 'src/imgFilters/avisynth/TimgFilterAvisynth.o' '-save-temps' '-v' '-shared-libgcc' /usr/libexec/gcc/i686-pc-mingw32/4.5.0/cc1plus.exe -fpreprocessed TimgFilterAvisynth.ii -quiet -dumpbase TimgFilterAvisynth.cpp -mstackrealign -mthreads -mtune=core2 -march=core2 -msse4.1 -mfpmath=sse -auxbase-strip src/imgFilters/avisynth/TimgFilterAvisynth.o -g -O4 -w -version -fexceptions -finline-functions -falign-functions -falign-jumps -falign-labels -fthread-jumps -fmerge-constants -fstrict-overflow -falign-loops -o TimgFilterAvisynth.s GNU C++ (GCC) version 4.5.0 20100227 (experimental) (i686-pc-mingw32) compiled by GNU C version 4.5.0 20100221 (experimental), GMP version 5.0.0, MPFR version 2.4.2, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 4.5.0 20100227 (experimental) (i686-pc-mingw32) compiled by GNU C version 4.5.0 20100221
[Bug c++/43196] [4.5 regression] ICE in dwarf2out_frame_debug_expr
--- Comment #1 from jojelino at gmail dot com 2010-02-27 08:12 --- Created an attachment (id=19973) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19973action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43196
[Bug c++/43196] [4.5 regression] ICE in dwarf2out_frame_debug_expr
--- Comment #2 from jojelino at gmail dot com 2010-02-27 08:44 --- when given without -mstackrealign, it works fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43196
[Bug tree-optimization/43186] [4.5 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #6 from d dot g dot gorbachev at gmail dot com 2010-02-27 10:17 --- Thanks! But it still does not work when a 3 is replaced by a 4. Also, the original testcase requires much time to compile. -- d dot g dot gorbachev at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug fortran/43178] Pointless resetting to NULL for local ALLOCATABLEs
--- Comment #11 from dominiq at lps dot ens dot fr 2010-02-27 10:35 --- With the patch in comment #10, the tests in pr40440 (the original one and the one in comment #2 give an ICE: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x gfc_trans_assignment (expr1=0x142a32110, expr2=0x0, init_flag=0 '\0', dealloc=0 '\0') at ../../work/gcc/fortran/trans-expr.c:5380 5380 if (expr2-expr_type == EXPR_FUNCTION expr2-rank 0) (gdb) bt #0 gfc_trans_assignment (expr1=0x142a32110, expr2=0x0, init_flag=0 '\0', dealloc=0 '\0') at ../../work/gcc/fortran/trans-expr.c:5380 #1 0x0001000c2304 in gfc_init_default_dt (sym=0x142a0a170, body=0x0, dealloc=0 '\0') at ../../work/gcc/fortran/trans-decl.c:3011 #2 0x0001000b1810 in gfc_trans_deferred_array (sym=0x142a0a170, body=0x1429dc820) at ../../work/gcc/fortran/trans-array.c:6258 #3 0x0001000c2aa1 in gfc_trans_deferred_vars (proc_sym=0x1428fbb60, fnbody=value temporarily unavailable, due to optimizations) at ../../work/gcc/fortran/trans-decl.c:3159 #4 0x0001000c3be4 in gfc_generate_function_code (ns=value temporarily unavailable, due to optimizations) at ../../work/gcc/fortran/trans-decl.c:4400 #5 0x0001000a79eb in gfc_generate_module_code (ns=value temporarily unavailable, due to optimizations) at ../../work/gcc/fortran/trans.c:1382 #6 0x00010006955f in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4228 #7 0x0001000a27fc in gfc_be_parse_file (set_yydebug=value temporarily unavailable, due to optimizations) at ../../work/gcc/fortran/f95-lang.c:239 #8 0x0001006d5c9a in toplev_main (argc=2, argv=0x7fff5fbfda18) at ../../work/gcc/toplev.c:1053 #9 0x000110a4 in start () Otherwise all my other tests passed and regression testing went fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43178
[Bug tree-optimization/43197] New: Endianness and Optimization
The attached code (which tries to generically load given-endianness values of varying width from memory) shows some interesting optimization quirks. It's especially pussling why optimization quality varies so greatly with width, and is actually worst for the native word width. For example: $ gcc -Wall -Wextra bad.cc -lstdc++ -O3 -### Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' --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 --disable-werror --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.1 (Ubuntu 4.4.1-4ubuntu9) COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-O3' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.4.1/cc1plus -quiet -D_GNU_SOURCE bad.cc -D_FORTIFY_SOURCE=2 -quiet -dumpbase bad.cc -mtune=generic -auxbase bad -O3 -Wall -Wextra -fstack-protector -o /tmp/ccnHgEb9.s COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-O3' '-mtune=generic' as -Qy -o /tmp/cceJWVC8.o /tmp/ccnHgEb9.s COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../:/lib/:/usr/lib/:/usr/lib/x86_64-linux-gnu/ COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-O3' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.4.1/collect2 --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../.. -L/usr/lib/x86_64-linux-gnu /tmp/cceJWVC8.o -lstdc++ -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.4.1/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crtn.o $ objdump -d a.out | c++filt | sed -n '/Test_/,/constructors/ p' out (See attachments for source and output.) -- Summary: Endianness and Optimization Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kai dot extern at googlemail 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=43197
[Bug tree-optimization/43197] Endianness and Optimization
--- Comment #1 from kai dot extern at googlemail dot com 2010-02-27 10:59 --- Created an attachment (id=19974) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19974action=view) C++ Source The source file to demonstrate the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43197
[Bug tree-optimization/43197] Endianness and Optimization
--- Comment #2 from kai dot extern at googlemail dot com 2010-02-27 11:01 --- Created an attachment (id=19975) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19975action=view) Disassembled output The results from compiling the source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43197
[Bug fortran/43173] [4.5 Regression] Unnecessary array temporary: Passing contiguous array as actual argument
--- Comment #5 from tkoenig at gcc dot gnu dot org 2010-02-27 11:35 --- I do not see the temporaries with gcc-Version 4.5.0 20100214 (experimental) (GCC) but I see this with gcc-Version 4.5.0 20100227 (experimental) (GCC) on x86_64-unknown-linux-gnu This makes this a regression. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Summary|Unnecessary array temporary:|[4.5 Regression] Unnecessary |Passing contiguous array as |array temporary: Passing |actual argument |contiguous array as actual ||argument Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43173
[Bug c++/43198] New: edge points to wrong declaration
I just tried to compile the package monotone-0.46 with the C++ compiler version 4.5 snapshot 20100225 and it said cmd_diff_log.cc:1128:1: error: edge points to wrong declaration: and cmd_diff_log.cc:1128:1: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required. -- Summary: edge points to wrong declaration Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43198
[Bug c++/43198] edge points to wrong declaration
--- Comment #1 from dcb314 at hotmail dot com 2010-02-27 11:56 --- Created an attachment (id=19976) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19976action=view) gzipped C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43198
[Bug fortran/43178] Pointless resetting to NULL for local ALLOCATABLEs
--- Comment #12 from burnus at gcc dot gnu dot org 2010-02-27 12:24 --- (In reply to comment #11) With the patch in comment #10, the tests in pr40440 (the original one and the one in comment #2 give an ICE: Thanks for testing! In trans-array.c's gfc_trans_deferred_array, my current version has - if (sym-value) + if (sym-value == NULL || !has_default_initializer (sym-ts.u.derived)) ^^ This part is new Hopefully, that is all what is needed. Still, the patch needs to be audited - I wouldn't be surprised if some free were missing, leading to memory leakage in the generated code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43178
Re: [Bug tree-optimization/43197] New: Endianness and Optimization
Sent from my iPhone On Feb 27, 2010, at 2:56 AM, kai dot extern at googlemail dot com gcc-bugzi...@gcc.gnu.org wrote: The attached code (which tries to generically load given-endianness values of varying width from memory) shows some interesting optimization quirks. It's especially pussling why optimization quality varies so greatly with width, and is actually worst for the native word width. You are violating c++ aliasing rules. You access a uint8_t via different types. For example: $ gcc -Wall -Wextra bad.cc -lstdc++ -O3 -### Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' --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 -- disable-werror --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.1 (Ubuntu 4.4.1-4ubuntu9) COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-O3' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.4.1/cc1plus -quiet -D_GNU_SOURCE bad.cc -D_FORTIFY_SOURCE=2 -quiet -dumpbase bad.cc - mtune=generic -auxbase bad -O3 -Wall -Wextra -fstack-protector -o /tmp/ccnHgEb9.s COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-O3' '-mtune=generic' as -Qy -o /tmp/cceJWVC8.o /tmp/ccnHgEb9.s COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/ 4.4.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/../../../:/lib/:/usr/lib/:/usr/lib/x86_64- linux-gnu/ COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-O3' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.4.1/collect2 --build-id --eh- frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1 -L/usr/lib/gcc/x86_64-linux- gnu/4.4.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib -L/lib/../ lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../.. -L/usr/lib/x86_64-linux-gnu /tmp/cceJWVC8.o -lstdc++ -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.4.1/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crtn.o $ objdump -d a.out | c++filt | sed -n '/Test_/,/constructors/ p' out (See attachments for source and output.) -- Summary: Endianness and Optimization Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kai dot extern at googlemail 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=43197
[Bug tree-optimization/43197] Endianness and Optimization
--- Comment #3 from pinskia at gmail dot com 2010-02-27 13:06 --- Subject: Re: New: Endianness and Optimization Sent from my iPhone On Feb 27, 2010, at 2:56 AM, kai dot extern at googlemail dot com gcc-bugzi...@gcc.gnu.org wrote: The attached code (which tries to generically load given-endianness values of varying width from memory) shows some interesting optimization quirks. It's especially pussling why optimization quality varies so greatly with width, and is actually worst for the native word width. You are violating c++ aliasing rules. You access a uint8_t via different types. For example: $ gcc -Wall -Wextra bad.cc -lstdc++ -O3 -### Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu9' --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 -- disable-werror --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.1 (Ubuntu 4.4.1-4ubuntu9) COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-O3' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.4.1/cc1plus -quiet -D_GNU_SOURCE bad.cc -D_FORTIFY_SOURCE=2 -quiet -dumpbase bad.cc - mtune=generic -auxbase bad -O3 -Wall -Wextra -fstack-protector -o /tmp/ccnHgEb9.s COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-O3' '-mtune=generic' as -Qy -o /tmp/cceJWVC8.o /tmp/ccnHgEb9.s COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/:/usr/lib/gcc/x86_64-linux-gnu/ 4.4.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/ x86_64-linux-gnu/4.4.1/../../../:/lib/:/usr/lib/:/usr/lib/x86_64- linux-gnu/ COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-O3' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.4.1/collect2 --build-id --eh- frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1 -L/usr/lib/gcc/x86_64-linux- gnu/4.4.1 -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib -L/lib/../ lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../.. -L/usr/lib/x86_64-linux-gnu /tmp/cceJWVC8.o -lstdc++ -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.4.1/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.4.1/../../../../lib/crtn.o $ objdump -d a.out | c++filt | sed -n '/Test_/,/constructors/ p' out (See attachments for source and output.) -- Summary: Endianness and Optimization Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kai dot extern at googlemail 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=43197 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43197
[Bug fortran/43199] New: Internal error using fortran-2003 .mod file
The generated m_string.mod from m_string.f03 generated with latest version of gcc-fortran 4.5 generates an internal error when used in any other fortran module through a use statement. _ module m_string !--- ! Copyright : Fran Martinez Fadrique ! Project : FORTRAN ! Author: Fran Martinez Fadrique ! Language : Fortran 95 ! Synopsis : Dynamic character string !--- !---USE statements-- !---End of use statements--- implicit none !---Public/Private declarations- private public t_string public string, string_ !---End of public/private declarations-- character(len=130), parameter, private :: sccs_info = '$Id: $' !---Declaration of module variables- ! Time type type t_string private character, dimension(:), allocatable :: string ! String buffer integer :: length = 0 ! String length integer :: size = 0 ! Total buffer size contains generic :: index = string_index_s, string_index_c procedure, private :: string_index_s procedure, private :: string_index_c generic :: operator(+) = string_concat_string, string_concat_char generic :: operator(//) = string_concat_string, string_concat_char procedure, private :: string_concat_string procedure, private :: string_concat_char generic :: operator(==) = string_equal_string, string_equal_char procedure, private :: string_equal_string procedure, private :: string_equal_char generic :: operator(/=) = string_nonequal_string, string_nonequal_char procedure, private :: string_nonequal_string procedure, private :: string_nonequal_char generic :: operator() = string_greater_string, string_greater_char generic :: lgt = string_greater_string, string_greater_char procedure, private :: string_greater_string procedure, private :: string_greater_char generic :: operator() = string_less_string, string_less_char generic :: llt = string_less_string, string_less_char procedure, private :: string_less_string procedure, private :: string_less_char generic :: operator(=) = string_greater_equal_string, string_greater_equal_char generic :: lge = string_greater_equal_string, string_greater_equal_char procedure, private :: string_greater_equal_string procedure, private :: string_greater_equal_char generic :: operator(=) = string_less_equal_string, string_less_equal_char generic :: lle = string_less_equal_string, string_less_equal_char procedure, private :: string_less_equal_string procedure, private :: string_less_equal_char procedure :: len = string_len procedure :: len_trim = string_len_trim procedure :: trim = string_trim procedure :: len_strip = string_len_strip procedure :: strip = string_strip procedure :: adjustl = string_adjustl procedure :: adjustr = string_adjustr procedure :: char = string_to_char procedure :: write = string_write procedure :: write_xml = string_write_xml procedure :: read = string_read end type t_string ! The blank character character, parameter :: blank = ' ' ! Element assignement operator interface assignment(=) module procedure string_assign_from_char module procedure char_assign_from_string end interface ! Concatenation operations interface operator(+) module procedure char_concat_string module procedure char_concat_char end interface interface operator(//) module procedure char_concat_string end interface ! Element comparison operators lead by character instead of string interface operator(==) module procedure char_equal_string end interface interface operator(/=) module procedure char_nonequal_string end interface interface operator() module procedure char_greater_string end interface interface operator(=) module procedure char_greater_equal_string end interface interface operator() module procedure char_less_string end interface interface operator(=) module procedure
[Bug tree-optimization/43197] Endianness and Optimization
--- Comment #4 from kai dot extern at googlemail dot com 2010-02-27 13:46
---
You are violating c++ aliasing rules. You access a uint8_t via
different types.un
Actually, I address other types via uint8_t, but that is neither here nor
there. (Oh, I just realized you probably didn't mean the union but the load in
mem2int. But the following comments apply just as well to that part.)
First, as far as I can tell, the code produced is clearly *correct*.
Second, the optimization of everything except uint64_t shows that gcc clearly
understands what I'm trying to do.
In fact, my first attempts had no type-punning whatsoever; however, the
resulting code demonstrated that gcc had no clue what I was trying to do - it
was pretty much completely unoptimized. So I went looking forways to describe
the problem that gcc would actually understand.
This particular solution grew out of some other gcc bug which compared various
versions of determining endianess, and showed that currently, the version with
unions is the only one gcc can optimize - that seems to be a regression
introduced with 4.0, and the bug seems to be still open.
Anyway, my point here is that gcc *does* understand this idiom. I see two
problems:
1. For some reason, gcc can optimize the byte_sex function to a constant -
except when the integer is 64 bits long. It is not obvious if the problem is in
the 64 bits, or in the 8 loop iterations, but something does not work there
which works in the smaller cases.
2. The actual byte swapping code (which has nothing whatsoever to do with any
aliasing) is clearly suboptimal in some cases. Again, it is not obvious what
property causes gcc to generate this one just fine for some cases, and not very
fine for others. The basic logic is obviously the same.
Anyway, if you can point out a way to write this that is completely
standards-conformant, generates decent code (at least as good as this version),
and does not rely on me telling the compiler what the endianness is, I'm
interested in learning. (I should probably point out that this ought to work
even for inconsistent endianness - I don't recall exactly, but I rember hearing
about a cpu that did something like 3412 byte ordering.)
Just for comparision, my first attempt looked like this:
template int n, typename X struct xword {
void operator=(X x) {
set(x);
};
operator X() {
return get();
};
protected:
void set(register X x) {
for (register int i = 0; i n; i++) {
m_x[TRAITS::le ? i : n - i - 1] = x 0xff;
x = 8;
};
};
X get() {
register X r;
for (register int i = 0; i n; i++) {
r = 8;
r |= m_x[TRAITS::le ? n - i - 1 : i];
};
return r;
};
private:
uint8_t m_x[n];
};
No aliasing issues. Also, no optimization whatsoever.
--
kai dot extern at googlemail dot com changed:
What|Removed |Added
CC||kai dot extern at googlemail
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43197
[Bug tree-optimization/42326] [4.5 Regression][graphite] segfault in tree-data-ref.c with Graphite building 200.sixtrack
--- Comment #9 from p dot vanhoof at oma dot be 2010-02-27 13:53 ---
The following Lagrange interpolation routine crashes the trunk
gcc -O1 -floop-parallelize-all -c bug.c
bug.c: In function lagrange:
bug.c:1:8: internal compiler error: Segmentation fault
... etc.
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/common/compilers/gcc450/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-mainline/configure --prefix=/usr/local/gcc450
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.5.0 20100226 (experimental) (GCC)
This is r157083 of the trunk.
cat bug.c
double lagrange(const double x[],
const double y[],
long n,
double xval)
{
long i, j;
double yval = 0.;
for( i=0; i n; i++ )
{
double l = 1.;
for( j=0; j n; j++ )
if( i != j )
l *= (xval-x[j])/(x[i]-x[j]);
yval += y[i]*l;
}
return yval;
}
The same problem?
--
p dot vanhoof at oma dot be changed:
What|Removed |Added
CC||p dot vanhoof at oma dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42326
[Bug middle-end/43057] [LTO] fold check: original tree changed by fold
--- Comment #3 from zsojka at seznam dot cz 2010-02-27 14:02 --- Testcase fails when compiled as C++ code too (without -flto): $ /mnt/sdb1/build-157106-checking-fold/gcc/cc1plus -O bug.c int main() Analyzing compilation unit Performing interprocedural optimizations visibility *free_lang_data early_local_cleanups whole-program inline static-var pure-constAssembling functions: int main() bug.c: In function #8216;int main()#8217;: bug.c:3:5: 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43057
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Comment #40 from zsojka at seznam dot cz 2010-02-27 14:06 ---
Follown file fails at all opt levels at both x86_64 and i?86:
-- testcase.cpp --
namespace {
bool bar(int i) { return i; }
}
int foo(int i) { return bar(i) ? i : 0; }
--
It was reduced from dyncast.cc (bootstrap fails there).
$ /mnt/sdb1/build-157106-checking-fold/gcc/cc1plus -O1 testcase.cpp
boolunnamed::bar(int) int foo(int)
Analyzing compilation unit
Performing interprocedural optimizations
visibility *free_lang_data early_local_cleanups whole-program inline
static-var pure-constAssembling functions:
int foo(int)
testcase.cpp: In function #8216;int foo(int)#8217;:
testcase.cpp:4:5: 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug ada/42253] [4.4/4.5 regression] run time crash on null for thin pointers
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-02-27 14:27 --- Subject: Bug 42253 Author: ebotcazou Date: Sat Feb 27 14:27:27 2010 New Revision: 157107 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157107 Log: PR ada/42253 * gcc-interface/utils2.c (build_binary_op) EQ_EXPR: Assert that fat pointer base types are variant of each other. Apply special treatment for null to fat pointer types in all cases. Added: trunk/gcc/testsuite/gnat.dg/thin_pointer1.adb - copied, changed from r157105, trunk/gcc/testsuite/gnat.dg/thin_pointer.adb trunk/gcc/testsuite/gnat.dg/thin_pointer1.ads - copied, changed from r157105, trunk/gcc/testsuite/gnat.dg/thin_pointer.ads trunk/gcc/testsuite/gnat.dg/thin_pointer2.adb trunk/gcc/testsuite/gnat.dg/thin_pointer2_pkg.adb trunk/gcc/testsuite/gnat.dg/thin_pointer2_pkg.ads Removed: trunk/gcc/testsuite/gnat.dg/thin_pointer.adb trunk/gcc/testsuite/gnat.dg/thin_pointer.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/utils2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
[Bug ada/42253] [4.4/4.5 regression] run time crash on null for thin pointers
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-02-27 14:30 --- Subject: Bug 42253 Author: ebotcazou Date: Sat Feb 27 14:30:12 2010 New Revision: 157108 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157108 Log: PR ada/42253 * gcc-interface/utils2.c (build_binary_op) EQ_EXPR: Assert that fat pointer base types are variant of each other. Apply special treatment for null to fat pointer types in all cases. Added: branches/gcc-4_4-branch/gcc/testsuite/gnat.dg/thin_pointer1.adb - copied, changed from r156340, branches/gcc-4_4-branch/gcc/testsuite/gnat.dg/thin_pointer.adb branches/gcc-4_4-branch/gcc/testsuite/gnat.dg/thin_pointer1.ads - copied, changed from r156340, branches/gcc-4_4-branch/gcc/testsuite/gnat.dg/thin_pointer.ads branches/gcc-4_4-branch/gcc/testsuite/gnat.dg/thin_pointer2.adb branches/gcc-4_4-branch/gcc/testsuite/gnat.dg/thin_pointer2_pkg.adb branches/gcc-4_4-branch/gcc/testsuite/gnat.dg/thin_pointer2_pkg.ads Removed: branches/gcc-4_4-branch/gcc/testsuite/gnat.dg/thin_pointer.adb branches/gcc-4_4-branch/gcc/testsuite/gnat.dg/thin_pointer.ads Modified: branches/gcc-4_4-branch/gcc/ada/ChangeLog branches/gcc-4_4-branch/gcc/ada/gcc-interface/utils2.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
[Bug ada/42253] [4.4/4.5 regression] run time crash on null for thin pointers
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-02-27 14:34 --- Thanks for reporting the problem. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||02/msg01202.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42253
[Bug lto/43200] New: [LTO] tree check: expected array_type, have pointer_type in array_ref_low_bound
== 1.c ==
extern void f(void);
const char *s = Hello, world!;
int main(void)
{
f();
return 0;
}
== 2.c ==
extern int puts(const char *);
extern const char s[];
void f(void)
{
puts(s);
}
=
When compiling with `gcc -flto 1.c 2.c', it causes ICE:
2.c:2:19: warning: type of 's' does not match original declaration
1.c:2:13: note: previously declared here
In file included from 2.c:2:0,
from 1.c:2,
from :0:
2.c: In function 'f':
2.c:6:7: internal compiler error: tree check: expected array_type, have
pointer_type in array_ref_low_bound, at expr.c:6207
No ICE with `-combine' instead of `-flto':
2.c:2:19: error: conflicting types for 's'
1.c:2:13: note: previous definition of 's' was here
--
Summary: [LTO] tree check: expected array_type, have pointer_type
in array_ref_low_bound
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43200
Working leaked Eathena dupe febuary 2010
Hey, you do know me but I won't tell you who I am in case I get banned. There was a ragnarok dupe leaked the other day which I've been using the last few days. Won't tell you who I am, but we're friends and I thought you might want to have it. If you use it, don't tell anyone. http://www.purepvpro.com/link.php?M=5845N=11L=1F=T No exe downloads don't worry, its a video file showing you how to do it. You don't need to download anything, just follow the login/trade it shows. See you later :p http://www.purepvpro.com/link.php?M=5845N=11L=1F=T
[Bug fortran/43199] Internal error using fortran-2003 .mod file
--- Comment #1 from kargl at gcc dot gnu dot org 2010-02-27 17:15 --- I changed the severity level to 'normal'. A Fortran issue is never considered to be bocker. Can you attach the files to the bug report? Copy and paste from a web browse is fraught with problems; in particular, whitespace and long lines. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43199
[Bug fortran/43185] [F2008] Implicit SAVE in MODULEs
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-27 17:25 --- Subject: Bug 43185 Author: burnus Date: Sat Feb 27 17:25:05 2010 New Revision: 157109 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157109 Log: 2010-02-27 Tobias Burnus bur...@net-b.de PR fortran/43185 * resolve.c (resolve_fl_variable_derived): Imply SAVE for module variables for Fortran 2008. 2010-02-27 Tobias Burnus bur...@net-b.de PR fortran/43185 * gfortran.dg/default_initialization_1.f90: Add -std=f2003. * gfortran.dg/default_initialization_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/default_initialization_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/default_initialization_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43185
[Bug fortran/43193] [OOP] Calling type-bound procedure of abstract type wrongly rejected
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-27 17:25 --- Close as INVALID. Patch posted was: http://gcc.gnu.org/ml/fortran/2010-02/msg00225.html However, Jim Xia thinks it is invalid - and I think he is right - as C611 has: R611 data-ref is part-ref [ % part-ref ] ... C611 (R611) If the rightmost part-name is of abstract type, data-ref shall be polymorphic. Thus, a data-ref something%parent, parent needs to by polymorphic (CLASS). And for the call, one has: R1219 procedure designator is [...] or data-ref % binding-name thus in something%parent%binding_name parent needs to be polymorphic, i.e. not abstract. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43193
[Bug tree-optimization/43197] Endianness and Optimization
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-02-27 17:25 --- I just think your endian swap is not recognized by the bswap pass. The main reason is because of byte_sex function which is not optimized at the tree level. But really there are better ways of writing endian swaps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43197
[Bug fortran/43185] [F2008] Implicit SAVE in MODULEs
--- Comment #5 from burnus at gcc dot gnu dot org 2010-02-27 17:26 --- ... and fixed on the 4.5 trunk. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43185
[Bug target/43196] [4.5 regression] ICE in dwarf2out_frame_debug_expr
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target Keywords||ice-on-valid-code Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43196
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #8 from manu at gcc dot gnu dot org 2010-02-27 17:44 --- (In reply to comment #7) Created an attachment (id=19963) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19963action=view) [edit] Reduced test case This is a somewhat reduced test case that is still way bigger than what I'd like, but still better than nothing. Hi, I have reduced the testcase in around half of its size and delta is still running. Once it is finished, I will upload it. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug fortran/43199] [OOP] ICE when reading module file: find_array_spec(): Component not found
--- Comment #2 from burnus at gcc dot gnu dot org 2010-02-27 17:47 --- Thanks for the report. (In reply to comment #1) I changed the severity level to 'normal'. A Fortran issue is never considered to be bocker. Especially not if it involves a new experimental feature such as polymorphic data types. Can you attach the files to the bug report? Copy and paste from a web browse is fraught with problems; in particular, whitespace and long lines. I think it was not that bad - only three or so overlong lines (comment lines); however, an attachment make the bug more readable. Reduced test case; compiles with NAG f95 v5.1 and ifort 11.1. gfortran fails with: end 1 Internal Error at (1): find_array_spec(): Component not found module m_string type t_string character, dimension(:), allocatable :: string end type t_string contains pure function string_to_char ( s ) result(res) class(t_string), intent(in) :: s character(len=size(s%string)) :: res res = '' end function string_to_char end module m_string use m_string end -- burnus at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-02-27 17:47:54 date|| Summary|Internal error using|[OOP] ICE when reading |fortran-2003 .mod file |module file: ||find_array_spec(): Component ||not found http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43199
[Bug c/43192] [4.5 Regression] Many test failures
--- Comment #5 from manu at gcc dot gnu dot org 2010-02-27 17:48 --- Subject: Bug 43192 Author: manu Date: Sat Feb 27 17:48:02 2010 New Revision: 157111 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157111 Log: 2010-02-27 Manuel López-Ibáñez m...@gcc.gnu.org PR c/24577 PR c/43192 * gcc.dg/pr8927-1.c: Match new note. * gcc.dg/990506-0.c: Likewise. * gcc.dg/gomp/flush-2.c: Likewise. * gcc.dg/gomp/atomic-5.c: Likewise. * gcc.dg/gomp/pr34607.c: Likewise. * gcc.dg/pr35746.c: Likewise. * gcc.dg/cpp/pragma-1.c: Likewise. * gcc.dg/cpp/pragma-2.c: Likewise. * gcc.dg/pr41842.c: Likewise. * gcc.dg/noncompile/20040629-1.c: Likewise. * objc.dg/private-1.m: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/990506-0.c trunk/gcc/testsuite/gcc.dg/cpp/pragma-1.c trunk/gcc/testsuite/gcc.dg/cpp/pragma-2.c trunk/gcc/testsuite/gcc.dg/gomp/atomic-5.c trunk/gcc/testsuite/gcc.dg/gomp/flush-2.c trunk/gcc/testsuite/gcc.dg/gomp/pr34607.c trunk/gcc/testsuite/gcc.dg/noncompile/20040629-1.c trunk/gcc/testsuite/gcc.dg/pr35746.c trunk/gcc/testsuite/gcc.dg/pr41842.c trunk/gcc/testsuite/gcc.dg/pr8927-1.c trunk/gcc/testsuite/objc.dg/private-1.m -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43192
[Bug c/24577] diagnostic informative note labelled error
--- Comment #9 from manu at gcc dot gnu dot org 2010-02-27 17:48 --- Subject: Bug 24577 Author: manu Date: Sat Feb 27 17:48:02 2010 New Revision: 157111 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157111 Log: 2010-02-27 Manuel López-Ibáñez m...@gcc.gnu.org PR c/24577 PR c/43192 * gcc.dg/pr8927-1.c: Match new note. * gcc.dg/990506-0.c: Likewise. * gcc.dg/gomp/flush-2.c: Likewise. * gcc.dg/gomp/atomic-5.c: Likewise. * gcc.dg/gomp/pr34607.c: Likewise. * gcc.dg/pr35746.c: Likewise. * gcc.dg/cpp/pragma-1.c: Likewise. * gcc.dg/cpp/pragma-2.c: Likewise. * gcc.dg/pr41842.c: Likewise. * gcc.dg/noncompile/20040629-1.c: Likewise. * objc.dg/private-1.m: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/990506-0.c trunk/gcc/testsuite/gcc.dg/cpp/pragma-1.c trunk/gcc/testsuite/gcc.dg/cpp/pragma-2.c trunk/gcc/testsuite/gcc.dg/gomp/atomic-5.c trunk/gcc/testsuite/gcc.dg/gomp/flush-2.c trunk/gcc/testsuite/gcc.dg/gomp/pr34607.c trunk/gcc/testsuite/gcc.dg/noncompile/20040629-1.c trunk/gcc/testsuite/gcc.dg/pr35746.c trunk/gcc/testsuite/gcc.dg/pr41842.c trunk/gcc/testsuite/gcc.dg/pr8927-1.c trunk/gcc/testsuite/objc.dg/private-1.m -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24577
[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1
--- Comment #6 from davek at gcc dot gnu dot org 2010-02-27 17:50 --- Created an attachment (id=19977) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19977action=view) Alternative approach This alternative approach attempts to place a circular dependency between the two generated DLLs by linking into the core library a pseudo-import library specially generated before the real -noncore import library is built. Gonna take it for a bootstrap and test cycle tonight. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
[Bug c/43192] [4.5 Regression] Many test failures
--- Comment #6 from manu at gcc dot gnu dot org 2010-02-27 18:04 --- Hopefully, this should be FIXED in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43192
[Bug fortran/43199] [OOP] ICE when reading module file: find_array_spec(): Component not found
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43199
[Bug pending/41998] GCC 4.6 pending patches meta-bug
--- Comment #8 from manu at gcc dot gnu dot org 2010-02-27 18:45 --- Other PRs block this one, not the other way around. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org BugsThisDependsOn||41952, 42617 OtherBugsDependingO|41952, 42617| nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41998
[Bug pending/41998] GCC 4.6 pending patches meta-bug
--- Comment #9 from manu at gcc dot gnu dot org 2010-02-27 18:47 --- Alias 4.6 -- manu at gcc dot gnu dot org changed: What|Removed |Added Alias||4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41998
[Bug other/42965] no warnings being treated as errors for individual -Werror=x options
--- Comment #3 from manu at gcc dot gnu dot org 2010-02-27 18:48 --- Patch approved for GCC 4.6 http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01188.html -- manu at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||41998 nThis|| Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42965
[Bug other/42966] add some indication that a warning has been converted to an error
--- Comment #3 from manu at gcc dot gnu dot org 2010-02-27 18:49 --- Patch approved http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01138.html -- manu at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||41998 nThis|| Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42966
[Bug c++/42054] [4.3/4.4/4.5 Regression] ICE with invalid template parameter
--- Comment #2 from simartin at gcc dot gnu dot org 2010-02-27 19:21 --- Subject: Bug 42054 Author: simartin Date: Sat Feb 27 19:21:39 2010 New Revision: 157112 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157112 Log: gcc/cp/ 2010-02-27 Simon Martin simar...@users.sourceforge.net PR c++/42054 * pt.c (redeclare_class_template): Return false if there are erroneous template parameters. gcc/testsuite/ 2010-02-27 Simon Martin simar...@users.sourceforge.net PR c++/42054: * g++.dg/parse/error37.C: New test. Added: trunk/gcc/testsuite/g++.dg/parse/error37.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42054
[Bug fortran/43155] I/O error message: Off-by one position of edit descriptor
--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-27 19:26 --- I think the main problem of comment 0 was a user error - or at least it is not reproducible with the information we have. The second problem is solved. I therefore changed the summary and close it as FIXED. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|Reading real numbers of the |I/O error message: Off-by |form 123+ 44 (with space) |one position of edit ||descriptor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43155
[Bug c++/42054] [4.3/4.4 Regression] ICE with invalid template parameter
--- Comment #3 from simartin at gcc dot gnu dot org 2010-02-27 19:28 --- Fixed in 4.5 -- simartin at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4/4.5 Regression] ICE|[4.3/4.4 Regression] ICE |with invalid template |with invalid template |parameter |parameter http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42054
[Bug preprocessor/43195] #pragma once and -H
--- Comment #1 from manu at gcc dot gnu dot org 2010-02-27 19:29 --- testing a patch -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |manu at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-27 19:29:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43195
[Bug fortran/43199] [OOP] ICE when reading module file: find_array_spec(): Component not found
--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-27 19:37 --- Janus, can you have a look? I was wondering whether the following patch makes sense. If you have time, can you finish a patch for this PR and PR 43169. Index: resolve.c === --- resolve.c (Revision 157111) +++ resolve.c (Arbeitskopie) @@ -4006,6 +4006,8 @@ find_array_spec (gfc_expr *e) case REF_COMPONENT: if (derived == NULL) derived = e-symtree-n.sym-ts.u.derived; +if (derived-attr.is_class) + derived = derived-components-ts.u.derived; c = derived-components; -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43199
[Bug tree-optimization/43186] [4.5 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-02-27 19:52 --- (In reply to comment #6) Thanks! But it still does not work when a 3 is replaced by a 4. Also, the original testcase requires much time to compile. Well, it really only requires much time and memory to compile, it's not never ending ;) What you get is in the original testcase 8 times inlining of foo and all the loop nest completely unrolled (without any intermediate optimization). The first patch added some intermediate optimization that reduces the amount of CFG left to further unrollings. Honza, can we restrict recursive inlining if that increases the loop nest depth (also for profile guess reasons)? I realize that manually doing the 8-fold inlining still would leave us with a slow complete unrolling. We could restrict us to unroll say a maximum loop nest depth of 3. Or what we really would need is constant propagation and dead code elimination for the unrolled BBs after each iteration. I'm adding the restriction on unrolling. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|REOPENED|ASSIGNED Keywords||compile-time-hog, memory-hog Last reconfirmed|2010-02-26 11:38:39 |2010-02-27 19:52:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug middle-end/43198] [4.5 Regression] edge points to wrong declaration
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org Component|c++ |middle-end Summary|edge points to wrong|[4.5 Regression] edge points |declaration |to wrong declaration Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43198
[Bug tree-optimization/42587] bswap not recognized for memory
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-02-27 20:04 --- *** Bug 43197 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||kai dot extern at googlemail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42587
[Bug tree-optimization/43197] Endianness and Optimization
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-02-27 20:04 --- *** This bug has been marked as a duplicate of 42587 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43197
[Bug c/43009] segmentation fault with -O3 when accessing byte-aligned array as dwords
--- Comment #9 from chris at crupp dot de 2010-02-27 20:12 --- I experienced the same issue. I'm not able to reproduce this in a short snippet, but if someone needs my whole source package then i can provide it. -- chris at crupp dot de changed: What|Removed |Added CC||chris at crupp dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43009
[Bug middle-end/43198] [4.5 Regression] edge points to wrong declaration
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-27 20:32 --- This is most likely a dup of bug 42450. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43198
[Bug tree-optimization/43197] Endianness and Optimization
--- Comment #7 from kai dot extern at googlemail dot com 2010-02-27 20:34 --- (In reply to comment #6) *** This bug has been marked as a duplicate of 42587 *** Oh? 42587 seems to be about not recognising memory bswap, which explains why my first attempt didn't work. But that wasn't what this bug was about - in this bug, the bswap was register-to-register, and some cases were recognized just fine. Also, the other half was about a different optimization failing for 64 bit types. Doesn't look like a duplicate to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43197
[Bug lto/43200] [LTO] tree check: expected array_type, have pointer_type in array_ref_low_bound
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-02-27 20:55 --- That's because -combine refuses to compile the testcase. LTO is very forgiving to global symbol type mismatches (maybe too forgiving). It basically chooses one type and replaces all other uses with a VIEW_CONVERT_EXPR to the uses type - but we clearly fail to adjust some accesses here. I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||lto Last reconfirmed|-00-00 00:00:00 |2010-02-27 20:55:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43200
[Bug lto/43201] New: Missed optimization with `-flto'
-- Summary: Missed optimization with `-flto' Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43201
[Bug lto/43201] Missed optimization with `-flto'
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-02-27 21:04 --- Created an attachment (id=19978) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19978action=view) Code produced by lto1 Compiled with `-O2 -flto' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43201
[Bug lto/43201] Missed optimization with `-flto'
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-02-27 21:05 --- Created an attachment (id=19979) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19979action=view) Code compiled without `-flto' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43201
[Bug lto/43201] Missed optimization with `-flto'
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2010-02-27 21:06 --- Created an attachment (id=19980) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19980action=view) C source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43201
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #9 from dodji at gcc dot gnu dot org 2010-02-27 21:14 --- Subject: Re: [4.5 Regression] ICE in tsubst, at cp/pt.c:9923 Hi, I have reduced the testcase in around half of its size and delta is still running. Once it is finished, I will upload it. You mean half of the size of the reduced testcase I did attach? That's interesting as delta was claiming it couldn't reduce it further for me. Thank you for doing this, Manu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug bootstrap/43202] New: wrong arch picked for i*86 intel darwin
After r157110, the wrong architecture, pentiumpro, is selected for gcc trunk built with... Using built-in specs. COLLECT_GCC=gcc-4 COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/i686-apple-darwin10/4.5.0/lto-wrapper Target: i686-apple-darwin10 Configured with: ../gcc-4.5-20100227/configure --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib --build=i686-apple-darwin10 --host=i686-apple-darwin10 --target=i686-apple-darwin10 Thread model: posix gcc version 4.5.0 20100227 (experimental) (GCC) The specs for the compiler are shown to be... # GNU C++ (GCC) version 4.5.0 20100227 (experimental) (i686-apple-darwin10) # compiled by GNU C version 4.5.0 20100227 (experimental), GMP version 5.0.0, MPFR version 2.4.1, MPC version 0.8 # GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 # options passed: -D__DYNAMIC__ t.cc -fPIC -mmacosx-version-min=10.6.3 # -mtune=generic -march=pentiumpro -fverbose-asm # options enabled: -fPIC -falign-loops -fargument-alias -fauto-inc-dec # -fbranch-count-reg -fcommon -fdelete-null-pointer-checks -fearly-inlining # -feliminate-unused-debug-types -fexceptions -ffunction-cse -fgcse-lm # -fident -finline-functions-called-once -fira-share-save-slots # -fira-share-spill-slots -fivopts -fkeep-static-consts # -fleading-underscore -fmerge-debug-strings -fmove-loop-invariants # -fpeephole -freg-struct-return -fsched-critical-path-heuristic # -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock # -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec # -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fshow-column # -fsigned-zeros -fsplit-ivs-in-unroller -ftrapping-math -ftree-cselim # -ftree-forwprop -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize # -ftree-parallelize-loops= -ftree-phiprop -ftree-pta -ftree-reassoc # -ftree-scev-cprop -ftree-slp-vectorize -ftree-vect-loop-version # -funit-at-a-time -fvect-cost-model -fverbose-asm # -fzero-initialized-in-bss -gstrict-dwarf -m128bit-long-double -m32 # -m80387 -maccumulate-outgoing-args -malign-stringops -mfancy-math-387 # -mfp-ret-in-387 -mfused-madd -mieee-fp -mno-red-zone -mno-sse4 # -mpush-args -msahf without even supporting sse2 now. This problem didn't seem to be present in the original proposed patch at http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01191.html. -- Summary: wrong arch picked for i*86 intel darwin Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: i686-apple-darwin10 GCC host triplet: i686-apple-darwin10 GCC target triplet: i686-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43202
[Bug lto/43201] Missed optimization with `-flto'
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-27 21:33 --- This is because p = 0; is not detected as dead store by tree DSE as in p = 0; r = *q; p = (T *) t[0]; *q may load from p because with LTO TBAA rules for pointers have been relaxed (for a reason but also in a somewhat simple manner). With non-LTO void * and void ** have different alias-sets, with LTO they do not (as especially mismatching void * and void ** is a very common error that would lead to many spurious miscompiles with LTO). Note that we really can't optimize this testcase without using TBAA and by design we do not. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||alias Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43201
[Bug bootstrap/43202] wrong arch picked for i*86 intel darwin
--- Comment #1 from hjl dot tools at gmail dot com 2010-02-27 21:37 --- Please try http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01222.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||02/msg01222.html Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43202
[Bug tree-optimization/43186] [4.5 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #8 from d dot g dot gorbachev at gmail dot com 2010-02-27 22:11 --- Well, it really only requires much time and memory to compile, it's not never ending ;) Ah, it means that machine is old. Also, the generated code is larger then what gcc 4.3 does (4.4 is affected, too). Should I file a bug report? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug tree-optimization/43186] [4.5 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-02-27 22:20 --- (In reply to comment #8) Well, it really only requires much time and memory to compile, it's not never ending ;) Ah, it means that machine is old. Also, the generated code is larger then what gcc 4.3 does (4.4 is affected, too). Should I file a bug report? GCC 4.3 did only unroll the very innermost loops. GCC 4.4 does have the same code (so I wondered why your initial testcase didn't trigger) - I can backport the parm change there. As for the size of the code - you can file a bugreport but what the loop optimizer analyzes looks reasonable. So I guess the inliner with its improved size/time estimates inlines more (you might want to verify this). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #10 from manu at gcc dot gnu dot org 2010-02-27 22:26 ---
Reduced testcase:
templateclass A class NumericTraits{};
templateclass B class CovariantVector{};
templateclass C class Image{};
templateclass H,
class E,
class D
class F {
typedef H G;
typedef
typename NumericTraitstypename G::PixelType::RealType
InputRealType;
};
templatetypename TInputImage,
typename TOutputImage=Image
CovariantVector
typename NumericTraits
typename TInputImage
::PixelType
::TInputImage
class XXX{};
XXXImagefloat
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug bootstrap/43202] wrong arch picked for i*86 intel darwin
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-02-27 22:28 --- With the patch proposed in comment 1, I now get... # GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 # options passed: -D__DYNAMIC__ t.cc -fPIC -mmacosx-version-min=10.6.3 # -mtune=generic -march=prescott -fverbose-asm # options enabled: -fPIC -falign-loops -fargument-alias -fauto-inc-dec # -fbranch-count-reg -fcommon -fdelete-null-pointer-checks -fearly-inlining # -feliminate-unused-debug-types -fexceptions -ffunction-cse -fgcse-lm # -fident -finline-functions-called-once -fira-share-save-slots # -fira-share-spill-slots -fivopts -fkeep-static-consts # -fleading-underscore -fmerge-debug-strings -fmove-loop-invariants # -fpeephole -freg-struct-return -fsched-critical-path-heuristic # -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock # -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec # -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fshow-column # -fsigned-zeros -fsplit-ivs-in-unroller -ftrapping-math -ftree-cselim # -ftree-forwprop -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize # -ftree-parallelize-loops= -ftree-phiprop -ftree-pta -ftree-reassoc # -ftree-scev-cprop -ftree-slp-vectorize -ftree-vect-loop-version # -funit-at-a-time -fvect-cost-model -fverbose-asm # -fzero-initialized-in-bss -gstrict-dwarf -m128bit-long-double -m32 # -m80387 -maccumulate-outgoing-args -malign-stringops -mfancy-math-387 # -mfp-ret-in-387 -mfused-madd -mieee-fp -mmmx -mno-red-zone -mno-sse4 # -mpush-args -msahf -msse -msse2 -msse3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43202
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #11 from manu at gcc dot gnu dot org 2010-02-27 22:29 --- Interestingly deleting the typedef H G; makes us give the following error: pr43087-delta.ii:24:18: error: no type named âPixelTypeâ in âclass Imagefloatâ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug bootstrap/43202] wrong arch picked for i*86 intel darwin
--- Comment #3 from hjl dot tools at gmail dot com 2010-02-27 22:34 --- (In reply to comment #2) With the patch proposed in comment 1, I now get... Does it fix your problem? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43202
[Bug libstdc++/43203] New: abi_check from libstdc++ tests fails with CFLAGS=-march=core2
I've tried to built gcc-4.4.3 with different CFLAGS and CXXFLAGS variable and have found that when they are -march=core2 there's one unexpected failure in libstdc++ tests: FAIL: abi_check. Everything else in test results is equal. I know that I should build gcc with neither CFLAGS nor CXXFLAGS set but maybe it's some kind of useful information. -- Summary: abi_check from libstdc++ tests fails with CFLAGS=- march=core2 Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: 4ernov 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=43203
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS=-march=core2
--- Comment #1 from 4ernov at gmail dot com 2010-02-27 22:37 --- Created an attachment (id=19981) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19981action=view) Test log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #12 from manu at gcc dot gnu dot org 2010-02-27 22:41 ---
I meant 'expanding the typedef'.
It would be nice to have a delta tool that expanded typedefs iteratively. Also,
it sometimes good to replace spaces by new lines to give delta larger search
space. I also use the following preprocessing:
cp -f $1 $1.bak
perl -i -0 -w -p -e 's/((class|struct)\s+[_A-Za-z]+)\s*\{/$1\{/sg;' $1
perl -i -0 -w -p -e 's/\{\s+\}/\{\}/sg;' $1
perl -i -0 -w -p -e 's/\s+\{/\{/sg;' $1
perl -i -0 -w -p -e 's/=\s+/=/sg;' $1
perl -i -0 -w -p -e 's/:\s+/:/sg;' $1
perl -i -0 -w -p -e 's/\s+\(/\(/sg;' $1
perl -i -0 -w -p -e 's/([a-zA-Z_]+)/\n$1/sg;' $1
perl -i -0 -w -p -e 's/([a-zA-Z_])/$1\n/sg;' $1
perl -i -0 -w -p -e 's/\n\n/\n/sg;' $1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug middle-end/43204] New: GCC 4.4 / 4.5 generates larger code for a particular testcase
The testcase is taken from attachment 19965 (bug 43186). Compile with `gcc -O3 -DBUG testcase.c' -- Summary: GCC 4.4 / 4.5 generates larger code for a particular testcase Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43204
[Bug middle-end/43204] GCC 4.4 / 4.5 generates larger code for a particular testcase
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-02-27 23:01 --- Created an attachment (id=19982) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19982action=view) Output of GCC 4.3 --- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-02-27 23:02 --- Created an attachment (id=19983) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19983action=view) Output of GCC 4.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43204
[Bug middle-end/43204] GCC 4.4 / 4.5 generates larger code for a particular testcase
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2010-02-27 23:01 --- Created an attachment (id=19982) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19982action=view) Output of GCC 4.3 --- Comment #2 from d dot g dot gorbachev at gmail dot com 2010-02-27 23:02 --- Created an attachment (id=19983) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19983action=view) Output of GCC 4.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43204
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS=-march=core2
--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-27 23:05 --- In any case, I don't think it can be a *library* issue, because the library itself is built with the *C++* compiler only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS=-march=core2
--- Comment #3 from 4ernov at gmail dot com 2010-02-27 23:11 --- I'm sorry, I didn't write the title correctly, CXXFLAGS is the same value as CFLAGS in my case, i.e. CXXFLAGS is -march=core2, too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug fortran/43205] New: -finit-local-zero and -fno-automatic used together with large 2-dim variables take too long to compile
I am using the 4.5.0 20100225 snapshot with macports on snow leopard. I have a large legacy fortran codebase that uses both -finit-local-zero and -fno-automatic together. The code was not working under gcc 4.4.3. I found that bug #41860 fixed this problem and had been checked into the trunk. So, I tried the head version and I found that my code was now working. However there were a few simple routines that were taking ~.5hr-1hr to compile and bringing my macbook pro to an almost unusable point during the compilation. I determined the problem was when there were large two dimensional arrays and both of the options were used together. I managed to cut this down to a very small test case. With either option missing this compiles immediately. Use them together it takes about 1.5 minutes: CCC subroutine testproblem C Use: gfortran -fno-automatic -finit-local-zero -c gfortran-45.F CCC integer nsub_sta(11146, 2000), nsub_sto(11146, 2000) write (*,*) nsub_sta(1,1) write (*,*) nsub_sto(1,1) return end Here is the version information for my compiler: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.5.0/lto-wrapper Target: x86_64-apple-darwin10 Configured with: ../gcc-4.5-20100225/configure --prefix=/opt/local --build=x86_64-apple-darwin10 --libdir=/opt/local/lib/gcc45 --includedir=/opt/local/include/gcc45 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.5 --with-gxx-include-dir=/opt/local/include/gcc45/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc==/opt/local --enable-stage1-checking --enable-languages=c,fortran Thread model: posix gcc version 4.5.0 20100225 (experimental) (GCC) -- Summary: -finit-local-zero and -fno-automatic used together with large 2-dim variables take too long to compile Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris dot walter at duke dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43205
[Bug fortran/43199] [OOP] ICE when reading module file: find_array_spec(): Component not found
--- Comment #4 from fmartinez at gmv dot com 2010-02-27 23:27 --- Created an attachment (id=19984) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19984action=view) Fortran source code File whose generated .mod file causes the compiler error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43199
[Bug tree-optimization/43186] [4.5 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-02-27 23:29 --- Subject: Bug 43186 Author: rguenth Date: Sat Feb 27 23:28:46 2010 New Revision: 157114 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157114 Log: 2010-02-27 Richard Guenther rguent...@suse.de PR tree-optimization/43186 * params.def (PARAM_MAX_UNROLL_ITERATIONS): New param. * doc/invoke.texi (max-completely-peel-loop-nest-depth): Document. * tree-ssa-loop-ivcanon.c (tree_unroll_loops_completely): Limit unroller iterations. * gcc.c-torture/compile/pr43186.c: Adjust testcase. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/params.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr43186.c trunk/gcc/tree-ssa-loop-ivcanon.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS=-march=core2
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-27 23:29 --- Then you are not inlining *at all*. What is happening is that *many* symbols are inadvertently exported at the baseline version instead of the right version, or at all. That is benign, and certainly we don't want to tighten *now* the linker script patterns in the 4.4.x branch to avoid that. Maybe for 4.5.0, and I'm not even sure... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug tree-optimization/43186] [4.4 Regression] A loop in tree_unroll_loops_completely never ends
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-02-27 23:29 --- Fixed for 4.5. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.3 Known to work|4.4.2 |4.3.4 4.5.0 Summary|[4.5 Regression] A loop in |[4.4 Regression] A loop in |tree_unroll_loops_completely|tree_unroll_loops_completely |never ends |never ends Target Milestone|4.5.0 |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43186
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #13 from hjl dot tools at gmail dot com 2010-02-27 23:31
---
(In reply to comment #10)
Reduced testcase:
templateclass A class NumericTraits{};
templateclass B class CovariantVector{};
templateclass C class Image{};
templateclass H,
class E,
class D
class F {
typedef H G;
typedef
typename NumericTraitstypename G::PixelType::RealType
InputRealType;
};
templatetypename TInputImage,
typename TOutputImage=Image
CovariantVector
typename NumericTraits
typename TInputImage
::PixelType
::TInputImage
class XXX{};
XXXImagefloat
It may be a different issue since the original testcase
compiles with older gcc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS=-march=core2
--- Comment #5 from 4ernov at gmail dot com 2010-02-27 23:37 --- Thank you for the problem description. But didn't completely understood: does it indicate any faults in my gcc build with this flags or is it just testsuite details and it's harmless? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #14 from manu at gcc dot gnu dot org 2010-02-27 23:45 --- (In reply to comment #13) It may be a different issue since the original testcase compiles with older gcc. It is still a regression from gcc 4.4.1: pr43087-delta.ii:25: error: no type named 'PixelType' in 'class Imagefloat' pr43087-delta.ii:25: error: template argument 2 is invalid pr43087-delta.ii:25: error: expected unqualified-id at end of input -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS=-march=core2
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-27 23:45 --- It's harmless for sure. But certainly you don't want to build like that unless you are debugging (and then you should add -g, of course), because you are disabling most of the optimizations, exactly like -O0. Performance-wise, the library is unusable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS=-march=core2
--- Comment #7 from 4ernov at gmail dot com 2010-02-27 23:54 --- Hmmm.. so it's also safe to build it with optimization, to say, -O2? Honestly, I was seriously convinced that it's dangerous because of big warnings in LFS etc. And I turned everything off every time.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #15 from hjl dot tools at gmail dot com 2010-02-28 00:03 --- (In reply to comment #14) (In reply to comment #13) It may be a different issue since the original testcase compiles with older gcc. It is still a regression from gcc 4.4.1: pr43087-delta.ii:25: error: no type named 'PixelType' in 'class Imagefloat' pr43087-delta.ii:25: error: template argument 2 is invalid pr43087-delta.ii:25: error: expected unqualified-id at end of input This issue is caused by revision 145440: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS=-march=core2
--- Comment #8 from paolo dot carlini at oracle dot com 2010-02-28 00:05 --- The default is of course -O2 -g, and I can tell you for sure that we (the maintainers) always use it (when we are not debugging) and the same is true for all the most important Linux distros. By the way, no warnings *at all* are emitted during the build, again, for sure on the major Linux distros. If you are referring to your own code, this is off-topic here, but normally a *release* build uses at least -O2, otherwise, performance are just *horrible*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug c++/43206] New: [4.5 Regression] Revision 145440 caused ICE at cp/pt.c:9249
Revision 145440:
http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html
caused:
[...@gnu-34 rrs]$ cat pr43087.cc
templateclass A class NumericTraits{};
templateclass B class CovariantVector{};
templateclass C class Image{};
templateclass H,
class E,
class D
class F {
typedef H G;
typedef
typename NumericTraitstypename G::PixelType::RealType
InputRealType;
};
templatetypename TInputImage,
typename TOutputImage=Image
CovariantVector
typename NumericTraits
typename TInputImage
::PixelType
::TInputImage
class XXX{};
XXXImagefloat
[...@gnu-34 rrs]$ ./145440/usr/bin/gcc -S pr43087.cc
pr43087.cc:25: internal compiler error: tree check: accessed elt 3 of tree_vec
with 2 elts in tsubst, at cp/pt.c:9249
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: [4.5 Regression] Revision 145440 caused ICE at
cp/pt.c:9249
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43206
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #16 from hjl dot tools at gmail dot com 2010-02-28 00:08 --- (In reply to comment #15) (In reply to comment #14) (In reply to comment #13) It may be a different issue since the original testcase compiles with older gcc. It is still a regression from gcc 4.4.1: pr43087-delta.ii:25: error: no type named 'PixelType' in 'class Imagefloat' pr43087-delta.ii:25: error: template argument 2 is invalid pr43087-delta.ii:25: error: expected unqualified-id at end of input This issue is caused by revision 145440: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html I opened PR 43206 for it. -- hjl dot tools at gmail dot com changed: What|Removed |Added BugsThisDependsOn||43206 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug c++/43206] [4.5 Regression] Revision 145440 caused ICE at cp/pt.c:9249
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43206
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS=-march=core2
--- Comment #9 from 4ernov at gmail dot com 2010-02-28 00:14 --- Paolo, thank you very much for informing me and sorry for some off-topic, but it's so important for me, because obviously I was really confused. Thank you. And what about this report? Should we close it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS=-march=core2
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-28 00:16 --- You are welcome. Don't worry, anyway, let's keep it open for now, maybe I'll tweak the patterns for 4.5.0, cannot hurt. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS=-march=core2
--- Comment #11 from 4ernov at gmail dot com 2010-02-28 00:21 --- Ok, thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug libstdc++/43203] abi_check from libstdc++ tests fails with CFLAGS=-march=core2
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-28 00:21 --- Actually, I'm thinking that *a few* times already we noticed that something was going wrong with inlining thanks to those slightly loose patterns. Thus, assuming nobody disagrees, I would just close this PR exactly for that reason. In two days or so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43203
[Bug bootstrap/43202] wrong arch picked for i*86 intel darwin
--- Comment #4 from hjl at gcc dot gnu dot org 2010-02-28 07:23 --- Subject: Bug 43202 Author: hjl Date: Sun Feb 28 07:23:31 2010 New Revision: 157118 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157118 Log: Restore i[34567]86-*-darwin* bootstrap. 2010-02-27 H.J. Lu hongjiu...@intel.com PR bootstrap/43202 * config.gcc: Enable SSE math for i[34567]86-*-darwin* by default. Set the default 32bit/64bit archs with $with_arch instead of $arch for i[34567]86-*-*|x86_64-*-* targets. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43202
[Bug bootstrap/43202] wrong arch picked for i*86 intel darwin
--- Comment #5 from hjl dot tools at gmail dot com 2010-02-28 07:24 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43202
[Bug bootstrap/43202] wrong arch picked for i*86 intel darwin
--- Comment #6 from hjl at gcc dot gnu dot org 2010-02-28 07:56 --- Subject: Bug 43202 Author: hjl Date: Sun Feb 28 07:56:36 2010 New Revision: 157119 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157119 Log: Don't set the default arch for i[34567]86-*-darwin*|x86_64-*-darwin*. 2010-02-27 H.J. Lu hongjiu...@intel.com PR bootstrap/43202 * config.gcc: Don't enable SSE math for i[34567]86-*-darwin* by default. Don't set the default arch for i[34567]86-*-darwin*|x86_64-*-darwin*. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43202
