[Bug tree-optimization/54942] [4.8 Regression] ICE: OOM with -O3 -fno-cse-follow-jumps -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54942 Igor Zamyatin changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #2 from Igor Zamyatin 2012-10-17 05:30:47 UTC --- I see similar for r192219
[Bug tree-optimization/54942] [4.8 Regression] ICE: OOM with -O3 -fno-cse-follow-jumps -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54942 --- Comment #1 from Zdenek Sojka 2012-10-17 05:00:16 UTC --- ==21397== Invalid read of size 8 ==21397==at 0x8C1D76: unroll_and_peel_loops(int) (sbitmap.h:141) ==21397==by 0x8B25E7: rtl_unroll_and_peel_loops() (loop-init.c:378) ==21397==by 0x905069: execute_one_pass(opt_pass*) (passes.c:2320) ==21397==by 0x905494: execute_pass_list(opt_pass*) (passes.c:2381) ==21397==by 0x9054A6: execute_pass_list(opt_pass*) (passes.c:2382) ==21397==by 0x9054A6: execute_pass_list(opt_pass*) (passes.c:2382) ==21397==by 0x6C61C7: expand_function(cgraph_node*) (cgraphunit.c:1601) ==21397==by 0x6C8079: compile() (cgraphunit.c:1705) ==21397==by 0x6C8654: finalize_compilation_unit() (cgraphunit.c:2080) ==21397==by 0x5A25B7: c_write_global_declarations() (c-decl.c:10118) ==21397==by 0x9EC004: compile_file() (toplev.c:560) ==21397==by 0x9EDBB7: toplev_main(int, char**) (toplev.c:1866) ==21397==by 0x5A334BC: (below main) (in /lib64/libc-2.15.so) ==21397== Address 0x67ec2a0 is 0 bytes after a block of size 16 alloc'd ==21397==at 0x4C29A80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21397==by 0x117A6D7: xmalloc (xmalloc.c:147) ==21397==by 0x983061: sbitmap_alloc(unsigned int) (sbitmap.c:85) ==21397==by 0x8C1D60: unroll_and_peel_loops(int) (loop-unroll.c:467) ==21397==by 0x8B25E7: rtl_unroll_and_peel_loops() (loop-init.c:378) ==21397==by 0x905069: execute_one_pass(opt_pass*) (passes.c:2320) ==21397==by 0x905494: execute_pass_list(opt_pass*) (passes.c:2381) ==21397==by 0x9054A6: execute_pass_list(opt_pass*) (passes.c:2382) ==21397==by 0x9054A6: execute_pass_list(opt_pass*) (passes.c:2382) ==21397==by 0x6C61C7: expand_function(cgraph_node*) (cgraphunit.c:1601) ==21397==by 0x6C8079: compile() (cgraphunit.c:1705) ==21397==by 0x6C8654: finalize_compilation_unit() (cgraphunit.c:2080) ==21397==by 0x5A25B7: c_write_global_declarations() (c-decl.c:10118) ==21397==by 0x9EC004: compile_file() (toplev.c:560) ==21397==by 0x9EDBB7: toplev_main(int, char**) (toplev.c:1866) ==21397==by 0x5A334BC: (below main) (in /lib64/libc-2.15.so) ==21397== ==21397== Invalid write of size 8 ==21397==at 0x8C1D87: unroll_and_peel_loops(int) (sbitmap.h:141) ==21397==by 0x8B25E7: rtl_unroll_and_peel_loops() (loop-init.c:378) ==21397==by 0x905069: execute_one_pass(opt_pass*) (passes.c:2320) ==21397==by 0x905494: execute_pass_list(opt_pass*) (passes.c:2381) ==21397==by 0x9054A6: execute_pass_list(opt_pass*) (passes.c:2382) ==21397==by 0x9054A6: execute_pass_list(opt_pass*) (passes.c:2382) ==21397==by 0x6C61C7: expand_function(cgraph_node*) (cgraphunit.c:1601) ==21397==by 0x6C8079: compile() (cgraphunit.c:1705) ==21397==by 0x6C8654: finalize_compilation_unit() (cgraphunit.c:2080) ==21397==by 0x5A25B7: c_write_global_declarations() (c-decl.c:10118) ==21397==by 0x9EC004: compile_file() (toplev.c:560) ==21397==by 0x9EDBB7: toplev_main(int, char**) (toplev.c:1866) ==21397==by 0x5A334BC: (below main) (in /lib64/libc-2.15.so) ==21397== Address 0x67ec2a0 is 0 bytes after a block of size 16 alloc'd ==21397==at 0x4C29A80: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==21397==by 0x117A6D7: xmalloc (xmalloc.c:147) ==21397==by 0x983061: sbitmap_alloc(unsigned int) (sbitmap.c:85) ==21397==by 0x8C1D60: unroll_and_peel_loops(int) (loop-unroll.c:467) ==21397==by 0x8B25E7: rtl_unroll_and_peel_loops() (loop-init.c:378) ==21397==by 0x905069: execute_one_pass(opt_pass*) (passes.c:2320) ==21397==by 0x905494: execute_pass_list(opt_pass*) (passes.c:2381) ==21397==by 0x9054A6: execute_pass_list(opt_pass*) (passes.c:2382) ==21397==by 0x9054A6: execute_pass_list(opt_pass*) (passes.c:2382) ==21397==by 0x6C61C7: expand_function(cgraph_node*) (cgraphunit.c:1601) ==21397==by 0x6C8079: compile() (cgraphunit.c:1705) ==21397==by 0x6C8654: finalize_compilation_unit() (cgraphunit.c:2080) ==21397==by 0x5A25B7: c_write_global_declarations() (c-decl.c:10118) ==21397==by 0x9EC004: compile_file() (toplev.c:560) ==21397==by 0x9EDBB7: toplev_main(int, char**) (toplev.c:1866) ==21397==by 0x5A334BC: (below main) (in /lib64/libc-2.15.so) ==21397== cc1: out of memory allocating 17179869180 bytes after a total of 0 bytes
[Bug tree-optimization/54942] New: [4.8 Regression] ICE: OOM with -O3 -fno-cse-follow-jumps -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54942 Bug #: 54942 Summary: [4.8 Regression] ICE: OOM with -O3 -fno-cse-follow-jumps -funroll-loops Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28459 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28459 reduced testcase Compiler output: $ gcc -O3 -fno-cse-follow-jumps -funroll-loops testcase.c cc1: out of memory allocating 17179869180 bytes after a total of 733184 bytes The original testcase didn't have uninitialised variables... I can provide it if needed. Tested revisions: r192509 - fail r191586 - OK 4.7 r191640 - OK
[Bug c++/54941] New: do not print line/column numbers for :0:0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54941 Bug #: 54941 Summary: do not print line/column numbers for :0:0 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@gcc.gnu.org /home/manuel/test3/192379M/build/gcc/testsuite/g++2/../../g++ -B/home/manuel/test3/192379M/build/gcc/testsuite/g++2/../../ /home/manuel/test3/src/gcc/testsuite/g++.dg/lookup/new1.C -fno-diagnostics-show-caret -nostdinc++ -I/home/manuel/test3/192379M/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/manuel/test3/192379M/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -I/home/manuel/test3/src/libstdc++-v3/libsupc++ -I/home/manuel/test3/src/libstdc++-v3/include/backward -I/home/manuel/test3/src/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++11 -pedantic-errors -Wno-long-long -S -m32 -o new1.s /home/manuel/test3/src/gcc/testsuite/g++.dg/lookup/new1.C: In function 'int main()': /home/manuel/test3/src/gcc/testsuite/g++.dg/lookup/new1.C:8:20: error: no matching function for call to 'operator new(sizetype, int*)' /home/manuel/test3/src/gcc/testsuite/g++.dg/lookup/new1.C:8:20: note: candidate is: :0:0: note: void* operator new(unsigned int) :0:0: note: candidate expects 1 argument, 2 provided!
[Bug translation/37457] pp_base_format, pretty-print.c:529
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37457 Manuel López-Ibáñez changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #5 from Manuel López-Ibáñez 2012-10-17 00:10:24 UTC --- No feedback in a very long time.
[Bug other/54423] building trunk on Darwin 12.1 fails in building libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54423 Nenad Vukicevic changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Nenad Vukicevic 2012-10-16 23:22:22 UTC --- Problem fixed with a clean install of Xcode.
[Bug other/54423] building trunk on Darwin 12.1 fails in building libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54423 --- Comment #4 from Nenad Vukicevic 2012-10-16 23:20:41 UTC --- I removed /Development and /Application/Xcode.app then installed it again. Now I am able to build gcc again. Thank you.
[Bug rtl-optimization/54870] [4.8 regression] gfortran.dg/array_constructor_4.f90 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54870 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Eric Botcazou 2012-10-16 23:19:31 UTC --- This should pass now.
[Bug rtl-optimization/54870] [4.8 regression] gfortran.dg/array_constructor_4.f90 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54870 --- Comment #5 from Eric Botcazou 2012-10-16 23:18:11 UTC --- Author: ebotcazou Date: Tue Oct 16 23:18:08 2012 New Revision: 192518 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192518 Log: PR rtl-optimization/54870 * tree.h (TREE_ADDRESSABLE): Document special usage on SSA_NAME. * cfgexpand.c (update_alias_info_with_stack_vars ): Set it on the SSA_NAME pointer that points to a partition if there is at least one variable with it set in the partition. * dse.c (local_variable_can_escape): New predicate. (can_escape): Call it. * gimplify.c (mark_addressable): If this is a partitioned decl, also mark the SSA_NAME pointer that points to a partition. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/cfgexpand.c branches/gcc-4_7-branch/gcc/dse.c branches/gcc-4_7-branch/gcc/gimplify.c branches/gcc-4_7-branch/gcc/tree.h
[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466
--- Comment #6 from Jonathan Wakely 2012-10-16
23:16:48 UTC ---
The second alias doesn't even have to be a template to show the problem:
template
struct X { };
template
using Y = const X;
using Z = Y;
[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466 --- Comment #5 from Paolo Carlini 2012-10-16 23:13:18 UTC --- Excellent.
[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466
--- Comment #4 from Jonathan Wakely 2012-10-16
23:09:30 UTC ---
template
struct X { };
template
using Y = const X;
template
using Z = Y;
[Bug c++/52964] No warning on negative array size in template instantatiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52964 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #7 from Paolo Carlini 2012-10-16 23:08:42 UTC --- Same issue, let's keep only one. *** This bug has been marked as a duplicate of bug 54706 ***
[Bug c++/54706] -fsyntax-only suppresses a compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54706 Paolo Carlini changed: What|Removed |Added CC||xinliangli at gmail dot com --- Comment #4 from Paolo Carlini 2012-10-16 23:08:42 UTC --- *** Bug 52964 has been marked as a duplicate of this bug. ***
[Bug c++/54770] sibling call optimization is not applied where it ought to be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54770 --- Comment #6 from Paolo Carlini 2012-10-16 23:06:16 UTC --- In terms of workarounds, what about using -std=c++11?
[Bug rtl-optimization/54870] [4.8 regression] gfortran.dg/array_constructor_4.f90 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54870 --- Comment #4 from Eric Botcazou 2012-10-16 22:49:13 UTC --- Author: ebotcazou Date: Tue Oct 16 22:49:07 2012 New Revision: 192517 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192517 Log: PR rtl-optimization/54870 * tree.h (TREE_ADDRESSABLE): Document special usage on SSA_NAME. * cfgexpand.c (update_alias_info_with_stack_vars ): Set it on the SSA_NAME pointer that points to a partition if there is at least one variable with it set in the partition. * dse.c (local_variable_can_escape): New predicate. (can_escape): Call it. * gimplify.c (mark_addressable): If this is a partitioned decl, also mark the SSA_NAME pointer that points to a partition. Modified: trunk/gcc/cfgexpand.c trunk/gcc/dse.c trunk/gcc/gimplify.c trunk/gcc/tree.h
[Bug c++/52995] Change in the handling of templates and visibility attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52995 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Paolo Carlini 2012-10-16 22:43:18 UTC --- Closing then.
[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466 --- Comment #3 from Paolo Carlini 2012-10-16 22:32:02 UTC --- A shorter self contained testcase, not involving the whole std::shared_ptr, would certainly help. Dodji, are there any chances you can look into this issue? The alias decls seem determinant.
[Bug c++/54928] Infinite output with after ICE with macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54928 --- Comment #9 from Paolo Carlini 2012-10-16 22:26:40 UTC --- Well, you know that already, but I have to remind you that this is not the best place to send patches. When you consider your fix mature enough (IMHO it is already! ;) please send it to the mailing list!! Thanks for all your help!
[Bug fortran/54940] [4.6/4.7/4.8 Regression] ICE in gfc_build_intrinsic_call, at fortran/expr.c:4609
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54940 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-16 CC||burnus at gcc dot gnu.org Summary|ICE in |[4.6/4.7/4.8 Regression] |gfc_build_intrinsic_call, |ICE in |at fortran/expr.c:4609 |gfc_build_intrinsic_call, ||at fortran/expr.c:4609 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres 2012-10-16 22:07:45 UTC --- 4.4.6, 4.5.3, and 4.6.2 (r179116) gives pr54940.f90:4.30: integer :: j(:), bug(size(j-1)) 1 Error: Variable 'j' cannot appear in the expression at (1) pr54940.f90:4.19: integer :: j(:), bug(size(j-1)) 1 Error: Array 'j' at (1) cannot have a deferred shape The ICE starts with 4.6.3. The ICE occurs at gcc_assert (result->symtree && (result->symtree->n.sym->attr.flavor == FL_PROCEDURE || result->symtree->n.sym->attr.flavor == FL_UNKNOWN)); introduced by r183314 and the backtrace is #8 0x0001009f2336 in fancy_abort (file=, line=4611, function=0x100b33690 "gfc_build_intrinsic_call") at ../../_clean/gcc/diagnostic.c:1120 #9 0x00010003b475 in gfc_build_intrinsic_call (name=0x100ab5a50 "size", where=DWARF-2 expression error: DW_OP_GNU_uninit must always be the very last op. ) at ../../_clean/gcc/fortran/expr.c:4609 #10 0x0001000a7927 in gfc_simplify_size (array=0x141814110, dim=, kind=) at ../../_clean/gcc/fortran/simplify.c:5586 #11 0x000100043a22 in do_simplify (specific=0x142022ff8, e=0x141813d60) at ../../_clean/gcc/fortran/intrinsic.c:3809 #12 0x000100050b21 in gfc_intrinsic_func_interface (expr=0x141813d60, error_flag=1) at ../../_clean/gcc/fortran/intrinsic.c:4152 #13 0x000100090f33 in gfc_resolve_expr (e=) at ../../_clean/gcc/fortran/resolve.c:2600 #14 0x0001e962 in resolve_array_bound (e=0x141813d60, check_constant=0) at ../../_clean/gcc/fortran/array.c:310 #15 0x0001f515 in gfc_resolve_array_spec (as=0x141813ba0, check_constant=0) at ../../_clean/gcc/fortran/array.c:348 #16 0x00010008abee in resolve_symbol (sym=) at ../../_clean/gcc/fortran/resolve.c:13108 #17 0x0001000acfec in do_traverse_symtree (st=, st_func=0, sym_func=0x10008a5d0 ) at ../../_clean/gcc/fortran/symbol.c:3448 #18 0x000100096fa2 in resolve_types (ns=) at ../../_clean/gcc/fortran/resolve.c:14259 #19 0x000100089e70 in gfc_resolve (ns=) at ../../_clean/gcc/fortran/resolve.c:14359 #20 0x00010007f241 in gfc_parse_file () at ../../_clean/gcc/fortran/parse.c:4607 #21 0x0001000bef36 in gfc_be_parse_file () at ../../_clean/gcc/fortran/f95-lang.c:191 #22 0x000100710fdf in compile_file () at ../../_clean/gcc/toplev.c:546 #23 0x000100712e7c in toplev_main (argc=, argv=) at ../../_clean/gcc/toplev.c:1866 #24 0x0001a254 in start (pc=, bases=0x0) at ../../../_clean/libgcc/unwind-dw2-fde.c:1055
[Bug fortran/54940] New: ICE in gfc_build_intrinsic_call, at fortran/expr.c:4609
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54940 Bug #: 54940 Summary: ICE in gfc_build_intrinsic_call, at fortran/expr.c:4609 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sla...@staszic.waw.pl :( $ cat bug.f95 module bug_m contains function bug() integer :: j(:), bug(size(j-1)) end function end module $ /usr/lib/gcc-snapshot/bin/gfortran bug.f95 f951: internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4609 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ /usr/lib/gcc-snapshot/bin/gfortran --version GNU Fortran (Debian 20120930-1) 4.8.0 20120930 (experimental) [trunk revision 191865] HTH, Sylwester
[Bug target/54938] sh libgcc_unpack_df.o fails to build: ../../../srcw/libgcc/fp-bit.h:221:19: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4273
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54938 --- Comment #5 from Oleg Endo 2012-10-16 21:22:02 UTC --- (In reply to comment #4) > > > > In emit_cmp_and_jump_insn_1, the line > > > > gcc_assert (!find_reg_note (insn, REG_BR_PROB, 0)); > > > > blows up, because of config/sh/sh.c (expand_cbranchsi4): > > > > rtx jump = emit_jump_insn (branch_expander (operands[3])); > > if (probability >= 0) > > add_reg_note (jump, REG_BR_PROB, GEN_INT (probability)); > > I am confused why this code causes the assert in emit_cmp_and_jump_insn_1. Summary: The backend attaches REG_BR_PROB notes when it expands cbranch patterns. The assumption in emit_cmp_and_jump_insn_1 is that no such notes have been attached yet. > Could you please attach a stack trace? A simplified stack trace: ../../../srcw/libgcc/fp-bit.c: In function '__unpack_d': ../../../srcw/libgcc/fp-bit.c:442:1: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4275 0x847036a emit_cmp_and_jump_insn_1 ../../gcc-trunk-van/gcc/optabs.c:4275 0x847036a emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*, machine_mode, int, rtx_def*, int) ../../gcc-trunk-van/gcc/optabs.c:4326 0x826e167 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int, machine_mode, rtx_def*, rtx_def*, rtx_def*, int) ../../gcc-trunk-van/gcc/dojump.c:1072 0x826f680 do_jump(tree_node*, rtx_def*, rtx_def*, int) ../../gcc-trunk-van/gcc/dojump.c:591 0x8271a87 jumpifnot_1(tree_code, tree_node*, tree_node*, rtx_def*, int) ../../gcc-trunk-van/gcc/dojump.c:116 0x8211433 expand_gimple_cond ../../gcc-trunk-van/gcc/cfgexpand.c:1850 0x8219a47 expand_gimple_basic_block ../../gcc-trunk-van/gcc/cfgexpand.c:3830 0x821b337 gimple_expand_cfg ../../gcc-trunk-van/gcc/cfgexpand.c:4475 ... but it doesn't show where the REG_BR_PROB reg note comes from. What happens is that 'emit_cmp_and_jump_insn_1' invokes 'emit_jump_insn' which ends up expanding the cbranchsi4 insn in the backend's machine description. On SH, the cbranchsi4 expander invokes expand_cbranchsi4 (in sh.c), which attaches a REG_BR_PROB note. In case of SImode cbranch, the probability is always set to -1 and expand_cbranchsi4 does not attach a note. So no problem with this one. However, when it comes to DImode cbranch (cbranchdi4), SH's expand_cbranchdi4 will split & expand the comparison into multiple SImode cbranch insns and attach REG_BR_PROB notes to them. After that it returns to emit_cmp_and_jump_insn_1 and the assert blows. > If there is a REG_BR_PROB note already but the > probability is different from what is passed to emit_cmp_and_jump_insn_1, > should the existing value be replaced or left as such. Hm, or maybe try to accumulate the probabilities in some useful way? In this crashing case for the DImode comparison prob in emit_cmp_and_jump_insn_1 is 6100, and SH's expand_cbranchdi4 expands two cbranchsi4 insns, one with prob '-1' (i.e. no reg note), and another one with '0'.
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #22 from Dominique d'Humieres 2012-10-16 20:58:58 UTC --- With the patch I see a ~10% slowdown in the Test4 - Lapack 2 (1001x1001) of test_fpu.f90 compared to revision 192449 [macbook] lin/test% time /opt/gcc/gcc4.8c/bin/gfortran -fprotect-parens -Ofast -funroll-loops test_lap.f90 6.742u 0.097s 0:06.87 99.4%0+0k 0+20io 0pf+0w [macbook] lin/test% a.out Benchmark running, hopefully as only ACTIVE task Test4 - Lapack 2 (1001x1001) inverts 2.6 sec Err= 0.250 total = 2.6 sec [macbook] lin/test% time gfc -fprotect-parens -Ofast -funroll-all-loops test_lap.f90 9.489u 0.116s 0:09.62 99.6%0+0k 0+16io 0pf+0w [macbook] lin/test% a.out Benchmark running, hopefully as only ACTIVE task Test4 - Lapack 2 (1001x1001) inverts 2.8 sec Err= 0.250 total = 2.8 sec This looks similar to what I saw in comment #5. However now dgetri is never inlined while dgetrf is inlined with the patch. Also dtrmv and dscal are inlined with the patch (respectively 20 and 21 occurrences without the patch). The last difference I see is 35 occurrences of dswap with the patch compared to 32 without.
[Bug other/54423] building trunk on Darwin 12.1 fails in building libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54423 Jack Howarth changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #3 from Jack Howarth 2012-10-16 20:15:03 UTC --- Apple has changed how Xcode is configured and /Developer is no longer used. Make sure you have installed the latest Xcode, the matching Command Line Tools from within the Preferences panel of the Xcode application and then have executed... sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer You are likely using some pre-Mountain Lion of the CLI in the deprecated /Developer directory.
[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus 2012-10-16 19:26:30 UTC --- (In reply to comment #1) > If Fortran requires i to be HUGE(i) + 1 after the loop body then what does > it say about the overflow? Interesting question. The Fortran standard just states (F2008): "8.1.6.6.4 Loop termination" "For a DO construct that is not a DO CONCURRENT construct, the loop terminates, and the DO construct becomes inactive, when any of the following occurs. [...] "* The iteration count is determined to be zero or the scalar-logical-expr is false, when tested during step (1) of the above execution cycle." [...] "When a DO construct becomes inactive, the DO variable, if any, of the DO construct retains its last defined value." where (1) is the first step of the iteration (8.1.6.6.2 The execution cycle): "(1) The iteration count, if any, is tested. If it is zero, the loop terminates and the DO construct becomes inactive. [...] "(2) The range of the loop is executed. "(3) The iteration count, if any, is decremented by one. The DO variable, if any, is incremented by the value of the incrementation parameter m3." Additionally, the standard specifies: "7.1.5.2.4 Evaluation of numeric intrinsic operations" "The execution of any numeric operation whose result is not defined by the arithmetic used by the processor is prohibited."
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 --- Comment #3 from Markus Trippelsdorf 2012-10-16 18:38:21 UTC --- Created attachment 28458 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28458 glibc math testcase Please note that gcc-4.6 and 4.7 also exceed the variable tracking size limit, but compile the test-case in just 36 seconds (10sec without var-tracking).
[Bug c++/54928] Infinite output with after ICE with macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54928 --- Comment #8 from Manuel López-Ibáñez 2012-10-16 18:05:52 UTC --- Created attachment 28457 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28457 better fix The code is re-using the diagnostic passed as an argument to produce new diagnostics, and by saving/reloading values on it. But we actually only need to modify things once, and if we use a new diagnostic struct, we don't need to touch the original. Of course, we should still not print the caret and macro expansion in internal_error, but that is a bit more complicated.
[Bug c++/54928] Infinite output with after ICE with macro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54928 --- Comment #7 from Manuel López-Ibáñez 2012-10-16 17:59:57 UTC --- This is the problem: Index: tree-diagnostic.c === --- tree-diagnostic.c (revision 192379) +++ tree-diagnostic.c (working copy) @@ -239,10 +239,13 @@ maybe_unwind_expanded_macro_loc (diagnos pp_destroy_prefix (context->printer); diagnostic_show_locus (context, diagnostic); /* At this step, as we've printed the context of the macro definition, we don't want to print the context of its expansion, otherwise, it'd be redundant. */ +diagnostic->kind = saved_kind; +diagnostic->location = saved_location; +pp_set_prefix (context->printer, saved_prefix); continue; } diagnostic->location = resolved_exp_loc; pp_set_prefix (context->printer, But I think the code can be a lot simpler with a slightly more complex patch.
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #21 from Dominique d'Humieres 2012-10-16 17:57:52 UTC --- Before the patch in comment #20, I get -rwxr-xr-x 1 dominiq staff 73336 Oct 16 19:19 a.out* [macbook] lin/test% time gfc -fprotect-parens -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer --param max-inline-insns-auto=150 -fwhole-program -flto -fno-tree-loop-if-convert fatigue.f90 8.485u 0.205s 0:08.73 99.4%0+0k 0+29io 0pf+0w [macbook] lin/test% ll a.out -rwxr-xr-x 1 dominiq staff 73336 Oct 16 19:19 a.out* [[macbook] lin/test% time a.out > /dev/null 2.916u 0.003s 0:02.92 99.6%0+0k 0+1io 0pf+0w [macbook] lin/test% time gfc -fprotect-parens -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer -fwhole-program -flto -fno-tree-loop-if-convert fatigue.f90 6.822u 0.193s 0:07.06 99.2%0+0k 0+30io 0pf+0w [macbook] lin/test% ll a.out -rwxr-xr-x 1 dominiq staff 69312 Oct 16 19:21 a.out* [macbook] lin/test% time a.out > /dev/null 4.851u 0.004s 0:04.86 99.7%0+0k 0+1io 0pf+0w After the patch I get [macbook] lin/test% time gfc -fprotect-parens -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer -fwhole-program -flto -fno-tree-loop-if-convert fatigue.f90 7.277u 0.217s 0:07.52 99.4%0+0k 0+28io 0pf+0w [macbook] lin/test% ll a.out-rwxr-xr-x 1 dominiq staff 69248 Oct 16 19:46 a.out* [macbook] lin/test% time a.out > /dev/null 2.912u 0.003s 0:02.91 100.0%0+0k 0+2io 0pf+0w So for this particular test with the same options, after the patch the compilation time is ~6% slower, the size is about the same (actually smaller;-) and the run time ~40% faster. Without the patch and with --param max-inline-insns-auto=150 compared to with the patch without this option, the compilation time is ~20% slower, the size is ~6% larger, and the runtime is the same. Further testing coming, thanks for the patch.
[Bug other/54423] building trunk on Darwin 12.1 fails in building libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54423 --- Comment #2 from Nenad Vukicevic 2012-10-16 17:38:37 UTC --- I verified that I have the latest Xcode (4.5). I verified that I installed the latest development CLI tools (via Xcode and manual download). * I see that 10.8 SDK directory exists under Xcode App - but not under /Developer * cc running is llvm - 4.2.1 * I see that it links with the following command: /Developer/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/as -arch x86_64 -force_cpusubtype_ALL -o /var/folders/z7/83zx0wdj4cx644rg7p7kgwb8gn/T//ccDk1do9.o /var/folders/z7/83zx0wdj4cx644rg7p7kgwb8gn/T//ccDTslhw.s /Developer/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/collect2 -dynamic -arch x86_64 -macosx_version_min 10.8.2 -weak_reference_mismatches non-weak -o t -lcrt1.10.6.o -L/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1 -L/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/../../.. /var/folders/z7/83zx0wdj4cx644rg7p7kgwb8gn/T//ccDk1do9.o -lSystem -lgcc -lSystem Note the "-lcrt1.10.6.0" on the command line. Is linking with crt1.10.6.0 the right fix for Mountain Lion?
[Bug lto/54911] lto-wrapper fails when compiling gcc with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54911 --- Comment #6 from j-frankish at slb dot com 2012-10-16 17:11:38 UTC --- This works - thanks CFLAGS="-march=i486 -mtune=i686 -Os -pipe" CXXFLAGS="-march=i486 -mtune=i686 -Os -pipe" CC="gcc -msse2 -flto -fuse-linker-plugin" CXX="g++ -msse2 -flto -fuse-linker-plugin" ../gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib --disable-libstdcxx-pch --enable-cloog-backend=isl --with-system-zlib --enable-frame-pointer --disable-bootstrap
[Bug target/54938] sh libgcc_unpack_df.o fails to build: ../../../srcw/libgcc/fp-bit.h:221:19: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4273
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54938
--- Comment #4 from Easwaran Raman 2012-10-16
17:04:05 UTC ---
(In reply to comment #3)
> Thanks Jörn.
> The problem is not related to my changes in PR 51244. It is caused by the
> latest change to optabs.c:
>
> 2012-10-15 Easwaran Raman
> * optabs.c (emit_cmp_and_jump_insn_1): Add a new parameter to
> specificy the probability of taking the jump.
> (emit_cmp_and_jump_insns): Likewise.
>
>
> In emit_cmp_and_jump_insn_1, the line
>
> gcc_assert (!find_reg_note (insn, REG_BR_PROB, 0));
>
> blows up, because of config/sh/sh.c (expand_cbranchsi4):
>
> rtx jump = emit_jump_insn (branch_expander (operands[3]));
> if (probability >= 0)
> add_reg_note (jump, REG_BR_PROB, GEN_INT (probability));
I am confused why this code causes the assert in emit_cmp_and_jump_insn_1.
Could you please attach a stack trace?
>
> The following seems to fix the problem
>
> Index: gcc/optabs.c
> ===
> --- gcc/optabs.c(revision 192494)
> +++ gcc/optabs.c(working copy)
> @@ -4270,8 +4270,8 @@
>&& JUMP_P (insn)
>&& any_condjump_p (insn))
> {
> - gcc_assert (!find_reg_note (insn, REG_BR_PROB, 0));
> - add_reg_note (insn, REG_BR_PROB, GEN_INT (prob));
> + if (!find_reg_note (insn, REG_BR_PROB, 0))
> +add_reg_note (insn, REG_BR_PROB, GEN_INT (prob));
> }
> }
>
>
> Easwaran, could you please have a look at that? Does the change above make
> sense?
While this would certainly make the error go away, it will be good to
understand the root cause. If there is a REG_BR_PROB note already but the
probability is different from what is passed to emit_cmp_and_jump_insn_1,
should the existing value be replaced or left as such.
Thanks,
Easwaran
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #20 from Jan Hubicka 2012-10-16 16:38:27 UTC --- Created attachment 28456 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28456 Path I am considering Hi, I am considering to enable inlining when inline-analysis says that the inline function will get significantly fater regardless the inline-insns-single/inline-sinsns-auto limits. The patch is attached. In general it may make more sense to gradually set the limits based on expected speedup but I am affraid this will become hard to understand and maintain. So for now lets have simple boolean decisions. It would be nice to know where it helps (i.e. for fatigue and cray) and where it doesn't. It also causes quite considerable code size growth on some of SPEC2000 for relatively little benefit, so I guess it will need more evaulation and reduction of inline-insns-auto limits. It also may be problem in unrealistic estimates in ipa-inline-analysis, this is first time we take them really seriously. Comments/ideas are welcome.
[Bug c++/54466] [C++11] Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-16 CC||dodji at gcc dot gnu.org Summary|Recursive Type Alias, |[C++11] Recursive Type |Member Function Pointer,|Alias, Member Function |Segmentation Fault |Pointer, Segmentation Fault Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely 2012-10-16 15:55:41 UTC --- confirmed
[Bug target/54908] misc regressions on emutls targets remain from dynamic initialization of non-function-local TLS variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54908
--- Comment #10 from Jack Howarth 2012-10-16
15:50:45 UTC ---
Note that the fix in comment 9 for libgomp/testsuite/libgomp.c++/pr24455.C
works for Xcode 3.2.6 and earlier on darwin10 but not Xcode 4.2. This is
because Apple broke weak symbol lookup in Xcode 4.2's linker (radr://10466868,
"-undefined dynamic_lookup linker bug"). This issue wasn't fixed until Xcode
4.4 (which is only available on darwin11 and darwin12).
Note that a simple testcase for this bug is...
--- weak.c -
#include
char *myweakfunc(void) __attribute__((weak)) ;
int main(int argc, char **argv)
{
if (myweakfunc)
printf ("found myweakfunc %s\n", myweakfunc());
else
printf("Weak func not found\n");
return 0;
}
% gcc weak.c -o wk -undefined dynamic_lookup
% ./wk
Weak func not found
[Bug c++/54466] Recursive Type Alias, Member Function Pointer, Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466 --- Comment #1 from Matt Clarkson 2012-10-16 15:46:31 UTC --- This is still an error on 4.7.2. It is the const before the std::shared_ptr that is the problem: template #if (__GNUC__ <= 4) && (__GNUC_MINOR__ <= 7) && (__GNUC_PATCHLEVEL__ <= 2) using CallbackPtr = std::shared_ptr; #else // This causes a segmentation fault on G++ 4.7.2 // Bug Report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54466 using CallbackPtr = const std::shared_ptr; #endif
[Bug c/53063] encode group options in the .opt files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063 --- Comment #5 from Manuel López-Ibáñez 2012-10-16 15:39:09 UTC --- Author: manu Date: Tue Oct 16 15:38:58 2012 New Revision: 192503 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192503 Log: 2012-10-16 Manuel López-Ibáñez PR c/53063 PR c/40989 * doc/options.texi (EnabledBy): Document new form. * optc-gen.awk: Handle new form of EnabledBy. * common.opt (Wunused-but-set-parameter): Use EnabledBy. (Wunused-parameter): Likewise. * opts.c (finish_options): Do not handle them explicitly. * opt-functions.awk (search_var_name): New. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/doc/options.texi trunk/gcc/opt-functions.awk trunk/gcc/optc-gen.awk trunk/gcc/opts.c
[Bug c/40989] -Werror= and #pragma diagnostics do not work with group flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40989 --- Comment #9 from Manuel López-Ibáñez 2012-10-16 15:39:08 UTC --- Author: manu Date: Tue Oct 16 15:38:58 2012 New Revision: 192503 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192503 Log: 2012-10-16 Manuel López-Ibáñez PR c/53063 PR c/40989 * doc/options.texi (EnabledBy): Document new form. * optc-gen.awk: Handle new form of EnabledBy. * common.opt (Wunused-but-set-parameter): Use EnabledBy. (Wunused-parameter): Likewise. * opts.c (finish_options): Do not handle them explicitly. * opt-functions.awk (search_var_name): New. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/doc/options.texi trunk/gcc/opt-functions.awk trunk/gcc/optc-gen.awk trunk/gcc/opts.c
[Bug tree-optimization/54939] Very poor vectorization of loops with complex arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 --- Comment #4 from Richard Biener 2012-10-16 15:31:52 UTC --- Thanks.
[Bug c/53063] encode group options in the .opt files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53063 --- Comment #4 from Manuel López-Ibáñez 2012-10-16 15:31:53 UTC --- Author: manu Date: Tue Oct 16 15:31:46 2012 New Revision: 192502 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192502 Log: 2012-10-16 Manuel López-Ibáñez PR c/53063 PR c/40989 gcc/ * optc-gen.awk: Handle new form of LangEnabledBy. * opts.c (set_Wstrict_aliasing): Declare here. Make static. * common.opt (Wstrict-aliasing=,Wstrict-overflow=): Do not use Init. * doc/options.texi (LangEnabledBy): Document new form. * flags.h (set_Wstrict_aliasing): Do not declare. c-family/ * c.opt (Wstrict-aliasing=,Wstrict-overflow=): Use LangEnabledBy. * c-opts.c (c_common_handle_option): Do not set them here. Add comment. (c_common_post_options): Likewise. testsuite/ * gcc.dg/Wstrict-overflow-24.c: New. Added: trunk/gcc/testsuite/gcc.dg/Wstrict-overflow-24.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/c-family/c.opt trunk/gcc/common.opt trunk/gcc/doc/options.texi trunk/gcc/flags.h trunk/gcc/optc-gen.awk trunk/gcc/opts.c trunk/gcc/testsuite/ChangeLog
[Bug c/40989] -Werror= and #pragma diagnostics do not work with group flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40989 --- Comment #8 from Manuel López-Ibáñez 2012-10-16 15:31:55 UTC --- Author: manu Date: Tue Oct 16 15:31:46 2012 New Revision: 192502 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192502 Log: 2012-10-16 Manuel López-Ibáñez PR c/53063 PR c/40989 gcc/ * optc-gen.awk: Handle new form of LangEnabledBy. * opts.c (set_Wstrict_aliasing): Declare here. Make static. * common.opt (Wstrict-aliasing=,Wstrict-overflow=): Do not use Init. * doc/options.texi (LangEnabledBy): Document new form. * flags.h (set_Wstrict_aliasing): Do not declare. c-family/ * c.opt (Wstrict-aliasing=,Wstrict-overflow=): Use LangEnabledBy. * c-opts.c (c_common_handle_option): Do not set them here. Add comment. (c_common_post_options): Likewise. testsuite/ * gcc.dg/Wstrict-overflow-24.c: New. Added: trunk/gcc/testsuite/gcc.dg/Wstrict-overflow-24.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/c-family/c.opt trunk/gcc/common.opt trunk/gcc/doc/options.texi trunk/gcc/flags.h trunk/gcc/optc-gen.awk trunk/gcc/opts.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/54939] Very poor vectorization of loops with complex arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 --- Comment #3 from Yuri Rumyantsev 2012-10-16 15:06:19 UTC --- I looked through the list of all issues related to vectorization but could not find duplicate.
[Bug tree-optimization/54939] Very poor vectorization of loops with complex arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 --- Comment #2 from Yuri Rumyantsev 2012-10-16 14:54:50 UTC --- Created attachment 28455 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28455 test reproducer
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 --- Comment #2 from Markus Trippelsdorf 2012-10-16 14:42:32 UTC --- Another example is math/test-tgmath2.c from glibc. (after compiling for 1:40 minutes): test-tgmath2.c: In function ‘test’: test-tgmath2.c:93:1: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without test (const int Vint4, const long long int Vllong4) ^ test-tgmath2.c:93:1: note: variable tracking size limit exceeded
[Bug tree-optimization/54939] Very poor vectorization of loops with complex arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-16 Blocks||53947 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2012-10-16 14:36:52 UTC --- Can you reproduce zaxpy source here please? Also please see the list of bugs referenced from PR53947, there is likely a duplicate for this issue.
[Bug tree-optimization/54939] New: Very poor vectorization of loops with complex arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 Bug #: 54939 Summary: Very poor vectorization of loops with complex arithmetic Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ysrum...@gmail.com Analyzing some performance anomaly for spec2000 I found out that 168.wupwise with vectorization is slower than without it on x86. The main problem is that gcc does not recognize some special idioms of complex addition and multiplication in process of loop vectorization. For example, for a simple zaxpy loop icc genearates 1.6X faster code than gcc. Here is assembly for zaxpy loop produced by icc: ..B1.4: # Preds ..B1.2 ..B1.4 movups(%rsi,%rdx), %xmm2#7.28 movups16(%rsi,%rdx), %xmm5 #7.28 movups(%rsi,%rcx), %xmm4#7.17 movups16(%rsi,%rcx), %xmm7 #7.17 movddup (%rsi,%rdx), %xmm3#7.27 incq %r8 #6.10 movddup 16(%rsi,%rdx), %xmm6 #7.27 unpckhpd %xmm2, %xmm2 #7.27 unpckhpd %xmm5, %xmm5 #7.27 mulpd %xmm1, %xmm3 #7.27 mulpd %xmm0, %xmm2 #7.27 mulpd %xmm1, %xmm6 #7.27 mulpd %xmm0, %xmm5 #7.27 addsubpd %xmm2, %xmm3 #7.27 addsubpd %xmm5, %xmm6 #7.27 addpd %xmm3, %xmm4 #7.9 addpd %xmm6, %xmm7 #7.9 movups%xmm4, (%rsi,%rcx)#7.9 movups%xmm7, 16(%rsi,%rcx) #7.9 addq $32, %rsi #6.10 cmpq %rdi, %r8 #6.10 jb..B1.4# Prob 64% #6.10 ( I got it with -xSSE4.2 -O3 options). Gor gcc compiler the following options were used: -m64 -mfpmath=sse -march=corei7 -O3 -ffast-math.
[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54824 --- Comment #7 from Jan Hubicka 2012-10-16 14:21:29 UTC --- > I'll try to plug the hole somewhere. Honza, any good idea? Hmm, adding __bulitin_noreturn call when this happens? Sounds sloppy, too. We should ask user to fix the source, too. Honza
[Bug target/54938] sh libgcc_unpack_df.o fails to build: ../../../srcw/libgcc/fp-bit.h:221:19: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4273
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54938
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-10-16
CC||eraman at google dot com
Ever Confirmed|0 |1
--- Comment #3 from Oleg Endo 2012-10-16 13:28:10
UTC ---
Thanks Jörn.
The problem is not related to my changes in PR 51244. It is caused by the
latest change to optabs.c:
2012-10-15 Easwaran Raman
* optabs.c (emit_cmp_and_jump_insn_1): Add a new parameter to
specificy the probability of taking the jump.
(emit_cmp_and_jump_insns): Likewise.
In emit_cmp_and_jump_insn_1, the line
gcc_assert (!find_reg_note (insn, REG_BR_PROB, 0));
blows up, because of config/sh/sh.c (expand_cbranchsi4):
rtx jump = emit_jump_insn (branch_expander (operands[3]));
if (probability >= 0)
add_reg_note (jump, REG_BR_PROB, GEN_INT (probability));
The following seems to fix the problem
Index: gcc/optabs.c
===
--- gcc/optabs.c(revision 192494)
+++ gcc/optabs.c(working copy)
@@ -4270,8 +4270,8 @@
&& JUMP_P (insn)
&& any_condjump_p (insn))
{
- gcc_assert (!find_reg_note (insn, REG_BR_PROB, 0));
- add_reg_note (insn, REG_BR_PROB, GEN_INT (prob));
+ if (!find_reg_note (insn, REG_BR_PROB, 0))
+add_reg_note (insn, REG_BR_PROB, GEN_INT (prob));
}
}
Easwaran, could you please have a look at that? Does the change above make
sense?
[Bug target/53975] [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975 Andrey Belevantsev changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #21 from Andrey Belevantsev 2012-10-16 13:24:23 UTC --- Fixed for trunk and 4.7.
[Bug rtl-optimization/53701] ICE on ia64 (when building Allegro 4.4) in sel-sched
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53701 --- Comment #9 from Andrey Belevantsev 2012-10-16 13:22:26 UTC --- Author: abel Date: Tue Oct 16 13:22:22 2012 New Revision: 192498 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192498 Log: 2012-10-16 Andrey Belevantsev Backport from mainline 2012-08-09 Andrey Belevantsev PR rtl-optimization/53701 * sel-sched.c (vinsn_vec_has_expr_p): Clarify function comment. Process not only expr's vinsns but all old vinsns from expr's history of changes. (update_and_record_unavailable_insns): Clarify comment. testsuite: 2012-10-16 Andrey Belevantsev Backport from mainline 2012-08-09 Andrey Belevantsev PR rtl-optimization/53701 * gcc.dg/pr53701.c: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr53701.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/sel-sched.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug target/53975] [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975 --- Comment #20 from Andrey Belevantsev 2012-10-16 13:20:37 UTC --- Author: abel Date: Tue Oct 16 13:20:30 2012 New Revision: 192497 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192497 Log: Backport from mainline 2012-07-31 Andrey Belevantsev PR target/53975 * sel-sched-ir.c (has_dependence_note_reg_use): Clarify comment. Revert 2011-08-04 Sergey Grechanik * sel-sched-ir.c (has_dependence_note_reg_use): Call ds_full_merge only if producer writes to the register given by regno. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/sel-sched-ir.c
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 --- Comment #17 from Tobias Burnus 2012-10-16 13:13:41 UTC --- Now fixed: Several issues with OPTIONAL. TODO: - Issues with OPTIONAL and ELEMENTAL, cf. commented FIXME lines in gfortran.dg/class_optional_2.f90 - Support packing of (non)polymorphic assumed-rank/assumed-shape arrays (-> CONTIGUOUS; cf. gfortran.dg/class_optional_2.f90) - Fix INTENT(OUT) handling for allocatable polymorphic arrays (cf. comment 0) - Analyse the old issue related to class_array_7.f03 (comment 11, comment 12)
[Bug fortran/50981] [4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #45 from Tobias Burnus 2012-10-16 13:08:39 UTC --- I close this PR now as FIXED. The initial problem has been fixed on 4.7 + trunk (= 4.8). Some issue exists in 4.4 to 4.6, another is a special case for a new 4.6 nonpolymorphism feature. I don't think it makes sense to backport those. I think all test cases of this PR are effectively fixed on the trunk (= 4.8). Some issues - mainly with ELEMENTAL - remain, but those are tracked in PR54618.
[Bug fortran/50981] [4.6 Regression] Wrong-code for scalarizing ELEMENTAL call with absent OPTIONAL argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981 --- Comment #44 from Tobias Burnus 2012-10-16 13:02:09 UTC --- Author: burnus Date: Tue Oct 16 13:02:02 2012 New Revision: 192495 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192495 Log: 2012-10-16 Tobias Burnus PR fortran/50981 PR fortran/54618 * trans.h (gfc_conv_derived_to_class, gfc_conv_class_to_class): Update prototype. * trans-stmt.c (trans_associate_var,gfc_trans_allocate): Update calls to those functions. * trans-expr.c (gfc_conv_derived_to_class, * gfc_conv_class_to_class, gfc_conv_expr_present): Handle absent polymorphic arguments. (class_scalar_coarray_to_class): New function. (gfc_conv_procedure_call): Update calls. 2012-10-16 Tobias Burnus PR fortran/50981 PR fortran/54618 * gfortran.dg/class_optional_1.f90: New. * gfortran.dg/class_optional_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_optional_1.f90 trunk/gcc/testsuite/gfortran.dg/class_optional_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog
[Bug fortran/54618] [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618 --- Comment #16 from Tobias Burnus 2012-10-16 13:02:09 UTC --- Author: burnus Date: Tue Oct 16 13:02:02 2012 New Revision: 192495 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192495 Log: 2012-10-16 Tobias Burnus PR fortran/50981 PR fortran/54618 * trans.h (gfc_conv_derived_to_class, gfc_conv_class_to_class): Update prototype. * trans-stmt.c (trans_associate_var,gfc_trans_allocate): Update calls to those functions. * trans-expr.c (gfc_conv_derived_to_class, * gfc_conv_class_to_class, gfc_conv_expr_present): Handle absent polymorphic arguments. (class_scalar_coarray_to_class): New function. (gfc_conv_procedure_call): Update calls. 2012-10-16 Tobias Burnus PR fortran/50981 PR fortran/54618 * gfortran.dg/class_optional_1.f90: New. * gfortran.dg/class_optional_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_optional_1.f90 trunk/gcc/testsuite/gfortran.dg/class_optional_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog
[Bug target/54938] sh libgcc_unpack_df.o fails to build: ../../../srcw/libgcc/fp-bit.h:221:19: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4273
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54938 --- Comment #2 from Jorn Wolfgang Rennecke 2012-10-16 12:35:47 UTC --- Created attachment 28454 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28454 preprocessed source cc1 invocation from using -v --save-temps: /home/amylaar/fsf/sh-192491/./gcc/cc1 -fpreprocessed fp-bit.i -quiet -dumpbase fp-bit.c -auxbase-strip _unpack_df.o -g -g -g -O2 -O2 -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fbuilding-libgcc -fno-stack-protector -fvisibility=hidden -o fp-bit.s
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #23 from Oleg Endo 2012-10-16 11:49:14 UTC --- (In reply to comment #22) > (In reply to comment #0) > > The code related to shift patterns in sh.c / sh.md maybe could use some > > improvements here and there. In some places clobbers and scratch regs > > could be > > avoided. > > There is also a large part that deals with minimizing and-shift/shift-and > > sequences, but there are no test cases to verify that those actually work. > > It would also be interesting to see, whether some of the and-shift/shift-and > > combine code could be reduced due to improvements in the middle-end. > > Be careful with removing 'useless' clobbers, as they might be needed to > facilitate instruction combinations into patterns that have these clobbers. Yeah, I've noticed ;) Logical left/right shifts are now expanded into T-clobbering and non-T-clobbering pattern variations.
[Bug target/54938] sh libgcc_unpack_df.o fails to build: ../../../srcw/libgcc/fp-bit.h:221:19: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4273
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54938 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #1 from Oleg Endo 2012-10-16 11:43:37 UTC --- Could you please try to extract a preprocessed source for this one? I'm afraid some of my recent patches for PR 51244 might have introduced this :T
[Bug debug/54796] [4.8 Regression] Non-addressable stack parameter debug quality regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54796 --- Comment #5 from Jakub Jelinek 2012-10-16 11:21:28 UTC --- Author: jakub Date: Tue Oct 16 11:21:20 2012 New Revision: 192494 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192494 Log: PR debug/54796 * rtl.h: Document jump flag on VALUE. * cselib.h (cselib_set_value_sp_based, cselib_sp_based_value_p): New prototypes. * alias.c (find_base_term): For cselib_sp_based_value_p return static_reg_base_value[STACK_POINTER_REGNUM]. * cselib.c (SP_BASED_VALUE_P): Define. (cselib_set_value_sp_based, cselib_sp_based_value_p): New functions. * var-tracking.c (add_stores): Call cselib_set_value_sp_based for not yet preserved VALUEs of sp on sp assignments if hard_frame_pointer_adjustment != -1. (vt_initialize): When setting hard_frame_pointer_adjustment, disassociate sp from its previous value and call cselib_set_value_sp_based on a new VALUE created for sp. * gcc.dg/guality/pr54796.c: New test. Added: trunk/gcc/testsuite/gcc.dg/guality/pr54796.c Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/cselib.c trunk/gcc/cselib.h trunk/gcc/rtl.h trunk/gcc/testsuite/ChangeLog trunk/gcc/var-tracking.c
[Bug tree-optimization/54889] [4.8 Regression] Revision 191983 gives compfail for 465.tonto in SPEC CPU 2006 when use -O3 -mavx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54889 --- Comment #4 from Jakub Jelinek 2012-10-16 11:19:42 UTC --- Author: jakub Date: Tue Oct 16 11:19:37 2012 New Revision: 192493 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192493 Log: PR tree-optimization/54889 * tree-vect-stmts.c (vectorizable_load): Add VIEW_CONVERT_EXPR if ARRAY_REF newref doesn't have compatible type with vectype element type, use vectype element type for MEM_REF. * gfortran.dg/pr54889.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr54889.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug rtl-optimization/54936] ICE: in prepare_cmp_insn, at optabs.c:4177 with -fnon-call-exceptions and vector float compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54936 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-16 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2012-10-16 11:13:25 UTC --- Hm, I think this is a general and/or target issue. We treat vector compares as possibly trapping (similar to scalar fp compares). What is new since 4.7 is that we can produce vector compares that may throw at the gimple level. The vectorizer will not create them and intrinsics are not marked as possibly throwing.
[Bug tree-optimization/54889] [4.8 Regression] Revision 191983 gives compfail for 465.tonto in SPEC CPU 2006 when use -O3 -mavx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54889 --- Comment #3 from Igor Zamyatin 2012-10-16 11:12:47 UTC --- Jakub, are you going to commit the fix or there are some issues with it?
[Bug target/54938] New: sh libgcc_unpack_df.o fails to build: ../../../srcw/libgcc/fp-bit.h:221:19: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4273
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54938 Bug #: 54938 Summary: sh libgcc_unpack_df.o fails to build: ../../../srcw/libgcc/fp-bit.h:221:19: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4273 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amyl...@gcc.gnu.org Target: sh-elf "make -j8 all-gcc all-target-libgcc all-target-newlib"" fails at _unpack_df.o: /home/amylaar/fsf/sh-192491/./gcc/xgcc -B/home/amylaar/fsf/sh-192491/./gcc/ -nostdinc -B/home/amylaar/fsf/sh-192491/sh-elf/newlib/ -isystem /home/amylaar/fsf/sh-192491/sh-elf/newlib/targ-include -isystem /home/amylaar/fsf/srcw/newlib/libc/include -B/home/amylaar/fsf/sh-192491/sh-elf/libgloss/sh -L/home/amylaar/fsf/sh-192491/sh-elf/libgloss/libnosys -L/home/amylaar/fsf/srcw/libgloss/sh -B/usr/local/sh-elf/bin/ -B/usr/local/sh-elf/lib/ -isystem /usr/local/sh-elf/include -isystem /usr/local/sh-elf/sys-include -L/home/amylaar/fsf/sh-192491/./ld-g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../.././gcc -I../../../srcw/libgcc -I../../../srcw/libgcc/. -I../../../srcw/libgcc/../gcc -I../../../srcw/libgcc/../include -DHAVE_CC_TLS -o _unpack_df.o -MT _unpack_df.o -MD -MP -MF _unpack_df.dep -DFINE_GRAINED_LIBRARIES -DL_unpack_df -c ../../../srcw/libgcc/fp-bit.c -fvisibility=hidden -DHIDE_EXPORTS ... In file included from ../../../srcw/libgcc/fp-bit.c:41:0: ../../../srcw/libgcc/fp-bit.c: In function ‘__unpack_d’: ../../../srcw/libgcc/fp-bit.h:221:19: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4273 # define unpack_d __unpack_d ^ ../../../srcw/libgcc/fp-bit.c:442:1: note: in expansion of macro 'unpack_d' unpack_d (FLO_union_type * src, fp_number_type * dst) ^ In file included from ../../../srcw/libgcc/fp-bit.c:41:0: ../../../srcw/libgcc/fp-bit.c: In function ‘__pack_d’: ../../../srcw/libgcc/fp-bit.h:220:17: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4273 # define pack_d __pack_d ^ ../../../srcw/libgcc/fp-bit.c:199:1: note: in expansion of macro 'pack_d' pack_d (const fp_number_type *src) ^
[Bug target/54089] [SH] Refactor shift patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 Jorn Wolfgang Rennecke changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #22 from Jorn Wolfgang Rennecke 2012-10-16 10:52:46 UTC --- (In reply to comment #0) > The code related to shift patterns in sh.c / sh.md maybe could use some > improvements here and there. In some places clobbers and scratch regs could > be > avoided. > There is also a large part that deals with minimizing and-shift/shift-and > sequences, but there are no test cases to verify that those actually work. > It would also be interesting to see, whether some of the and-shift/shift-and > combine code could be reduced due to improvements in the middle-end. Be careful with removing 'useless' clobbers, as they might be needed to facilitate instruction combinations into patterns that have these clobbers.
[Bug c++/51786] [c++0x] Invalid declaration with decltype accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51786
--- Comment #5 from Paolo Carlini 2012-10-16
10:49:22 UTC ---
The problem is that by the time at the end of cp_parser_simple_declaration we
call check_tag_decl (via shadow_tag), which is supposed to check that the
simple declaration is valid, we already called finish_decltype_type thus it
doesn't see the decltype, it sees something like:
void foo() { struct A; }
a valid simple declaration.
[Bug target/54407] FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407 --- Comment #16 from Jonathan Wakely 2012-10-16 10:07:31 UTC --- Agreed, please just disable the test entirely on the targets where it fails
[Bug tree-optimization/54901] [4.8 Regression] air.f90, aermod.f90, and mdbx.f90 are miscompiled with '-m64 -O3 -funroll-loops -fwhole-program' after revision 192213
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54901 --- Comment #3 from Dominique d'Humieres 2012-10-16 09:51:21 UTC --- > Dominique, could you attach the tests. http://www.polyhedron.com/polyhedron_benchmark_suite0html > Probably a dup of the discussion going on here: > http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01414.html Probably, as it seems fixed by some revision before r192440 (included). I'ld like to investigate which revision caused the miscompilations and which one fixed them. Please let me close this PR as fixed myself.
[Bug tree-optimization/54901] [4.8 Regression] air.f90, aermod.f90, and mdbx.f90 are miscompiled with '-m64 -O3 -funroll-loops -fwhole-program' after revision 192213
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54901 Steven Bosscher changed: What|Removed |Added CC|steven at gcc dot gnu.org | --- Comment #2 from Steven Bosscher 2012-10-16 09:12:39 UTC --- Probably a dup of the discussion going on here: http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01414.html
[Bug tree-optimization/54901] [4.8 Regression] air.f90, aermod.f90, and mdbx.f90 are miscompiled with '-m64 -O3 -funroll-loops -fwhole-program' after revision 192213
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54901 Vladimir Yakovlev changed: What|Removed |Added CC||vbyakovl23 at gmail dot com --- Comment #1 from Vladimir Yakovlev 2012-10-16 08:55:16 UTC --- Dominique, could you attach the tests.
[Bug c/51712] -Wtype-limits should not trigger for types of implementation-defined signedness
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51712 --- Comment #14 from Manuel López-Ibáñez 2012-10-16 08:43:28 UTC --- (In reply to comment #13) > If the -fno-short-enums option is needed here, isn't that a bug? Agreed. This is just hiding the bug for the testsuite but not fixing it for users. This is one patch fixing this: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00383.html but a better fix is mentioned in the comments: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00972.html Implementing any of those options will fix this bug and add the infrastructure needed to fix similar bugs.
[Bug c/51712] -Wtype-limits should not trigger for types of implementation-defined signedness
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51712 --- Comment #13 from Jonathan Nieder 2012-10-16 07:55:56 UTC --- Hi Kyrill, (In reply to comment #11) > Adding the -fno-short-enums fixes the > extra warning generated by the arg >= 0 comparison in pr51712.c > > "warning: comparison is always true due to limited range of data type > [-Wtype-limits] > return arg >= 0 && arg <= BAR;" If the -fno-short-enums option is needed here, isn't that a bug?
