[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #17 from Oleg Endo --- Adrian, the recent GCC 5 build/bootstrap on SH included D, didn't it?
[Bug other/67457] New: segfault in libbacktrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457 Bug ID: 67457 Summary: segfault in libbacktrace Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Target Milestone: --- gfortran on trunk uses libbacktrace to print backtraces on error. In an out-of-memory situation, libbacktrace will fail to print a backtrace and segfault instead. While having something like a backtrace would be nice (and other compilers seem to manage), I guess that's difficult. For the segfault gdb print this: Starting program: /data/vjoost/gnu/bugs/a.out Operating system error: Cannot allocate memory Allocation would exceed memory limit Error termination. Backtrace: Could not print backtrace: mmap: Cannot allocate memory Could not print backtrace: mmap: Cannot allocate memory Could not print backtrace: mmap: Cannot allocate memory Program received signal SIGSEGV, Segmentation fault. backtrace_free_locked (state=0x77ecc000, size=3912, addr=0x20b7) at ../../../gcc/libbacktrace/mmap.c:75 75p->size = size; (gdb) bt #0 backtrace_free_locked (state=0x77ecc000, size=3912, addr=0x20b7) at ../../../gcc/libbacktrace/mmap.c:75 #1 backtrace_free (state=0x77ecc000, addr=0x20b7, size=3912, error_callback=, data=) at ../../../gcc/libbacktrace/mmap.c:199 #2 0x77fcd077 in backtrace_alloc (state=state@entry=0x77ecc000, size=size@entry=8376, error_callback=error_callback@entry=0x77ee8cd0 , data=data@entry=0x7fffde90) at ../../../gcc/libbacktrace/mmap.c:148 #3 0x77fcc7f8 in elf_initialize_syminfo (sdata=0x77ec0620, data=0x7fffde90, error_callback=0x77ee8cd0 , strtab_size=, strtab=, symtab_size=, symtab_data=0x77eb5088 "", base_address=140737352400896, state=0x77ecc000) at ../../../gcc/libbacktrace/elf.c:380 #4 elf_add (state=, descriptor=, base_address=140737352400896, error_callback=, data=0x7fffde90, fileline_fn=fileline_fn@entry=0x7fffd998, found_sym=0x7fffda70, found_dwarf=0x7fffd994, exe=0) at ../../../gcc/libbacktrace/elf.c:748 #5 0x77fccc67 in phdr_callback (info=0x7fffd9e0, size=, pdata=0x7fffda80) at ../../../gcc/libbacktrace/elf.c:903 #6 0x003ba4b26726 in dl_iterate_phdr () from /lib64/libc.so.6 #7 0x77fccd30 in backtrace_initialize (state=state@entry=0x77ecc000, descriptor=, error_callback=error_callback@entry=0x77ee8cd0 , data=data@entry=0x7fffde90, fileline_fn=fileline_fn@entry=0x7fffdb08) at ../../../gcc/libbacktrace/elf.c:944 #8 0x77fcb8b4 in fileline_initialize (state=state@entry=0x77ecc000, error_callback=error_callback@entry=0x77ee8cd0 , data=data@entry=0x7fffde90) at ../../../gcc/libbacktrace/fileline.c:136 #9 0x77fcb992 in backtrace_pcinfo (state=0x77ecc000, pc=140737352994313, callback=0x77ee8b10 , error_callback=0x77ee8cd0 , data=0x7fffde90) at ../../../gcc/libbacktrace/fileline.c:170 #10 0x77fcbe61 in unwind (context=, vdata=0x7fffde50) at ../../../gcc/libbacktrace/backtrace.c:83 #11 0x77ea8439 in _Unwind_Backtrace (trace=trace@entry=0x77fcbe10 , trace_argument=trace_argument@entry=0x7fffde50) at ../../../gcc/libgcc/unwind.inc:295 #12 0x77fcbeb5 in backtrace_full (state=state@entry=0x77ecc000, skip=skip@entry=0, callback=callback@entry=0x77ee8b10 , error_callback=error_callback@entry=0x77ee8cd0 , data=data@entry=0x7fffde90) at ../../../gcc/libbacktrace/backtrace.c:106 #13 0x77ee8e0a in _gfortrani_show_backtrace (in_signal_handler=in_signal_handler@entry=false) at ../../../gcc/libgfortran/runtime/backtrace.c:156 #14 0x77ee9906 in _gfortrani_exit_error (status=status@entry=1) at ../../../gcc/libgfortran/runtime/error.c:196 #15 0x77ee9b03 in _gfortrani_os_error (message=0x400a28 "Allocation would exceed memory limit") at ../../../gcc/libgfortran/runtime/error.c:348 #16 0x0040081e in foomod::foo (a=..., n=0) at test_1.f90:7 #17 0x004008c0 in MAIN__ () at test_1.f90:16 Testcase: > cat test_1.f90 MODULE foomod CONTAINS SUBROUTINE foo(a,N) INTEGER, DIMENSION(:), POINTER :: a INTEGER :: N ALLOCATE(a(N)) a=0 END SUBROUTINE END MODULE foomod USE foomod INTEGER, DIMENSION(:), POINTER :: a INTEGER :: N DO CALL foo(a,N) ENDDO END > gfortran -g test_1.f90 > ulimit -v 100 > ./a.out Operating system error: Cannot allocate memory Allocation would exceed memory limit Error termination. Backtrace: Could not print backtrace: mmap: Cannot allocate memory Could not print backtrace: mmap: Cannot allocate memory Could not print backtrace: mmap: Cannot allocate memory Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace f
[Bug target/67458] New: x86: atomic store with memory_order_release doesn't order other stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67458 Bug ID: 67458 Summary: x86: atomic store with memory_order_release doesn't order other stores Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: peter at cordes dot ca Target Milestone: --- As I understand it, std::atomic::store(val, memory_order_release) is a StoreStore barrier. However, when compiling for x86 (but not ARM or PowerPC), g++ moves a store past the barrier. Tested on godbolt: https://goo.gl/62ZCAS with x86 g++ 4.7.3 to 5.2, ARM g++ 4.8.2, and PowerPC g++ 4.8.2. Test case: #include std::atomic a; int b(0); using namespace std; void set(void) { b = 2; a.store(1, memory_order_release); b = 3; } ASM output: set(): # x86-64 g++ -std=c++11 -O3 # missing b=2 store before the MO_release store movl$1, a(%rip) movl$3, b(%rip) ret set(): # ARM g++ -std=c++11 -O3 movwr3, #:lower16:.LANCHOR0 movtr3, #:upper16:.LANCHOR0 movsr2, #2 movsr1, #1 str r2, [r3] # b = 2 movsr2, #3 dmb sy # full memory barrier. Couldn't this be just a dmb st (StoreStore barrier)? str r1, [r3, #4] # a = 1 str r2, [r3] # b = 3 bx lr Changing the atomic store to: atomic_thread_fence(memory_order_release); // stand-alone StoreStore barrier a.store(1, memory_order_relaxed); changes the x86 asm to be what I expected (and what clang produces for both versions): movl$2, b(%rip) movl$1, a(%rip) movl$3, b(%rip) ret (With no change to ARM or PowerPC asm) http://en.cppreference.com/w/cpp/atomic/atomic_thread_fence points out that unlike with a MO_release fence, a std::atomic::store(MO_release) can move downward so it appears after a later relaxed store. i.e. it's not a normal StoreStore barrier. So I think this would be valid output for the a.store(1, MO_release) version, but not the thread_fence(MO_release) version: movl$3, b(%rip) # b=3 can appear before a=1, so b=2 never needs to happen movl$1, a(%rip) ret BTW, I noticed this while writing up an answer to http://stackoverflow.com/questions/32384901/atomic-operations-stdatomic-and-ordering-of-writes.
[Bug target/67459] New: [SH] addc/subc/negc set of T reg rtx seem wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67459 Bug ID: 67459 Summary: [SH] addc/subc/negc set of T reg rtx seem wrong Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target Milestone: --- Target: sh*-*-* The following should be verified. Currently there is no problem because nothing in GCC understands or uses the exact T reg values. However, clrt/sett optimization might want to do that in the future, for which correct set rtxes are needed in the insns. addc: (set (reg:SI T_REG) (ltu:SI (plus:SI (match_dup 1) (match_dup 2)) (match_dup 1)))] The insn operation description says (comparisons are unsigned): if (R[n] > R[n] + R[m]) T = 1; else if (R[n] + R[m] > R[n] + R[m] + T) T = 1; else T = 0; which could probably be simplified a bit. subc: (set (reg:SI T_REG) (gtu:SI (minus:SI (minus:SI (match_dup 1) (match_dup 2)) (reg:SI T_REG)) (match_dup 1)))] The insn operation description says (comparisons are unsigned): if (R[n] < R[n] - R[m]) T = 1; else if (R[n] - R[m] < R[n] - R[m] - T) T = 1; else T = 0; negc: (set (reg:SI T_REG) (ne:SI (ior:SI (reg:SI T_REG) (match_dup 1)) (const_int 0)))] The insn operation description says: if (0 < 0 - R[m]) T = 1; else if (0 - R[m] - T < R[n]) T = 1; else T = 0;
[Bug target/65250] [SH] Improve comparisons followed by a negated cstore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65250 --- Comment #1 from Oleg Endo --- The patch attachment 36012 for PR 54236 improves the treg_set_expr machinery by doing proper comparison inversion, instead of trying only EQ <-> NE. This will be the prerequisite to match a (set (reg:SI 168) (leu:SI (reg:SI 4 r4 [ value ]) (const_int 2 [0x2]))) with a treg_set_expr. As for the multiple-set negc movrt insn, it's probably better to get rid of that altogether. Its main purpose is to indicate that the T reg is clobbered by the negc and to get a little bit of constant sharing of the -1 constant. If constant optimization is done after split1, this will be not necessary anymore. In some cases, a sett insn after a negc with constant -1 can be optimized away. To keep this, a negc insn that initially clobbers the T reg should be converted to the full multiple-set negc insn "negc" after combine/split1. Then the clrt_sett optimization pass (PR 53976) should be extended to understand addc, subc and negc insns which involve constants, to figure out whether a clrt or sett is really needed. Before that PR 67459 needs to be fixed.
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #18 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #17) > Adrian, the recent GCC 5 build/bootstrap on SH included D, didn't it? If you mean that gdc is built with gcc-5 on sh4, then no. The gdc packages are missing for gcc-5 on sh4 [1]. Adrian > [1] ftp://ftp.debian-ports.org/debian/pool-sh4/main/g/gcc-5/
[Bug fortran/60355] C519 of Fortran 2008 for BIND attribute not enforced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60355 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-05 Blocks||39627 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed at r227506. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39627 [Bug 39627] [meta-bug] Fortran 2008 support
[Bug fortran/55758] LOGICAL and BIND(C): Reject kind=2/4/8/16 with -std=f2008, improve warning, switch to nonBOOLEAN_TYPE for those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55758 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dominique d'Humieres --- > What remains to be fixed? If anything, is it related to pr47605? No answer since a year and a half. Closing as FIXED. Please open new PR(s) for remaining issue(s).
[Bug fortran/67460] New: [5/6 Regression] Spurious: f951: all warnings being treated as errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67460 Bug ID: 67460 Summary: [5/6 Regression] Spurious: f951: all warnings being treated as errors Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Target Milestone: --- The testcase below leads to spurious output at compile time, even though no warning (or error) is emitted. This started with the 5. release, 4.9 is fine. In a large build this can trigger many times, but it does not always trigger. > gfortran -c -std=f2003 -Werror bug.f90 f951: all warnings being treated as errors > cat bug.f90 MODULE btree_i8_k_sp2d_v TYPE btree_node INTEGER id TYPE(btree_node_p), DIMENSION(:), POINTER :: subtrees TYPE(btree_node), POINTER :: parent END TYPE btree_node TYPE btree_node_p TYPE(btree_node), POINTER :: node END TYPE btree_node_p CONTAINS RECURSIVE SUBROUTINE btree_verify_node (tree, node, level, nids, lastv,& count, num_nodes, max_leaf_level, min_leaf_level, printing) TYPE(btree_node), INTENT(IN) :: node INTEGER :: branch IF (ASSOCIATED (node%subtrees(branch)%node)) THEN IF (node%subtrees(branch)%node%parent%id .NE. node%id) THEN WRITE(*,*)'foo' ENDIF ENDIF END SUBROUTINE btree_verify_node END MODULE btree_i8_k_sp2d_v
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #19 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #18) > (In reply to Oleg Endo from comment #17) > > Adrian, the recent GCC 5 build/bootstrap on SH included D, didn't it? > > If you mean that gdc is built with gcc-5 on sh4, then no. The gdc packages > are missing for gcc-5 on sh4 [1]. Yes, that's what I meant. Could you try building gdc with gcc 5?
[Bug fortran/47648] libgfortran/libgfortran.h:53:29: fatal error: quadmath_weak.h: No such file or directory - FreeBSD ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47648 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from Dominique d'Humieres --- > Is it still a problem? No answer since a year and a half. Closing as FIXED. Please open new PR(s) for remaining issue(s).
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 --- Comment #27 from Dominique d'Humieres --- > Is it still true on recent versions of Cygwin (it has been fixed on darwin > since darwin10, see pr34136)? Ping! Without answer I'll close this PR as FIXED.
[Bug fortran/67177] MOVE_ALLOC not automatically allocating deferred character arrays in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67177 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed for 5.2 and trunk (6.0). Note that it is in general better to post the non working test rather the working one.
[Bug fortran/67460] [5/6 Regression] Spurious: f951: all warnings being treated as errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67460 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-05 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- No error with revision r218658 (2014-12-12), error with r218716 (2014-12-14), likely r218694.
[Bug fortran/66694] Failure in function returning an allocated CHARACTER array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66694 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0). The backtrace is * thread #1: tid = 0x4aa0976, 0x0001000e32d2 f951`gfc_alloc_allocatable_for_assignment(loop=, expr1=0x00014202b1a0, expr2=) + 3810 at trans-array.c:8698, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) frame #0: 0x0001000e32d2 f951`gfc_alloc_allocatable_for_assignment(loop=, expr1=0x00014202b1a0, expr2=) + 3810 at trans-array.c:8698 8695 { 8696 if (expr2->ts.deferred) 8697 { -> 8698 if (TREE_CODE (expr2->ts.u.cl->backend_decl) == VAR_DECL) 8699 tmp = expr2->ts.u.cl->backend_decl; 8700 else 8701 tmp = rss->info->string_length; (lldb) bt * thread #1: tid = 0x4aa0976, 0x0001000e32d2 f951`gfc_alloc_allocatable_for_assignment(loop=, expr1=0x00014202b1a0, expr2=) + 3810 at trans-array.c:8698, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0) * frame #0: 0x0001000e32d2 f951`gfc_alloc_allocatable_for_assignment(loop=, expr1=0x00014202b1a0, expr2=) + 3810 at trans-array.c:8698 frame #1: 0x00010010b8a9 f951`gfc_trans_assignment_1(expr1=0x00014202b1a0, expr2=0x00014202b610, init_flag=, dealloc=) + 1545 at trans-expr.c:9330 frame #2: 0x0001000d2696 f951`trans_code(code=0x00014202b6d0, cond=0x) + 1606 at trans.c:1674 frame #3: 0x0001000f7915 f951`gfc_generate_function_code(ns=) + 1061 at trans-decl.c:5900 frame #4: 0x0001000f7738 f951`gfc_generate_function_code(ns=0x000142814800) + 584 at trans-decl.c:5038 frame #5: 0x00010008a3ec f951`gfc_parse_file() + 1628 at parse.c:5521 frame #6: 0x0001000cf386 f951`gfc_be_parse_file + 54 at f95-lang.c:209 frame #7: 0x000100901c09 f951`compile_file + 57 at toplev.c:544 frame #8: 0x000100cd673c f951`toplev::main(int, char**) + 1151 at toplev.c:2046 frame #9: 0x000100cd62bd f951`toplev::main(this=, argc=2, argv=0x7fff5fbff350) + 717 frame #10: 0x000100cd81a9 f951`main(argc=2, argv=0x7fff5fbff350) + 41 at main.c:39 frame #11: 0x7fff8aaf35c9 libdyld.dylib`start + 1
[Bug fortran/66465] [4.9.2,5.1.0,6.0.0] procedure pointer component & non-component interpreted as different type or kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66465 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug fortran/66227] [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66227 Dominique d'Humieres changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- The output of the test is F T F T T T F T when compiled with 4.8 up to trunk (6.0). Am I correct to understand that the first and third answers are wrong?
[Bug c++/67461] New: Multiple atomic stores generate a StoreLoad barrier between each one, not just at the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67461 Bug ID: 67461 Summary: Multiple atomic stores generate a StoreLoad barrier between each one, not just at the end Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: peter at cordes dot ca Target Milestone: --- Multiple atomic stores in a row generate multiple barriers. I noticed this while playing around with the same code that led to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67458. This is a separate issue, but if I left out any context, look at that bug. I suspect this is a case of correctness trumps performance, since atomics are still new. These cases are probably just missing optimizations for weird use-cases, and fixing them is not very likely to benefit real code (unless it over-uses atomics). #include std::atomic a, c; void simple_set(void){ a=1; a=1; a=3; c=2; a=3; } compiles to (x86, g++ 5.2.0 -O3, on godbolt.org) movl$1, %eax movl%eax, a(%rip) # a=1 mfence movl%eax, a(%rip) # a=1 movl$3, %eax mfence movl%eax, a(%rip) # a=3 mfence movl$2, c(%rip)# c=2 mfence movl%eax, a(%rip) # a=3 mfence ret First, does the C++ standard actually require multiple stores to the same variable in a row, if there are no intervening loads or stores in the source? I would have thought that at least a=1; a=1; would collapse to a single store. Consider initially: a=0 thread1: a=1; a=1; thread2: tmp=a.exchange(2); tmp2=a; These operations have to happen in some order, but isn't the compiler allowed to make decisions at compile-time that eliminate some possible orders? e.g. collapsing both a=1 operations into a single store would make this impossible: a=1; tmp=a.exchange(2); a=1; tmp2=a; But the remaining two orderings are valid, and I think it would be an error for software to depend on that interleaved ordering being possible. Does the standard require generation of machine code that can end up with tmp=1, tmp2=1? If it does, then this isn't a bug. >.< More generally, collapsing a=1; a=3; into a single store should be ok for the same reason. A producer thread doing stores separated by StoreStore barriers to feed a consumer thread doing loads separated by LoadLoad barriers gives no guarantee that the consumer doesn't miss some events. --- There are no loads between the stores, so I don't understand having multiple StoreLoad barriers (mfence), unless that's just a missing optimization, too. Are the mfence instructions between each store supposed to protect a signal handler from something? An interrupt could come in after the first store, but before the first mfence. (clang uses (lock) xchg for each atomic store with sequential consistency, which would prevent the possibility of an interrupt between the store and the mfence). I guess if the signal handler sees a=3, it knows that the mfence between a=1 and a=3 has already happened, but not necessarily the mfence after a=3. If these extra mfences in a sequence of stores are just for the potential benefit of a signal handler, doesn't that already as part of the context switch to/from the kernel? It seems very inefficient that stores to multiple atomic variables produces multiple mfences. It's worse for ARM, where there's a full memory barrier before/after every atomic store, so two stores in a row produces two memory barriers in a row. dmb sy movsr2, #1 str r2, [r3] # a=1 dmb sy dmb sy str r2, [r3] # a=1 dmb sy
[Bug rtl-optimization/67462] New: [6 Regression] FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67462 Bug ID: 67462 Summary: [6 Regression] FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made" Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: ktkachov at gcc dot gnu.org Target Milestone: --- On Linux/x86-64, r227368 caused: spawn -ignore SIGHUP /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ /export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.dg/ifcvt-3.c -m32 -fno-diagnostics-show-caret -fdiagnostics-color=never -fdump-rtl-ce1 -O2 -ffat-lto-objects -S -o ifcvt-3.s PASS: gcc.dg/ifcvt-3.c (test for excess errors) FAIL: gcc.dg/ifcvt-3.c scan-rtl-dump ce1 "3 true changes made"
[Bug fortran/67076] [5/6 Regression] Critical inside a module procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67076 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-05 CC||burnus at gcc dot gnu.org Summary|Critical inside a module|[5/6 Regression] Critical |procedure |inside a module procedure Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- The test in comment 0 compiles with r213892 (2014-08-12) and gives an ICE with r214068 (2014-08-16), likely r213979.
[Bug c/63336] cilkplus array notation ICE in find_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63336 --- Comment #5 from tprince at computer dot org --- Created attachment 36294 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36294&action=edit shortened c code C source with external function calls removed
[Bug c/63336] cilkplus array notation ICE in find_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63336 --- Comment #6 from tprince at computer dot org --- Created attachment 36295 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36295&action=edit pre-processed C source pre-processed, without function calls
[Bug objc/67455] Inheriting from Object doesn't provide alloc, init or new rendering methods usless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67455 --- Comment #2 from James Hobson --- Okay. Interesting. Why is it then that many place on the internet indicate that they do? http://ubuntuforums.org/showthread.php?t=1064045 http://wiki.codeblocks.org/index.php?title=Installing_Objective-C_Compiler#Test_Build https://en.wikibooks.org/wiki/Objective-C_Programming/syntax Are they using something different?
[Bug objc/67455] Inheriting from Object doesn't provide alloc, init or new rendering methods usless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67455 --- Comment #3 from James Hobson --- Or more importantly, how can I write an +alloc method?
[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312 --- Comment #20 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #12) > Created attachment 36224 [details] > Stage 3 compiled version of ctfeexpr.dmd.o (unstripped) (In reply to John Paul Adrian Glaubitz from comment #11) > Created attachment 36223 [details] > Stage 2 compiled version of ctfeexpr.dmd.o (unstripped) I could spot only one difference: stage2: cmp/pz r1 // T = r1 >= 0 stage3: not r1,r0 shll r0 // T = ~r0 >> 31 Both versions are functionally equivalent. The increase from 1 insn to 2 insns then seems to cause other differences, which are mainly only offsets. Sometimes register allocation could also be affected. The question is why this is happening...
[Bug pending/67463] New: PGO (Profile Guided Optimizations) are not applied with gcc-5.2.1 (they are fine on gcc-4.9.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67463 Bug ID: 67463 Summary: PGO (Profile Guided Optimizations) are not applied with gcc-5.2.1 (they are fine on gcc-4.9.x) Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pending Assignee: unassigned at gcc dot gnu.org Reporter: shlomif at shlomifish dot org Target Milestone: --- With these source files: http://www.shlomifish.org/Files/files/arcs/investigate-gcc-PGO-0.2.0.tar.xz Generated from tag "0.2.0" of the repository at https://github.com/shlomif/investigate-lack-of-PGO-in-gcc-5.2.x--re-fc-solve and by following the instructions in the README namely: <<< 1. Make sure gcc, GNU make , etc. are in the path (a GNU/Linux system is preferable). Also install libtcmalloc, which is part of the gperftools / google-perftools package. 2. cd to the source/ directory and type "bash RUN_PGO.bash" . This will build everything. 3. Type "bash RUN_ME_TO_TIME.bash" to time the results. Here (= Mageia Linux x86-64 6/Cauldron) the gcc-4.9.x results are faster than those of the ones with gcc-5.2.1-0.20150811.4.mga6 . >>> Then I'm getting the benchmarks for the PGO version of the sources running at about 9.29seconds with gcc-5.2.1 while at gcc-4.9.x they are about 9.00seconds. It seems that for some reason -fprofile-use has no effect in gcc-5.2.1. Regards, -- Shlomi Fish
[Bug fortran/67460] [5/6 Regression] Spurious: f951: all warnings being treated as errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67460 --- Comment #2 from Manuel López-Ibáñez --- Again a problem caused by buffering. Some warnings converted into error may get buffered and then discarded but that doesn't reset ->some_warnings_are_errors. However, we probably do not need this variable at all, since we now count explicitly how many warnings were converted into errors and this number is kept up to date for buffered diagnostics. I think this patch should fix it, but I have not tested it yet: Index: diagnostic.c === --- diagnostic.c(revision 227395) +++ diagnostic.c(working copy) @@ -135,11 +135,10 @@ diagnostic_initialize (diagnostic_contex much more elaborated pretty-printer if they wish. */ context->printer = XNEW (pretty_printer); new (context->printer) pretty_printer (); memset (context->diagnostic_count, 0, sizeof context->diagnostic_count); - context->some_warnings_are_errors = false; context->warning_as_error_requested = false; context->n_opts = n_opts; context->classify_diagnostic = XNEWVEC (diagnostic_t, n_opts); for (i = 0; i < n_opts; i++) context->classify_diagnostic[i] = DK_UNSPECIFIED; @@ -202,11 +201,11 @@ diagnostic_color_init (diagnostic_contex void diagnostic_finish (diagnostic_context *context) { /* Some of the errors may actually have been warnings. */ - if (context->some_warnings_are_errors) + if (diagnostic_kind_count (context, DK_WERROR)) { /* -Werror was given. */ if (context->warning_as_error_requested) pp_verbatim (context->printer, _("%s: all warnings being treated as errors"), @@ -859,13 +858,10 @@ diagnostic_report_diagnostic (diagnostic warnings for ranges of source code. */ if (diagnostic->kind == DK_IGNORED) return false; } - if (orig_diag_kind == DK_WARNING && diagnostic->kind == DK_ERROR) -context->some_warnings_are_errors = true; - context->lock++; if (diagnostic->kind == DK_ICE || diagnostic->kind == DK_ICE_NOBT) { #ifndef ENABLE_CHECKING Index: diagnostic.h === --- diagnostic.h(revision 227395) +++ diagnostic.h(working copy) @@ -64,14 +64,10 @@ struct diagnostic_context pretty_printer *printer; /* The number of times we have issued diagnostics. */ int diagnostic_count[DK_LAST_DIAGNOSTIC_KIND]; - /* True if we should display the "warnings are being tread as error" - message, usually displayed once per compiler run. */ - bool some_warnings_are_errors; - /* True if it has been requested that warnings be treated as errors. */ bool warning_as_error_requested; /* The number of option indexes that can be passed to warning() et al. */
[Bug fortran/66189] Block loops for inline matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66189 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-09-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- IMO the matmul inlining should be restricted to small matrices, thus I am not convinced that this worth the work.
[Bug fortran/67460] [5/6 Regression] Spurious: f951: all warnings being treated as errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67460 --- Comment #3 from Joost VandeVondele --- (In reply to Manuel López-Ibáñez from comment #2) > Again a problem caused by buffering. Some warnings converted into error may > get buffered and then discarded but that doesn't reset > ->some_warnings_are_errors. However, we probably do not need this variable > at all, since we now count explicitly how many warnings were converted into > errors and this number is kept up to date for buffered diagnostics. I think > this patch should fix it, but I have not tested it yet: yes, fixes the testcase.
[Bug rtl-optimization/66236] [6 Regression] FAIL: gcc.c-torture/execute/pr42691.c on alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66236 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #5 from Bernd Edlinger --- (In reply to Uroš Bizjak from comment #4) > (In reply to Thomas Preud'homme from comment #3) > > Alternatively, you can try the patch proposed at [1] and see if it fixes the > > issue you're facing since it seems to be the same one. > > > > [1] https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01901.html > > Thomas, > > yes the referred patch also fixes this issue. > > Thanks! that was committed already. Thus this one should be fixed too?
[Bug rtl-optimization/66236] [6 Regression] FAIL: gcc.c-torture/execute/pr42691.c on alpha-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66236 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Uroš Bizjak --- (In reply to Bernd Edlinger from comment #5) > that was committed already. Thus this one should be fixed too? Yes, this was fixed.
[Bug tree-optimization/67464] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67464 Bug ID: 67464 Summary: wrong code at -O3 on x86_64-linux-gnu Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes. This is a regression from 5.2.x. $ gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix gcc version 6.0.0 20150905 (experimental) [trunk revision 227508] (GCC) $ $ gcc-trunk -O2 small.c; ./a.out 01 $ gcc-5.2 -O3 small.c; ./a.out 01 $ $ gcc-trunk -O3 small.c $ ./a.out 00 $ - int printf (const char *, ...); int a = 1, b, c, d, e, f, g; void fn1 () { c = b; for (; d; d--) ; for (f = 0; f < 1; f++) for (e = 0; e < 1; e++) c = 0; } int main () { int h = a; b = h = g < 1 ? a : a < 0; for (a = 0; a < 1; a++) fn1 (); printf ("0"); printf ("%d\n", b); // b should be 1, not 0 return 0; }
[Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430 Dominique d'Humieres changed: What|Removed |Added Status|RESOLVED|SUSPENDED Last reconfirmed||2015-09-05 Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- >From https://groups.google.com/forum/#!topic/comp.lang.fortran/Vk4D8iDZOdc This has just been discussed on the J3 mailing list. (Bob Corbett (I think) picked up the original question and passed it on). My understanding of the discussion so far is that A) whoops, there's an error introduced by the reallocation on assignment stuff B) It has always been the intent of J3 to make the distinction between defined and intrinsic assignment to be a compile time choice. C) A (likely? possible?) fix is to add something like "unless the ranks are different" to one of the rules in the disambiguation text for intrinsic and defined assignment. (It's possible it was "ranks are the same", I don't remember) That's about all I remember of the discussion. Dick Hendrickson Marking this PR as SUSPENDED while waiting for the J3 ruling.
[Bug fortran/63921] [F08] pointer function as lvalue doesn't work when the function is a type bound function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63921 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #3) > Reset the importance to normal: as for today there are 854 open PRs and > several hundreds of them are more or as 'critical' than this one. > > If this PR is really critical for you, you should consider to fix it > yourself (or hire someone to do it for you). Dear Mirco, You will be happy to know that I have a patch for pointer function assignment, which fixes your problem. It will be submitted tomorrow. Dominique tested the patch today and recalled your problem report. I have recast your testcase and it appears below. I might not use this in the testsuite since it largely duplicates the one that I had written. However, the line STENCIL%JMP (1, 1 ) = 10.0d0 + STENCIL%JMP (1, 1 ) is neat and I will probably add something like it together with an attribution to you. Dominique also reminded me that PR40054 covers this missing feature from gfortran. Thanks for the report. Paul ! { dg-do run } ! ! Testcase for pointer function assignment from PR63921 ! Contributed by Mirco Valentini ! MODULE grid IMPLICIT NONE PRIVATE REAL(KIND=8), DIMENSION(100,100), TARGET :: WORKSPACE TYPE, PUBLIC :: grid_t REAL(KIND=8), DIMENSION(:,:), POINTER :: P => NULL () END TYPE PUBLIC :: INIT CONTAINS SUBROUTINE INIT( DAT ) IMPLICIT NONE TYPE(grid_t), INTENT(INOUT) :: DAT INTEGER :: I, J DAT%P => WORKSPACE DO I = 1, 100 DO J = 1, 100 DAT%P(I,J) = REAL ((I - 1)*100 + J - 1 ) END DO ENDDO END SUBROUTINE INIT END MODULE grid MODULE subgrid USE :: grid, ONLY: grid_t IMPLICIT NONE PRIVATE TYPE, PUBLIC :: subgrid_t INTEGER, DIMENSION(4) :: range CLASS(grid_t), POINTER:: grd => NULL () CONTAINS PROCEDURE, PASS :: INIT => LVALUE_INIT PROCEDURE, PASS :: JMP => LVALUE_JMP END TYPE CONTAINS SUBROUTINE LVALUE_INIT(HOBJ, P, D ) IMPLICIT NONE CLASS(subgrid_t), INTENT(INOUT) :: HOBJ TYPE(grid_t), POINTER, INTENT(IN):: P INTEGER, DIMENSION(4), INTENT(IN):: D HOBJ%range = D HOBJ%grd => P END SUBROUTINE LVALUE_INIT FUNCTION LVALUE_JMP(HOBJ, I, J ) RESULT(P) IMPLICIT NONE CLASS(subgrid_t), INTENT(INOUT) :: HOBJ INTEGER, INTENT(IN) :: I, J REAL(KIND=8), POINTER :: P P => HOBJ%grd%P( HOBJ%range(1) + I - 1, HOBJ%range(3) + J - 1 ) END FUNCTION LVALUE_JMP END MODULE subgrid PROGRAM test_lvalue USE :: grid USE :: subgrid IMPLICIT NONE TYPE(grid_t), POINTER :: GRID TYPE(subgrid_t) :: STENCIL REAL(KIND=8), POINTER :: real_tmp_ptr REAL(KIND=8) :: old_val ALLOCATE (GRID) CALL INIT (GRID) CALL STENCIL%INIT (GRID, [50, 52, 50, 53 ]) old_val = STENCIL%JMP (1, 1 ) ! Workaround !real_tmp_ptr => STENCIL%JMP( 1, 1 ) !real_tmp_ptr = 10.0d0 + STENCIL%JMP( 1, 1 ) ! This failed STENCIL%JMP (1, 1 ) = 10.0d0 + STENCIL%JMP (1, 1 ) if (STENCIL%JMP (1, 1 ) .ne. old_val + 10.0d0) call abort END PROGRAM test_lvalue
[Bug tree-optimization/67465] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67465 Bug ID: 67465 Summary: wrong code at -O3 on x86_64-linux-gnu Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes. This is a regression from 5.2.x. Different from PR 67464, -fno-tree-vectorize makes the bug disappear. $ gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix gcc version 6.0.0 20150905 (experimental) [trunk revision 227508] (GCC) $ $ gcc-trunk -O2 small.c; ./a.out $ gcc-trunk -O3 -fno-tree-vectorize small.c; ./a.out $ gcc-5.2 -O3 small.c; ./a.out $ $ gcc-trunk -O3 small.c $ ./a.out Aborted $ -- int a, b, c, d, e, h; int fn1 (int p1) { { int g[2]; for (int i = 0; i < 1; i++) g[i] = 0; if (g[0] < c) { a = (unsigned) (1 ^ p1) % 2; return 0; } } return 0; } void fn2 () { for (h = 0; h < 1; h++) { for (int j = 0; j < 2; j++) { for (b = 1; b; b = 0) a = 1; for (; b < 1; b++) ; if (e) continue; a = 2; } fn1 (h); short k = -16; d = k > a; } } int main () { fn2 (); if (a != 2) __builtin_abort (); return 0; }
[Bug c++/67466] New: Project segfaulting, working with other compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67466 Bug ID: 67466 Summary: Project segfaulting, working with other compilers Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: morandidodo at gmail dot com Target Milestone: --- First of all, sorry but I am not able to create a MWE which is able to reproduce the bug. I found this issue re-compiling the Voxelands project (https://gitlab.com/voxelands/voxelands.git) with gcc 5.2. I am working with an updated Arch Linux distribution on a x64 machine. The compilation process is configured, inside a "build" directory within the root of the git repo, using the following command: cmake .. -DCMAKE_BUILD_TYPE=Debug -DRUN_IN_PLACE=ON The compilation will terminate successfully, but running the code with gdb will lead to a segmentation fault and a stack smashing detection. Adding " -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang" to the configuration allow the compilation using clang, and in this case the application seems to run without problem (clang support the stack protector option, so it should detect if it exists). I performed different tests, trying to reproduce the bug with minimal examples, but I failed. I only found two things that could be useful. The first one is the simple backtrace from gdb: #0 0x73edb5f8 in raise () from /usr/lib/libc.so.6 #1 0x73edca7a in abort () from /usr/lib/libc.so.6 #2 0x73f1a05a in __libc_message () from /usr/lib/libc.so.6 #3 0x73fa15c7 in __fortify_fail () from /usr/lib/libc.so.6 #4 0x73fa1590 in __stack_chk_fail () from /usr/lib/libc.so.6 #5 0x0043b691 in ItemSAO::ItemSAO (this=0xa77520 , env=0x0, id=0, pos=..., inventorystring="\030") at /home/enki/development/voxelands/src/content_sao.cpp:81 #6 0x00445277 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/enki/development/voxelands/src/content_sao.cpp:62 #7 0x0044534b in _GLOBAL__sub_I__ZN18ServerActiveObject7m_typesE () at /home/enki/development/voxelands/src/content_sao.cpp:1583 #8 0x0073ff3d in __libc_csu_init () #9 0x73ec859f in __libc_start_main () from /usr/lib/libc.so.6 #10 0x004384d9 in _start () Line content_sao.cpp is the end of the function, but, IMHO, none of the created object on the stack should raise this problem. I recompiled the project adding manually "-fsanitize=address", and this is what I obtained: = ==17176==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6070dff0 at pc 0x006d62d9 bp 0x7fffe590 sp 0x7fffe580 WRITE of size 8 at 0x6070dff0 thread T0 #0 0x6d62d8 in std::_Rb_tree, std::allocator > > >, std::_Select1st, std::allocator > > > >, std::less, std::allocator, std::allocator > > > > >::_Rb_tree_impl, false>::_Rb_tree_impl() /usr/include/c++/5.2.0/bits/stl_tree.h:588 #1 0x6d4937 in std::_Rb_tree, std::allocator > > >, std::_Select1st, std::allocator > > > >, std::less, std::allocator, std::allocator > > > > >::_Rb_tree() /usr/include/c++/5.2.0/bits/stl_tree.h:807 #2 0x6d3cb1 in std::map, std::allocator > >, std::less, std::allocator, std::allocator > > > > >::map() /usr/include/c++/5.2.0/bits/stl_map.h:166 #3 0x6d3170 in InventoryDiff::InventoryDiff() /home/enki/development/voxelands/src/inventory.h:543 #4 0x6cc7c0 in Inventory::Inventory() /home/enki/development/voxelands/src/inventory.cpp:1159 #5 0x490b8a in ChestNodeMetadata::ChestNodeMetadata() /home/enki/development/voxelands/src/content_nodemeta.cpp:200 #6 0x4c7642 in __static_initialization_and_destruction_0 /home/enki/development/voxelands/src/content_nodemeta.cpp:194 #7 0x4c7a65 in _GLOBAL__sub_I_proto_SignNodeMetadata /home/enki/development/voxelands/src/content_nodemeta.cpp:4363 #8 0xa3747c in __libc_csu_init (/home/enki/development/voxelands/bin/voxelands+0xa3747c) #9 0x72f5859e in __libc_start_main (/usr/lib/libc.so.6+0x2059e) #10 0x4390d8 in _start (/home/enki/development/voxelands/bin/voxelands+0x4390d8) 0x6070dff5 is located 0 bytes to the right of 69-byte region [0x6070dfb0,0x6070dff5) allocated by thread T0 here: #0 0x76f04842 in operator new(unsigned long) /build/gcc-multilib/src/gcc-5.2.0/libsanitizer/asan/asan_new_delete.cc:60 #1 0x490b7f in ChestNodeMetadata::ChestNodeMetadata() /home/enki/development/voxelands/src/content_nodemeta.cpp:200 #2 0x4c7642 in __static_initialization_and_destruction_0 /home/enki/development/voxelands/src/content_nodemeta.cpp:194 #3 0x4c7a65 in _GLOBAL__sub_I_proto_SignNodeMetadata /home/enki/development/voxelands/src/content_nodemeta.cpp:4363 #4 0xa3747c in __libc_csu_init (/home/enki/development/voxelands/bin/voxelands+0xa3747
[Bug fortran/25071] dummy argument larger than actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071 --- Comment #12 from Dominique d'Humieres --- No activity for more than four years. AFAICT everything is fixed, but for comment 7 preferring an error instead of the warning. Since warnings can be turned into errors with -Werror, I don't think this PR should stay opened.
[Bug fortran/66238] C/Fortran interoperability broken with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66238 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-06 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- The two first tests are fixed with the patch [Book15] gcc/work% diff -up ../_clean/gcc/testsuite/gfortran.dg/bind_c_usage_16_c.c gcc/testsuite/gfortran.dg/bind_c_usage_16_c.c --- ../_clean/gcc/testsuite/gfortran.dg/bind_c_usage_16_c.c 2009-11-25 18:17:40.0 +0100 +++ gcc/testsuite/gfortran.dg/bind_c_usage_16_c.c 2015-09-05 22:17:49.0 +0200 @@ -5,13 +5,13 @@ #include -char returnA(char *); -char returnB(void); +unsigned char returnA(unsigned char *); +unsigned char returnB(void); void test(void); int main() { - char c; + unsigned char c; c = 'z'; c = returnA(&c); if (c != 'A') abort(); [Book15] gcc/work% diff -up ../_clean/gcc/testsuite/gfortran.dg/bind_c_usage_17_c.c gcc/testsuite/gfortran.dg/bind_c_usage_17_c.c --- ../_clean/gcc/testsuite/gfortran.dg/bind_c_usage_17_c.c 2009-11-25 18:17:47.0 +0100 +++ gcc/testsuite/gfortran.dg/bind_c_usage_17_c.c 2015-09-05 22:19:22.0 +0200 @@ -1,4 +1,4 @@ /* PR fortran/37201. Linked with bind_c_usage_17.f90. */ -char cdir(void){return '/';} +unsigned char cdir(void){return '/';} > For c_char_tests, a possible problem is the declaration of arguments as > character(c_char), value :: foo > This declares a character of len c_char and default kind as far as I know. > According to > https://gcc.gnu.org/onlinedocs/gfortran/Interoperable-Subroutines-and-Functions.html > the canonical declaration is rather: > character(kind=c_char) :: foo(*) > With the value attribute, I don't know how it should be handled though. Either I don't understand this or it is not working.
[Bug fortran/66762] ICE when compiling gfortran.dg/submodule_[16].f90 with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66762 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-06 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- Not fixed yet!-(
[Bug fortran/66833] [4.9/5.1/6.0]: ICE on assumed-rank character actual argument to intrinsic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66833 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-06 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug fortran/66158] Use DO loop constraints for optimizing bounds checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66158 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-09-06 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Bounds checking is rather cheap. Does the proposed optimization worth the work?