[Bug fortran/41403] Optimization: NIST test FM013.f fails at -O1 and above
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-09-19 06:15 --- Reduced case: Expected result: $ ./a.out 0 ERRORS ENCOUNTERED Wrong result: $ ./a.out 1 ERRORS ENCOUNTERED PROGRAM FM013 I01 = 5 I02 = 6 IVPASS=0 IVFAIL=0 IVDELE=0 ICZERO=0 IVTNUM = 126 C IF (ICZERO) 31260, 1260, 31260 1260 CONTINUE ASSIGN 1263 TO I GO TO I, (1262,1263,1264) 1262 ICON01 = 1262 GO TO 1265 1263 ICON01 = 1263 GO TO 1265 1264 ICON01 = 1264 1265 CONTINUE GO TO 41260 31260 IVDELE = IVDELE + 1 IF (ICZERO) 41260, 1271, 41260 41260 IF ( ICON01 - 1263 ) 21260, 11260, 21260 11260 IVPASS = IVPASS + 1 GO TO 1271 21260 IVFAIL = IVFAIL + 1 IVCOMP=ICON01 IVCORR = 1263 1271 CONTINUE IVTNUM = 127 9 CONTINUE WRITE (I02,90008) IVFAIL STOP 90008 FORMAT ( ,15X,I5, ERRORS ENCOUNTERED ) END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41403
[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)
--- Comment #7 from cgd at gcc dot gnu dot org 2009-09-19 06:15 --- Subject: Bug 28435 Author: cgd Date: Sat Sep 19 06:15:21 2009 New Revision: 151879 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151879 Log: [libcpp/ChangeLog] 2009-09-18 Chris Demetriou c...@google.com PR preprocessor/28435: * include/cpplib.h (struct cpp_options): Add new member deps.need_preprocessor_output. * files.c (open_file_failed): If preprocessor output is needed always report an error. [gcc/ChangeLog] 2009-09-19 Chris Demetriou c...@google.com PR preprocessor/28435: * c-opts.c (c_common_handle_option): For -MD and -MMD, indicate to cpplib that the preprocessor output is needed. [gcc/testsuite/ChangeLog] 2009-09-19 Chris Demetriou c...@google.com PR preprocessor/28435: * gcc.dg/cpp/missing-header-MD.c: New test. * gcc.dg/cpp/missing-header-MMD.c: New test. * gcc.dg/cpp/missing-sysheader-MD.c: New test. * gcc.dg/cpp/missing-sysheader-MMD.c: New test. Added: trunk/gcc/testsuite/gcc.dg/cpp/missing-header-MD.c trunk/gcc/testsuite/gcc.dg/cpp/missing-header-MMD.c trunk/gcc/testsuite/gcc.dg/cpp/missing-sysheader-MD.c trunk/gcc/testsuite/gcc.dg/cpp/missing-sysheader-MMD.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-opts.c trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/files.c trunk/libcpp/include/cpplib.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435
[Bug middle-end/41260] [4.5 Regression] major regressions on *-apple-darwin10 at -m64 caused by r147995
--- Comment #37 from howarth at nitro dot med dot uc dot edu 2009-09-19 06:17 --- Executing... make -k check RUNTESTFLAGS=--target_board=unix/-Wl,-no_compact_unwind shows that all of the g++ regressions caused by 147995 are eliminated. Unfortunately, this approach plays havoc with the gcc.dg/pch and g++.dg/pch testsuite with hundreds of new failures of the form... FAIL: ./array-1.H -g (test for excess errors) FAIL: g++.dg/pch/array-1.C -g FAIL: g++.dg/pch/array-1.C -g assembly comparison so it definitely would be better to try to fix this issue by not adding epilog unwind information for Darwin instead. It should also be noted that are darwin10, libgcc is subsumed into libSystem and the FSF libgcc is never actually used for unwinding regardless linkage order for -lSystem and -lgcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260
[Bug bootstrap/35619] [4.3/4.4/4.5 Regression] fixed includes not being found if building in src dir
--- Comment #32 from rwild at gcc dot gnu dot org 2009-09-19 08:30 --- Subject: Bug 35619 Author: rwild Date: Sat Sep 19 08:29:58 2009 New Revision: 151880 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151880 Log: Fix long-standing in-tree build include-fixed bug. gcc/: PR bootstrap/35619 * Makefile.in (stmp-fixinc): Ensure `include-fixed' is created in the directory this rule is called from, rather than the toplevel 'gcc' directory, to fix in-tree build. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35619
[Bug bootstrap/35619] [4.3/4.4 Regression] fixed includes not being found if building in src dir
--- Comment #33 from rwild at gcc dot gnu dot org 2009-09-19 08:33 --- Fixed on trunk. -- rwild at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.4 4.4.1 Known to work||4.5.0 Last reconfirmed|2009-09-16 17:46:56 |2009-09-19 08:33:14 date|| Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression] fixed |fixed includes not being|includes not being found if |found if building in src dir|building in src dir http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35619
[Bug bootstrap/41404] New: expr.c undefined reference while linking jc1
Bootstrap fails with: java/expr.o:expr.c:(.debug_loc+0x7d61): undefined reference to `LASF74' Configured tr...@151860 with: /gnu/gcc/gcc-unpatched/configure '--prefix=/opt/gcc-tools' '-v' '--with-gmp=/usr' '--with-mpfr=/usr' '--enable-bootstrap' '--enable-version-specific-runtime-libs' '--enable-static' '--enable-shared' '--enable-shared-libgcc' '--disable-__cxa_atexit' '--with-gnu-ld' '--with-gnu-as' '--with-dwarf2' '--disable-sjlj-exceptions' '--disable-symvers' '--enable-libjava' '--enable-interpreter' '--program-suffix=-4' '--enable-libgomp' '--enable-libssp' '--disable-libada' '--enable-threads=posix' '--with-arch=i686' '--with-tune=generic' 'CC=gcc-4' 'CXX=g++-4' 'CC_FOR_TARGET=gcc-4' 'CXX_FOR_TARGET=g++-4' '--with-ecj-jar=/usr/share/java/ecj.jar' 'LD=/opt/gcc-tools/bin/ld.exe' 'LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe' 'AS=/opt/gcc-tools/bin/as.exe' 'AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe' '--disable-win32-registry' '--disable-libgcj-debug' '--enable-languages=c,c++,java,objc,obj-c++' 21 | tee conf.log -- Summary: expr.c undefined reference while linking jc1 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davek at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-19 09:20 --- Unsurprisingly, adding -g0 to the build line results in an expr.o without the undefined reference. /gnu/gcc/obj.no.pr41357/./prev-gcc/xgcc -B/gnu/gcc/obj.no.pr41357/./prev-gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include-c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I ../gcc -Ijava -I/gnu/gcc/gcc-unpatched/gcc -I/gnu/gcc/gcc-unpatched/gcc/java -I/gnu/gcc/gcc-unpatched/gcc/../include -I/gnu/gcc/gcc-unpatched/gcc/../libcpp/include -I/usr/include -I/usr/include -I/gnu/gcc/gcc-unpatched/gcc/../libdecnumber -I/gnu/gcc/gcc-unpatched/gcc/../libdecnumber/dpd -I../libdecnumber /gnu/gcc/gcc-unpatched/gcc/java/expr.c -o java/expr.o --save-temps -g0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option
--- Comment #3 from davek at gcc dot gnu dot org 2009-09-19 09:21 --- (In reply to comment #2) Unsurprisingly, Oops, sorry, wrong PR! I was on the wrong browser tab. Apologies. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #1 from davek at gcc dot gnu dot org 2009-09-19 09:21 --- Unsurprisingly, adding -g0 to the build line results in an expr.o without the undefined reference. /gnu/gcc/obj.no.pr41357/./prev-gcc/xgcc -B/gnu/gcc/obj.no.pr41357/./prev-gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include-c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I ../gcc -Ijava -I/gnu/gcc/gcc-unpatched/gcc -I/gnu/gcc/gcc-unpatched/gcc/java -I/gnu/gcc/gcc-unpatched/gcc/../include -I/gnu/gcc/gcc-unpatched/gcc/../libcpp/include -I/usr/include -I/usr/include -I/gnu/gcc/gcc-unpatched/gcc/../libdecnumber -I/gnu/gcc/gcc-unpatched/gcc/../libdecnumber/dpd -I../libdecnumber /gnu/gcc/gcc-unpatched/gcc/java/expr.c -o java/expr.o --save-temps -g0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-19 09:33 ---
This is where the subsequently-undefined reference is being generated:
Will ignore next 72 crossings of breakpoint 1. Continuing.
Hardware watchpoint 1: {data variable, no debug info} 14169456
Old value = 73
New value = 74
0x004c5fe2 in mem_loc_descriptor ()
(gdb) bt
#0 0x004c5fe2 in mem_loc_descriptor ()
#1 0x004c6926 in loc_descriptor ()
#2 0x004c9e43 in add_location_or_const_value_attribute.clone.13 ()
#3 0x004caa5b in gen_variable_die ()
#4 0x004d250d in gen_decl_die ()
#5 0x004d726e in decls_for_scope ()
#6 0x004d3d05 in gen_subprogram_die ()
#7 0x004d27c0 in gen_decl_die ()
#8 0x0082586f in rest_of_handle_final ()
#9 0x00604685 in execute_one_pass ()
#10 0x006048ec in execute_pass_list ()
#11 0x006048ff in execute_pass_list ()
#12 0x006048ff in execute_pass_list ()
#13 0x007fbe60 in tree_rest_of_compilation ()
#14 0x0060774d in cgraph_expand_function ()
#15 0x00609861 in cgraph_finalize_compilation_unit ()
#16 0x0041f9db in c_write_global_declarations ()
#17 0x0063267c in toplev_main ()
#18 0x00496820 in main ()
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-19 09:43 --- Please attach preprocessed source. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot ||org, hubicka at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #4 from davek at gcc dot gnu dot org 2009-09-19 09:44 ---
Fortunately it even happens when using the stage1 compiler, which has usable
debug info:
(gdb) c 73
Will ignore next 72 crossings of breakpoint 1. Continuing.
Hardware watchpoint 1: dw2_string_counter
Old value = 73
New value = 74
gen_label_for_indirect_string (node=0x7ee82980)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:6849
6849 node-label = xstrdup (label);
(gdb) bt
#0 gen_label_for_indirect_string (node=0x7ee82980)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:6849
#1 0x007b00f3 in get_debug_string_label (str=0x7f15d578 goto)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:6862
#2 0x007b9d00 in mem_loc_descriptor (rtl=0x7f23f420, mode=VOIDmode,
initialized=VAR_INIT_STATUS_INITIALIZED)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:11610
#3 0x007ba7ba in loc_descriptor (rtl=0x7f23f420, mode=SImode,
initialized=VAR_INIT_STATUS_INITIALIZED)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:11968
#4 0x007ba0a5 in loc_descriptor (rtl=0x7ebdd810, mode=SImode,
initialized=VAR_INIT_STATUS_INITIALIZED)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:11742
#5 0x007bfd60 in add_location_or_const_value_attribute (die=0x7ef9fb58,
decl=0x7f004bc0, attr=DW_AT_location)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:13769
#6 0x007c7ea8 in gen_variable_die (decl=0x7f004bc0, origin=0x0,
context_die=0x7ef9c940) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:16129
#7 0x007ccb2b in gen_decl_die (decl=0x7f004bc0, origin=0x0,
context_die=0x7ef9c940) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:17388
#8 0x007cb12d in process_scope_var (stmt=0x7f01a020, decl=0x7f004bc0,
origin=0x0, context_die=0x7ef9c940)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:16990
#9 0x007cb1b0 in decls_for_scope (stmt=0x7f01a020, context_die=0x7ef9c940,
depth=0) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:17012
#10 0x007c6df5 in gen_subprogram_die (decl=0x7f6af500, context_die=0x7fcb3f00)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:15853
#11 0x007cc80f in gen_decl_die (decl=0x7f6af500, origin=0x0,
context_die=0x7fcb3f00) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:17323
#12 0x007cd881 in dwarf2out_decl (decl=0x7f6af500)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:17694
#13 0x013c68a5 in rest_of_handle_final ()
at /gnu/gcc/gcc-unpatched/gcc/final.c:4284
#14 0x00b9de10 in execute_one_pass (pass=0x24668e0)
at /gnu/gcc/gcc-unpatched/gcc/passes.c:1295
#15 0x00b9dfb0 in execute_pass_list (pass=0x24668e0)
at /gnu/gcc/gcc-unpatched/gcc/passes.c:1344
#16 0x00b9dfcc in execute_pass_list (pass=0x2464680)
at /gnu/gcc/gcc-unpatched/gcc/passes.c:1345
#17 0x00b9dfcc in execute_pass_list (pass=0x2464640)
at /gnu/gcc/gcc-unpatched/gcc/passes.c:1345
#18 0x012dfc0a in tree_rest_of_compilation (fndecl=0x7f6af500)
at /gnu/gcc/gcc-unpatched/gcc/tree-optimize.c:389
#19 0x00bbfccc in cgraph_expand_function (node=0x7f108b00)
at /gnu/gcc/gcc-unpatched/gcc/cgraphunit.c:1158
#20 0x00bbfe89 in cgraph_expand_all_functions ()
at /gnu/gcc/gcc-unpatched/gcc/cgraphunit.c:1217
#21 0x00bc0452 in cgraph_optimize ()
at /gnu/gcc/gcc-unpatched/gcc/cgraphunit.c:1440
#22 0x00bbf9a9 in cgraph_finalize_compilation_unit ()
at /gnu/gcc/gcc-unpatched/gcc/cgraphunit.c:1087
#23 0x00479c29 in c_write_global_declarations ()
at /gnu/gcc/gcc-unpatched/gcc/c-decl.c:9361
#24 0x00db0ca4 in compile_file () at /gnu/gcc/gcc-unpatched/gcc/toplev.c:1050
#25 0x00db2cbe in do_compile () at /gnu/gcc/gcc-unpatched/gcc/toplev.c:2382
#26 0x00db2d8c in toplev_main (argc=32, argv=0x8079df0)
at /gnu/gcc/gcc-unpatched/gcc/toplev.c:2424
#27 0x006281ed in main (argc=32, argv=0x8079df0)
at /gnu/gcc/gcc-unpatched/gcc/main.c:35
(gdb)
(gdb) print node[0]
$1 = {str = 0x7f23fe18 goto, refcount = 1, form = 0, label = 0x0}
(gdb)
(gdb) up
#1 0x007b00f3 in get_debug_string_label (str=0x7f15d578 goto)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:6862
6862 gen_label_for_indirect_string (node);
(gdb) up
#2 0x007b9d00 in mem_loc_descriptor (rtl=0x7f23f420, mode=VOIDmode,
initialized=VAR_INIT_STATUS_INITIALIZED)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:11610
11610 rtl = get_debug_string_label (XSTR (rtl, 0));
(gdb) call debug_rtx (rtl)
(const_string:SI (goto))
(gdb)
That's a touch odd.
ad...@ubik /gnu/gcc/gcc/gcc
$ grep -w goto java/expr.c
goto fail;
ad...@ubik /gnu/gcc/gcc/gcc
$
goto fail indeed. Why would a keyword end up as a debug info string?
(preprocessed source on the way)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug middle-end/41398] can't resolve .LFE1408 {*UND* section} - .Ltext0 {.text section}
--- Comment #5 from jakub at gcc dot gnu dot org 2009-09-19 09:48 --- Please try http://gcc.gnu.org/viewcvs?root=gccview=revrev=151753 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41398
[Bug bootstrap/41405] New: [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
Bootstrap fails at revision 151873 on *-apple-darwin9 with ... checking for long long... yes checking size of long long... configure: error: in `/opt/gcc/darwin_buildw/gcc': configure: error: cannot compute sizeof (long long) See `config.log' for more details. make[2]: *** [configure-stage3-gcc] Error 77 make[1]: *** [stage3-bubble] Error 2 make: *** [all] Error 2 Looking at the config.log files I see: configure:5754: /opt/gcc/i686-darwin/./prev-gcc/xgcc -B/opt/gcc/i686-darwin/./prev-gcc/ -B/opt/gcc/gcc4.5w/i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w /i686-apple-darwin9/bin/ -B/opt/gcc/gcc4.5w/i686-apple-darwin9/lib/ -isystem /opt/gcc/gcc4.5w/i686-apple-darwin9/include -isystem /opt/gcc/gcc4.5w/i68 6-apple-darwin9/sys-include-o conftest -g -O2 -fomit-frame-pointer conftest.c 5 Assertion failed: (!Unknown one-operand), function LinkLocation, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 157 1. xgcc: Internal error: Abort trap (program dsymutil) Last successful builds: 151801 on i686-apple-darwin9 (see http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01688.html) and 151771 on powerpc-apple-darwin9 (see http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01689.html). This PR may be a duplicate of pr41395, but the symptoms are different along with the revision numbers. See also http://gcc.gnu.org/ml/gcc-regression/2009-09/msg00190.html for a possible culprit. -- Summary: [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: *-apple-darwin9 GCC host triplet: *-apple-darwin9 GCC target triplet: *-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #5 from davek at gcc dot gnu dot org 2009-09-19 09:49 --- Created an attachment (id=18606) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18606action=view) unreduced preprocessed source. compile this with: /gnu/gcc/obj.no.pr41357/./stage1-gcc/cc1.exe -fpreprocessed expr.i -quiet -dumpbase expr.c -mtune=generic -march=i686 -auxbase-strip java/expr.o -g -O2 -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -version -fno-common -o expr.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #6 from davek at gcc dot gnu dot org 2009-09-19 09:56 --- heh, it's my old friend add_location_or_const_value_attribute() from pr41357 (gdb) up #5 0x007bfd60 in add_location_or_const_value_attribute (die=0x7ef9fb58, decl=0x7f004bc0, attr=DW_AT_location) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:13769 13769 descr = loc_by_reference (loc_descriptor (varloc, DECL_MODE(decl), (gdb) print decl $2 = (tree) 0x7f004bc0 (gdb) call debug_tree (decl) var_decl 0x7f004bc0 opname type pointer_type 0x7fc63560 type integer_type 0x7fc634f0 char readonly sizes-gimplified public string-flag QI size integer_cst 0x7fef03c0 constant 8 unit size integer_cst 0x7fef03e0 constant 1 align 8 symtab 2144046360 alias set -1 canonical type 0x7fc634f0 precision 8 min integer_cst 0x7fef0380 -128 max integer_cst 0x7fef0460 127 pointer_to_this pointer_type 0x7fc63560 sizes-gimplified asm_written public unsigned SI size integer_cst 0x7fef0580 constant 32 unit size integer_cst 0x7fef0320 constant 4 align 32 symtab 2144046304 alias set -1 canonical type 0x7fc63560 pointer_to_this pointer_type 0x7fc63aa0 unsigned SI file /gnu/gcc/gcc-unpatched/gcc/java/expr.c line 3304 col 15 size integer_cst 0x7fef0580 32 unit size integer_cst 0x7fef0320 4 align 32 context function_decl 0x7f6af500 process_jvm_instruction chain var_decl 0x7f004c20 oldpc (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #7 from davek at gcc dot gnu dot org 2009-09-19 10:44 --- Was off-by-one on the rtx, it's actually ret not goto. The refcount of the indirect_string_node goes to zero here, in prune_unused_types_walk_attribs(): (gdb) c Continuing. Hardware watchpoint 5: ((struct indirect_string_node *) 2123651344)-refcount Old value = 2 New value = 0 prune_unused_types_walk_attribs (die=0x7eec09d8) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18314 18314 for (ix = 0; VEC_iterate (dw_attr_node, die-die_attr, ix, a); ix++) (gdb) bt #0 prune_unused_types_walk_attribs (die=0x7eec09d8) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18314 #1 0x007cf108 in prune_unused_types_walk (die=0x7eec09d8) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18472 #2 0x007cf135 in prune_unused_types_walk (die=0x7eec0690) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18478 #3 0x007cf135 in prune_unused_types_walk (die=0x7fcb3f00) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18478 #4 0x007cf38c in prune_unused_types () at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18579 #5 0x007cfc45 in dwarf2out_finish ( filename=0x80b5288 /gnu/gcc/gcc-unpatched/gcc/java/expr.c) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18758 #6 0x00db0d32 in compile_file () at /gnu/gcc/gcc-unpatched/gcc/toplev.c:1080 #7 0x00db2cbe in do_compile () at /gnu/gcc/gcc-unpatched/gcc/toplev.c:2382 #8 0x00db2d8c in toplev_main (argc=30, argv=0x8079df0) at /gnu/gcc/gcc-unpatched/gcc/toplev.c:2424 #9 0x006281ed in main (argc=30, argv=0x8079df0) at /gnu/gcc/gcc-unpatched/gcc/main.c:35 (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #8 from jakub at gcc dot gnu dot org 2009-09-19 10:50 --- The ret string is shared between some attribute and a value from CONST_STRING. But prune_unused_types_walk_attribs resets the count to 0: /* Set the string's refcount to 0 so that prune_unused_types_mark accounts properly for it. */ if (AT_class (a) == dw_val_class_str) a-dw_attr_val.v.val_str-refcount = 0; and while attributes are walked, location lists are not and thus nothing notices it is still used. I'll have to read the prune_unused_types stuff carefully to understand how this can be fixed, ideally if we could just decrement refcount in prune_unused_types_walk_attribs, as long as we are sure it is walked for all attributes, it could fix this. Alternatively we'd have to walk all location lists as well, looking for labels for strings. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #9 from davek at gcc dot gnu dot org 2009-09-19 10:56 ---
(In reply to comment #8)
The ret string is shared between some attribute and a value from
CONST_STRING.
Sorry, as I just figured out I was off by one on that:
(gdb) fin
Run till exit from #0 gen_label_for_indirect_string (node=0x7e945910)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:6849
get_debug_string_label (str=0x7f15e0b8 ret)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:6864
6864 return gen_rtx_SYMBOL_REF (Pmode, node-label);
(gdb) print ((struct indirect_string_node *) 0x7e945910)[0]
$5 = {str = 0x7ff2f498 ret, refcount = 2, form = 0,
label = 0x8284dc0 *LASF74}
(gdb)
But prune_unused_types_walk_attribs resets the count to 0:
/* Set the string's refcount to 0 so that prune_unused_types_mark
accounts properly for it. */
if (AT_class (a) == dw_val_class_str)
a-dw_attr_val.v.val_str-refcount = 0;
and while attributes are walked, location lists are not and thus nothing
notices it is still used. I'll have to read the prune_unused_types stuff
carefully to understand how this can be fixed, ideally if we could just
decrement refcount in prune_unused_types_walk_attribs, as long as we are sure
it is walked for all attributes, it could fix this. Alternatively we'd have
to
walk all location lists as well, looking for labels for strings.
But we're looking at the same suspect here anyway :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #10 from jakub at gcc dot gnu dot org 2009-09-19 11:04 --- Actually, I think it is wrong how mem_loc_descriptor handles CONST_STRING, I'm afraid we can't do anything for it, unless we can find such string in the rodata section of the compilation unit. .byte 0x3 # DW_OP_addr .long .LASF74 .byte 0x9f # DW_OP_stack_value .byte 0x93 # DW_OP_piece .byte 0x4 # uleb128 0x4 doesn't look right, .LASF74 is a label in .debug_str section, which isn't allocated, so I wonder what will the debugger do with that anyway. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #11 from davek at gcc dot gnu dot org 2009-09-19 11:17 --- (In reply to comment #10) Actually, I think it is wrong how mem_loc_descriptor handles CONST_STRING, I'm afraid we can't do anything for it, unless we can find such string in the rodata section of the compilation unit. So rather than write code to index and search all the strings emitted during compilation, I'm giving this a try: Index: dwarf2out.c === --- dwarf2out.c (revision 151860) +++ dwarf2out.c (working copy) @@ -11598,8 +11598,8 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mod break; case CONST_STRING: - rtl = get_debug_string_label (XSTR (rtl, 0)); - goto symref; + /* These can't easily be tracked, see PR41404. */ + break; default: #ifdef ENABLE_CHECKING As might be expected, there is no longer an undefined reference to any debuginfo string in the generated source after this. Shall I take it for a full bootstrap and test? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #12 from davek at gcc dot gnu dot org 2009-09-19 11:34 --- (In reply to comment #10) we can't do anything for it, unless we can find such string in the rodata section of the compilation unit. .LASF74 is a label in .debug_str section, which isn't allocated, so I wonder what will the debugger do with that anyway. I don't actually understand this (yet), as I don't know why the debugger would need the debug info to be loaded into the inferior's memory; it's not like the .debug_loc section gets allocated either. However I'm perfectly able to go ahead and test a patch without fully understanding that :) if you think just giving up on tracking string values is the way to go. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug fortran/31447] set intent(out) arguments to uninitialized
--- Comment #3 from jv244 at cam dot ac dot uk 2009-09-19 11:37 --- I've also run into this issue, it would be great if there would be a flag like -finit-undefined-intentout (?), so that intent(out) variable would first be undefined by the compiler (in a way that valgrind notices this with memcheck). This is easy to do on the source level (see below), so I would hope this is possible as well in the FE. The example would be: MODULE test CONTAINS SUBROUTINE S1(a) INTEGER, DIMENSION(:,:), INTENT(OUT) :: a ! FE generated code INTEGER :: uninitialized_a_type_dummy a=RESHAPE((/(TRANSFER(uninitialized_a_type_dummy,uninitialized_a_type_dummy),i=1,SIZE(a))/),SHAPE(a)) ! rest of the procedure END SUBROUTINE END MODULE test USE test INTEGER :: a(3,3) a=0 CALL S1(a) write(6,*) a IF(ANY(a.NE.0)) WRITE(6,*) No problem END In this way, valgrind does produce a warning when a is being written after the call to S1. The above example works also for derived types with default initializers and similar. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31447
[Bug libstdc++/38923] symbol versioning disabled due to non-portable sed script
-- rwild at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rwild at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-19 11:38:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
[Bug c/41406] New: internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156
x86_64-w64-mingw32-gcc -DHAVE_AV_CONFIG_H -I. -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -std=c99 -Wall -O3 -floop-strip-mine -MMD -MF libavutil/aes.d -MT libavutil/aes.o -save-temps -c -o libavutil/aes.o libavutil/aes.c libavutil/aes.c: In function 'subshift': libavutil/aes.c:56:24: warning: initialization from incompatible pointer type libavutil/aes.c:57:24: warning: initialization from incompatible pointer type libavutil/aes.c: In function 'crypt': libavutil/aes.c:84:9: warning: passing argument 2 of 'mix' from incompatible pointer type libavutil/aes.c:73:20: note: expected 'uint32_t (*)[256]' but argument is of type 'const uint32_t *' libavutil/aes.c:85:9: warning: passing argument 1 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'uint64_t *' but argument is of type 'uint8_t (*)[4]' libavutil/aes.c:85:9: warning: passing argument 2 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'const uint64_t *' but argument is of type 'uint8_t (*)[4]' libavutil/aes.c:85:9: warning: passing argument 3 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'const uint64_t *' but argument is of type 'uint8_t (*)[4]' libavutil/aes.c:87:5: warning: passing argument 1 of 'subshift' from incompatible pointer type libavutil/aes.c:55:13: note: expected 'uint8_t (*)[16]' but argument is of type 'uint8_t *' libavutil/aes.c: In function 'av_aes_crypt': libavutil/aes.c:92:9: warning: passing argument 1 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'uint64_t *' but argument is of type 'uint8_t (*)[4]' libavutil/aes.c:92:9: warning: passing argument 2 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'const uint64_t *' but argument is of type 'const uint8_t *' libavutil/aes.c:92:9: warning: passing argument 3 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'const uint64_t *' but argument is of type 'uint8_t (*)[4]' libavutil/aes.c:94:13: warning: passing argument 4 of 'crypt' from incompatible pointer type libavutil/aes.c:80:20: note: expected 'const uint32_t *' but argument is of type 'uint32_t (*)[256]' libavutil/aes.c:96:17: warning: passing argument 1 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'uint64_t *' but argument is of type 'uint8_t (*)[4]' libavutil/aes.c:96:17: warning: passing argument 2 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'const uint64_t *' but argument is of type 'uint8_t (*)[4]' libavutil/aes.c:96:17: warning: passing argument 3 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'const uint64_t *' but argument is of type 'uint8_t *' libavutil/aes.c:99:13: warning: passing argument 1 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'uint64_t *' but argument is of type 'uint8_t *' libavutil/aes.c:99:13: warning: passing argument 2 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'const uint64_t *' but argument is of type 'uint8_t (*)[4]' libavutil/aes.c:99:13: warning: passing argument 3 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'const uint64_t *' but argument is of type 'uint8_t (*)[4]' libavutil/aes.c:101:13: warning: passing argument 1 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'uint64_t *' but argument is of type 'uint8_t (*)[4]' libavutil/aes.c:101:13: warning: passing argument 2 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'const uint64_t *' but argument is of type 'uint8_t (*)[4]' libavutil/aes.c:101:13: warning: passing argument 3 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'const uint64_t *' but argument is of type 'uint8_t *' libavutil/aes.c:102:13: warning: passing argument 4 of 'crypt' from incompatible pointer type libavutil/aes.c:80:20: note: expected 'const uint32_t *' but argument is of type 'uint32_t (*)[256]' libavutil/aes.c:103:13: warning: passing argument 1 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'uint64_t *' but argument is of type 'uint8_t *' libavutil/aes.c:103:13: warning: passing argument 2 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'const uint64_t *' but argument is of type 'uint8_t (*)[4]' libavutil/aes.c:103:13: warning: passing argument 3 of 'addkey' from incompatible pointer type libavutil/aes.c:50:20: note: expected 'const uint64_t *' but argument is of type 'uint8_t (*)[4]' libavutil/aes.c: In function 'av_aes_init': libavutil/aes.c:149:9: warning: passing argument 1 of 'init_multbl2' from incompatible pointer type libavutil/aes.c:111:13: note: expected 'uint8_t *' but argument is of type 'uint32_t *' libavutil/aes.c:150:9: warning: passing argument 1 of
[Bug c/41406] internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156
--- Comment #1 from t7 at gmail dot com 2009-09-19 11:55 --- Created an attachment (id=18607) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18607action=view) Preprocessed test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41406
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #13 from jakub at gcc dot gnu dot org 2009-09-19 12:12 ---
Consider:
__attribute__((noinline))
int bar (void)
{
const char *foo = foo;
asm volatile (nop : : : memory);
foo = bar;
asm volatile (nop : : : memory);
return 16;
}
int main (void)
{
bar ();
return 0;
}
-g -O2 we get:
.LLST1:
.quad .LVL0-.Ltext0 # Location list begin address (*.LLST1)
.quad .LVL1-.Ltext0 # Location list end address (*.LLST1)
.value 0xc # Location expression size
.byte 0x3 # DW_OP_addr
.quad .LASF0
.byte 0x9f# DW_OP_stack_value
.byte 0x93# DW_OP_piece
.uleb128 0x8
.quad .LVL1-.Ltext0 # Location list begin address (*.LLST1)
.quad .LFE0-.Ltext0 # Location list end address (*.LLST1)
.value 0xc # Location expression size
.byte 0x3 # DW_OP_addr
.quad .LASF1
.byte 0x9f# DW_OP_stack_value
.byte 0x93# DW_OP_piece
.uleb128 0x8
.quad 0x0 # Location list terminator begin (*.LLST1)
.quad 0x0 # Location list terminator end (*.LLST1)
gdb ./test
b bar
r
(gdb) p foo
$1 = 0x42 Address 0x42 out of bounds
(gdb) n
7 asm volatile (nop : : : memory);
(gdb) p foo
$2 = 0x24 Address 0x24 out of bounds
which isn't surprising, for all other references to .debug_str we want a
relative offset into the section from the start of .debug_str section.
Contents of section .debug_str:
474e5520 4320342e 352e3020 32303039 GNU C 4.5.0 2009
0010 30393136 20286578 70657269 6d656e74 0916 (experiment
0020 616c2900 62617200 6d61696e 002f7573 al).bar.main./us
0030 722f7372 632f6763 632f6f62 6a2f6763 r/src/gcc/obj/gc
0040 6300666f 6f006368 617200 c.foo.char.
BTW, if the foo = bar; line is commented out, we have:
.uleb128 0x3# (DIE (0x51) DW_TAG_variable)
.ascii foo\0 # DW_AT_name
.byte 0x1 # DW_AT_decl_file (t.c)
.byte 0x4 # DW_AT_decl_line
.long 0x68# DW_AT_type
.ascii foo\0 # DW_AT_const_value
and gdb still won't do the right thing, but again it is IMHO gcc's fault:
(gdb) p foo
$1 = 0x504046f6f66 Address 0x504046f6f66 out of bounds
the value of the variable isn't the const string, but an address of it...
Now, if const char *foo = foo; is changed into const char foo[] = foo;
(in which case using DW_AT_const_value foo\0 would probably be the right
thing), then current trunk will drop the location for the variable on the
floor.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||jan dot kratochvil at redhat
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #14 from davek at gcc dot gnu dot org 2009-09-19 12:32 --- (In reply to comment #13) Thanks for taking the time to explain that. I think the implication of what you're saying is that we can in fact handle strings and just giving up on them is too severe, but we need to decide somewhere a bit further up the call stack whether to use the string itself or the address-of the string as the value in the location table, based on the type of the var_decl; is that about right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41348] Bootstrap fails with --with-arch=i686
--- Comment #2 from aanisimov at inbox dot ru 2009-09-19 12:32 --- that one is expected and doesn't fail the build. What's the output after that? Indeed, I've messed up a bit last time. Rev. 151361 builds fine, but with rev. 151362 I get Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! gcc/cfgloopmanip.o differs libiberty/pic/make-temp-file.o differs libiberty/make-temp-file.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/artem/testing/gcc-build' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/artem/testing/gcc-build' make: *** [all] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41348
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #15 from davek at gcc dot gnu dot org 2009-09-19 13:13 --- (In reply to comment #14) (In reply to comment #13) Thanks for taking the time to explain that. I think the implication of what you're saying is that we can in fact handle strings and just giving up on them is too severe, but we need to decide somewhere a bit further up the call stack whether to use the string itself or the address-of the string as the value in the location table, based on the type of the var_decl; is that about right? Hmm, maybe not; maybe we should be generating the location notes differently in the first place. (gdb) print varloc $3 = (rtx) 0x7ebdd9b0 (gdb) call debug_rtx(varloc) (var_location opname (expr_list:REG_DEP_TRUE (const_string:SI (ret)) (const_int 0 [0x0]))) (gdb) If that note held the address of the ret string constant we'd be ok. But I'm not sure if we can get that when we need it, the label we'd need to sym_ref probably doesn't exist until we actually emit the string pool. So maybe punting on strings is the best we can do after all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug middle-end/41407] New: Bootstrap fails with ICE on i686
Building rev. 151881 fails with ../../../gcc/libgcc/../gcc/libgcc2.c: In function __powisf2: ../../../gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in convert_regs_1, at reg-stack.c:3052 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [_powisf2.o] Erreur 1 make[3]: quittant le répertoire « /home/artem/testing/gcc-build/i486-slackware-linux/libgcc » make[2]: *** [all-stage2-target-libgcc] Erreur 2 make[2]: quittant le répertoire « /home/artem/testing/gcc-build » make[1]: *** [stage2-bubble] Erreur 2 make[1]: quittant le répertoire « /home/artem/testing/gcc-build » make: *** [all] Erreur 2 I passed the following options to configure: ../gcc/configure --prefix=/tmp/gcc45 --enable-shared --enable-bootstrap --enable-languages=c,c++ --enable-threads=posix --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose --with-arch=i686 --target=i486-slackware-linux --build=i486-slackware-linux --host=i486-slackware-linux -- Summary: Bootstrap fails with ICE on i686 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aanisimov at inbox dot ru GCC build triplet: i486-slackware-linux GCC host triplet: i486-slackware-linux GCC target triplet: i486-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41407
[Bug fortran/41408] New: Segmentation fault calling DGETRF from gfortran
I get a segmentation fault while calling LAPACK function DGETRF. The same program works the way it is supposed to (ie runs without error and gives the expected output) using either g95 or Sun Studio. I am running 32-bit Ubuntu 9.04. I've confirmed the error on a Slackware 12.1 box as well, and also in the latest development release (downloaded from the link on the gfortran wiki). $ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --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-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) A code sample that will replicate the bug is program det_test implicit none integer, parameter :: p15=selected_real_kind(15) real(p15) :: A(2,2) integer :: info A(1,1) = 1.0 A(1,2) = 0.0 A(2,1) = 3.0 A(2,2) = 0.5 info = 1 call DGETRF(2,2,A,2,2,info) write(*,*) A(1,1) write(*,*) A(1,2) write(*,*) A(2,1) write(*,*) A(2,2) end program det_test I saved the file as 'dettest.f95' and compiled using gfortran -save-temps dettest.f95 -o dettest -L/usr/lib -llapack -lblas The compiler gave no output. Running the executable, the only output is Segmentation Fault. dettest.s file output: .file dettest.f95 .section.rodata .align 4 .type options.0.543, @object .size options.0.543, 28 options.0.543: .long 68 .long 127 .long 0 .long 0 .long 0 .long 1 .long 0 .align 4 .LC4: .long 2 .LC5: .string dettest.f95 .text .globl MAIN__ .type MAIN__, @function MAIN__: pushl %ebp movl%esp, %ebp subl$344, %esp movl$options.0.543, 4(%esp) movl$7, (%esp) call_gfortran_set_options fld1 fstpl -40(%ebp) fldz fstpl -24(%ebp) fldl.LC2 fstpl -32(%ebp) fldl.LC3 fstpl -16(%ebp) movl$1, -4(%ebp) leal-4(%ebp), %eax movl%eax, 20(%esp) movl$.LC4, 16(%esp) movl$.LC4, 12(%esp) leal-40(%ebp), %eax movl%eax, 8(%esp) movl$.LC4, 4(%esp) movl$.LC4, (%esp) calldgetrf_ movl$.LC5, -308(%ebp) movl$12, -304(%ebp) movl$128, -316(%ebp) movl$6, -312(%ebp) leal-316(%ebp), %eax movl%eax, (%esp) call_gfortran_st_write movl$8, 8(%esp) leal-40(%ebp), %eax movl%eax, 4(%esp) leal-316(%ebp), %eax movl%eax, (%esp) call_gfortran_transfer_real leal-316(%ebp), %eax movl%eax, (%esp) call_gfortran_st_write_done movl$.LC5, -308(%ebp) movl$13, -304(%ebp) movl$128, -316(%ebp) movl$6, -312(%ebp) leal-316(%ebp), %eax movl%eax, (%esp) call_gfortran_st_write movl$8, 8(%esp) leal-40(%ebp), %eax addl$16, %eax movl%eax, 4(%esp) leal-316(%ebp), %eax movl%eax, (%esp) call_gfortran_transfer_real leal-316(%ebp), %eax movl%eax, (%esp) call_gfortran_st_write_done movl$.LC5, -308(%ebp) movl$14, -304(%ebp) movl$128, -316(%ebp) movl$6, -312(%ebp) leal-316(%ebp), %eax movl%eax, (%esp) call_gfortran_st_write movl$8, 8(%esp) leal-40(%ebp), %eax addl$8, %eax movl%eax, 4(%esp) leal-316(%ebp), %eax movl%eax, (%esp) call_gfortran_transfer_real leal-316(%ebp), %eax movl%eax, (%esp) call_gfortran_st_write_done movl$.LC5, -308(%ebp) movl$15, -304(%ebp) movl$128, -316(%ebp) movl$6, -312(%ebp) leal-316(%ebp), %eax movl%eax, (%esp) call_gfortran_st_write movl$8, 8(%esp) leal-40(%ebp), %eax addl$24, %eax movl%eax, 4(%esp) leal-316(%ebp), %eax movl%eax, (%esp) call_gfortran_transfer_real leal-316(%ebp), %eax movl%eax, (%esp) call_gfortran_st_write_done leave ret
[Bug middle-end/41409] New: Bootstrap fails with ICE on i686
Building rev. 151881 fails with ../../../gcc/libgcc/../gcc/libgcc2.c: In function __powisf2: ../../../gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in convert_regs_1, at reg-stack.c:3052 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [_powisf2.o] Erreur 1 make[3]: quittant le répertoire « /home/artem/testing/gcc-build/i486-slackware-linux/libgcc » make[2]: *** [all-stage2-target-libgcc] Erreur 2 make[2]: quittant le répertoire « /home/artem/testing/gcc-build » make[1]: *** [stage2-bubble] Erreur 2 make[1]: quittant le répertoire « /home/artem/testing/gcc-build » make: *** [all] Erreur 2 I passed the following options to configure: ../gcc/configure --prefix=/tmp/gcc45 --enable-shared --enable-bootstrap --enable-languages=c,c++ --enable-threads=posix --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose --with-arch=i686 --target=i486-slackware-linux --build=i486-slackware-linux --host=i486-slackware-linux -- Summary: Bootstrap fails with ICE on i686 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aanisimov at inbox dot ru GCC build triplet: i486-slackware-linux GCC host triplet: i486-slackware-linux GCC target triplet: i486-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41409
[Bug fortran/41408] Segmentation fault calling DGETRF from gfortran
--- Comment #1 from dominiq at lps dot ens dot fr 2009-09-19 14:01 --- Have a look at http://linux.die.net/man/l/dgetrf for the calling convention. The following works for me: program det_test implicit none integer, parameter :: p15=selected_real_kind(15) integer :: ipiv(2) real(p15) :: A(2,2) integer :: info A(1,1) = 1.0 A(1,2) = 0.0 A(2,1) = 3.0 A(2,2) = 0.5 info = 1 call DGETRF(2,2,A,2,ipiv,info) write(*,*) A(1,1) write(*,*) A(1,2) write(*,*) A(2,1) write(*,*) A(2,2) end program det_test [ibook-dhum] bug/timing% gfc pr41408_db.f90 -Wl,-framework -Wl,vecLib [ibook-dhum] bug/timing% a.out 3. 0.5 0.1 -0.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41408
[Bug target/41211] internal compiler error when using x86_64-w64-mingw32-gcc to build sqlite3 alter.c
--- Comment #9 from ktietz at gcc dot gnu dot org 2009-09-19 14:32 --- (In reply to comment #7) I recompile the whole toolchain using today's newest code, the same result, cross compiler runs fine, native compiler runs crash. I retested your example with current trunk as native compiler, and I had no ICE on compile. I've used current runtime headers, binutils, and trunk version of gcc with the patch for xmm register restore pending at the moment on gcc's ML. The libaries gmp and mpfr I build in tree of gcc's source root. Sorry, I can't reproduce this ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41211
[Bug fortran/41408] Segmentation fault calling DGETRF from gfortran
--- Comment #2 from lanceb at k-state dot edu 2009-09-19 14:48 --- Subject: Re: Segmentation fault calling DGETRF from gfortran Well, that's an embarrassing mistake. My apologies. For some reason the example code does run correctly for G95. In my (much larger) program I do call DGETRF correctly, and get a segmentation fault when using gfortran but not G95. I will continue to look at it. Obviously I have not isolated the problem. Sorry for the trouble. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41408
[Bug fortran/41408] Segmentation fault calling DGETRF from gfortran
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-09-19 15:01 --- Lets keep this bug open while you are hunting so we don't forget. Waiting -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41408
[Bug middle-end/41398] can't resolve .LFE1408 {*UND* section} - .Ltext0 {.text section}
--- Comment #6 from pluto at agmk dot net 2009-09-19 15:52 --- current head of 4.4 branch is fixed by r150797. -- pluto at agmk dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41398
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #11 from hjl dot tools at gmail dot com 2009-09-19 15:58 --- *** Bug 41409 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||aanisimov at inbox dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug middle-end/41409] Bootstrap fails with ICE on i686
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-19 15:58 --- *** This bug has been marked as a duplicate of 41395 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41409
[Bug middle-end/41407] Bootstrap fails with ICE on i686
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-19 15:59 --- *** This bug has been marked as a duplicate of 41395 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41407
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #12 from hjl dot tools at gmail dot com 2009-09-19 15:59 --- *** Bug 41407 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #16 from hubicka at ucw dot cz 2009-09-19 16:10 --- Subject: Re: expr.c undefined reference while linking jc1 Actually, I think it is wrong how mem_loc_descriptor handles CONST_STRING, I'm afraid we can't do anything for it, unless we can find such string in the rodata section of the compilation unit. Patch I sent to improve tree_loc code also has code to lookup constants in constant pool. For strings in particular this has pretty good chance of success. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug target/41156] [4.4/4.5 Regression] zlib segfault in inflate_table() compiled w/ -O -msse2 ftree-vectorize
--- Comment #9 from mahatma at eu dot by 2009-09-19 16:12 --- Created an attachment (id=18608) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18608action=view) sse 32bit - -mstackrealign (example only!) Previous my ideas too heavy. :) IMHO native solution for this problem is -mstackrealign. It solving problems with known to me packages (including zlib). I trying to make STACK_REALIGN_DEFAULT related from TARGET_SSE !TARGET_64BIT (see patch). But got internal compiler error on gcc self-compiling with -march=pentium4. Without sse (=without -mstackrealign) self-compiling works. Why -mstackrealign may be bad and why gcc dont' self-compiling so? Error: === /var/tmp/portage/sys-devel/gcc-4.4.1/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.4.1/work/build/./gcc/ -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -g -mtune=pentium4 -march=pentium4 -pipe -w -O2 -O2 -g -mtune=pentium4 -march=pentium4 -pipe -w -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I/var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc -I/var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/. -I/var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/../gcc -I/var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/../include -I/var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o unwind-c.o -MT unwind-c.o -MD -MP -MF unwind-c.dep -fexceptions -c /var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/../gcc/unwind-c.c -fvisibility=hidden -DHIDE_EXPORTS In file included from /var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/../gcc/unwind-dw2.c:1555: /var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/../gcc/unwind.inc: In function '_Unwind_ForcedUnwind': /var/tmp/portage/sys-devel/gcc-4.4.1/work/gcc-4.4.1/libgcc/../gcc/unwind.inc:212: internal compiler error: in ix86_expand_epilogue, at config/i386/i386.c:8570 === -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41156
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #17 from davek at gcc dot gnu dot org 2009-09-19 16:25 --- (In reply to comment #16) Patch I sent to improve tree_loc code also has code to lookup constants in constant pool. For strings in particular this has pretty good chance of success. I see you wrote: There was latent bug in that code causing undefined references to constant pool values that was optimized out. This is fixed now. That sounds like this bug! I'll test your patches against my tree, thanks for the help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug middle-end/41260] [4.5 Regression] major regressions on *-apple-darwin10 at -m64 caused by r147995
--- Comment #38 from howarth at nitro dot med dot uc dot edu 2009-09-19 16:31 --- The solution we want to implement is described below... --- I dug into this. Based on the .s files in bugzilla, the latest gcc is now adding dwarf unwind info to describe the function epilog. If you run dwarfdump --eh-frame on the .o files made with the new compiler, you'll see extra dwarf unwind instructions at the end like: ... DW_CFA_advance_loc4 (64) #-- advance to near end of function DW_CFA_restore (rbp) DW_CFA_def_cfa (rsp, 8) DW_CFA_nop DW_CFA_nop The linker's conversion to compact unwind runs the dwarf unwind info for a function and then records the state at the end. Adding unwind info for the epilog breaks this. In the long term, I can add heuristics to the linker to detect that what looks like unwind info for the epilog and stop processing the dwarf instructions. The short term fix for gcc is to *not* add epilog unwind information for Darwin. Epilog unwind information is never needed for exception processing. Its only use is for debugging or sampling when you want to asynchronously make a stack back trace. -Nick -- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260
[Bug rtl-optimization/40987] Wrong optimization with if-conversion
--- Comment #9 from mikpe at it dot uu dot se 2009-09-19 16:57 ---
Seems like an if-conversion bug, in particular noce_try_store_flag_constants()
appears to break on HWI32 platforms when long long literals are involved.
In this test case, noce_t_s_f_c() is invoked with an IF where a (the false
value) and b (the true value) are both DImode CONST_INTs. a is zero. b is
stored as 0x8000, which is truncated but sign-extends to the correct value.
noce_t_s_f_c() then computes a subtraction and some log2() on these truncated
values, and selects the second code generation template x = (test != 0)
3;.
The code becomes (from the ce1 dump file):
(insn 27 8 28 2 pr40987.c:4 (parallel [
(set (reg:DI 62)
(sign_extend:DI (reg/v:SI 60 [ arg ])))
(clobber (reg:CC 17 flags))
(clobber (scratch:SI))
]) 90 {*extendsidi2_1} (nil))
(insn 28 27 29 2 pr40987.c:4 (parallel [
(set (reg/v:DI 58 [ val ])
(lshiftrt:DI (reg:DI 62)
(const_int 63 [0x3f])))
(clobber (reg:CC 17 flags))
]) 394 {*lshrdi3_1} (nil))
# since this is a logical downshift, it produces 0 or 1 from the sign bit
(insn 29 28 17 2 pr40987.c:4 (parallel [
(set (reg/v:DI 58 [ val ])
(ashift:DI (reg/v:DI 58 [ val ])
(const_int 31 [0x1f])))
(clobber (reg:CC 17 flags))
]) 356 {*ashldi3_1} (nil))
# which is shifted up to produce 0 or 0x8000, the high 32 bits are lost
All gcc-4.x releases have this bug. It does not trigger in gcc-3.4.6. There it
seems that the true/false values are swapped compared to 4.x, and a test near
the top of noce_t_s_f_c() causes it to bail out and not perform the conversion.
(The test looks the same in 4.x, but the IF-operands are swapped so it does not
bail.)
I don't know if this code can be fixed to handle longer-than-HWI literals. The
simplest solution might be to just detect the situation and bail out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40987
[Bug middle-end/41410] New: Bootstrap fails with ICE on i686
Building rev. 151881 fails with ../../../gcc/libgcc/../gcc/libgcc2.c: In function __powisf2: ../../../gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in convert_regs_1, at reg-stack.c:3052 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [_powisf2.o] Erreur 1 make[3]: quittant le répertoire « /home/artem/testing/gcc-build/i486-slackware-linux/libgcc » make[2]: *** [all-stage2-target-libgcc] Erreur 2 make[2]: quittant le répertoire « /home/artem/testing/gcc-build » make[1]: *** [stage2-bubble] Erreur 2 make[1]: quittant le répertoire « /home/artem/testing/gcc-build » make: *** [all] Erreur 2 I passed the following options to configure: ../gcc/configure --prefix=/tmp/gcc45 --enable-shared --enable-bootstrap --enable-languages=c,c++ --enable-threads=posix --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose --with-arch=i686 --target=i486-slackware-linux --build=i486-slackware-linux --host=i486-slackware-linux -- Summary: Bootstrap fails with ICE on i686 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aanisimov at inbox dot ru GCC build triplet: i486-slackware-linux GCC host triplet: i486-slackware-linux GCC target triplet: i486-slackware-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41410
[Bug target/41358] correct types for OpenBSD targets
--- Comment #3 from jsg at openbsd dot org 2009-09-19 17:11 --- http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01269.html inclusive of stdint bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41358
[Bug fortran/41328] [4.4 regression] bad iostat when reading DOS file in a character array (non-advancing)
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-09-19 17:21 --- Subject: Bug 41328 Author: jvdelisle Date: Sat Sep 19 17:21:20 2009 New Revision: 151883 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151883 Log: 2009-09-19 Jerry DeLisle jvdeli...@gcc.gnu.org Backport from mainline: PR libgfortran/41328 * io/transfer.c (read_sf): Adjust fbuf position and do proper fbuf reads to traverse CR, CR-LF, and LF style line ends.Set at_eof flag on short read if any characters were successfully read so that EOF condition with no EOR marker succeeds. Modified: branches/gcc-4_4-branch/libgfortran/ChangeLog branches/gcc-4_4-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41328
[Bug fortran/41328] [4.4 regression] bad iostat when reading DOS file in a character array (non-advancing)
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-09-19 17:24 --- Subject: Bug 41328 Author: jvdelisle Date: Sat Sep 19 17:23:43 2009 New Revision: 151884 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151884 Log: 2009-09-19 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/41328 * gfortran.dg/cr_lf.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/cr_lf.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41328
[Bug middle-end/39886] [4.5 Regression] Revision 145283 caused ICE in purge_dead_edges, at cfgrtl.c:2274
--- Comment #8 from hjl dot tools at gmail dot com 2009-09-19 17:29 --- It is caused by revision 145283: http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00790.html -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|[4.5 Regression] ICE in |[4.5 Regression] Revision |purge_dead_edges, at|145283 caused ICE in |cfgrtl.c:2274 |purge_dead_edges, at ||cfgrtl.c:2274 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39886
[Bug fortran/41328] [4.4 regression] bad iostat when reading DOS file in a character array (non-advancing)
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-09-19 17:35 --- Fixed on 4.4, closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41328
[Bug middle-end/41410] Bootstrap fails with ICE on i686
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-19 17:50 --- Why do you open 3 bug reports for the same problem? *** This bug has been marked as a duplicate of 41395 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41410
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #13 from hjl dot tools at gmail dot com 2009-09-19 17:50 --- *** Bug 41410 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #18 from davek at gcc dot gnu dot org 2009-09-19 17:59 --- (In reply to comment #17) (In reply to comment #16) Patch I sent to improve tree_loc code also has code to lookup constants in constant pool. For strings in particular this has pretty good chance of success. I see you wrote: There was latent bug in that code causing undefined references to constant pool values that was optimized out. This is fixed now. That sounds like this bug! I'll test your patches against my tree, thanks for the help. :-( There must be one more latent bug in the code; after applying both the patches you sent today and rebuilding dwarf2out.o and cc1.exe, no difference in the generated source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #19 from hubicka at ucw dot cz 2009-09-19 18:24 --- Subject: Re: expr.c undefined reference while linking jc1 :-( There must be one more latent bug in the code; after applying both the patches you sent today and rebuilding dwarf2out.o and cc1.exe, no difference in the generated source. You would need to add code handling RTL CONST_STRING same way as tree STRING_CST is handled. If Jakub thinks it makes sense, I can add that. and indeed, I am quite sure there are number of latent problems in that :(( Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug middle-end/41403] Optimization: NIST test FM013.f fails at -O1 and above
--- Comment #4 from jv244 at cam dot ac dot uk 2009-09-19 18:27 --- further reduced, looks more like a middle end issue to me: IVFAIL=0 ASSIGN 1263 TO I GO TO I, (1262,1263,1264) 1262 ICON01 = 1262 GO TO 1265 1263 ICON01 = 1263 GO TO 1265 1264 ICON01 = 1264 1265 CONTINUE 41260 IF ( ICON01 - 1263 ) 21260, 11260, 21260 11260 IVPASS = IVPASS + 1 GO TO 1271 21260 IVFAIL = IVFAIL + 1 1271 CONTINUE WRITE (6,*) IVFAIL END -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |middle-end Ever Confirmed|0 |1 Known to fail||4.3.1 4.4.2 4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-09-19 18:27:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41403
[Bug c/41411] New: ICE: mem_loc_descriptor, at dwarf2out.c:11616
Using native gcc to compile sparc of same source. The offending file belongs to newlib. Preprocessed output shortly. $ gcc --version gcc (GCC) 4.5.0 20090919 (experimental) [trunk revision 151882] /users/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc -B/users/joel/test-gcc/b-gcc1-sparc/./gcc/ -nostdinc -B/users/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/ -isystem /users/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/targ-include -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/sparc-rtems4.10/bin/ -B/users/joel/test-gcc/install-svn/sparc-rtems4.10/lib/ -isystem /users/joel/test-gcc/install-svn/sparc-rtems4.10/include -isystem /users/joel/test-gcc/install-svn/sparc-rtems4.10/sys-include -DPACKAGE_NAME=\newlib\ -DPACKAGE_TARNAME=\newlib\ -DPACKAGE_VERSION=\1.17.0\ -DPACKAGE_STRING=\newlib\ 1.17.0\ -DPACKAGE_BUGREPORT=\\ -I. -I/users/joel/test-gcc/gcc-svn/newlib/libm/common -O2 -DMALLOC_ALIGNMENT=8 -DMALLOC_PROVIDED -DEXIT_PROVIDED -DMISSING_SYSCALL_NAMES -DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_FCNTL -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT -D_NO_GETPASS -D_NO_SIGSET -fno-builtin -g -O2 -c -o lib_a-s_rint.o `test -f 's_rint.c' || echo '/users/joel/test-gcc/gcc-svn/newlib/libm/common/'`s_rint.c (high:SI (symbol_ref/u:SI (*.LLC6) [flags 0x2]))/users/joel/test-gcc/gcc-svn/newlib/libm/common/s_log1p.c: In function 'log1p': /users/joel/test-gcc/gcc-svn/newlib/libm/common/s_log1p.c:215:1: internal compiler error: in mem_loc_descriptor, at dwarf2out.c:11616 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE: mem_loc_descriptor, at dwarf2out.c:11616 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joel at gcc dot gnu dot org GCC target triplet: sparc-rtems4.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41411
[Bug middle-end/41403] miscompilation of goto/label using code
--- Comment #5 from jv244 at cam dot ac dot uk 2009-09-19 18:48 ---
and also fails in C
#include stdio.h
main()
{
int i;
int i0;
void * i1;
int icon01;
int ivfail;
int ivpass;
int D1545;
ivfail = 0;
i0 = -1;
i1 = label_001263;
if (i1 == label_001262) goto label_001262;
if (i1 == label_001263) goto label_001263;
if (i1 == label_001264) goto label_001264;
label_001262:
icon01 = 1262;
goto label_001265;
label_001263:
icon01 = 1263;
goto label_001265;
label_001264:
icon01 = 1264;
label_001265:
label_041260:
D1545 = icon01 + -1263;
if (D1545 != 0) goto label_021260; else goto label_011260;
label_011260:;
ivpass = ivpass + 1;
goto label_001271;
label_021260:
ivfail = ivfail + 1;
label_001271:
printf(%d\n,ivfail);
}
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Priority|P3 |P2
Summary|Optimization: NIST test |miscompilation of goto/label
|FM013.f fails at -O1 and|using code
|above |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41403
[Bug middle-end/41403] miscompilation of goto/label using code
--- Comment #6 from jv244 at cam dot ac dot uk 2009-09-19 18:54 ---
and smaller C testcase:
main()
{
void * i1;
int icon01;
int ivfail;
int D1545;
ivfail = 0;
i1 = label_001263;
if (i1 == label_001262) goto label_001262;
if (i1 == label_001263) goto label_001263;
label_001262:
icon01 = 1262;
goto label_001265;
label_001263:
icon01 = 1263;
label_001265:
D1545 = icon01 + -1263;
if (D1545 != 0) goto label_021260; else goto label_011260;
label_011260:;
goto label_001271;
label_021260:
ivfail = ivfail + 1;
label_001271:
printf(%d\n,ivfail);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41403
[Bug c/41411] ICE: mem_loc_descriptor, at dwarf2out.c:11616
--- Comment #1 from joel at gcc dot gnu dot org 2009-09-19 18:58 --- Created an attachment (id=18609) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18609action=view) Preprocessed code to generate bug dropping -g from the command line fixes it. Full command in next comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41411
[Bug c/41411] ICE: mem_loc_descriptor, at dwarf2out.c:11616
--- Comment #2 from joel at gcc dot gnu dot org 2009-09-19 18:59 --- This is the command I used to generate the ICE on the attached test case. Dropping the -g got rid of the ICE. /users/joel/test-gcc/b-gcc1-sparc/./gcc/xgcc -B/users/joel/test-gcc/b-gcc1-sparc/./gcc/ -B/users/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/ -isystem /users/joel/test-gcc/b-gcc1-sparc/sparc-rtems4.10/newlib/targ-include -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/sparc-rtems4.10/bin/ -B/users/joel/test-gcc/install-svn/sparc-rtems4.10/lib/ -isystem /users/joel/test-gcc/install-svn/sparc-rtems4.10/include -isystem /users/joel/test-gcc/install-svn/sparc-rtems4.10/sys-include -c -O2 -fno-builtin -g j.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41411
[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)
--- Comment #8 from cgd at gcc dot gnu dot org 2009-09-19 19:26 --- Fixed in trunk in rev 151879. -- cgd at gcc dot gnu dot org changed: What|Removed |Added CC||cgd at gcc dot gnu dot org Status|NEW |RESOLVED Keywords||patch Known to fail||4.2.0 4.2.1 4.2.2 4.3.1 ||4.4.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug middle-end/41411] [4.5 Regression] ICE: mem_loc_descriptor, at dwarf2out.c:11616
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Component|c |middle-end Summary|ICE: mem_loc_descriptor, at |[4.5 Regression] ICE: |dwarf2out.c:11616 |mem_loc_descriptor, at ||dwarf2out.c:11616 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41411
[Bug tree-optimization/41377] [4.5 Regression] Revision 151696 caused ICE in unsplit_eh
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41377
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap with checking disabled
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Summary|[4.5 regression] Revision |[4.5 regression] Revision |151800 failed bootstrap |151800 failed bootstrap with ||checking disabled http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-19 20:44 --- Assertion failed: (!Unknown one-operand), function LinkLocation, file /SourceCache/dwarf_utilities/dwarf_utilities-66/source/DWARFdSYM.cpp, line 157 1. xgcc: Internal error: Abort trap (program dsymutil) this means this is a darwin bug, dsymutil abort()s. Please report to apple instead. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #20 from davek at gcc dot gnu dot org 2009-09-19 21:20 --- (In reply to comment #19) Subject: Re: expr.c undefined reference while linking jc1 :-( There must be one more latent bug in the code; after applying both the patches you sent today and rebuilding dwarf2out.o and cc1.exe, no difference in the generated source. You would need to add code handling RTL CONST_STRING same way as tree STRING_CST is handled. If Jakub thinks it makes sense, I can add that. and indeed, I am quite sure there are number of latent problems in that :(( What's your timescale for this if you were to do it? If it's likely to take a few days, should we maybe commit something roughly like the patch from comment 11 as a band-aid to get trunk building again and have you remove it again as part of the subsequent patch to handle strings? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #14 from ubizjak at gmail dot com 2009-09-19 21:21 --- Checking is not a problem here, see Comments #9 and #10. -- ubizjak at gmail dot com changed: What|Removed |Added Summary|[4.5 regression] Revision |[4.5 regression] Revision |151800 failed bootstrap with|151800 failed bootstrap |checking disabled | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
--- Comment #2 from dominiq at lps dot ens dot fr 2009-09-19 21:31 --- this means this is a darwin bug, dsymutil abort()s. Please report to apple instead. What should I report to apple? gcc 4.5.0 is working probably at least up to revision 151807 (currently building libjava) then some change in a later revision triggered the problem: the change is not in the apple side, but in the gcc one. This may uncover an apple bug, but in the present situation I don't see what I should report to apple and expect an answer from them. So please leave the pr open for the moment. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #35 from hjl dot tools at gmail dot com 2009-09-19 21:37 --- Created an attachment (id=18610) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18610action=view) An updated patch for gcc 4.4 -- hjl dot tools at gmail dot com changed: What|Removed |Added Attachment #18393|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #36 from hjl dot tools at gmail dot com 2009-09-19 21:38 --- Created an attachment (id=18611) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18611action=view) An updated patch for gcc trunk -- hjl dot tools at gmail dot com changed: What|Removed |Added Attachment #18314|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #37 from hjl dot tools at gmail dot com 2009-09-19 21:38 --- (In reply to comment #33) Created an attachment (id=18579) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18579action=view) [edit] Another bug in 4.4 patch Another bug in 4.4 patch. This one doesn't need stack alignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
--- Comment #3 from dominiq at lps dot ens dot fr 2009-09-19 21:40 --- When bootstrapping r151807 will finish (couple hours from now). I am planning to bootstrap r151815. What is the estimated likelihood that the problem is triggered by * dwarf2out.c (loc_descriptor): Emit DW_OP_stack_value and DW_OP_implicit_value even without dwarf_version 4. ? -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #38 from hjl dot tools at gmail dot com 2009-09-19 21:40 --- (In reply to comment #32) Created an attachment (id=18578) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18578action=view) [edit] A bug example for 4.4 patch Shows a bug in 4.4 patch Please try the updated patch in comment #35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)
--- Comment #10 from hjl dot tools at gmail dot com 2009-09-19 21:47 --- All new tests are failing. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-19 22:04 --- Yes, probably the apple tools barf on the new dwarf opcodes. Please report the issue to them. A GCC side fix would be to add an option to restrict dwarf to dwarf2 and turn that option on by default for darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug middle-end/41411] [4.5 Regression] ICE: mem_loc_descriptor, at dwarf2out.c:11616
--- Comment #3 from hubicka at ucw dot cz 2009-09-19 22:20 --- Subject: Re: [4.5 Regression] ICE: mem_loc_descriptor, at dwarf2out.c:11616 This is because mem_loc_descriptor gets called on: (high:SI (symbol_ref/u:SI (*.LLC6) [flags 0x2])) Jakub, this is yours code, but it seems to me that mem_loc_descriptor is OK to be called on pretty much and RTL expression now with VTA so it is bug it does not know about HIGH. HIGH can probably be represented via masking out the low order bits, but I can't find in the docs if the bits are specified in some target independent way and I am not sure how to important is to handle it. It seems that we must've confused value tracking to end up with such an expression in any variable interesting to debugging output? Index: dwarf2out.c === --- dwarf2out.c (revision 151837) +++ dwarf2out.c (working copy) @@ -11566,6 +11624,7 @@ mem_loc_descriptor (rtx rtl, enum machin case ROTATE: case ROTATERT: case TRUNCATE: +case HIGH: /* In theory, we could implement the above. */ /* DWARF cannot represent the unsigned compare operations natively. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41411
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #15 from developer at sandoe-acoustics dot co dot uk 2009-09-19 22:45 --- just checked; powerpc-apple-darwin9 [at 151880] this also fails. looking through the error log there do seem to be a large number of garbage strings in the informational messages; e.g. ../../../gcc-4-5-regtest/libgcc/../gcc/unwind-dw2-fde.h: In function âÃòlast_fdeâÃô: if that's of any relevance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug middle-end/41260] [4.5 Regression] major regressions on *-apple-darwin10 at -m64 caused by r147995
--- Comment #39 from howarth at nitro dot med dot uc dot edu 2009-09-19
22:47 ---
The patch...
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 151890)
+++ gcc/config/darwin.h (working copy)
@@ -372,7 +372,9 @@
/* Machine dependent libraries. */
-#define LIB_SPEC %{!static:-lSystem}
+#define LIB_SPEC %{!static:\
+ %:version-compare(= 10.6 mmacosx-version-min= -no_compact_unwind) \
+ -lSystem}
/* Support -mmacosx-version-min by supplying different (stub) libgcc_s.dylib
libraries to link against, and by not linking against libgcc_s on
eliminates the regressions from r147995 as shown in the testsuite results...
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01761.html.
Still it would be better to suppress the epilog unwind information on darwin
instead of resorting to -no_compact_unwind which leaves binaries built under
darwin8/9
with gcc 4.5 non-portable to darwin10 and later.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41260
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2009-09-19 23:14 --- Same problem on x86_64-apple-darwin10 with current gcc trunk... onfigure:5749: checking size of long long configure:5754: /sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/lib/ -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10/include -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10/sys-include-o conftest -g -O2 conftest.c 5 Assertion failed: (!Unknown one-operand), function LinkLocation, file /SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line 1571. xgcc: Internal error: Abort trap (program dsymutil) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug tree-optimization/41406] -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156
--- Comment #2 from spop at gcc dot gnu dot org 2009-09-19 23:18 --- What version of gcc do you use? I cannot reproduce the error on amd64-linux with the current trunk at rev.151881. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41406
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2009-09-19 23:22 --- This seems strange to me. If I create the offending conftest.c test file and execute... /sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/lib/ -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10/include -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10/sys-include-o conftest -g -O2 --save-temps conftest.c I get... Assertion failed: (!Unknown one-operand), function LinkLocation, file /SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line 1571. xgcc: Internal error: Abort trap (program dsymutil) whereas if I then use the preprocessed source file to execute... /sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20090919/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/bin/ -B/sw/lib/gcc4.5/x86_64-apple-darwin10/lib/ -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10/include -isystem /sw/lib/gcc4.5/x86_64-apple-darwin10/sys-include -o conftest -g -O2 conftest.i I get no error and a conftest executable is created that runs without errors. This would seem to point back at the xgcc as at fault and not dsymutil, no? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-09-19 23:23 --- Created an attachment (id=18612) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18612action=view) conftest.c file created on x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2009-09-19 23:24 --- Created an attachment (id=18613) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18613action=view) preprocessed source for conftest.c created on x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug tree-optimization/41406] -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156
--- Comment #3 from t7 at gmail dot com 2009-09-19 23:25 --- (In reply to comment #2) What version of gcc do you use? I cannot reproduce the error on amd64-linux with the current trunk at rev.151881. I used the cross compiler I compiled from gcc trunk svn revision 151878. This bug gets triggered when combination of these flags are used -O3 -floop-strip-mine I suppose that this is some what specific to the target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41406
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2009-09-19 23:26 --- Created an attachment (id=18614) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18614action=view) assembly file for conftest.c created with --save-temps on x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
Re: [Bug tree-optimization/41406] -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156
Could you run gdb and report the backtrace? # gdb build-gcc/gcc/cc1 (gdb) run -O3 -floop-strip-mine ... aes.i (gdb) bt Thanks, Sebastian
[Bug tree-optimization/41406] -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156
--- Comment #4 from sebpop at gmail dot com 2009-09-19 23:31 --- Subject: Re: -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156 Could you run gdb and report the backtrace? # gdb build-gcc/gcc/cc1 (gdb) run -O3 -floop-strip-mine ... aes.i (gdb) bt Thanks, Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41406
[Bug tree-optimization/41406] -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156
--- Comment #5 from spop at gcc dot gnu dot org 2009-09-19 23:36 --- Subject: Re: -O3 conflict with -floop-strip-mine internal compiler error: in build_loop_iteration_domains, at graphite-sese-to-poly.c:1156 Actually I can see what is going wrong: the number of iterations is unknown when it should be known at that point. No need of the backtrace. Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41406
[Bug bootstrap/41405] [4.5 Regression] Bootstrap fails at revision 151873 on *-apple-darwin9
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2009-09-19 23:37 --- I should also point out that --save-temps produces identical conftest.s files whether xgcc compiles from conftest.c or conftest.i. Only it errors when starting from conftest.c but not conftest.i (which was obtained from the first step with --save-temps). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41405
[Bug c++/41412] New: SEGFAULT when declaring two 724 x 724 matrices of doubles in class
When two matrices of the type double, sized [724][724] or more are declared, as
private variables of a class, the program crashes as soon as this class
constructor is called.
724 is the magic number; 723 does not trigger the bug. The type has to be
double also, no other built-in does the job.
The exact version I'm using is Ubuntu 4.3.3-5ubuntu4.
Here's a little source file that triggers the bug:
class foo
{
double a[724][724], b[724][724];
public:
foo ()
{
}
};
int
main ()
{
foo bar;
}
--
Summary: SEGFAULT when declaring two 724 x 724 matrices of
doubles in class
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: maltusan at gmail dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41412
[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)
--- Comment #11 from cgd at google dot com 2009-09-20 01:34 --- Subject: Re: -MMD vs not found system header (included from a system header) Gack, sorry, looks like I screwed this up. When I retested after updating, I only compared test results before/after, and saw what I was expecting, I didn't actually recheck all of the output from the new tests. I'll see about fixing ASAP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435
[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)
--- Comment #12 from cgd at gcc dot gnu dot org 2009-09-20 01:57 --- (In reply to comment #11) Gack, sorry, looks like I screwed this up. When I retested after updating, I only compared test results before/after, and saw what I was expecting, I didn't actually recheck all of the output from the new tests. Actually, it looking at this error further, I can't see how the new tests ever passed in trunk. (I initially wrote this in 4.4.0, where I definitely verified that all of the tests passed... but the 'fatal error' bit was changed in trunk, and so I had to change the tests. And I know that I diffed the test results in trunk, but I can only conclude that I never actually verified that they all passed in trunk. *sigh*) Anyway, testing the fix now (copying the error-checking style from the current missing-header-1 test). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435
[Bug c++/41412] SEGFAULT when declaring two 724 x 724 matrices of doubles in class
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-20 02:33 --- You are allocating 8MB on stack. You need to raise your stack limit. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41412
[Bug c++/41412] SEGFAULT when declaring two 724 x 724 matrices of doubles in class
--- Comment #2 from maltusan at gmail dot com 2009-09-20 04:13 --- Oh. I'm sorry. As it didn't happen when I declared the variables outside a class, I didn't think it was a memory issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41412
