[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?
