[Bug libstdc++/60521] std::lock_guard ignores adopt_lock strategy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60521 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- No, only 4.7 branch and later is currently supported.
[Bug middle-end/60534] New: ICE: in expand_GOMP_SIMD_VF, at internal-fn.c:142 with -fopenmp -O -fno-tree-loop-optimize and #pragma omp simd reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60534 Bug ID: 60534 Summary: ICE: in expand_GOMP_SIMD_VF, at internal-fn.c:142 with -fopenmp -O -fno-tree-loop-optimize and #pragma omp simd reduction Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 32358 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32358action=edit reduced testcase Compiler output: $ gcc -fopenmp -O -fno-tree-loop-optimize testcase.c testcase.c: In function 'foo': testcase.c:4:1: internal compiler error: in expand_GOMP_SIMD_VF, at internal-fn.c:142 foo (int a) ^ 0x946367 expand_GOMP_SIMD_VF /mnt/svn/gcc-trunk/gcc/internal-fn.c:142 0x7561f9 expand_call_stmt /mnt/svn/gcc-trunk/gcc/cfgexpand.c:2190 0x7561f9 expand_gimple_stmt_1 /mnt/svn/gcc-trunk/gcc/cfgexpand.c:3160 0x7561f9 expand_gimple_stmt /mnt/svn/gcc-trunk/gcc/cfgexpand.c:3312 0x757667 expand_gimple_basic_block /mnt/svn/gcc-trunk/gcc/cfgexpand.c:5152 0x759a0e gimple_expand_cfg /mnt/svn/gcc-trunk/gcc/cfgexpand.c:5731 0x759a0e execute /mnt/svn/gcc-trunk/gcc/cfgexpand.c:5951 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r208561 - ICE 4.8 - ignoring #pragma omp simd
[Bug other/60535] New: [4.9 Regression] Link failure with -flto and -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60535 Bug ID: 60535 Summary: [4.9 Regression] Link failure with -flto and -fsanitize=undefined Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Created attachment 32359 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32359action=edit unreduced testcase Trying to build Firefox with -flto and -fsanitize=undefined fails: markus@x4 libopus % g++ -fsanitize=undefined -flto -O2 jskwgen.ii /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function column_comparator(void const*, void const*): error: undefined reference to '.Lubsan_data0.3163' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function column_comparator(void const*, void const*): error: undefined reference to '.Lubsan_data3.3217' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function column_comparator(void const*, void const*): error: undefined reference to '.Lubsan_data2.3199' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function column_comparator(void const*, void const*): error: undefined reference to '.Lubsan_data1.3181' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function length_comparator(void const*, void const*): error: undefined reference to '.Lubsan_data6.3285' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function length_comparator(void const*, void const*): error: undefined reference to '.Lubsan_data5.3266' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function length_comparator(void const*, void const*): error: undefined reference to '.Lubsan_data4.3248' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function p(gen_opt*, char const*, ...): error: undefined reference to '.Lubsan_data7.3311' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function indent(gen_opt*): error: undefined reference to '.Lubsan_data8.3344' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function indent(gen_opt*): error: undefined reference to '.Lubsan_data9.3362' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function line(gen_opt*, char const*, ...): error: undefined reference to '.Lubsan_data10.3389' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function line(gen_opt*, char const*, ...): error: undefined reference to '.Lubsan_data11.3407' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function qchar(char, char*): error: undefined reference to '.Lubsan_data14.3475' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function qchar(char, char*): error: undefined reference to '.Lubsan_data12.3439' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function qchar(char, char*): error: undefined reference to '.Lubsan_data21.3601' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function qchar(char, char*): error: undefined reference to '.Lubsan_data20.3583' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function qchar(char, char*): error: undefined reference to '.Lubsan_data19.3565' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function qchar(char, char*): error: undefined reference to '.Lubsan_data13.3457' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function qchar(char, char*): error: undefined reference to '.Lubsan_data18.3547' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function qchar(char, char*): error: undefined reference to '.Lubsan_data17.3529' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function qchar(char, char*): error: undefined reference to '.Lubsan_data16.3511' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function qchar(char, char*): error: undefined reference to '.Lubsan_data15.3493' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function generate_letter_switch_r(gen_opt*, unsigned int*, unsigned int, unsigned int*, unsigned int): error: undefined reference to '.Lubsan_data23.3723' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function generate_letter_switch_r(gen_opt*, unsigned int*, unsigned int, unsigned int*, unsigned int): error: undefined reference to '.Lubsan_data43.4083' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function generate_letter_switch_r(gen_opt*, unsigned int*, unsigned int, unsigned int*, unsigned int): error: undefined reference to '.Lubsan_data44.4101' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function generate_letter_switch_r(gen_opt*, unsigned int*, unsigned int, unsigned int*, unsigned int): error: undefined reference to '.Lubsan_data45.4119' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function generate_letter_switch_r(gen_opt*, unsigned int*, unsigned int, unsigned int*, unsigned int): error: undefined reference to '.Lubsan_data46.4137' /tmp/ccMC55Z1.ltrans0.ltrans.o:ccMC55Z1.ltrans0.o:function generate_letter_switch_r(gen_opt*, unsigned int*, unsigned int, unsigned int*, unsigned int): error: undefined reference to '.Lubsan_data47.4155'
[Bug lto/56706] [4.8 Regression] failure building CP2K at -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2013-10-25 00:00:00 |2014-3-15 --- Comment #14 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- current 4.8 branch still fails as described in comment #0
[Bug fortran/60529] [4.9 Regression] [OOP] ICE with allocatable sub-component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60529 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-15 CC||janus at gcc dot gnu.org Summary|internal compiler error |[4.9 Regression] [OOP] ICE |with allocatable|with allocatable |sub-component |sub-component Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed. Slightly reduced test case: implicit none type :: TS integer, allocatable :: i end type type :: T type (TS) :: s(1) end type class(T), allocatable :: X end Does not show an error with 4.6, 4.7 and 4.8. Backtrace with 4.9: 0x61ea98 gfc_conv_descriptor_data_get(tree_node*) /home/jweil/gcc49/trunk/gcc/fortran/trans-array.c:145 0x6245a0 gfc_array_deallocate(tree_node*, tree_node*, tree_node*, tree_node*, tree_node*, gfc_expr*) /home/jweil/gcc49/trunk/gcc/fortran/trans-array.c:5340 0x66bf8d gfc_trans_deallocate(gfc_code*) /home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:5476 0x61b5a7 trans_code /home/jweil/gcc49/trunk/gcc/fortran/trans.c:1782 0x669bd1 gfc_trans_simple_do /home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:1438 0x669bd1 gfc_trans_do(gfc_code*, tree_node*) /home/jweil/gcc49/trunk/gcc/fortran/trans-stmt.c:1601 0x61b66a trans_code /home/jweil/gcc49/trunk/gcc/fortran/trans.c:1732 0x63b132 gfc_generate_function_code(gfc_namespace*) /home/jweil/gcc49/trunk/gcc/fortran/trans-decl.c:5610 0x63afe7 gfc_generate_contained_functions /home/jweil/gcc49/trunk/gcc/fortran/trans-decl.c:4728 0x63afe7 gfc_generate_function_code(gfc_namespace*) /home/jweil/gcc49/trunk/gcc/fortran/trans-decl.c:5546 Probably caused by the finalization implementation?
[Bug rtl-optimization/60533] [4.8/4.9 regression] Error introduced by bb-reorder at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-15
Ever confirmed|0 |1
--- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Following bb-reorder, insns 266 and 268 are now in block 12, but insn 283 is
in block 87, a great distance away. As a result, r6 is now upward exposed
by insn 283 in block 87, which has blocks 12 and 86 as predecessors. Block
86 ends with a call in insn 887, which clobbers the volatile register r6.
So along the path from block 86 to block 87, insn 283 is guaranteed to see
garbage in r6.
There is nothing in the prior graph corresponding to a path from block 86 to
block 87; this bogus path was introduced by the block reordering.
Right, because there is a barrier right after the call in the prior graph:
(call_insn 887 885 888 109 (parallel [
(set (reg:DI 3 3)
(call (mem:SI (symbol_ref/i:DI
(_ZN5vigra6detail14UnionFindArrayIiE9makeUnionEii) [flags 0x1]
function_decl 0x1bc04a00 makeUnion) [0 makeUnion S4 A8])
(const_int 0 [0])))
(clobber (reg:DI 65 lr))
])
/home/ubuntu/libvigraimpex/ubuntu1/libvigraimpex-1.10.0+dfsg/include/vigra/labelvolume.hxx:287
625 {*call_value_nonlocal_aixdi}
(expr_list:REG_DEAD (reg:DI 5 5)
(expr_list:REG_DEAD (reg:DI 4 4)
(expr_list:REG_DEAD (reg:DI 2 2)
(expr_list:REG_UNUSED (reg:DI 3 3)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:DI 2 2))
(expr_list:REG_LABEL_TARGET (use (reg:DI 5 5))
(expr_list:REG_LABEL_TARGET (use (reg:DI 4 4))
(expr_list:REG_LABEL_OPERAND (use (reg:DI 3 3))
(nil))
(barrier 888 887 889)
so the compiler thinks that the call never returns. Can you find out why?
[Bug sanitizer/60536] New: Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 Bug ID: 60536 Summary: Backtrace corrupted on Firefox build with -fsanitize=address and -flto Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org When I build Firefox with debugging symbols and -fsanitize=address -flto I get: markus@x4 mozilla-central % /var/tmp/moz-build-dir/dist/bin/firefox | more = ==5620==ERROR: AddressSanitizer: heap-use-after-free on address 0x60201210 at pc 0x7fc5d71a6dbd bp 0x7fffe89a1510 sp 0x7fffe89a14e8 READ of size 2 at 0x60201210 thread T0 Program /var/tmp/moz-build-dir/dist/bin/firefox (pid = 5620) received signal 6. Stack: UNKNOWN [/lib/libpthread.so.0 +0xF8B0] gsignal+0x0034 [/lib/libc.so.6 +0x00033FF4] abort+0x0147 [/lib/libc.so.6 +0x000353E7] UNKNOWN [/lib/libgcc_s.so.1 +0x0001094D] UNKNOWN [/lib/libgcc_s.so.1 +0x0001154F] dl_iterate_phdr+0x0134 [/lib/libc.so.6 +0x00116F94] _Unwind_Find_FDE+0x01D9 [/lib/libgcc_s.so.1 +0x00012AD9] UNKNOWN [/lib/libgcc_s.so.1 +0xEFAB] _Unwind_Backtrace+0x004B [/lib/libgcc_s.so.1 +0x000104CB] UNKNOWN [/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1 +0x000709A4] UNKNOWN [/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1 +0x00073D21] __asan_report_error+0x083A [/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1 +0x00064ADA] __interceptor_setlocale+0x0155 [/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1 +0x0003CDD5] Program /var/tmp/moz-build-dir/dist/bin/firefox (pid = 5620) received signal 6. Stack: UNKNOWN [/lib/libpthread.so.0 +0xF8B0] gsignal+0x0034 [/lib/libc.so.6 +0x00033FF4] abort+0x0147 [/lib/libc.so.6 +0x000353E7] UNKNOWN [/lib/libgcc_s.so.1 +0x0001094D] UNKNOWN [/lib/libgcc_s.so.1 +0x0001154F] dl_iterate_phdr+0x0134 [/lib/libc.so.6 +0x00116F94] _Unwind_Find_FDE+0x01D9 [/lib/libgcc_s.so.1 +0x00012AD9] UNKNOWN [/lib/libgcc_s.so.1 +0xEFAB] _Unwind_Backtrace+0x004B [/lib/libgcc_s.so.1 +0x000104CB] NS_StackWalk+0x00C2 [/var/tmp/moz-build-dir/dist/bin/libxul.so +0x013A0502] UNKNOWN [/var/tmp/moz-build-dir/dist/bin/libxul.so +0x05905F50] UNKNOWN [/var/tmp/moz-build-dir/dist/bin/libxul.so +0x056B77D4] UNKNOWN [/lib/libpthread.so.0 +0xF8B0] gsignal+0x0034 [/lib/libc.so.6 +0x00033FF4] abort+0x0147 [/lib/libc.so.6 +0x000353E7] UNKNOWN [/lib/libgcc_s.so.1 +0x0001094D] UNKNOWN [/lib/libgcc_s.so.1 +0x0001154F] dl_iterate_phdr+0x0134 [/lib/libc.so.6 +0x00116F94] _Unwind_Find_FDE+0x01D9 [/lib/libgcc_s.so.1 +0x00012AD9] UNKNOWN [/lib/libgcc_s.so.1 +0xEFAB] _Unwind_Backtrace+0x004B [/lib/libgcc_s.so.1 +0x000104CB] UNKNOWN [/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1 +0x000709A4] UNKNOWN [/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1 +0x00073D21] __asan_report_error+0x083A [/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1 +0x00064ADA] __interceptor_setlocale+0x0155 [/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/libasan.so.1 +0x0003CDD5] Program /var/tmp/moz-build-dir/dist/bin/firefox (pid = 5620) received signal 6. Stack: UNKNOWN [/lib/libpthread.so.0 +0xF8B0] gsignal+0x0034 [/lib/libc.so.6 +0x00033FF4] abort+0x0147 [/lib/libc.so.6 +0x000353E7] UNKNOWN [/lib/libgcc_s.so.1 +0x0001094D] UNKNOWN [/lib/libgcc_s.so.1 +0x0001154F] dl_iterate_phdr+0x0134 [/lib/libc.so.6 +0x00116F94] _Unwind_Find_FDE+0x01D9 [/lib/libgcc_s.so.1 +0x00012AD9] UNKNOWN [/lib/libgcc_s.so.1 +0xEFAB] _Unwind_Backtrace+0x004B [/lib/libgcc_s.so.1 +0x000104CB] NS_StackWalk+0x00C2 [/var/tmp/moz-build-dir/dist/bin/libxul.so +0x013A0502] UNKNOWN [/var/tmp/moz-build-dir/dist/bin/libxul.so +0x05905F50] UNKNOWN [/var/tmp/moz-build-dir/dist/bin/libxul.so +0x056B77D4] UNKNOWN [/lib/libpthread.so.0 +0xF8B0] gsignal+0x0034 [/lib/libc.so.6 +0x00033FF4] abort+0x0147 [/lib/libc.so.6 +0x000353E7] UNKNOWN [/lib/libgcc_s.so.1 +0x0001094D] UNKNOWN [/lib/libgcc_s.so.1 +0x0001154F] dl_iterate_phdr+0x0134 [/lib/libc.so.6 +0x00116F94] _Unwind_Find_FDE+0x01D9 [/lib/libgcc_s.so.1 +0x00012AD9] UNKNOWN [/lib/libgcc_s.so.1 +0xEFAB] _Unwind_Backtrace+0x004B [/lib/libgcc_s.so.1 +0x000104CB] NS_StackWalk+0x00C2 [/var/tmp/moz-build-dir/dist/bin/libxul.so +0x013A0502] UNKNOWN [/var/tmp/moz-build-dir/dist/bin/libxul.so +0x05905F50] UNKNOWN [/var/tmp/moz-build-dir/dist/bin/libxul.so +0x056B77D4] UNKNOWN [/lib/libpthread.so.0 +0xF8B0] gsignal+0x0034 [/lib/libc.so.6 +0x00033FF4] abort+0x0147 [/lib/libc.so.6 +0x000353E7] UNKNOWN [/lib/libgcc_s.so.1 +0x0001094D] UNKNOWN [/lib/libgcc_s.so.1 +0x0001154F]
[Bug fortran/55207] [F08] Variables declared in the main program should implicitly get the SAVE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 --- Comment #14 from janus at gcc dot gnu.org --- Author: janus Date: Sat Mar 15 10:53:04 2014 New Revision: 208590 URL: http://gcc.gnu.org/viewcvs?rev=208590root=gccview=rev Log: 2014-03-15 Janus Weil ja...@gcc.gnu.org PR fortran/55207 * decl.c (match_attr_spec): Variables in the main program implicitly get the SAVE attribute in Fortran 2008. 2014-03-15 Janus Weil ja...@gcc.gnu.org PR fortran/55207 * gfortran.dg/assumed_rank_7.f90: Explicitly deallocate variables. * gfortran.dg/c_ptr_tests_16.f90: Put into subroutine. * gfortran.dg/inline_sum_bounds_check_1.f90: Add -Wno-aggressive-loop-optimizations and remove an unused variable. * gfortran.dg/intent_optimize_1.f90: Put into subroutine. * gfortran.dg/pointer_init_9.f90: New. * gfortran.dg/volatile4.f90: Put into subroutine. * gfortran.dg/volatile6.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/pointer_init_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/assumed_rank_7.f90 trunk/gcc/testsuite/gfortran.dg/c_ptr_tests_16.f90 trunk/gcc/testsuite/gfortran.dg/inline_sum_bounds_check_1.f90 trunk/gcc/testsuite/gfortran.dg/intent_optimize_1.f90 trunk/gcc/testsuite/gfortran.dg/volatile4.f90 trunk/gcc/testsuite/gfortran.dg/volatile6.f90
[Bug fortran/60529] [4.9 Regression] [OOP] ICE with allocatable sub-component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60529 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- r206362 (2014-01-06) is OK, r206567 (2014-01-12) gives the ICE. Probably caused by the finalization implementation? Author: janus Date: Mon Jan 6 23:21:39 2014 New Revision: 206379 URL: http://gcc.gnu.org/viewcvs?rev=206379root=gccview=rev Log: 2014-01-06 Janus Weil ja...@gcc.gnu.org PR fortran/59589 * class.c (comp_is_finalizable): New function to dermine if a given component is finalizable. (finalize_component, generate_finalization_wrapper): Use it. 2014-01-06 Janus Weil ja...@gcc.gnu.org PR fortran/59589 * gfortran.dg/class_allocate_16.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/class_allocate_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/testsuite/ChangeLog is in the range.
[Bug fortran/55887] [OOP][F08] ICE with CLASS and data-target pointer association in (default) initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55887 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- In fact the target should implicitly get the SAVE attribute, which is what PR 55207 is about. Once that is fixed, also the remaining ICE here should be gone. It is. Closing as duplicate. *** This bug has been marked as a duplicate of bug 55207 ***
[Bug fortran/45290] [F08] pointer initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290 Bug 45290 depends on bug 55887, which changed state. Bug 55887 Summary: [OOP][F08] ICE with CLASS and data-target pointer association in (default) initialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55887 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/55207] [F08] Variables declared in the main program should implicitly get the SAVE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 55887 has been marked as a duplicate of this bug. ***
[Bug fortran/51076] [F2008][tracking] Pointer initialization in init expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51076 Bug 51076 depends on bug 55887, which changed state. Bug 55887 Summary: [OOP][F08] ICE with CLASS and data-target pointer association in (default) initialization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55887 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug ada/60504] [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 --- Comment #4 from Mikael Pettersson mikpelinux at gmail dot com --- (In reply to Eric Botcazou from comment #3) Nothing obvious stands out. I presume that exceptions cannot be caught? OK, it's presumably http://gcc.gnu.org/ml/gcc/2013-12/msg00157.html but no ARM maintainer has stepped in yet. :-( Try this: I'm trying this right now.
[Bug sanitizer/60536] Backtrace corrupted on Firefox build with -fsanitize=address and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60536 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Also happens without -flto.
[Bug c++/60531] template function not resolved when comparing functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60531 --- Comment #1 from Harald van Dijk harald at gigawatt dot nl --- It is rejected as far back as 2.95.x, so almost certainly not a regression.
[Bug fortran/56201] Realloc on assignment: Wrong code when assigning a zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56201 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Seems to be also okay looking at the dump: if ((real(kind=4)[0:] * restrict) r.data == 0B) r.data = (void * restrict) __builtin_malloc (1); else if (D.2390) r.data = (void * restrict) __builtin_realloc ((void *) r.data, 1); This closing as WORKSFORME
[Bug fortran/55207] [F08] Variables declared in the main program should implicitly get the SAVE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from janus at gcc dot gnu.org --- Fixed with r208590. Closing.
[Bug fortran/37336] [F03] Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Bug 37336 depends on bug 55207, which changed state. Bug 55207 Summary: [F08] Variables declared in the main program should implicitly get the SAVE attribute http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/59176] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59176 --- Comment #11 from David Binderman dcb314 at hotmail dot com --- (In reply to Jan Hubicka from comment #10) I will check how to silence the verifier. Over two weeks has elapsed. Is there anything I can help with to expedite this bug fix ? 4.9.0 is due soon.
[Bug tree-optimization/60537] New: Loop optimization code bloat for simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60537
Bug ID: 60537
Summary: Loop optimization code bloat for simple loops
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
I have noticed this on SH, maybe it also applies to other targets (checked on
4.9 r208241).
The following simple loop (simple strlen implementation):
unsigned int test (const char* s0)
{
const char* s1 = s0;
while (*s1)
s1++;
return s1 - s0;
}
With -O2 -m4 gets compiled to:
mov.b @r4,r1
tst r1,r1
bt/s.L4
mov r4,r1
add #1,r1
.align 2
.L3:
mov r1,r0
mov.b @r0,r2
tst r2,r2
bf/s.L3
add #1,r1
rts
sub r4,r0
.align 1
.L4:
rts
mov #0,r0
With -Os -m4 it is basically just the inner loop:
movr4,r1
.L2:
mov r1,r0
mov.b @r0,r2
tst r2,r2
bf/s.L2
add #1,r1
rts
sub r4,r0
The additional loop test in the loop header in the -O2 version seems a bit
pointless. If the loop exists at the first iteration, it simply falls through.
The additional test and jump around the loop doesn't gain anything in this
case but just increases code size unnecessarily.
[Bug middle-end/60429] [4.7/4.8 Regression] Miscompilation (aliasing) with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60429 --- Comment #25 from Allan Jensen linux at carewolf dot com --- Will it be backported to 4.8?
[Bug target/60538] New: [SH] improve support for cmp/str insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60538
Bug ID: 60538
Summary: [SH] improve support for cmp/str insn
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
Currently the cmp/str insn is only utilized in some builtin string functions.
There are some known higher level operations that could be implemented via the
cmp/str insn, most notably a 'contains zero byte' function, which can be done
in various ways:
bool haszero (unsigned int x)
{
return (x - 0x01010101) ~x 0x80808080;
}
bool haszero2 (unsigned int x)
{
return ~x 0x7F7F7F7F) + 0x7F7F7F7F) | x) | 0x7F7F7F7F);
}
bool haszero3 (unsigned int x)
{
return ((x 0xFF) (x 0xFF00) (x 0xFF) (x 0xFF00));
}
bool haszero4 (unsigned int x)
{
return ((x 0xFF) ((x 8) 0xFF)
((x 16) 0xFF) ((x 24) 0xFF)) == 0;
}
bool haszero5 (unsigned int x)
{
// this one looks quite difficult for combine.
const unsigned char* p = (const unsigned char*)x;
return (*p *(p + 1) *(p + 2) *(p + 3)) == 0;
}
bool haszero6 (unsigned int x)
{
// this one is probably impossible to do with combine patterns
// due to the conditional branch involved.
bool r = ((x + 0x7EFEFEFF) ^ ~x) 0x81010100;
if (r)
r = ~x 0x7F7F7F7F) + 0x7F7F7F7F) | v) | 0x7F7F7F7F);
return r;
}
bool haszero7 (unsigned int a)
{
return ((a 0xFF) == 0
| (a 0xFF00) == 0
| (a 0xFF) == 0
| (a 0xFF00) == 0);
}
The expected minimal SH code for the functions above those would be:
mov #0,r1
cmp/str r1,r4
rts
movt r0
It would also be nice if the actual cmp/str operation was recognized, although
that's a bit more difficult to match.
A while ago I've already tried out adding combine patterns for those kinds of
things, with limited success. The problem is that combine would try out only 3
or 4 insns at once and matching such complex operations require lots of combine
bridge patterns.
The annoying thing with combine bridge patterns are that they have to be split
again manually if they don't make it into the final complex pattern.
Moreover, if a combine bridge pattern is matched but doesn't make it into the
final pattern, there will be missed combine opportunities which would have been
taken if the bridge pattern wasn't matched.
One possible solution could be to have explicit combine bridge patterns. If a
bridge pattern doesn't get combined with another (bridge) pattern, combine
should discard the match and try out other options.
Combine bridge patterns could be identified by e.g. special insn attributes or
by adding a 'define_bridge_insn' or something like that.
Another rather brute force option would be to run the combine pass (and split
pass) again after split1.
[Bug target/60539] New: [SH] builtin string functions ignore loop and label alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60539
Bug ID: 60539
Summary: [SH] builtin string functions ignore loop and label
alignment
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
CC: christian.bruel at st dot com
Target: sh*-*-*
The following function:
unsigned int test (const char* x)
{
return __builtin_strlen (x);
}
compiled with -m4 -O2:
mov r4,r0
tst #3,r0
bf/s.L14
mov r4,r1
mov #0,r3
.L12:
mov.l @r1+,r2
cmp/str r3,r2
bf .L12
add #-4,r1
.L14:
mov.b @r1+,r2
tst r2,r2
bf/s.L14
mov r1,r0
rts
subcr4,r0
The loop and label alignments are missing. E.g. when not optimizing for size,
the loop alignment is set to '4 bytes' (.align 2), which seems to be ignored by
the code that expands the builtin functions.
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- Any reason why the patch in comment 7 has not been applied? I have it in my working tree since a while without any associated problem.
[Bug middle-end/60540] New: Don't convert int to float when comparing int with float constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
Bug ID: 60540
Summary: Don't convert int to float when comparing int with
float constant
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
This is probably not something that one would write on purpose, but I've seen
it somewhere:
bool test (int a)
{
return a 1.0;
}
On SH with -O2 -m4 this compiles to:
lds r4,fpul
mova.L3,r0
fmov.s @r0+,fr5// load double constant 1.0
fmov.s @r0+,fr4
float fpul,dr2// convert 'a' to double
fcmp/gt dr4,dr2 // double double
rts
movtr0
.L4:
.align 2
.L3:
.long 0
.long 1072693248
In this case an integer comparison could be done instead, which does not
require converting the integer variable to float/double. This seems like a
target independent issue.
[Bug fortran/58324] Bogus END-of-line error with list-directed I/O of file without trailing sequential record marker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58324 --- Comment #5 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Mar 15 15:12:01 2014 New Revision: 208591 URL: http://gcc.gnu.org/viewcvs?rev=208591root=gccview=rev Log: 2014-03-15 Jerry DeLisle jvdeli...@gcc.gnu PR libfortran/58324 * io/list_read.c (finish_list_read): Read one character to check for the end of the file. If it is the end, then issue the file end error message. If not, use eat_line to reach the end without giving error. The next attempt to read will then issue the error as described above. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug middle-end/60540] Don't convert int to float when comparing int with float (double) constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Summary|Don't convert int to float |Don't convert int to float |when comparing int with |when comparing int with |float constant |float (double) constant --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- In this case an integer comparison could be done instead, which does not require converting the integer variable to float/double. Well the C standard requires it, though we could optimize it away since 32bit integers can be exactly represented in a 64bit IEEE double.
[Bug fortran/58324] Bogus END-of-line error with list-directed I/O of file without trailing sequential record marker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58324 --- Comment #6 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Mar 15 15:15:22 2014 New Revision: 208592 URL: http://gcc.gnu.org/viewcvs?rev=208592root=gccview=rev Log: 2014-03-15 Jerry DeLisle jvdeli...@gcc.gnu PR libfortran/58324 * gfortran.dg/list_read_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/list_read_12.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/60540] Don't convert int to float when comparing int with float (double) constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540 --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) Well the C standard requires it, though we could optimize it away since 32bit integers can be exactly represented in a 64bit IEEE double. Yes, for doubles, absolutely. If converting a 32 bit int value to a 32 bit float, the resulting value is undefined behavior if it can't be represented by a 32 bit float, at least as far as I know. If this is the case, it could also be OK to do it for 32 bit floats, at least when doing unsafe math optimizations.
[Bug fortran/45290] [F08] pointer initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290 --- Comment #16 from janus at gcc dot gnu.org --- (In reply to janus from comment #13) (2) We currently get a slightly inappropriate error message for: implicit none integer, target, save :: t1 integer, pointer :: p1 = t end This can be fixed with the following patch (not regtested yet): Index: gcc/fortran/decl.c === --- gcc/fortran/decl.c(revision 208590) +++ gcc/fortran/decl.c(working copy) @@ -1759,8 +1759,8 @@ match_pointer_init (gfc_expr **init, int procptr) return MATCH_ERROR; } - if (!procptr) -gfc_resolve_expr (*init); + if (!procptr !gfc_resolve_expr (*init)) +return MATCH_ERROR; if (!gfc_notify_std (GFC_STD_F2008, non-NULL pointer initialization at %C))
[Bug lto/60530] openssh-6.5p1 can't be built with lto - revision 208516
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60530 --- Comment #3 from David Kredba nheghathivhistha at gmail dot com --- Thank you. So it is Openssh bug? -fpie should come from configure processing, should not?
[Bug middle-end/60540] Don't convert int to float when comparing int with float (double) constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
Harald van Dijk harald at gigawatt dot nl changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #3 from Harald van Dijk harald at gigawatt dot nl ---
(In reply to Oleg Endo from comment #2)
If converting a 32 bit int value to a 32 bit float, the resulting value is
undefined behavior if it can't be represented by a 32 bit float, at least as
far as I know.
Only if the int is out of float's range. If the int is in float's range, but
merely cannot be represented exactly, the value is rounded. Whether it is
rounded up or down is implementation-defined, but the result must be one of the
two nearest representable values. (C99 6.3.1.5p2)
Testcase:
#include stdlib.h
int f(int i) {
return i = 16777216.f;
}
int main(void) {
if (!f(16777217))
abort();
}
16777217 is rounded down, so this does not abort, but would abort if (i =
16777216.f) is optimised to (i = 16777216).
However, it would still be possible to optimise this to (i = 16777217).
[Bug target/60541] New: [4.9 Regression] ICE: in final_scan_insn, at final.c:2952: could not split insn with -march=barcelona
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60541
Bug ID: 60541
Summary: [4.9 Regression] ICE: in final_scan_insn, at
final.c:2952: could not split insn with
-march=barcelona
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Created attachment 32360
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32360action=edit
reduced testcase
Compiler output:
$ gcc -march=barcelona testcase.c
testcase.c: In function 'foo':
testcase.c:4:1: error: could not split insn
}
^
(insn 7 4 8 2 (parallel [
(set (reg:DF 21 xmm0 [orig:83 D.1796 ] [83])
(float:DF (mem/c:DI (plus:DI (reg/f:DI 6 bp)
(const_int -8 [0xfff8])) [0 a+0 S8
A64])))
(clobber (mem/c:DI (plus:DI (reg/f:DI 6 bp)
(const_int -24 [0xffe8])) [0 S8 A64]))
]) testcase.c:3 219 {*floatdidf2_sse_with_temp}
(nil))
testcase.c:4:1: internal compiler error: in final_scan_insn, at final.c:2952
0xac1248 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/mnt/svn/gcc-trunk/gcc/rtl-error.c:109
0x871bf4 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
/mnt/svn/gcc-trunk/gcc/final.c:2952
0x872a9d final(rtx_def*, _IO_FILE*, int)
/mnt/svn/gcc-trunk/gcc/final.c:2023
0x872fae rest_of_handle_final
/mnt/svn/gcc-trunk/gcc/final.c:4427
0x872fae execute
/mnt/svn/gcc-trunk/gcc/final.c:4502
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-208561-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-208561-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20140314 (experimental) (GCC)
[Bug fortran/45290] [F08] pointer initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290 --- Comment #17 from janus at gcc dot gnu.org --- (In reply to janus from comment #16) (In reply to janus from comment #13) (2) We currently get a slightly inappropriate error message for: This can be fixed with the following patch ... which does regtest cleanly in fact.
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #11 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #10) Any reason why the patch in comment 7 has not been applied? It was posted at http://gcc.gnu.org/ml/fortran/2013-08/msg00068.html some time ago, but did not directly get an ok and was apparently forgotten about again. TODO: A proper treatment of array arguments seems to be missing for both SIZEOF and STORAGE_SIZE. Question is whether the patch should be applied now and the array treatment added later, or if it should happen in one go.
[Bug fortran/60542] [4.9 Regression] realloc_on_assign_5.f03 aborts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60542 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org Target Milestone|--- |4.9.0 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org --- Janus, do you have any idea?
[Bug fortran/60542] New: [4.9 Regression] realloc_on_assign_5.f03 aborts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60542 Bug ID: 60542 Summary: [4.9 Regression] realloc_on_assign_5.f03 aborts Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org This is not PR 47674 (or so I think). ig25@linux-fd1f:~/Krempel/Where gfortran realloc_on_assign_5.f03 ig25@linux-fd1f:~/Krempel/Where ./a.out Program aborted. Backtrace: #0 0x7F67C6393417 #1 0x7F67C6394B12 #2 0x7F67C64651C8 #3 0x400C9E in MAIN__ at realloc_on_assign_5.f03:?
[Bug fortran/60542] [4.9 Regression] realloc_on_assign_5.f03 aborts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60542 --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #1) Janus, do you have any idea? Not without any further info: * What OS/configure line? * What GCC revision? When did it show up? * Can you generate a better backtrace (with -g3 -O0)?
[Bug rtl-optimization/57425] [4.8 Regression] RTL alias analysis unprepared to handle stack slot sharing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57425 --- Comment #17 from Mikael Pettersson mikpelinux at gmail dot com --- The backport patch has now been submitted: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00758.html
[Bug fortran/60542] [4.9 Regression] realloc_on_assign_5.f03 aborts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60542 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org --- This is with current trunk (as of a few minutes ago), on x86_64-unknown-linux-gnu. ig25@linux-fd1f:~/Krempel/Where gfortran -g realloc_on_assign_5.f03 ig25@linux-fd1f:~/Krempel/Where gfortran -v Es werden eingebaute Spezifikationen verwendet. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Ziel: x86_64-unknown-linux-gnu Konfiguriert mit: ../trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran,c++ Thread-Modell: posix gcc-Version 4.9.0 20140315 (experimental) (GCC) ig25@linux-fd1f:~/Krempel/Where ./a.out Program aborted. Backtrace: #0 0x7F2AC9F1D417 #1 0x7F2AC9F1EB12 #2 0x7F2AC9FEF208 #3 0x400C9E in MAIN__ at realloc_on_assign_5.f03:16 (discriminator 1) Abgebrochen gdb tells me this is at Breakpoint 1, 0x76ff2b90 in abort () from /lib64/libc.so.6 (gdb) bt #0 0x76ff2b90 in abort () from /lib64/libc.so.6 #1 0x77adbaf9 in _gfortrani_sys_abort () at ../../../trunk/libgfortran/runtime/error.c:173 #2 0x77bac209 in _gfortran_abort () at ../../../trunk/libgfortran/intrinsics/abort.c:33 #3 0x00400c9f in MAIN__ () at realloc_on_assign_5.f03:16 (gdb) up #1 0x77adbaf9 in _gfortrani_sys_abort () at ../../../trunk/libgfortran/runtime/error.c:173 173 abort(); (gdb) up #2 0x77bac209 in _gfortran_abort () at ../../../trunk/libgfortran/intrinsics/abort.c:33 33sys_abort (); (gdb) up #3 0x00400c9f in MAIN__ () at realloc_on_assign_5.f03:16 16if (a .ne. 'x') call abort
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #36 from David Kredba nheghathivhistha at gmail dot com --- I did not: /var/tmp/portage/app-office/calligra-2.8.0/temp/ccv1d4Ui.ltrans1.ltrans.o: In function `operator': /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/sheets/Condition.h:170: undefined reference to `Calligra::Sheets::qHash(Calligra::Sheets::Conditions const)' /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/sheets/Condition.h:170: undefined reference to `Calligra::Sheets::qHash(Calligra::Sheets::Conditions const)' /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/sheets/Condition.h:170: undefined reference to `Calligra::Sheets::qHash(Calligra::Sheets::Conditions const)' /var/tmp/portage/app-office/calligra-2.8.0/temp/ccv1d4Ui.ltrans1.ltrans.o: In function `qMapLessThanKey': /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/sheets/Condition.h:170: undefined reference to `Calligra::Sheets::qHash(Calligra::Sheets::Conditions const)' /var/tmp/portage/app-office/calligra-2.8.0/temp/ccv1d4Ui.ltrans1.ltrans.o: In function `operator': /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/sheets/Condition.h:170: undefined reference to `Calligra::Sheets::qHash(Calligra::Sheets::Conditions const)' /var/tmp/portage/app-office/calligra-2.8.0/temp/ccv1d4Ui.ltrans1.ltrans.o:/var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/sheets/Condition.h:170: more undefined references to `Calligra::Sheets::qHash(Calligra::Sheets::Conditions const)' follow collect2: error: ld returned 1 exit status sheets/CMakeFiles/calligrasheetscommon.dir/build.make:3104: recipe for target 'lib/libcalligrasheetscommon.so.13.0.0' failed trunk revision 208592 I am sorry I do not know how to reduce it.
[Bug fortran/60542] [4.9 Regression] realloc_on_assign_5.f03 aborts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60542 --- Comment #4 from janus at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #3) This is with current trunk (as of a few minutes ago), on x86_64-unknown-linux-gnu. I'm on the same platform and don't see the failure with gcc version 4.9.0 20140315 (experimental) [trunk revision 208590] (GCC) ig25@linux-fd1f:~/Krempel/Where ./a.out Program aborted. Backtrace: #0 0x7F2AC9F1D417 #1 0x7F2AC9F1EB12 #2 0x7F2AC9FEF208 #3 0x400C9E in MAIN__ at realloc_on_assign_5.f03:16 (discriminator 1) Abgebrochen So maybe you can try this? Index: realloc_on_assign_5.f03 === --- realloc_on_assign_5.f03(revision 208590) +++ realloc_on_assign_5.f03(working copy) @@ -13,6 +13,7 @@ if (a .ne. 'ax') call abort if (len (a) .ne. 2) call abort a = (a(2:2)) + print *,a if (a .ne. 'x') call abort if (len (a) .ne. 1) call abort end program main Maybe you could do a bit of debugging to see what goes wrong and where the error actually comes from?
[Bug fortran/60542] [4.9 Regression] realloc_on_assign_5.f03 aborts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60542 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug target/60525] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60525 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- *** Bug 60541 has been marked as a duplicate of this bug. ***
[Bug target/60541] [4.9 Regression] ICE: in final_scan_insn, at final.c:2952: could not split insn with -march=barcelona
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60541 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed by r208587. *** This bug has been marked as a duplicate of bug 60525 ***
[Bug fortran/57305] [OOP] ICE when calling SIZEOF on an unlimited polymorphic variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57305 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- TODO: A proper treatment of array arguments seems to be missing for both SIZEOF and STORAGE_SIZE. ??? besides if (sizeof(b)/= 24) call abort() if (storage_size(b) /= 64) call abort() Question is whether the patch should be applied now and the array treatment added later, or if it should happen in one go. Unless the patch remove the ICE by silent wrong codes, I'ld say incremental fix is not bad.
[Bug fortran/58324] Bogus END-of-line error with list-directed I/O of file without trailing sequential record marker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58324 --- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Mar 15 20:31:33 2014 New Revision: 208595 URL: http://gcc.gnu.org/viewcvs?rev=208595root=gccview=rev Log: 2014-03-15 Jerry DeLisle jvdeli...@gcc.gnu Backport from mainline PR libfortran/58324 PR libfortran/38199 * io/list_read.c (finish_list_read): Read one character to check for the end of the file. If it is the end, then issue the file end error message. If not, use eat_line to reach the end without giving error. The next attempt to read will then issue the error as described above. * io/read.c (read_decimal): Quickly skip spaces to avoid calls to next_char. * io/unit.c (is_trim_ok): New helper function to check various conditions to see if its OK to trim the internal unit string. (get_internal_unit): Use LEN_TRIM to shorten selected internal unit strings for optimizing READ. Enable this optimization for formatted READ. Modified: branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/list_read.c branches/gcc-4_8-branch/libgfortran/io/read.c branches/gcc-4_8-branch/libgfortran/io/unit.c
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #43 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Mar 15 20:31:33 2014 New Revision: 208595 URL: http://gcc.gnu.org/viewcvs?rev=208595root=gccview=rev Log: 2014-03-15 Jerry DeLisle jvdeli...@gcc.gnu Backport from mainline PR libfortran/58324 PR libfortran/38199 * io/list_read.c (finish_list_read): Read one character to check for the end of the file. If it is the end, then issue the file end error message. If not, use eat_line to reach the end without giving error. The next attempt to read will then issue the error as described above. * io/read.c (read_decimal): Quickly skip spaces to avoid calls to next_char. * io/unit.c (is_trim_ok): New helper function to check various conditions to see if its OK to trim the internal unit string. (get_internal_unit): Use LEN_TRIM to shorten selected internal unit strings for optimizing READ. Enable this optimization for formatted READ. Modified: branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/list_read.c branches/gcc-4_8-branch/libgfortran/io/read.c branches/gcc-4_8-branch/libgfortran/io/unit.c
[Bug fortran/58324] Bogus END-of-line error with list-directed I/O of file without trailing sequential record marker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58324 --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Mar 15 20:34:58 2014 New Revision: 208596 URL: http://gcc.gnu.org/viewcvs?rev=208596root=gccview=rev Log: 2014-03-15 Jerry DeLisle jvdeli...@gcc.gnu Backport from mainline PR libfortran/58324 * gfortran.dg/list_read_12.f90: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/list_read_12.f90 Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug ada/60504] [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 --- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com --- Sorry, no joy. With Eric's suggested patch I still got: === acats tests === Running chapter a ... FAIL: a87b59a Running chapter c2 ... Running chapter c3 ... FAIL: c380004 Running chapter c4 ... Running chapter c5 ... Running chapter c6 ... FAIL: c64201b FAIL: c64201c Running chapter c7 ... FAIL: c761007 Running chapter c8 ... FAIL: c85018a FAIL: c85018b Running chapter c9 ... FAIL: c930001 FAIL: c93004a FAIL: c93004b FAIL: c93004c FAIL: c93004d FAIL: c93004f FAIL: c940013 FAIL: c94001a FAIL: c94001b FAIL: c94001c FAIL: c94001f FAIL: c94002a FAIL: c94002g FAIL: c94007a FAIL: c94008a FAIL: c94008b FAIL: c94008c FAIL: c94008d FAIL: c94020a which is an improvement, but not a complete fix. At that point I aborted the whole thing. All FAILs were Execution terminated by abort of environment task. I'm going to try a revert of the unwind changes next, as soon as I can identify the corresponding svn revision numbers.
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #37 from Jason Merrill jason at gcc dot gnu.org --- (In reply to David Kredba from comment #36) I am sorry I do not know how to reduce it. You don't need to reduce it. Try building without LTO and with -save-temps, and send me the .i output for the file with the unresolved symbol errors.
[Bug c++/60391] [c++1y] ICE with auto parameter for operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60391 Adam Butcher abutcher at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |abutcher at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug c++/60391] [c++1y] ICE with auto parameter for operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60391 Adam Butcher abutcher at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-15 Ever confirmed|0 |1
[Bug c++/60390] [c++1y] ICE with declaring function with auto parameter as friend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60390 Adam Butcher abutcher at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-15 Assignee|unassigned at gcc dot gnu.org |abutcher at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #44 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Mar 15 23:06:44 2014 New Revision: 208599 URL: http://gcc.gnu.org/viewcvs?rev=208599root=gccview=rev Log: 2014-03-15 Jerry DeLisle jvdeli...@gcc.gnu Backport from mainline PR libfortran/58324 PR libfortran/38199 * intrinsics/string_intriniscs_inc.c (string_len_trim): Remove prototypes for string_len_trim and move to... * libgfortran.h (string_len_trim): ... here and (string_len_trim_char4): ...here. * io/list_read.c (finish_list_read): Read one character to check for the end of the file. If it is the end, then issue the file end error message. If not, use eat_line to reach the end without giving error. The next attempt to read will then issue the error as described above. * io/read.c (read_decimal): Quickly skip spaces to avoid calls to next_char. * io/unit.c (is_trim_ok): New helper function to check various conditions to see if its OK to trim the internal unit string. (get_internal_unit): Use LEN_TRIM to shorten selected internal unit strings for optimizing READ. Enable this optimization for formatted READ. Backport from mainline PR libfortran/58324 * gfortran.dg/list_read_12.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/list_read_12.f90 Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/intrinsics/string_intrinsics_inc.c branches/gcc-4_7-branch/libgfortran/io/list_read.c branches/gcc-4_7-branch/libgfortran/io/read.c branches/gcc-4_7-branch/libgfortran/io/unit.c branches/gcc-4_7-branch/libgfortran/libgfortran.h
[Bug fortran/58324] Bogus END-of-line error with list-directed I/O of file without trailing sequential record marker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58324 --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sat Mar 15 23:06:44 2014 New Revision: 208599 URL: http://gcc.gnu.org/viewcvs?rev=208599root=gccview=rev Log: 2014-03-15 Jerry DeLisle jvdeli...@gcc.gnu Backport from mainline PR libfortran/58324 PR libfortran/38199 * intrinsics/string_intriniscs_inc.c (string_len_trim): Remove prototypes for string_len_trim and move to... * libgfortran.h (string_len_trim): ... here and (string_len_trim_char4): ...here. * io/list_read.c (finish_list_read): Read one character to check for the end of the file. If it is the end, then issue the file end error message. If not, use eat_line to reach the end without giving error. The next attempt to read will then issue the error as described above. * io/read.c (read_decimal): Quickly skip spaces to avoid calls to next_char. * io/unit.c (is_trim_ok): New helper function to check various conditions to see if its OK to trim the internal unit string. (get_internal_unit): Use LEN_TRIM to shorten selected internal unit strings for optimizing READ. Enable this optimization for formatted READ. Backport from mainline PR libfortran/58324 * gfortran.dg/list_read_12.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/list_read_12.f90 Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/intrinsics/string_intrinsics_inc.c branches/gcc-4_7-branch/libgfortran/io/list_read.c branches/gcc-4_7-branch/libgfortran/io/read.c branches/gcc-4_7-branch/libgfortran/io/unit.c branches/gcc-4_7-branch/libgfortran/libgfortran.h
[Bug fortran/58324] Bogus END-of-line error with list-directed I/O of file without trailing sequential record marker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58324 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Fixed and closing.
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #45 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Fixed and closing.
[Bug fortran/60542] [4.9 Regression] realloc_on_assign_5.f03 aborts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60542
--- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org ---
Here's what valgrind has to say:
ig25@linux-fd1f:~/Krempel/Where cat r.f90
! { dg-do run }
! Test the fix for PR47523 in which concatenations did not work
! correctly with assignments to deferred character length scalars.
!
! Contributed by Thomas Koenig tkoe...@gcc.gnu.org
!
program main
implicit none
character(:), allocatable :: a, b
a = 'a'
if (a .ne. 'a') call abort
a = a // 'x'
if (a .ne. 'ax') call abort
if (len (a) .ne. 2) call abort
a = (a(2:2))
print *,a
if (a .ne. 'x') call abort
if (len (a) .ne. 1) call abort
end program main
ig25@linux-fd1f:~/Krempel/Where gfortran -g r.f90
ig25@linux-fd1f:~/Krempel/Where valgrind ./a.out
==27652== Memcheck, a memory error detector
==27652== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==27652== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==27652== Command: ./a.out
==27652==
==27652== Invalid read of size 1
==27652==at 0x4C2BD60: memcpy@GLIBC_2.2.5 (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==27652==by 0x400DBE: MAIN__ (r.f90:15)
==27652==by 0x400EDE: main (r.f90:19)
==27652== Address 0x5c56521 is 0 bytes after a block of size 1 alloc'd
==27652==at 0x4C29B7E: realloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==27652==by 0x400D7A: MAIN__ (r.f90:15)
==27652==by 0x400EDE: main (r.f90:19)
==27652==
Program aborted. Backtrace:
#0 0x4E4B417
#1 0x4E4CB12
#2 0x4F1D208
#3 0x400E87 in MAIN__ at r.f90:17 (discriminator 1)
==27652==
==27652== HEAP SUMMARY:
==27652== in use at exit: 3,700 bytes in 18 blocks
==27652== total heap usage: 25 allocs, 7 frees, 11,845 bytes allocated
==27652==
==27652== LEAK SUMMARY:
==27652==definitely lost: 0 bytes in 0 blocks
==27652==indirectly lost: 0 bytes in 0 blocks
==27652== possibly lost: 0 bytes in 0 blocks
==27652==still reachable: 3,700 bytes in 18 blocks
==27652== suppressed: 0 bytes in 0 blocks
==27652== Rerun with --leak-check=full to see details of leaked memory
==27652==
==27652== For counts of detected and suppressed errors, rerun with: -v
==27652== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2)
Abgebrochen
[Bug rtl-optimization/60533] [4.8/4.9 regression] Error introduced by bb-reorder at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 --- Comment #6 from Bill Schmidt wschmidt at gcc dot gnu.org --- Ah, thanks, I didn't see that. I will track down where the bogus barrier is being introduced. Thanks for the help!
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #11 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sun Mar 16 00:18:21 2014 New Revision: 208603 URL: http://gcc.gnu.org/viewcvs?rev=208603root=gccview=rev Log: 2014-03-15 Dominique d'Humieres domi...@lps.ens.fr Backport from mainline PR libgfortran/60128 * io/write_float.def (output_float): Remove unused variable nzero_real. Replace a double space with a single one. (determine_en_precision): Fix wrong handling of the EN format. Modified: branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/write_float.def
[Bug fortran/60542] [4.9 Regression] realloc_on_assign_5.f03 aborts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60542 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- This is not PR 47674 (or so I think). Why do you think so? The valgrind report in comment 5 is the same as the one in pr47674 comment 0. Tobias Burnus wrote: gfortran.dg/realloc_on_assign_5.f03 segfaults here; it works if I unset the environment variable MALLOC_CHECK_. Are you using MALLOC_CHECK_?
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #12 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Author: jvdelisle Date: Sun Mar 16 00:35:19 2014 New Revision: 208604 URL: http://gcc.gnu.org/viewcvs?rev=208604root=gccview=rev Log: 2014-03-15 Dominique d'Humieres domi...@lps.ens.fr Backport from mainline PR libfortran/60128 * gfortran.dg/fmt_en.f90: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/fmt_en.f90 Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Fixed on trunk and 4.8. Closing
[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59727 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- Although the code now work as expected by the reporter (after r208528 for trunk, r208595 for 4.8, and r208599), I agree that the code is invalid. Closing as such.
[Bug fortran/60526] [4.7/4.8/4.9 Regression] Accepts-invalid: Variable name same as type name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60526 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-16 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug tree-optimization/60533] [4.8/4.9 regression] Error introduced by cunrolli pass at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 --- Comment #7 from Bill Schmidt wschmidt at gcc dot gnu.org --- The problem is actually introduced much earlier, during the cunrolli (complete unroll inner) pass. I'm attaching dumps from 055t.copyrename2 and 056t.cunrolli to show what happens. Prior to unrolling, we have a loop formed by blocks 47,19,20,...,46, with the original call to makeUnion at the end of block 45. The unroller decides that this loop will be executed exactly 3 times and unrolls it completely. (It's not clear to me on what basis this decision is made in the first place; it doesn't seem justified on the surface.) In any case, the third copy of the loop comprises blocks 74 through 101, with the call to makeUnion duplicated at the end of block 100. The unroller then inserts a __builtin_unreachable at the end of block 101 for some reason. This survives until the rewrite into RTL, at which point it is converted to the barrier that causes the bad block reordering.
[Bug tree-optimization/60533] [4.8/4.9 regression] Error introduced by cunrolli pass at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 --- Comment #9 from Bill Schmidt wschmidt at gcc dot gnu.org --- Created attachment 32362 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32362action=edit Dump after complete unrolling
[Bug tree-optimization/60533] [4.8/4.9 regression] Error introduced by cunrolli pass at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 --- Comment #8 from Bill Schmidt wschmidt at gcc dot gnu.org --- Created attachment 32361 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32361action=edit Dump before complete unrolling
Re: [Bug tree-optimization/60533] [4.8/4.9 regression] Error introduced by cunrolli pass at -O3
On Mar 15, 2014, at 7:59 PM, wschmidt at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 --- Comment #7 from Bill Schmidt wschmidt at gcc dot gnu.org --- The problem is actually introduced much earlier, during the cunrolli (complete unroll inner) pass. I'm attaching dumps from 055t.copyrename2 and 056t.cunrolli to show what happens. Prior to unrolling, we have a loop formed by blocks 47,19,20,...,46, with the original call to makeUnion at the end of block 45. The unroller decides that this loop will be executed exactly 3 times and unrolls it completely. (It's not clear to me on what basis this decision is made in the first place; it doesn't seem justified on the surface.) What is the type of bc? That access to bc in bb 46 looks like to be the cause. What is the original code look like, do we have an out of bounds access here or just a miscombining to create one? Thanks, Andrew In any case, the third copy of the loop comprises blocks 74 through 101, with the call to makeUnion duplicated at the end of block 100. The unroller then inserts a __builtin_unreachable at the end of block 101 for some reason. This survives until the rewrite into RTL, at which point it is converted to the barrier that causes the bad block reordering.
[Bug tree-optimization/60533] [4.8/4.9 regression] Error introduced by cunrolli pass at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 --- Comment #10 from pinskia at gmail dot com pinskia at gmail dot com --- On Mar 15, 2014, at 7:59 PM, wschmidt at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60533 --- Comment #7 from Bill Schmidt wschmidt at gcc dot gnu.org --- The problem is actually introduced much earlier, during the cunrolli (complete unroll inner) pass. I'm attaching dumps from 055t.copyrename2 and 056t.cunrolli to show what happens. Prior to unrolling, we have a loop formed by blocks 47,19,20,...,46, with the original call to makeUnion at the end of block 45. The unroller decides that this loop will be executed exactly 3 times and unrolls it completely. (It's not clear to me on what basis this decision is made in the first place; it doesn't seem justified on the surface.) What is the type of bc? That access to bc in bb 46 looks like to be the cause. What is the original code look like, do we have an out of bounds access here or just a miscombining to create one? Thanks, Andrew In any case, the third copy of the loop comprises blocks 74 through 101, with the call to makeUnion duplicated at the end of block 100. The unroller then inserts a __builtin_unreachable at the end of block 101 for some reason. This survives until the rewrite into RTL, at which point it is converted to the barrier that causes the bad block reordering.
