[Bug c++/53672] gcc/branches/cilkplus does not like C++ spawn (when optimized)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53672 --- Comment #3 from John Forrest jjhforrest at gmail dot com 2012-06-15 06:57:43 UTC --- Balaji, Attached - AbcMatrix.ii gives segfault using compile There are more than a dozen places in my code where code such as - for (int i=0;inumberBlocks-1;i++) which[i]=cilk_spawn pivotColumnDantzig(i,useRowCopy,updates,spare,best[i]); which[numberBlocks-1]=pivotColumnDantzig(numberBlocks-1,useRowCopy,updates, spare,best[numberBlocks-1]); cilk_sync; inside a class such as AbcMatrix segfaults on compilation. If I create a non class static function doWork(AbcMatrix * matrix, other stuff) and in that function do which[i]=cilk_spawn(matrix,other stuff) it works. There is not much of an overhead but is ugly and time consuming. Hope you can reproduce fault. Regards, John On 14/06/12 17:56, bviyer at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53672 Balaji V. Iyerbviyer at gmail dot com changed: What|Removed |Added CC||bviyer at gmail dot com --- Comment #1 from Balaji V. Iyerbviyer at gmail dot com 2012-06-14 16:56:19 UTC --- Hello John, This problem seem to be fixed as of this commit: git:0ac59c91905a106865589114d4e55f0c7f256874 svn: revision:188147 I tried your code and mine passes fine. Thanks, Balaji V. Iyer.
[Bug lto/43581] exception handling broken across shared libaries with -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43581 --- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-06-15 07:46:47 UTC --- This problem was most probably due to binutils as I can reproduce it even with 4.8 using GNU gold (GNU Binutils 2.21.51.20110514) 1.11 while looks fixed with GNU gold (GNU Binutils 2.22) 1.11 p.s. the test in comment 6 fails as dlclose triggers a (expected?) segfault in __gxx_exception_cleanup(_Unwind_Reason_Code, _Unwind_Exception*) ()
[Bug go/53679] New: Build failure in libgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53679 Bug #: 53679 Summary: Build failure in libgo Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: al...@archlinux.org Since revision 187850, I get build failures for libgo due to the use of -Werror and not checking the return value of write: /build/src/gcc-4.7.1/libgo/runtime/print.c: In function 'gwrite': /build/src/gcc-4.7.1/libgo/runtime/print.c:20:3: error: ignoring return value of 'write', declared with attribute warn_unused_result [-Werror=unused-result] cc1: all warnings being treated as errors
[Bug libstdc++/53680] New: Link problems with static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 Bug #: 53680 Summary: Link problems with static libstdc++ Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d@ngs.ru Target: i686-pc-linux-gnu The same problem as fixed in Bug 12595 but in Release 4.7: versioned symbols in the static libstdc++.a
[Bug bootstrap/53681] New: s390 bootstrap failure since 187965
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53681
Bug #: 53681
Summary: s390 bootstrap failure since 187965
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kreb...@gcc.gnu.org
int
__gcov_execle (const char *path, char *arg, ...)
{
__builtin_va_list ap, aq;
while (__builtin_va_arg (ap, char *))
length++;
}
cc1 -fpreprocessed t.c -quiet
t.c: In function ‘__gcov_execle’:
t.c:6:7: error: ‘length’ undeclared (first use in this function)
length++;
^
t.c:6:7: note: each undeclared identifier is reported only once for each
function it appears in
t.c:5:32: internal compiler error: Segmentation fault
while (__builtin_va_arg (ap, char *))
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
(gdb) r
Starting program: /home/andreas/patched/gcc-head-build/gcc/cc1 -fpreprocessed
t.c -quiet
t.c: In function ‘__gcov_execle’:
t.c:6:7: error: ‘length’ undeclared (first use in this function)
length++;
^
t.c:6:7: note: each undeclared identifier is reported only once for each
function it appears in
Program received signal SIGSEGV, Segmentation fault.
0x82618f00 in mark_sym_for_renaming (sym=0x3fff7f3a320)
at /home/andreas/patched/gcc-head/gcc/tree-into-ssa.c:2997
2997 bitmap_set_bit (SYMS_TO_RENAME (cfun), DECL_UID (sym));
(gdb) bt
#0 0x82618f00 in mark_sym_for_renaming (sym=0x3fff7f3a320)
at /home/andreas/patched/gcc-head/gcc/tree-into-ssa.c:2997
#1 0x83c03f98 in s390_gimplify_va_arg (valist=0x3fff8026300,
type=0x3fff7f549d8, pre_p=0x3ffd7d0,
post_p=0x3ffa698) at
/home/andreas/patched/gcc-head/gcc/config/s390/s390.c:9047
#2 0x8057b192 in gimplify_va_arg_expr (expr_p=0x3fff8026290,
pre_p=0x3ffd7d0, post_p=0x3ffa698)
at /home/andreas/patched/gcc-head/gcc/builtins.c:4509
#3 0x81256160 in gimplify_expr (expr_p=0x3fff8026290,
pre_p=0x3ffd7d0, post_p=0x3ffa698,
gimple_test_f=0x8109c684 is_gimple_val, fallback=1) at
/home/andreas/patched/gcc-head/gcc/gimplify.c:7178
#4 0x8125b52a in gimplify_expr (expr_p=0x3fff802a020,
pre_p=0x3ffd7d0, post_p=0x3ffa698,
gimple_test_f=0x8109aca8 is_gimple_condexpr, fallback=1)
at /home/andreas/patched/gcc-head/gcc/gimplify.c:7743
#5 0x81233282 in gimplify_cond_expr (expr_p=0x3fff728,
pre_p=0x3ffd7d0, fallback=0)
at /home/andreas/patched/gcc-head/gcc/gimplify.c:3240
#6 0x81255808 in gimplify_expr (expr_p=0x3fff728,
pre_p=0x3ffd7d0, post_p=0x3ffbcf8,
gimple_test_f=0x8123f6a8 is_gimple_stmt, fallback=0) at
/home/andreas/patched/gcc-head/gcc/gimplify.c:7085
#7 0x812474e8 in gimplify_stmt (stmt_p=0x3fff728,
seq_p=0x3ffd7d0)
at /home/andreas/patched/gcc-head/gcc/gimplify.c:5662
#8 0x812217e0 in gimplify_statement_list (expr_p=0x3fff802a060,
pre_p=0x3ffd7d0)
at /home/andreas/patched/gcc-head/gcc/gimplify.c:1529
#9 0x812597d2 in gimplify_expr (expr_p=0x3fff802a060,
pre_p=0x3ffd7d0, post_p=0x3ffcb10,
gimple_test_f=0x8123f6a8 is_gimple_stmt, fallback=0) at
/home/andreas/patched/gcc-head/gcc/gimplify.c:7514
#10 0x812474e8 in gimplify_stmt (stmt_p=0x3fff802a060,
seq_p=0x3ffd7d0)
at /home/andreas/patched/gcc-head/gcc/gimplify.c:5662
#11 0x8121f25e in gimplify_bind_expr (expr_p=0x3fff8019298,
pre_p=0x3ffe7d8)
at /home/andreas/patched/gcc-head/gcc/gimplify.c:1223
#12 0x81257358 in gimplify_expr (expr_p=0x3fff8019298,
pre_p=0x3ffe7d8, post_p=0x3ffdaf0,
gimple_test_f=0x8123f6a8 is_gimple_stmt, fallback=0) at
/home/andreas/patched/gcc-head/gcc/gimplify.c:7299
#13 0x812474e8 in gimplify_stmt (stmt_p=0x3fff8019298,
seq_p=0x3ffe7d8)
at /home/andreas/patched/gcc-head/gcc/gimplify.c:5662
#14 0x8125e548 in gimplify_body (fndecl=0x3fff8019200, do_parms=1
'\001')
at /home/andreas/patched/gcc-head/gcc/gimplify.c:8160
#15 0x8126070a in gimplify_function_tree (fndecl=0x3fff8019200)
at /home/andreas/patched/gcc-head/gcc/gimplify.c:8294
#16 0x809aabea in cgraph_analyze_function (node=0x3fff802b000)
at /home/andreas/patched/gcc-head/gcc/cgraphunit.c:652
#17 0x809ac59e in cgraph_analyze_functions () at
/home/andreas/patched/gcc-head/gcc/cgraphunit.c:938
#18 0x809b166e in finalize_compilation_unit () at
/home/andreas/patched/gcc-head/gcc/cgraphunit.c:2086
#19 0x8011b6c2 in c_write_global_declarations () at
/home/andreas/patched/gcc-head/gcc/c-decl.c:10112
#20 0x821d8430 in compile_file () at
/home/andreas/patched/gcc-head/gcc/toplev.c:568
#21 0x821db150 in do_compile () at
[Bug bootstrap/53681] s390 bootstrap failure since 187965
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53681 Andreas Krebbel krebbel at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 CC||krebbel at gcc dot gnu.org, ||matz at suse dot de
[Bug bootstrap/53681] s390 bootstrap failure since 187965
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53681 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-15 08:26:17 UTC --- This is an ice-on-invalid - how can that break bootstrap?
[Bug libstdc++/53680] Link problems with static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-06-15 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-06-15 08:27:53 UTC --- Please provide more information, your assessment it's the same bug might not be true.
[Bug bootstrap/53675] [4.8 Regression] bootstrap fails on netbsd5.1 due to unsupported dwarf4 info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53675 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug libstdc++/53680] Link problems with static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #2 from __vic d.v.a at ngs dot ru 2012-06-15 08:30:06 UTC --- $ uname -a Linux m246 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:40 EST 2010 i686 i686 i386 GNU/Linux $ cat /etc/*-release CentOS release 5.4 (Final) When building on $ uname -a Linux jansmb 2.6.9-103.ELsmp #1 SMP Fri Dec 9 04:31:51 EST 2011 i686 i686 i386 GNU/Linux $ cat /etc/*-release CentOS release 4.9 (Final) it's all right
[Bug bootstrap/53681] s390 bootstrap failure since 187965
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53681
--- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org 2012-06-15
08:30:21 UTC ---
(In reply to comment #1)
This is an ice-on-invalid - how can that break bootstrap?
delta was a bit too eager. Same happens with:
int
__gcov_execle (const char *path, char *arg, ...)
{
int length = 0;
__builtin_va_list ap, aq;
while (__builtin_va_arg (ap, char *))
length++;
}
[Bug libstdc++/53680] Link problems with static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #3 from __vic d.v.a at ngs dot ru 2012-06-15 08:34:13 UTC --- When I'm trying link libstdc++.a statically to my .so I see messages like: undefined versioned symbol name std::defer_lock@@GLIBCPP_3 $ nm libstdc++.a | grep @ shows me that archive contains versioned symbols. Do you need the entire list?
[Bug bootstrap/53681] s390 bootstrap failure since 187965
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53681 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-15 08:42:03 UTC --- When delta reducing ICE on valid, it is always better to add to a script second compilation (perhaps with -O0 for speed) using some compiler where it initially compiles fine to make sure delta doesn't turn ice-on-valid into ice-on-invalid.
[Bug libstdc++/49894] [C++0x] Uniform initialization in constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49894 __vic d.v.a at ngs dot ru changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #13 from __vic d.v.a at ngs dot ru 2012-06-15 08:51:36 UTC --- NSDMI works fine. Thanx
[Bug libstdc++/53680] Link problems with static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #4 from __vic d.v.a at ngs dot ru 2012-06-15 08:57:21 UTC --- Note: undocumented configure option --disable-symvers helps but I think building with default parameters must work properly
[Bug rtl-optimization/53533] [4.7/4.8 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-15 09:03:04 UTC --- This started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=173856 The current cost model is seriously insufficient.
[Bug middle-end/53590] compiler fails to generate SIMD instruction for FP division
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53590 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-06-15 09:22:04 UTC --- Author: ebotcazou Date: Fri Jun 15 09:22:00 2012 New Revision: 188651 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188651 Log: PR middle-end/53590 * common.opt (-fdelete-dead-exceptions): New switch. * doc/invoke.texi (Code Gen Options): Document it. * cse.c (count_reg_usage) CALL_INSN: Use !insn_nothrow_p in lieu of insn_could_throw_p predicate. Do not skip an insn that could throw if dead exceptions can be deleted. (insn_live_p): Likewise, do not return true in that case. * dce.c (can_alter_cfg): New flag. (deletable_insn_p): Do not return false for an insn that can throw if the CFG can be altered and dead exceptions can be deleted. (init_dce): Set can_alter_cfg to false for fast DCE, true otherwise. * dse.c (scan_insn): Use !insn_nothrow_p in lieu of insn_could_throw_ predicate. Do not preserve an insn that could throw if dead exceptions can be deleted. * function.h (struct function): Add can_delete_dead_exceptions flag. * function.c (allocate_struct_function): Set it. * lto-streamer-in.c (input_struct_function_base): Stream it. * lto-streamer-out.c (input_struct_function_base): Likewise. * tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Do not mark a statement that could throw as necessary if dead exceptions can be deleted. ada/ * gcc-interface/misc.c (gnat_init_options_struct): Set opts-x_flag_delete_dead_exceptions to 1. Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/misc.c trunk/gcc/common.opt trunk/gcc/cse.c trunk/gcc/dce.c trunk/gcc/doc/invoke.texi trunk/gcc/dse.c trunk/gcc/function.c trunk/gcc/function.h trunk/gcc/lto-streamer-in.c trunk/gcc/lto-streamer-out.c trunk/gcc/tree-ssa-dce.c
[Bug middle-end/53590] compiler fails to generate SIMD instruction for FP division
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53590 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-06-15 10:00:25 UTC --- Fixed on the mainline.
[Bug libstdc++/53680] Versioned symbols in static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #5 from __vic d.v.a at ngs dot ru 2012-06-15 10:22:36 UTC --- The exact description: $ g++ -o formats/alcatel_alm9_decoder.fmt -shared -Llib -static-libgcc -O3 -Wl,-s -Wl,--no-undefined src/alcatel_alm9_decoder.o formats.a decoder.a -ljanuary_tools -ljanuary /usr/bin/ld: formats/alcatel_alm9_decoder.fmt: undefined versioned symbol name _ZSt10adopt_lock@@GLIBCXX_3.4.11 /usr/bin/ld: failed to set dynamic section sizes: Bad value collect2: error: ld returned 1 exit status $ nm lib/libstdc++.a | grep adopt B _ZN9__gnu_cxx10adopt_lockE B _ZSt10adopt_lock@@GLIBCXX_3.4.11
[Bug libstdc++/53680] Versioned symbols in static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-15 10:25:32 UTC --- (In reply to comment #4) Note: undocumented configure option --disable-symvers helps but I think building with default parameters must work properly It's not undocumented http://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html
[Bug libstdc++/53680] Versioned symbols in static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-15 10:29:36 UTC --- isn't this PR 52689 ?
[Bug libstdc++/53680] Versioned symbols in static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #8 from __vic d.v.a at ngs dot ru 2012-06-15 10:30:30 UTC --- (In reply to comment #6) (In reply to comment #4) Note: undocumented configure option --disable-symvers helps but I think building with default parameters must work properly It's not undocumented http://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html Ok. But still. It must not be a mandatory option to build correct static lib
[Bug libstdc++/53680] Versioned symbols in static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #9 from __vic d.v.a at ngs dot ru 2012-06-15 10:33:13 UTC --- (In reply to comment #7) isn't this PR 52689 ? Probably it is.
[Bug libstdc++/53680] Versioned symbols in static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 --- Comment #10 from __vic d.v.a at ngs dot ru 2012-06-15 10:36:24 UTC --- When 4.7.1 will be released?
[Bug libstdc++/53680] Versioned symbols in static libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53680 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-15 10:37:41 UTC --- yesterday http://gcc.gnu.org/gcc-4.7/ marking as dup, please reopen if 4.7.1 doesn't fix it *** This bug has been marked as a duplicate of bug 52689 ***
[Bug libstdc++/52689] static linking with libstdc++ fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||d.v.a at ngs dot ru --- Comment #23 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-15 10:37:41 UTC --- *** Bug 53680 has been marked as a duplicate of this bug. ***
[Bug ada/53592] ICE on assignment to component of vector_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53592 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-06-15 10:41:19 UTC --- Author: ebotcazou Date: Fri Jun 15 10:41:13 2012 New Revision: 188653 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188653 Log: PR ada/53592 * gcc-interface/gigi.h (maybe_vector_array): Make static inline. * gcc-interface/utils.c (maybe_vector_array): Delete. * gcc-interface/trans.c (gnat_to_gnu) N_Indexed_Component: Mark the array object as addressable if it has vector type and is on the LHS. Added: trunk/gcc/testsuite/gnat.dg/vect8.adb trunk/gcc/testsuite/gnat.dg/vect8.ads Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/gigi.h trunk/gcc/ada/gcc-interface/trans.c trunk/gcc/ada/gcc-interface/utils.c trunk/gcc/testsuite/ChangeLog
[Bug target/53682] New: [4.7/4.8 Regression] ICE in cselib_lookup (SEGV) on i586-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53682 Bug #: 53682 Summary: [4.7/4.8 Regression] ICE in cselib_lookup (SEGV) on i586-linux-gnu Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org Created attachment 27625 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27625 test case works with 4.6 branch, fails with 4.7.1 on i586-linux-gnu, works on x86_64-linux-gnu. omitting one of the -fPIC, -fvisibility=hidden, -funroll-loops options avoids the ice. $ gcc -c -g -O2 -fPIC -fvisibility=hidden -funroll-loops mini_q_math.c mini_q_math.c: In function 'ByteToDir': mini_q_math.c:124:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Program received signal SIGSEGV, Segmentation fault. 0x081e657b in cselib_lookup(rtx_def*, machine_mode, int, machine_mode) () (gdb) bt #0 0x081e657b in cselib_lookup(rtx_def*, machine_mode, int, machine_mode) () #1 0x081e7034 in ?? () #2 0x08590da2 in ?? () #3 0x085a8680 in ?? () #4 0x08189983 in find_base_term(rtx_def*) () #5 0x08189a28 in find_base_term(rtx_def*) () #6 0x08189b69 in find_base_term(rtx_def*) () #7 0x0818b3e8 in ?? () #8 0x081e7820 in ?? () #9 0x081e88f7 in ?? () #10 0x081e9183 in cselib_process_insn(rtx_def*) () #11 0x0856c723 in ?? () #12 0x0857323c in variable_tracking_main() () #13 0x0836e2bc in execute_one_pass(opt_pass*) () #14 0x0836e615 in execute_pass_list(opt_pass*) () #15 0x0836e628 in execute_pass_list(opt_pass*) () #16 0x0836e628 in execute_pass_list(opt_pass*) () #17 0x0844d434 in tree_rest_of_compilation(tree_node*) () #18 0x081dd654 in ?? () #19 0x081deeb5 in cgraph_optimize() () #20 0x081df3ef in cgraph_finalize_compilation_unit() () #21 0x081185fc in c_write_global_declarations() () #22 0x0840661a in toplev_main(int, char**) () #23 0x0810712b in main ()
[Bug ada/53592] ICE on assignment to component of vector_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53592 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-06-15 10:46:16 UTC --- Author: ebotcazou Date: Fri Jun 15 10:46:12 2012 New Revision: 188654 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188654 Log: PR ada/53592 * gcc-interface/gigi.h (maybe_vector_array): Make static inline. * gcc-interface/utils.c (maybe_vector_array): Delete. * gcc-interface/trans.c (gnat_to_gnu) N_Indexed_Component: Mark the array object as addressable if it has vector type and is on the LHS. Added: branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/vect8.adb - copied unchanged from r188653, trunk/gcc/testsuite/gnat.dg/vect8.adb branches/gcc-4_7-branch/gcc/testsuite/gnat.dg/vect8.ads - copied unchanged from r188653, trunk/gcc/testsuite/gnat.dg/vect8.ads Modified: branches/gcc-4_7-branch/gcc/ada/ChangeLog branches/gcc-4_7-branch/gcc/ada/gcc-interface/gigi.h branches/gcc-4_7-branch/gcc/ada/gcc-interface/trans.c branches/gcc-4_7-branch/gcc/ada/gcc-interface/utils.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug ada/53592] ICE on assignment to component of vector_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53592 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.2 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-06-15 10:51:13 UTC --- .
[Bug tree-optimization/51581] Integer division by constant is not vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51581 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-15 11:07:54 UTC --- Author: jakub Date: Fri Jun 15 11:07:47 2012 New Revision: 188656 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188656 Log: PR tree-optimization/51581 * expr.h (choose_multiplier): New prototype. * expmed.c (choose_multiplier): No longer static. Change multiplier_ptr from rtx * to UHWI *. (expand_divmod): Adjust callers. * tree-vect-patterns.c (vect_recog_sdivmod_pow2_pattern): Renamed to... (vect_recog_divmod_pattern): ... this. Pass bb_vinfo as last argument to new_stmt_vec_info. Attempt to optimize also divisions by non-pow2 constants if integer vector division isn't supported. * tree-vect-stmts.c (vect_analyze_stmt): If node != NULL, don't look at pattern stmts and sequences. * gcc.c-torture/execute/pr51581-1.c: New test. * gcc.c-torture/execute/pr51581-2.c: New test. * gcc.dg/vect/pr51581-1.c: New test. * gcc.dg/vect/pr51581-2.c: New test. * gcc.dg/vect/pr51581-3.c: New test. * gcc.target/i386/avx-pr51581-1.c: New test. * gcc.target/i386/avx-pr51581-2.c: New test. * gcc.target/i386/avx2-pr51581-1.c: New test. * gcc.target/i386/avx2-pr51581-2.c: New test. * gcc.dg/vect/slp-26.c (main1): Divide by 0x8031 instead of 3. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr51581-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr51581-2.c trunk/gcc/testsuite/gcc.dg/vect/pr51581-1.c trunk/gcc/testsuite/gcc.dg/vect/pr51581-2.c trunk/gcc/testsuite/gcc.dg/vect/pr51581-3.c trunk/gcc/testsuite/gcc.target/i386/avx-pr51581-1.c trunk/gcc/testsuite/gcc.target/i386/avx-pr51581-2.c trunk/gcc/testsuite/gcc.target/i386/avx2-pr51581-1.c trunk/gcc/testsuite/gcc.target/i386/avx2-pr51581-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c trunk/gcc/expr.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/slp-26.c trunk/gcc/tree-vect-patterns.c trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/51581] Integer division by constant is not vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51581 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-15 11:09:11 UTC --- Fixed for 4.8+.
[Bug rtl-optimization/53589] [4.7/4.8 Regression] ICE in maybe_record_trace_start with asm goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53589 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-15 11:10:45 UTC --- Fixed.
[Bug c/53580] Internal Segmentation fault in nested omp parallel, omp parallel for and omp parallel for reduction Directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53580 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-15 11:12:27 UTC --- FIxed for 4.7+, not backporting further, as this is ice-on-invalid only.
[Bug c++/53683] New: cout doesn't support std::u16string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53683
Bug #: 53683
Summary: cout doesn't support std::u16string
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rui.mac...@gmail.com
Consider the following test program:
code
#include iostream
#include string
int main(void)
{
std::u16string test;
std::cout test std::endl;
return 0;
}
/code
When compiling this code with g++ 4.6.3, with the flags -std=c++0x -Wall
-pedantic, the following error message is displayed:
message
main.c++: In function ‘int main()’:
main.c++:9:15: error: no match for ‘operator’ in ‘std::cout test’
main.c++:9:15: note: candidates are:
/usr/include/c++/4.6/ostream:110:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT,
_Traits::operator(std::basic_ostream_CharT, _Traits::__ostream_type
(*)(std::basic_ostream_CharT, _Traits::__ostream_type)) [with _CharT = char,
_Traits = std::char_traitschar, std::basic_ostream_CharT,
_Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:110:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_stringchar16_t}’ to
‘std::basic_ostreamchar::__ostream_type
(*)(std::basic_ostreamchar::__ostream_type) {aka std::basic_ostreamchar
(*)(std::basic_ostreamchar)}’
/usr/include/c++/4.6/ostream:119:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT,
_Traits::operator(std::basic_ostream_CharT, _Traits::__ios_type
(*)(std::basic_ostream_CharT, _Traits::__ios_type)) [with _CharT = char,
_Traits = std::char_traitschar, std::basic_ostream_CharT,
_Traits::__ostream_type = std::basic_ostreamchar, std::basic_ostream_CharT,
_Traits::__ios_type = std::basic_ioschar]
/usr/include/c++/4.6/ostream:119:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_stringchar16_t}’ to
‘std::basic_ostreamchar::__ios_type
(*)(std::basic_ostreamchar::__ios_type) {aka std::basic_ioschar
(*)(std::basic_ioschar)}’
/usr/include/c++/4.6/ostream:129:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT,
_Traits::operator(std::ios_base (*)(std::ios_base)) [with _CharT = char,
_Traits = std::char_traitschar, std::basic_ostream_CharT,
_Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:129:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_stringchar16_t}’ to ‘std::ios_base
(*)(std::ios_base)’
/usr/include/c++/4.6/ostream:167:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT, _Traits::operator(long
int) [with _CharT = char, _Traits = std::char_traitschar,
std::basic_ostream_CharT, _Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:167:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_stringchar16_t}’ to ‘long int’
/usr/include/c++/4.6/ostream:171:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT, _Traits::operator(long
unsigned int) [with _CharT = char, _Traits = std::char_traitschar,
std::basic_ostream_CharT, _Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:171:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_stringchar16_t}’ to ‘long unsigned int’
/usr/include/c++/4.6/ostream:175:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT, _Traits::operator(bool)
[with _CharT = char, _Traits = std::char_traitschar,
std::basic_ostream_CharT, _Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:175:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_stringchar16_t}’ to ‘bool’
/usr/include/c++/4.6/bits/ostream.tcc:93:5: note: std::basic_ostream_CharT,
_Traits std::basic_ostream_CharT, _Traits::operator(short int) [with
_CharT = char, _Traits = std::char_traitschar]
/usr/include/c++/4.6/bits/ostream.tcc:93:5: note: no known conversion for
argument 1 from ‘std::u16string {aka std::basic_stringchar16_t}’ to ‘short
int’
/usr/include/c++/4.6/ostream:182:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT, _Traits::operator(short
unsigned int) [with _CharT = char, _Traits = std::char_traitschar,
std::basic_ostream_CharT, _Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:182:7: note: no known conversion for argument 1
from ‘std::u16string {aka std::basic_stringchar16_t}’ to ‘short unsigned int’
/usr/include/c++/4.6/bits/ostream.tcc:107:5: note: std::basic_ostream_CharT,
_Traits std::basic_ostream_CharT, _Traits::operator(int) [with _CharT =
char, _Traits = std::char_traitschar]
/usr/include/c++/4.6/bits/ostream.tcc:107:5: note: no
[Bug target/53682] [4.7/4.8 Regression] ICE in cselib_lookup (SEGV) on i586-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53682 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-15 CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |4.7.2 Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-15 11:41:37 UTC --- Probably started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=182760
[Bug libstdc++/53683] cout doesn't support std::u16string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53683 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-15 12:00:15 UTC --- (In reply to comment #0) If, in the test program, std::u16string is replaced with std::u32string, the program is successfully compiled. That's surprising - it shouldn't work (and doesn't with G++ 4.7) It would be nice if std::cout also supported std::u16string objects. std::cout is for char You could use std::wstring_convert to convert a std::u16string to std::string for output (but GCC doesn't have wsring_convert yet, I plan to work on it next week.)
[Bug target/53682] [4.7/4.8 Regression] ICE in cselib_lookup (SEGV) on i586-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53682 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-06-15 12:00:45 UTC --- Possible the second two calls of promote_debug_loc should be replaced by a loop over the locs, looking for the right l-loc that -g0 would have created in that case. Anyway, it needs to be debugged how exactly -g0 vs. -g behaves in these cases.
[Bug ada/53684] New: Cannot raise custom exceptions in configurable runtime mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53684 Bug #: 53684 Summary: Cannot raise custom exceptions in configurable runtime mode Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: lagu...@archeia.com According to the HIE docs, (http://docs.adacore.com/gnat-hie-docs/html/gnathie_ug_3.html#SEC8) it states when using a configurable runtime, exceptions declarations are valid. In an attempt to build a hello world kernel for i386 using FS GNAT 4.6 on Debian testing, it fails to build. Compile the test with: gnatmake -gnat2005 -g -a -x -gnatg -gnatec=./gnat.adc test.adb --RTS=. -cargs -m32 -march=i386 Results are: test.adb:5:04: construct not allowed in configurable run-time mode test.adb:5:04: file a-except.ads not found test.adb:5:04: entity Ada.Exceptions.Raise_Exception not available gnatmake: test.adb compilation error Expected results: What is expected is that a-except is not looked for and the exception is caught using the local handler or redirected to last_chance_handler. Has been tested with GNAT GPL 2011, same results. Asked a friend with access to GNAT PRO 7.1, same results again. My System: $ uname -a Linux rogue 3.2.0-2-amd64 #1 SMP Mon May 21 17:45:41 UTC 2012 x86_64 GNU/Linux $ gnat GNAT 4.6 Copyright 1996-2010, Free Software Foundation, Inc. List of available commands gnat bind gnatbind gnat chop gnatchop gnat clean gnatclean gnat compilegnatmake -f -u -c gnat check gnatcheck gnat elim gnatelim gnat find gnatfind gnat krunch gnatkr gnat link gnatlink gnat list gnatls gnat make gnatmake gnat metric gnatmetric gnat name gnatname gnat preprocess gnatprep gnat pretty gnatpp gnat stack gnatstack gnat stub gnatstub gnat xref gnatxref All commands except chop, krunch and preprocess accept project file switches -vPx, -Pprj and -Xnam=val
[Bug libstdc++/53683] cout doesn't support std::u16string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53683 --- Comment #2 from Rui Maciel rui.maciel at gmail dot com 2012-06-15 13:08:01 UTC --- (In reply to comment #1) (In reply to comment #0) If, in the test program, std::u16string is replaced with std::u32string, the program is successfully compiled. That's surprising - it shouldn't work (and doesn't with G++ 4.7) It would be nice if std::cout also supported std::u16string objects. std::cout is for char You could use std::wstring_convert to convert a std::u16string to std::string for output (but GCC doesn't have wsring_convert yet, I plan to work on it next week.) You are absolutely right. I assumed that the definition of std::ostream also included definitions for operator that supported definitions of basic_stringcharT with a charT other than char, but it appears my assumptions were completely baseless. In that case, is it possible to tweak gcc to return a friendlier error message? The current one is a bit long and frightening. For example, is it possible define an operator that throws a compiler error with any message similar to basic_ostreamcharT,traits doesn't provide an operator for basic_stringsome_other_T? This sort of error message would be a whole lot easier to digest.
[Bug tree-optimization/53636] SLP may create invalid unaligned memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53636 --- Comment #1 from Ulrich Weigand uweigand at gcc dot gnu.org 2012-06-15 13:30:40 UTC --- Author: uweigand Date: Fri Jun 15 13:30:36 2012 New Revision: 188661 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188661 Log: gcc/ PR tree-optimization/53636 * tree-vect-data-refs.c (vect_compute_data_ref_alignment): Verify stride when doing basic-block vectorization. gcc/testsuite/ PR tree-optimization/53636 * gcc.target/arm/pr53636.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr53636.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug c++/52672] internal compiler error: in cxx_eval_indirect_ref, at cp/semantics.c:6766
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52672 nightstrike nightstrike at gmail dot com changed: What|Removed |Added CC||nightstrike at gmail dot ||com --- Comment #8 from nightstrike nightstrike at gmail dot com 2012-06-15 14:04:06 UTC --- This fails on x86_64-w64-mingw32 with the following excess errors: /opt/x/gcc/gcc/testsuite/g++.dg/cpp0x/constexpr-52672.C:7:54: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] /opt/x/gcc/gcc/testsuite/g++.dg/cpp0x/constexpr-52672.C:8:64: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] /opt/x/gcc/gcc/testsuite/g++.dg/cpp0x/constexpr-52672.C:8:65: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
[Bug bootstrap/53681] s390 bootstrap failure since 187965
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53681 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #4 from Michael Matz matz at gcc dot gnu.org 2012-06-15 14:21:05 UTC --- I don't see how r187965 could cause this, but I do see the problem. mark_sym_for_renaming (called via the s390 va_arg_expr expander) is called during, well, gimplification from GENERIC. At that point SSA isn't initialized yet, so cfun-gimple_df is still NULL, and so SYMS_TO_RENAME gives a segfault. You either have to guard the call to mark_sym_for_renaming with gimple_in_ssa_p(), or get rid of the call alltogether. I don't see how new va_arg expressions would be generated during SSA optimizers, so the latter solution would be safe. No other backend calls mark_sym_for_renaming either, so just remove it.
[Bug fortran/53685] New: surprising warns about transfer with explicit character range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53685 Bug #: 53685 Summary: surprising warns about transfer with explicit character range Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ajma...@googlemail.com Fortran code: subroutine test() implicit none character(len=4) :: record_type integer :: i i=transfer(record_type,i) ! no warning i=transfer(record_type(1:4),i) ! warning return end gfortran -c -Wsurprising test.f test.f:6.17: i=transfer(record_type(1:4),i) ! warning 1 Warning: Intrinsic TRANSFER at (1) has partly undefined result: source size 0 result size 4 When the string length is explicitly given the compiler thinks it is length 0, even though it is the same length as the previous instance. Seen with 4.7.1 built from source.
[Bug libstdc++/53683] cout doesn't support std::u16string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53683
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-15
14:39:32 UTC ---
I don't know where you got that error message, I get a much simpler one.
Trunk shows:
u.cc: In function 'int main()':
u.cc:8:18: error: cannot bind 'std::ostream {aka std::basic_ostreamchar}'
lvalue to 'std::basic_ostreamchar'
std::cout test std::endl;
^
In file included from /home/jwakely/gcc/4.8/include/c++/4.8.0/iostream:40:0,
from u.cc:1:
/home/jwakely/gcc/4.8/include/c++/4.8.0/ostream:604:5: error: initializing
argument 1 of 'std::basic_ostream_CharT, _Traits
std::operator(std::basic_ostream_CharT, _Traits, const _Tp) [with _CharT
= char; _Traits = std::char_traitschar; _Tp = std::basic_stringchar16_t]'
operator(basic_ostream_CharT, _Traits __os, const _Tp __x)
^
4.6 is similar but without the caret diagnostics and with a longer path to the
header.
That error isn't very helpful really, but is because the only match is the
catch all template for writing to rvalue streams, which can't be used because
std::cout is an lvalue:
templatetypename _CharT, typename _Traits, typename _Tp
inline basic_ostream_CharT, _Traits
operator(basic_ostream_CharT, _Traits __os, const _Tp __x)
But it's a lot better than the error you pasted, which I don't recognise.
I'll look into trying to add some constraints to the templates to improve
diagnostics.
[Bug middle-end/53590] compiler fails to generate SIMD instruction for FP division
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53590 --- Comment #11 from Georg georggcc at googlemail dot com 2012-06-15 14:54:21 UTC --- (In reply to comment #10) Fixed on the mainline. Perfect result when run with -fdelete-dead-exceptions, or when run without the switch (i.e., switches as before). Adding -fno-delete-dead-exceptions, I see the old (expected?) redundant ..., divsd, movapd, divpd, divsd, movapd, ... sequence, though. Just mentioning.
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #58 from Michael Matz matz at gcc dot gnu.org 2012-06-15 14:56:33 UTC --- Author: matz Date: Fri Jun 15 14:56:26 2012 New Revision: 188667 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188667 Log: PR middle-end/38474 * cfgexpand.c (add_alias_set_conflicts): Remove. (expand_used_vars): Don't call it. (aggregate_contains_union_type): Remove. * function.c (n_temp_slots_in_use): New static data. (make_slot_available, assign_stack_temp_for_type): Update it. (init_temp_slots): Zero it. (remove_unused_temp_slot_addresses): Use it for quicker removal. (remove_unused_temp_slot_addresses_1): Use htab_clear_slot. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/function.c
[Bug tree-optimization/53636] SLP may create invalid unaligned memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53636 --- Comment #2 from Ulrich Weigand uweigand at gcc dot gnu.org 2012-06-15 15:11:51 UTC --- Now fixed on mainline; still fails on 4.7. (While the bug is probably latent even earlier, this particular test case does not crash on 4.6.)
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #59 from Michael Matz matz at gcc dot gnu.org 2012-06-15 15:12:59 UTC --- There should be no compile performance problems in expand anymore. The alias stmt walker as used from IPA remains a problem, though.
[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 --- Comment #3 from Niall Douglas s_gccbugzilla at nedprod dot com 2012-06-15 15:13:37 UTC --- (In reply to comment #1) There's no point differentiating the gnu variants, they don't have any ABI impact. They don't have any ABI impact that we know of at the present time in this present generation of GCCs. As a debug aid that's likely to be there from now on and forever, who's to say about the future. Better to cover all bases now I'd say, just in case. This could (and probably should) be done in the library because the output of G++ is ABI compatible, it's only standard library components that are not. There are no shortage of third party libraries which enable special new stuff when compiled with GNU additions turned on. Also, the ISO C++ standard is quite clear that ABI between C++03 and C++11 compiled code is not guaranteed in the case where C++11 libraries/shared objects are linked into a C++03 compiled program. Indeed, really an error ought to be thrown if this happens for safety's sake, a warning as a minimum. Niall
[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 --- Comment #4 from Niall Douglas s_gccbugzilla at nedprod dot com 2012-06-15 15:23:21 UTC --- (In reply to comment #2) you can use -frecord-gcc-switches to detect mixed objects in linked library. Indeed, one could grok the .text section this adds, parse the command line and determine the build settings. However, this is why that would be a poorer choice: 1. Last time I looked record-gcc-switches only works with ELF outputs. 2. You can't debug prebuilt system provided shared objects as these won't have been compiled with -frecord-gcc-switches. 3. Parsing an ELF .text section is hard from within programs as compared to dlsym(dll, __gplusplus_std_cplusplus11) 4. Automated build config tools already have machinery for seeing if some symbol is exported by some binary object. That lets the proposed system fit into said existing machinery easily, whereas groking .text sections is considerably harder. For example, an automated build config might adapt how it builds itself according to how system provided shared libraries were built. 5. Future GCC command line switches may change. Indeed, one day -std will default to c++11, not c++98. When that happens your .text section parsing will break. The proposed system doesn't have that problem and is more futureproof. Niall
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #60 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-06-15 15:26:20 UTC --- (In reply to comment #59) There should be no compile performance problems in expand anymore. The alias stmt walker as used from IPA remains a problem, though. Thanks... expand is now indeed essentially gone from the timing report. gfortran -ftime-report -ffree-line-length-512 -g -c testcase.f90 Execution times (seconds) phase setup : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 243 kB ( 0%) ggc phase parsing : 3.57 ( 9%) usr 0.06 ( 7%) sys 3.63 ( 9%) wall 47592 kB ( 7%) ggc phase cgraph: 36.49 (91%) usr 0.86 (93%) sys 37.34 (91%) wall 647436 kB (93%) ggc phase generate : 36.50 (91%) usr 0.86 (93%) sys 37.36 (91%) wall 647838 kB (93%) ggc garbage collection : 1.04 ( 3%) usr 0.00 ( 0%) sys 1.04 ( 3%) wall 0 kB ( 0%) ggc callgraph construction : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 15909 kB ( 2%) ggc callgraph optimization : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 201 kB ( 0%) ggc cfg construction: 0.08 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 7 kB ( 0%) ggc cfg cleanup : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc CFG verifier: 1.26 ( 3%) usr 0.00 ( 0%) sys 1.25 ( 3%) wall 0 kB ( 0%) ggc trivially dead code : 0.43 ( 1%) usr 0.00 ( 0%) sys 0.41 ( 1%) wall 0 kB ( 0%) ggc df scan insns : 0.98 ( 2%) usr 0.24 (26%) sys 1.24 ( 3%) wall 11 kB ( 0%) ggc df live regs: 0.58 ( 1%) usr 0.01 ( 1%) sys 0.57 ( 1%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.43 ( 1%) usr 0.01 ( 1%) sys 0.45 ( 1%) wall 19416 kB ( 3%) ggc register information: 0.18 ( 0%) usr 0.00 ( 0%) sys 0.18 ( 0%) wall 0 kB ( 0%) ggc alias analysis : 0.15 ( 0%) usr 0.00 ( 0%) sys 0.14 ( 0%) wall 8337 kB ( 1%) ggc rebuild jump labels : 0.22 ( 1%) usr 0.00 ( 0%) sys 0.21 ( 1%) wall 0 kB ( 0%) ggc parser (global) : 3.57 ( 9%) usr 0.06 ( 7%) sys 3.63 ( 9%) wall 47587 kB ( 7%) ggc inline heuristics : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 54 kB ( 0%) ggc tree gimplify : 0.51 ( 1%) usr 0.01 ( 1%) sys 0.51 ( 1%) wall 26304 kB ( 4%) ggc tree eh : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 39 kB ( 0%) ggc tree CFG construction : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 190 kB ( 0%) ggc tree CFG cleanup: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc tree find ref. vars : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 3263 kB ( 0%) ggc tree PHI insertion : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree SSA other : 0.01 ( 0%) usr 0.01 ( 1%) sys 0.02 ( 0%) wall 18 kB ( 0%) ggc tree operand scan : 0.03 ( 0%) usr 0.03 ( 3%) sys 0.05 ( 0%) wall 118 kB ( 0%) ggc tree SSA verifier : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 0 kB ( 0%) ggc tree STMT verifier : 0.56 ( 1%) usr 0.05 ( 5%) sys 0.63 ( 2%) wall 0 kB ( 0%) ggc callgraph verifier : 0.25 ( 1%) usr 0.00 ( 0%) sys 0.27 ( 1%) wall 0 kB ( 0%) ggc out of ssa : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc expand vars : 1.02 ( 3%) usr 0.02 ( 2%) sys 1.03 ( 3%) wall 10086 kB ( 1%) ggc expand : 2.03 ( 5%) usr 0.12 (13%) sys 2.18 ( 5%) wall 249774 kB (36%) ggc post expand cleanups: 0.14 ( 0%) usr 0.01 ( 1%) sys 0.14 ( 0%) wall 1744 kB ( 0%) ggc integrated RA : 10.75 (27%) usr 0.15 (16%) sys 10.93 (27%) wall 128826 kB (19%) ggc reload : 5.56 (14%) usr 0.16 (17%) sys 5.77 (14%) wall 123587 kB (18%) ggc thread pro- epilogue : 2.65 ( 7%) usr 0.00 ( 0%) sys 2.64 ( 6%) wall 198 kB ( 0%) ggc machine dep reorg : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc final : 3.11 ( 8%) usr 0.04 ( 4%) sys 3.15 ( 8%) wall 7227 kB ( 1%) ggc symout : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 4914 kB ( 1%) ggc rest of compilation : 2.46 ( 6%) usr 0.00 ( 0%) sys 2.39 ( 6%) wall 47578 kB ( 7%) ggc unaccounted todo: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc verify RTL sharing : 1.49 ( 4%) usr 0.00 ( 0%) sys 1.48 ( 4%) wall 0 kB ( 0%) ggc TOTAL : 40.09 0.9241.02 695674 kB
[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-15 15:37:34 UTC --- (In reply to comment #3) (In reply to comment #1) There's no point differentiating the gnu variants, they don't have any ABI impact. They don't have any ABI impact that we know of at the present time in this present generation of GCCs. As a debug aid that's likely to be there from now on and forever, who's to say about the future. The GCC maintainers are to say. Better to cover all bases now I'd say, just in case. There's no point adding (and maintaining) yet another feature to handle hypothetical differences which *by*design* should not happen. Far more relevant than c++11 vs gnu++11 is -fabi-version=n, which your scheme doesn't cover. This could (and probably should) be done in the library because the output of G++ is ABI compatible, it's only standard library components that are not. There are no shortage of third party libraries which enable special new stuff when compiled with GNU additions turned on. Not GCC's problem, and no different to libraries which enable new things when -fno-rtti or -fno-exceptions is used Also, the ISO C++ standard is quite clear that ABI between C++03 and C++11 compiled code is not guaranteed in the case where C++11 libraries/shared objects are linked into a C++03 compiled program. Indeed, really an error ought to be thrown if this happens for safety's sake, a warning as a minimum. [citation needed] ;) The standard says nothing about libraries/shared objects It's entirely possible to use G++ to build 100% ABI compatible applications using a mixture of -std=c++98 and -std=c++11 objects, if you don't use the parts of the standard library that are incompatible. A mandatory or warning would cause problems for anyone doing that.
[Bug ada/53686] New: gnatchop -r raises STORAGE_ERROR on all inputs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53686
Bug #: 53686
Summary: gnatchop -r raises STORAGE_ERROR on all inputs
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: georg...@googlemail.com
Given any unit, such as
package Unit is
pragma Pure (Unit);
end Unit;
in file unit.ada, gnatchop fails when run with -r (or -r -w):
$ PATH=${HOME}/mine/bin:/usr/bin:/bin gnatchop -r -v unit.ada
GNATCHOP 4.8.0 20120615 (experimental)
Copyright (C) 1998-2012, Free Software Foundation, Inc.
/home/bauhaus/mine/bin/gcc -c -x ada -gnats -gnatu unit.ada
splitting unit.ada into:
raised STORAGE_ERROR : stack overflow or erroneous memory access
$
${HOME}/mine has an installation of GCC Rev 188651.
An attempt at debugging hints at line 1605 in gnatchop.ada,
Reference : String :=
pragma Source_Reference (00,
Nam.all ); EOL.Str;
(gdb) ...
Program received signal SIGSEGV, Segmentation fault.
__memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:1955
1955../sysdeps/x86_64/multiarch/memcpy-ssse3.S: No such file or directory.
(gdb) where
#0 __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:1955
#1 0x00451cff in gnatchop.write_source_reference_pragma (info=...,
line=1, file=0x775740, eol=..., success=optimized out) at
/home/bauhaus/src/gcc/trunk/gcc/ada/gnatchop.adb:1605
#2 0x00452efa in gnatchop.write_unit (source=..., num=num@entry=1,
ts_time=ts_time@entry=1339772574, write_bom=optimized out, sourceL=error
reading variable: Unhandled dwarf expression opcode 0xfa)
at /home/bauhaus/src/gcc/trunk/gcc/ada/gnatchop.adb:1740
#3 0x00456f94 in gnatchop.write_chopped_files (input=1) at
/home/bauhaus/src/gcc/trunk/gcc/ada/gnatchop.adb:1475
#4 gnatchop () at /home/bauhaus/src/gcc/trunk/gcc/ada/gnatchop.adb:1861
Linux newnews 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
$ uname -a
Linux newnews 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux
$ PATH=${HOME}/mine/bin:$PATH gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/bauhaus/mine/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/bauhaus/src/gcc/trunk/configure
--prefix=/home/bauhaus/mine --disable-nls --disable-libstdcxx-pch
--enable-languages=c,ada,c++,fortran LIBRARY_PATH=/usr/lib/x86_64-linux-gnu
Thread model: posix
gcc version 4.8.0 20120615 (experimental) (GCC)
[Bug go/53679] Build failure in libgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53679 --- Comment #1 from safety0ff.bugz at gmail dot com 2012-06-15 15:52:18 UTC --- Created attachment 27626 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27626 Allows me to compile it, I do know if there's any value if checking for errors writing to stdout
[Bug go/53679] Build failure in libgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53679 safety0ff.bugz at gmail dot com changed: What|Removed |Added Attachment #27626|Allows me to compile it, I |Allows me to compile it, I description|do know if there's any |do know if there's any |value if checking for |value if checking for |errors writing to stdout|errors writing to stderr --- Comment #1 from safety0ff.bugz at gmail dot com 2012-06-15 15:52:18 UTC --- Created attachment 27626 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27626 Allows me to compile it, I do know if there's any value if checking for errors writing to stderr
[Bug fortran/53685] surprising warns about transfer with explicit character range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53685 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-15 CC||burnus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-06-15 16:18:36 UTC --- Confirmed. The size is determined via target-memory.c's gfc_target_expr_size. There seems to be two issues: (a) A minor one that in the second case, the length of record_type is e-ts-u.cl-length == NULL instead of 4 (as one could be simply calculated). b) And the missing error handling for gfc_target_expr_size in gfc_calculate_transfer_sizes: There, the result size is error checked, namely: if (result_elt_size == 0) return FAILURE; But a similar line for source_size is lacking. Regarding (a): The question is whether one shouldn't set expr-ts.u.cl-length to expr-ref-next-...-u.ss.length for substrings. I don't know whether that messes with the CL cleanup or other issues, but it'd make handling substrings easier than checking whether there is a last_ref(expr)-u.ss.length. Patch for the second issue. --- a/gcc/fortran/check.c +++ b/gcc/fortran/check.c @@ -4003,2 +4003,4 @@ gfc_calculate_transfer_sizes (gfc_expr *source, gfc_expr *mold, gfc_expr *size, *source_size = gfc_target_expr_size (source); + if (source_size == 0) +return FAILURE;
[Bug go/53679] Build failure in libgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53679 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-06-15 16:41:53 UTC --- Actually this is due to your modifications to gcc to enable fority by default and glibc's bad idea that write needs to be check for error after each write.
[Bug c++/51033] generic vector subscript and shuffle support was not added to C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51033 --- Comment #27 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-06-15 16:43:44 UTC --- Author: ramana Date: Fri Jun 15 16:43:36 2012 New Revision: 188671 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188671 Log: 2012-06-15 Marc Glisse marc.gli...@inria.fr PR c++/51033 * c-typeck.c (c_build_vec_perm_expr): Move to c-family/c-common.c. * c-tree.h (c_build_vec_perm_expr): Move to c-family/c-common.h. cp/ 2012-06-15 Marc Glisse marc.gli...@inria.fr PR c++/51033 * semantics.c (literal_type_p): Handle VECTOR_TYPE. (potential_constant_expression_1): Handle VEC_PERM_EXPR. * parser.c (cp_parser_postfix_expression): Handle RID_BUILTIN_SHUFFLE. c-family 2012-06-15 Marc Glisse marc.gli...@inria.fr PR c++/51033 * c-common.h (c_build_vec_perm_expr): Move decl here. * c-common.c (c_build_vec_perm_expr): Move definition here. 2012-06-15 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR c++/51033 * c-c++-common/torture/vshuf-16.inc: Move from gcc.c-torture/execute/. * c-c++-common/torture/vshuf-2.inc: Likewise. * c-c++-common/torture/vshuf-4.inc: Likewise. * c-c++-common/torture/vshuf-8.inc: Likewise. * c-c++-common/torture/vshuf-main.inc: Likewise. * c-c++-common/torture/vshuf-v16hi.c: Likewise. * c-c++-common/torture/vshuf-v16qi.c: Likewise. * c-c++-common/torture/vshuf-v2df.c: Likewise. * c-c++-common/torture/vshuf-v2di.c: Likewise. * c-c++-common/torture/vshuf-v2sf.c: Likewise. * c-c++-common/torture/vshuf-v2si.c: Likewise. * c-c++-common/torture/vshuf-v4df.c: Likewise. * c-c++-common/torture/vshuf-v4di.c: Likewise. * c-c++-common/torture/vshuf-v4hi.c: Likewise. * c-c++-common/torture/vshuf-v4sf.c: Likewise. * c-c++-common/torture/vshuf-v4si.c: Likewise. * c-c++-common/torture/vshuf-v8hi.c: Likewise. * c-c++-common/torture/vshuf-v8qi.c: Likewise. * c-c++-common/torture/vshuf-v8si.c: Likewise. Added: trunk/gcc/testsuite/c-c++-common/torture/vshuf-16.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-16.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-2.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-2.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-4.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-4.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-8.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-8.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-main.inc - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-main.inc trunk/gcc/testsuite/c-c++-common/torture/vshuf-v16hi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v16hi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v16qi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v16qi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v2df.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2df.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v2di.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2di.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v2sf.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2sf.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v2si.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v2si.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4df.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4df.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4di.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4di.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4hi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4hi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4sf.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4sf.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v4si.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v4si.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v8hi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v8hi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v8qi.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v8qi.c trunk/gcc/testsuite/c-c++-common/torture/vshuf-v8si.c - copied unchanged from r188659, trunk/gcc/testsuite/gcc.c-torture/execute/vshuf-v8si.c Removed:
[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 --- Comment #6 from Niall Douglas s_gccbugzilla at nedprod dot com 2012-06-15 16:53:01 UTC --- (In reply to comment #5) They don't have any ABI impact that we know of at the present time in this present generation of GCCs. As a debug aid that's likely to be there from now on and forever, who's to say about the future. The GCC maintainers are to say. It's safer to fail safe. And no maintainer is omniscient. Better to cover all bases now I'd say, just in case. There's no point adding (and maintaining) yet another feature to handle hypothetical differences which *by*design* should not happen. There's the ideal world and there's the real world. This is a very likely ongoing real world problem whose fix requires perhaps five lines of new code - hardly a big new feature requiring umpteen lines of code. I'd write the patch myself except I'd put those five lines in the wrong place because GCC's code base is so monolithic. Technically, you could add it to the top of stddef.h or whatever is a guaranteed included library header: #if defined(__cpluscplus) and __cplusplus==201103L extern C void __gplusplus_std_cplusplus11() __attribute__ ((weak)); #elif defined(__cpluscplus) and __cplusplus==199711L extern C void __gplusplus_std_cplusplus97() __attribute__ ((weak)); #elif ... #else #error Unknown C++ variant, cannot set magic symbol #endif ... assuming that compiles which I can't test on this laptop. Far more relevant than c++11 vs gnu++11 is -fabi-version=n, which your scheme doesn't cover. ABI is a GCC issue :). I'd certainly recommend it for that too. You may need to bump ABI if needed to solve C++11 and C++03 interop and a way for checking for that would also be useful. There are no shortage of third party libraries which enable special new stuff when compiled with GNU additions turned on. Not GCC's problem, and no different to libraries which enable new things when -fno-rtti or -fno-exceptions is used Look, it's a debug aid, and if GCC offers special extra features then it's GCC's problem if libraries use them. In the future GCC is going to see lots of C++11 bugs submitted. You're going to ask the question are you *really* sure you compiled everything with C++11?. Right now they'll say yes, but they may well be wrong. This debug aid is as much for your future sanity as anything. Also, the ISO C++ standard is quite clear that ABI between C++03 and C++11 compiled code is not guaranteed in the case where C++11 libraries/shared objects are linked into a C++03 compiled program. Indeed, really an error ought to be thrown if this happens for safety's sake, a warning as a minimum. [citation needed] ;) :) ... I don't suppose you'd take my word as ISO SC22 convenor for Ireland would you? ;) No, it's fair enough, I only know that from watching the discussions on ISO and I have no idea if it's actually written in the final published standard. It is however written in Nicolai Josuttis' updated C++11 The C++ standard library in the chapter on C++11 core language changes. And if you think it through, there has to be in practice ABI breakage in 03 ABIs because no one could have anticipated during their design of what 11 would require [1]. [1]: This may not apply to GCC as it revised its ABI quite recently, and I'm sure its designers took into account likely future 11 requirements. The standard says nothing about libraries/shared objects I know only too well. I have an early draft for shared library implementation on my desk for WG14. It's too ambitious for WG14 as it explicitly adds interop for non-C languages. It's entirely possible to use G++ to build 100% ABI compatible applications using a mixture of -std=c++98 and -std=c++11 objects, if you don't use the parts of the standard library that are incompatible. A mandatory or warning would cause problems for anyone doing that. Sure. Any C++ implementation may choose to go beyond what is needed. However, I personally can see lots of potential for monsters to lurk there. I think the proposed debug aid will save a lot of time for a lot of people in the long run, and for the cost of implementation and almost nil cost of maintenance I'd just go ahead and implement it if I were ye. Which I'm not, so all I can do is try to persuade and advocate. Niall
[Bug fortran/53685] surprising warns about transfer with explicit character range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53685 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-06-15 17:02:44 UTC --- (In reply to comment #1) (a) A minor one that in the second case, the length of record_type is e-ts-u.cl-length == NULL instead of 4 (as one could be simply calculated). That should be fixed by the following patch (untested). The question is why e-ref-type == REF_SUBSTRING was excluded if (and only if) it was the first reference? The whole condition plus function call was added 2007-08-31 in the big patch for PR fortran/31879, PR fortran/31197, PR fortran/31258 and PR fortran/32703: http://gcc.gnu.org/viewcvs?view=revisionrevision=127939 --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -6325,4 +6325,3 @@ gfc_resolve_expr (gfc_expr *e) - if (e-ts.type == BT_CHARACTER e-ts.u.cl == NULL e-ref - e-ref-type != REF_SUBSTRING) + if (e-ts.type == BT_CHARACTER e-ts.u.cl == NULL e-ref) gfc_resolve_substring_charlen (e);
[Bug rtl-optimization/53687] New: _mm_cmpistri generates redundant movslq %ecx,%rcx on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53687
Bug #: 53687
Summary: _mm_cmpistri generates redundant movslq %ecx,%rcx on
x86-64
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jbem...@zonnet.nl
Compile the following strcmp() implementation with -O5 -march=corei7
#include nmmintrin.h
static inline int __strcmp(const char * cs, const char * ct)
{
// Works for both 32-bit and 64-bit code
// see http://www.strchr.com/strcmp_and_strlen_using_sse_4.2
long diff = cs-ct;
long nextbytes = 16;
ct -= 16;
loop:
__m128i ct16cs = _mm_loadu_si128( (const __m128i *) (ct += nextbytes) );
int offset = _mm_cmpistri( ct16cs, * (const __m128i *) (ct+diff),
_SIDD_CMP_EQUAL_EACH | _SIDD_NEGATIVE_POLARITY );
__asm__ __volatile__ goto( ja %l[loop] \n jc %l[not_equal] : : :
memory : loop, not_equal );
return 0;
not_equal:
return ct[diff+offset] - ct[offset];
}
GCC generates the following code:
004007c0 strcmp:
4007c0:48 29 f7 sub%rsi,%rdi
4007c3:48 83 ee 10 sub$0x10,%rsi
4007c7:48 83 c6 10 add$0x10,%rsi
4007cb:f3 0f 6f 06 movdqu (%rsi),%xmm0
4007cf:66 0f 3a 63 04 3e 18 pcmpistri $0x18,(%rsi,%rdi,1),%xmm0
4007d6:77 efja 4007c7 strcmp+0x7
4007d8:72 06jb 4007e0 strcmp+0x20
4007da:31 c0xor%eax,%eax
4007dc:c3 retq
4007dd:0f 1f 00 nopl (%rax)
* 4007e0:48 63 c9 movslq %ecx,%rcx
4007e3:48 01 f7 add%rsi,%rdi
4007e6:0f be 04 0f movsbl (%rdi,%rcx,1),%eax
4007ea:0f be 14 0e movsbl (%rsi,%rcx,1),%edx
4007ee:29 d0sub%edx,%eax
4007f0:c3 retq
4007f1:66 66 66 66 66 66 2e data32 data32 data32 data32 data32 nopw
4007f8:0f 1f 84 00 00 00 00%cs:0x0(%rax,%rax,1)
4007ff:00
The movslq instruction is redundant, because pcmpistri clears the upper bits
of RCX when generating an index (verified using gdb)
[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-15
17:46:51 UTC ---
(In reply to comment #6)
Technically, you could add it to the top of stddef.h or whatever is a
guaranteed included library header:
libstdc++'s bits/c++config.h would be the right place and as part of the std
lib the symbol should probably be named __glibcxx_blah
I think you'd also need an actual definition or nothing will be emitted for the
declaration alone:
#if __GXX_WEAK__
#if __cplusplus == 201103L
extern C void __glibcxx_std_cxx11() __attribute__((weak));
extern C void __glibcxx_std_cxx11() { }
#else if __cplusplus == 199711L
extern C void __glibcxx_std_cxx98() __attribute__((weak));
extern C void __glibcxx_std_cxx98() { }
#else
#warning Unknown C++ standard version
#endif
#endif
No, it's fair enough, I only know that from watching the discussions on ISO
and
I have no idea if it's actually written in the final published standard. It is
however written in Nicolai Josuttis' updated C++11 The C++ standard library
in the chapter on C++11 core language changes. And if you think it through,
there has to be in practice ABI breakage in 03 ABIs because no one could have
anticipated during their design of what 11 would require [1].
[1]: This may not apply to GCC as it revised its ABI quite recently, and I'm
sure its designers took into account likely future 11 requirements.
The current G++ ABI is eight years old and (modulo bugs) the same for c++98 and
c++11, see Bug 53646 comment 17
Again, the incompatibilities are in the library not the core language.
Whether that's generally true for other compilers is irrelevant here.
[Bug middle-end/53688] New: [4.8 Regression] 191.fma3d in SPEC CPU 2000 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53688 Bug #: 53688 Summary: [4.8 Regression] 191.fma3d in SPEC CPU 2000 miscompiled Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: rgue...@gcc.gnu.org On Linux/x86-64, revision 188429: http://gcc.gnu.org/ml/gcc-cvs/2012-06/msg00339.html miscompiles 191.fma3d in SPEC CPU 2000: gfortran -O2 -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin -DSPEC_CPU2000_LP64 fma3d.o beam_.o include_file_.o penta_.o segment_set_.o body_force_.o indx_.o periodic_bc_.o sliding_interface_.o constrained_node_.o layering_.o plate_pair_.o sliding_node_.o contact_node_.o location_.o platq_.o spot_weld_.o contact_surface_.o lsold_.o platt_.o spring_.o coord_.o massprop_.o pressure_bc_.o spring_bc_.o damper_.o material_.o property_.o state_variables_.o damper_bc_.o mean_stress_.o shared_common_data.o stress_.o displacement_bc_.o membq_.o qa_record_.o tabulated_function_.o element_set_.o membt_.o relink_scratch_.o tetra_.o enumerated_sets_.o motion_.o results_.o tied_bc_.o force_.o nodal_point_mass_.o rigid_body_.o truss_.o force_bc_.o node_.o rigid_body_mass_.o value_.o gauge1d_.o node_set_.o rigid_wall_bc_.o velocity_ic_.o gauge2d_.o nonreflecting_bc_.o section_1d_.o gauge3d_.o nrbc_data_.o section_2d_.o hexah_.o output_.o segment_.o lsold.o damper.o spring.o material_00.o material_10.o material_11.o material_17.o material_22.o material_25.o material_32.o material_33.o material_34a.o material_36.o material_38.o material_dm.o material_sp.o sort.o pdb.o beam.o membq.o membt.o penta.o tetra.o hexah.o platq.o truss.o platt.o fma1.o getirv.o relink.o output.o fma2.o partition.o strain.o slide.o -o fma3d Running 191.fma3d ref base lto default *** Miscompare of fma3d.out, see /export/gnu/import/git/gcc-test-spec-lto/spec/2000/x86_64/spec/benchspec/CFP2000/191.fma3d /run/0003/fma3d.out.mis
[Bug c/53689] New: [SH] GCC emits an invalid slot instruction for RTE (Return from Exception)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53689
Bug #: 53689
Summary: [SH] GCC emits an invalid slot instruction for RTE
(Return from Exception)
Classification: Unclassified
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mrko...@gmail.com
Under target (sh-elf) big-endian SuperH-2 (SH7604) (options -m2 -mb
-fno-omit-frame-pointer).
When defining an interrupt handler:
static void __attribute__ ((interrupt_handler))
foo(void)
{
}
GCC 4.5.3 emits the following:
_foo:
0:2f e6 mov.lr14,@-r15
2:6e f3 movr15,r14
4:6f e3 movr14,r15
6:00 2b rte
8:6e f6 mov.l@r15+,r14
How to generate the interrupt:
int
main(int argc, char *argv[])
{
__asm__ __volatile__ (trapa #32\n
tst #0, r0);
return 0;
}
the TRAPA instruction pushes both the SR and PC register values onto the stack
before jumping the interrupt handler foo().
Upon exiting foo(), with RTE, the delay slot is NOT executed first. Instead,
RTE pops both the SR and PC register off the stack, then the slot instruction
is executed.
The (hack) solution is:
static void __attribute__ ((interrupt_handler))
foo(void)
{
__asm__ __volatile__ (mov.l @r15+, r14\n
rte\n
nop);
}
[Bug middle-end/53688] [4.8 Regression] 191.fma3d in SPEC CPU 2000 miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53688 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||areg.melikadamyan at gmail ||dot com Target Milestone|--- |4.8.0
[Bug c++/52816] [C++11] Access to private members inside decltype in the signature of a member template causes access control error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52816 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-15 Summary|Access to private members |[C++11] Access to private |inside decltype in the |members inside decltype in |signature of a member |the signature of a member |template causes access |template causes access |control error |control error Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-15 18:43:38 UTC --- confirmed
[Bug c++/53690] New: \u0000 and \U00000000 are wrong encoded as U+0001.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53690
Bug #: 53690
Summary: \u and \U are wrong encoded as U+0001.
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kenn...@gmail.com
Tested with gcc 4.7 and 4.5 (via ideone)
~~~
#include cstdint
#include cstdio
int main() {
uint32_t a = U'\U';
uint32_t b = U'\u';
uint32_t c = U'\x00';
uint32_t d = U'\0';
uint16_t e = u'\U';
uint16_t f = u'\u';
uint16_t g = u'\x00';
uint16_t h = u'\0';
printf(%x %x %x %x %x %x %x %x\n, a, b, c, d, e, f, g, h);
return 0;
}
// Compile with:
//
// g++ -std=c++11 x.cpp
~~~
This program prints 1 1 0 0 1 1 0 0, but the expected output should be 0 0 0
0 0 0 0 0.
gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7-20120505/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold
--enable-ld=default --enable-plugin --with-plugin-ld=ld.gold
--with-linker-hash-style=gnu --enable-multilib --disable-libssp
--disable-build-with-cxx --disable-build-poststage1-with-cxx
--enable-checking=release --with-fpmath=sse
Thread model: posix
gcc version 4.7.0 20120505 (prerelease) (GCC)
[Bug bootstrap/53675] [4.8 Regression] bootstrap fails on netbsd5.1 due to unsupported dwarf4 info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53675
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-15
19:43:30 UTC ---
Created attachment 27627
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27627
Build log with new binutils
Using a newer binutils (2.22) the errors about dwarf4 are gone, but the
multiple definition errors remain.
GCC still shouldn't be issuing DWARF4 info when the linker doesn't support it
and --with-dwarf2 is used, but that's not the problem.
Every file that includes mutex and uses std::call_once gets a multiple
definition error for the lambda expression on line 815
../src/c++11/.libs/libc++11convenience.a(future.o): In function `operator()':
/home/jwakely/build/x86_64-unknown-netbsd5.1/libstdc++-v3/include/mutex:815:
multiple definition of `void std::call_oncevoid (std::thread::*)(),
std::reference_wrapperstd::thread (std::once_flag, void
(std::thread::*)(),
std::reference_wrapperstd::thread)::{lambda()#1}::_FUN()'
.libs/compatibility-thread-c++0x.o:/home/jwakely/build/x86_64-unknown-netbsd5.1/libstdc++-v3/include/mutex:815:
first defined here
I'll try to reproduce this on other platforms by using --disable-tls, so that
code path is taken.
[Bug c++/53672] gcc/branches/cilkplus does not like C++ spawn (when optimized)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53672 --- Comment #4 from bviyer at gcc dot gnu.org 2012-06-15 19:44:04 UTC --- Author: bviyer Date: Fri Jun 15 19:43:57 2012 New Revision: 188680 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=188680 Log: This patch fixes bug PR 53672. 2012-06-15 Balaji V. Iyer balaji.v.i...@intel.com * dwarf2out.c (dwarf2out_function_decl): Added a check for spawn helper. Modified: branches/cilkplus/gcc/ChangeLog.cilk branches/cilkplus/gcc/dwarf2out.c
[Bug c++/53672] gcc/branches/cilkplus does not like C++ spawn (when optimized)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53672 --- Comment #5 from Balaji V. Iyer bviyer at gmail dot com 2012-06-15 19:46:13 UTC --- Hello John, The revision mentioned above should fix this problem. Thanks, Balaji V. Iyer.
[Bug fortran/53691] New: ICE in LAPACK 3.4.1 cgbrfsx.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53691 Bug #: 53691 Summary: ICE in LAPACK 3.4.1 cgbrfsx.f Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fo...@rmki.kfki.hu fl_g77 -c -m64 -mtune=generic -Wall -Wstrict-aliasing=3 -O3 -fomit-frame-pointer -fPIC cgbrfsx.f cgbrfsx.f:519.23: REF_TYPE = PARAMS( LA_LINRX_ITREF_I ) 1 Warning: Possible change of value in conversion from REAL(4) to INTEGER(4) at (1) f951: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. fl_g77 -v: Using built-in specs. COLLECT_GCC=fl_g77 COLLECT_LTO_WRAPPER=/home/devel/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-4.7.1/configure --prefix=/home/devel --build=x86_64-pc-linux-gnu --enable-languages=c,c++,fortran --enable-long-long --enable-threads --enable-__cxa_atexit --with-gmp=/home/devel --with-mpfr=/home/devel --without-ppl --without-cloog --disable-multilib --disable-nls --program-suffix=-4.7.1 Thread model: posix gcc version 4.7.1 (GCC)
[Bug debug/53671] [4.8 Regression] Many guality test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-06-15 AssignedTo|unassigned at gcc dot |aoliva at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-06-15 20:20:13 UTC --- I see the drap and some of the pr36728-1 fails in my test logs. I don't understand how I failed to notice them when comparing results; I probably mistakenly used an already-failing baseline. I'll look into this, thanks.
[Bug fortran/53692] New: OPTIONAL: Scalarizing over the wrong array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53692 Bug #: 53692 Summary: OPTIONAL: Scalarizing over the wrong array Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: mik...@gcc.gnu.org Blocks: 50981 The following program of Daniel C Chen fails due to invalid OPTIONAL handling: The scalarizer uses the first array instead of the first array belonging to a nonoptional argument. Cf. http://j3-fortran.org/pipermail/j3/2012-June/005356.html See also: 12.5.2.12p3(6), An optional dummy argument that is not present is subject to the following restrictions. ... (6) If it is an array, it shall not be supplied as an actual argument to an elemental procedure unless an array of the same rank is supplied as an actual argument corresponding to a nonoptional dummy argument of that elemental procedure. Untested draft patch. I think one might need to have a fall back if there is no actual argument (which is an array) belonging to a nonoptional dummy. In that case (cf. above) one can assume that the first array in the list has to be present. --- a/gcc/fortran/trans-array.c +++ b/gcc/fortran/trans-array.c @@ -4356,3 +4356,4 @@ set_loop_bounds (gfc_loopinfo *loop) || ss_type == GFC_SS_TEMP - || ss_type == GFC_SS_REFERENCE) + || ss_type == GFC_SS_REFERENCE + || ss-info-can_be_null_ref) continue; Program main implicit none integer :: arr(2) arr = [ 1, 2 ] call sub1(arg2=arr) contains subroutine sub1(arg1,arg2) integer, optional :: arg1(:) integer :: arg2(:) print *,fun1 (arg1, arg2) if (size (fun1 (arg1, arg2)) /= 2) call abort() if (any (fun1 (arg1, arg2) /= [1,2])) call abort() end subroutine elemental function fun1(arg1,arg2) integer,intent(in), optional :: arg1 integer,intent(in) :: arg2 integer :: fun1 fun1 = arg2 end function end program
[Bug c++/53690] [C++11] \u0000 and \U00000000 are wrongly encoded as U+0001.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53690 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-15 Version|unknown |4.8.0 Summary|\u and \U are |[C++11] \u and |wrongly encoded as U+0001. |\U are wrongly ||encoded as U+0001. Ever Confirmed|0 |1 Known to fail||4.6.3, 4.7.1, 4.8.0 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-15 20:48:07 UTC --- confirmed
[Bug fortran/53691] [4.7/4.8 Regression] ICE in LAPACK 3.4.1 cgbrfsx.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53691 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-06-15 Summary|ICE in LAPACK 3.4.1 |[4.7/4.8 Regression] ICE in |cgbrfsx.f |LAPACK 3.4.1 cgbrfsx.f Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-06-15 20:50:56 UTC --- Confirmed with only -Wall. r176696 is OK, r177649 gives the segmentation fault. The backtrace for trunk is #0 gfc_calculate_transfer_sizes (source=0x142275aa0, mold=0x142276350, size=0x142276110, source_size=0x7fff5fbfce80, result_size=0x7fff5fbfce88, result_length_p=0x0) at /opt/mp/include/gmp.h:1745 #1 0x0001fa59 in gfc_check_transfer (source=0x142275aa0, mold=0x142276350, size=0x142276110) at ../../work/gcc/fortran/check.c:4070 #2 0x00010003a405 in check_specific (specific=0x142829e28, expr=0x1422761d0, error_flag=0) at ../../work/gcc/fortran/intrinsic.c:3916 #3 0x000100046f67 in gfc_intrinsic_func_interface (expr=0x1422761d0, error_flag=0) at ../../work/gcc/fortran/intrinsic.c:4132 #4 0x0001000863fa in gfc_resolve_expr (e=value optimized out) at ../../work/gcc/fortran/resolve.c:2335 #5 0x000100086d39 in resolve_actual_arglist (arg=value optimized out, ptype=value optimized out, no_formal_args=value optimized out) at ../../work/gcc/fortran/resolve.c:1774 #6 0x0001000874e3 in resolve_call (c=value optimized out) at ../../work/gcc/fortran/resolve.c:3691 #7 0x00010008d66e in resolve_code (code=value optimized out, ns=value optimized out) at ../../work/gcc/fortran/resolve.c:9533 #8 0x00010008d1ec in gfc_resolve_blocks (b=value optimized out, ns=value optimized out) at ../../work/gcc/fortran/resolve.c:9103 #9 0x00010008d366 in resolve_code (code=value optimized out, ns=value optimized out) at ../../work/gcc/fortran/resolve.c:9372 #10 0x00010008d1ec in gfc_resolve_blocks (b=value optimized out, ns=value optimized out) at ../../work/gcc/fortran/resolve.c:9103 #11 0x00010008d366 in resolve_code (code=value optimized out, ns=value optimized out) at ../../work/gcc/fortran/resolve.c:9372 #12 0x00010008fc84 in resolve_codes (ns=value optimized out) at ../../work/gcc/fortran/resolve.c:14044 #13 0x00010007f868 in gfc_resolve (ns=value optimized out) at ../../work/gcc/fortran/resolve.c:14071 #14 0x00010007514b in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4387 #15 0x0001000b4216 in gfc_be_parse_file () at ../../work/gcc/fortran/f95-lang.c:191 #16 0x00010072ada1 in toplev_main (argc=3, argv=0x7fff5fbfd750) at ../../work/gcc/toplev.c:550 #17 0x000118c4 in start ()
[Bug rtl-optimization/53533] [4.7/4.8 regression] vectorization causes loop unrolling test slowdown as measured by Adobe's C++Benchmark
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53533 --- Comment #18 from Richard Henderson rth at gcc dot gnu.org 2012-06-15 21:04:49 UTC --- See comments in http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01081.html It's not the vectorization costing, as previously suggested.
[Bug fortran/53691] [4.7/4.8 Regression] ICE in LAPACK 3.4.1 cgbrfsx.f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53691 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-06-15 21:23:42 UTC --- Reduced test case SUBROUTINE CGBRFSX(N, RWORK) INTEGER N REAL RWORK(*) REAL ZERO PARAMETER (ZERO = 0.0E+0) call foo(TRANSFER (RWORK(1:2*N), (/ (ZERO, ZERO) /), N)) end It yields a segmentation fault when compiled with -Wsurprising.
[Bug c++/53565] [4.8 Regression] FAIL: libgomp.c++/for-7.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53565 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||jakub at redhat dot com --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-06-15 21:56:49 UTC --- This is indeed caused/exposed by http://gcc.gnu.org/viewcvs?view=revisionsortby=daterevision=188116
[Bug go/53679] Build failure in libgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53679
--- Comment #3 from Allan McRae allan at archlinux dot org 2012-06-15
22:36:54 UTC ---
Just to be clear, I have not modified the compiler to enable fortify by
default, but it is in my CFLAGS...
As this is the only place that glibc's decision to enforce a check on the
return value of write causes the build to fail with these CFLAGS, it would be
nice to include the posted work-around, or equivalently:
- runtime_write(2, v, n)
+ if(runtime_write(2, v, n)) {}
[Bug c++/53693] New: [4.7 regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1438
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53693 Bug #: 53693 Summary: [4.7 regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1438 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: bear...@gmail.com Created attachment 27628 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27628 Code that generates ICE With 4.7.0 and up I'm now getting an ICE when building this bit of code with -O3 or -ftree-vectorize and the C++ compiler: $ g++ -O1 -ftree-vectorize ice.cxx -o ice ice.cxx: In function 'void filter_scanlines(void*, int, void*, int, int, int)': ice.cxx:2:1: internal compiler error: in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1438
