[Bug middle-end/38318] moving the allocation of temps out of loops.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318 --- Comment #12 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Marc Glisse from comment #11) So S2 cannot call free (or realloc) on the pointer and then exit or call longjmp or do an infinite loop or anything like that in fortran? Maybe we'll need a flag set by the front-end that says whether (all) functions are safe. well, not free or realloc or longjmp, but infinite loops are allowed in S2. The point is, one is really not passing a pointer to S2 (from a Fortran point of view).
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Kostya Serebryany from comment #7) -fno-omit-frame-pointer: that may or may not be a good idea, I don't know. I seem to need it to get good backtraces (i.e. full stack, line numbers etc.). Might be something I'm doing wrong, it is hard to figure out what the best practice is. I agree that -g incurs some overhead, but indeed, some line number information is most helpful to debug the issues flagged by sanitizer. If there are better approaches, they could indeed substitute the plain '-g'. I hardly dare to mention it, but would be nice have these symbolic stacks printed without the symbolize python script that seems needed now (and I believe is not part of gcc). I believe in this context libbacktrace has been metioned.
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #17 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Sergey Matveev from comment #16) Under the current behavior -fsanitize=address,leak is equivalent to -fsanitize=address. We've considered other options, such as making -fsanitize=leak change the default run-time behavior (currently the ASan runtime always has leak detection runtime-disabled by default, whereas the standalone LSan runtime always has it enabled). But we never arrived at anything sensible. From my 'user perspective' it would be great if -fsanitize=leak would perform leak checking by default (i.e. remove the requirement to export ASAN_OPTIONS=detect_leaks=1). At that point it would be natural to expect that -fsanitize=address,leak just enables the leak checking by default, while -fsanitize=address might not. Out of curiosity, is there a runtime performance difference in using -llsan or -lasan for leak checking only ?
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #19 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Kostya Serebryany from comment #18) I don't think we've measured pure-lsan slowdown, but I expect it to be small. asan/lsan bring in a different allocator (malloc/free). We tried to make it very fast and our measurements show that's it is close to tcmalloc performance (but a bit more greedy in memory). It also performs stack unwind on every malloc, so on malloc-intensive apps you may see some small slowdown. I our simulation code, it looks like the overhead for leak checking is about 20%. I haven't done very careful measurements yet, since this is more or less what we're willing to pay to integrate the (very useful) feature in our testing setup.
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #21 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Kostya Serebryany from comment #20) I our simulation code, it looks like the overhead for leak checking is about 20%. I haven't done very careful measurements yet, since this is more or less what we're willing to pay to integrate the (very useful) feature in our testing setup. that's with -fsanitize=address? No, full asan is about 100% (or more) overhead for us (I guess the overhead depends on the optimization level, but roughly speaking). This is only the leak checking (as obtained by only linking with -fsanitize=address and exporting the flag).
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-11/msg01389.htm ||l CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #19 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- posted patch: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01389.html
[Bug sanitizer/55439] ThreadSanitizer: handle atomic operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55439 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Jakub, your patch went in trunk 1yr ago, should this be closed as fixed ?
[Bug sanitizer/59188] New: [4.9 Regression] lib64/libtsan.so: undefined reference to `sigsetjmp'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
Bug ID: 59188
Summary: [4.9 Regression] lib64/libtsan.so: undefined reference
to `sigsetjmp'
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
looks like it is not possible to use -fsanitize=thread with current trunk.
cat test.c
int main()
{
return 0;
}
gcc -fsanitize=thread -pie -fPIC test.c
/data/vjoost/gnu/gcc_trunk/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib64/libtsan.so:
undefined reference to `sigsetjmp'
collect2: error: ld returned 1 exit status
[Bug sanitizer/59188] [4.9 Regression] lib64/libtsan.so: undefined reference to `sigsetjmp'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Dmitry Vyukov from comment #3) Can you please try the following patch compiles with warnings: ../../../../gcc/libsanitizer/tsan/tsan_interceptors.cc:2022:12: note: in expansion of macro ‘REAL’ *(uptr*)REAL(_setjmp) = dlsym(RTLD_NEXT, _setjmp); ^ ../../../../gcc/libsanitizer/interception/interception.h:145:25: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] However, it fixes the issue mentioned.
[Bug libgomp/59194] New: tsan detects race for real variables in an OMP reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194 Bug ID: 59194 Summary: tsan detects race for real variables in an OMP reduction clause Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch CC: jakub at gcc dot gnu.org This seems either a bug in libgomp or tsan, not clear which one. To reproduce, libgomp must be compiled first with -fsanitize=thread as described in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561#c15 and the following workaround applied to get tsan to work with trunk. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188#c3 The following program: cat test.f90 INTEGER :: i REAL :: m m=0.0 !$OMP PARALLEL DO REDUCTION(+:m) DO i=1,10 m=m+1.0 ENDDO IF (m.NE.10.0) CALL ABORT() END compiled and executed as gfortran -g -fPIE -pie -fopenmp -fsanitize=thread test.f90 ; export OMP_NUM_THREADS=2 ; ./a.out triggers the error below. Interestingly, this only happens if 'm' is decleared REAL, not if INTEGER. == WARNING: ThreadSanitizer: data race (pid=13744) Atomic write of size 4 at 0x7fffc5e9bfa0 by main thread: #0 __tsan_atomic32_compare_exchange_strong ??:0 (libtsan.so.0+0x00016da2) #1 MAIN__._omp_fn.0 test.f90:0 (exe+0x0ed1) #2 GOMP_parallel /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:167 (libgomp.so.1+0xe98c) #3 MAIN__ test.f90:0 (exe+0x0d73) #4 main ??:0 (exe+0x0df5) Previous read of size 4 at 0x7fffc5e9bfa0 by thread T1: #0 MAIN__._omp_fn.0 test.f90:0 (exe+0x0e9d) #1 gomp_thread_start /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:117 (libgomp.so.1+0x00014e40) Location is stack of main thread. Thread T1 (tid=13746, running) created by main thread at: #0 pthread_create /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libsanitizer/tsan/../../../../gcc/libsanitizer/tsan/tsan_interceptors.cc:853 (libtsan.so.0+0x00035b1a) #1 gomp_team_start /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:795 (libgomp.so.1+0x00015686) #2 GOMP_parallel /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:166 (libgomp.so.1+0xe987) #3 MAIN__ test.f90:0 (exe+0x0d73) #4 main ??:0 (exe+0x0df5) SUMMARY: ThreadSanitizer: data race ??:0 __tsan_atomic32_compare_exchange_strong ==
[Bug libgomp/59194] tsan detects race for real variables in an OMP reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Andrew Pinski from comment #1) I think this is still a dup of bug 40362. I think the linux-futex case should be fixed by http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561#c38 PR40362 is still relevant for --disable-linux-futex However, admittedly, I don't know this topic well enough to figure this out from the code myself.
[Bug libgomp/59194] tsan detects race for real variables in an OMP reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- actually it seems more general an issue, the following: SUBROUTINE S1(m) REAL :: m !$OMP ATOMIC m=m+1.0 END REAL :: m m=0.0 !$OMP PARALLEL CALL S1(m) !$OMP END PARALLEL END flags race for the atomic update of m. Again, does work for integers but not for reals.
[Bug libgomp/59194] tsan detects race for real variables in an OMP reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jakub Jelinek from comment #4) I bet tsan complains because the load is not atomic, but does it really matter? I think there are (at least) two possible answers to this. 1) No, it doesn't matter, because we get the right result. This actually is great, already and your and other gcc-ers effort is much appreciated. 2) But yes, it does. For users, having a tool to help verify/debug an OMP program is very valuable. tsan is pretty close to doing being exactly that, and the gomp+tsan combination would be really a plus for gcc, increasing in importance as OMP (or related variants) becomes more and more common. Such false positives reduce the value of the gomp+tsan tool significantly. Therefore, if these issues could be fixed easily without significant downside, I think this should be done. I'd happy to try patches, and do some tsan+omp testing.
[Bug libgomp/59194] tsan detects race for real variables in an OMP reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jakub Jelinek from comment #4) I bet tsan complains because the load is not atomic, but does it really matter? If we read garbage there, compare and swap will fail and next time we'll have hopefully correct value already from what compare and swap said was the previous value. Actually, I believe this might fail. If the garbage read happens to be equal to what a 3rd thread writes in the meanwhile (admittedly, small change), the compare and swap will succeed and not fail.
[Bug libgomp/59194] tsan detects race for real variables in an OMP reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jakub Jelinek from comment #7) And the problem with that is? Because the arithmetics is based on the value we've read, it shouldn't be a problem. Ah...right. That said, during stage3 I'll look at how costly would be to use there __atomic_load_n with MEMMODEL_RELAXED. Thanks!
[Bug sanitizer/59215] tsan: warning in shared_ptr_base.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #14 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jonathan Wakely from comment #10) No, you're right, that's a different issue. I think we've just been relying on loads of (correctly-aligned) _Atomic_word being atomic, although that's not going to keep tsan happy! There's no barrier on the read, but I think the worst that will happen is we won't see the correct value and the CAS loop will go round again. We won't see __count==0 spuriously, because once that count reaches zero it never gets incremented again. Interestingly, a very similar comment was made yesterday in the context of libgomp: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194#c4 If for performance reasons a plain load would nevertheless be preferred over an atomic one, I wonder if these threading libraries could e.g. use conditional compilation such that, when compiled with -fsanitize=thread, an atomic load is used nevertheless. Does -fsanitize=thread define a __SANITIZE_THREAD_IN_USE or similar ?
[Bug fortran/59229] [4.9.0 Regression] ICE in ix86_expand_set_or_movmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-21 CC||Joost.VandeVondele at mat dot ethz ||.ch Ever confirmed|0 |1 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Confirmed... very satisfying to see that this single file 8 lines programs are still bleeding edge.
[Bug fortran/59229] [4.9.0 Regression] ICE in ix86_expand_set_or_movmem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- reducing..
[Bug fortran/45586] [4.8/4.9 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #97 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Richard Biener from comment #89) I believe the correct solution will involve implementing the proposal for introducing explicit restrict tags and using that in the fortran frontend (removing the restrict qualification work). See http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01011.html. I guess that has now become: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02727.html progress!
[Bug libstdc++/59215] tsan: warning in shared_ptr_base.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215 --- Comment #18 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jonathan Wakely from comment #17) But I can't test it yet because libtsan is giving me undefined references to sigsetjmp. workaround in PR59188
[Bug sanitizer/59188] [4.9 Regression] lib64/libtsan.so: undefined reference to `sigsetjmp'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2013-11-21 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Richard Biener from comment #9) Fixed unlikely, the fix only went to the llvm repo so far. (works for me now). depends on your libc
[Bug lto/56706] [4.8/4.9 Regression] failure building CP2K at -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 --- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Richard Biener from comment #8) Waiting for analysis. Analysis by whom, and if me, what can I do ?
[Bug web/56063] [bugzilla] last reconfirmed : now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56063 --- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Frederic, are you still looking into this one ? I still believe this would be progress.
[Bug lto/56706] [4.8/4.9 Regression] failure building CP2K at -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 --- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- So, after the change from fat to slim lto, I've added the CP2K SVN repo to use gcc-ar (so that the instructions in comment #1 should still work). Now, the issue discussed here fails to reproduce because during the lto phase we run into: /data/vjoost/clean/cp2k/cp2k/makefiles/../src/thermostat_methods.F:102:0: internal compiler error: tree check: expected ssa_name, have integer_cst in simplify_conversion_from_bitmask, at tree-ssa-forwprop.c:1189 SUBROUTINE create_thermostats(thermostats, md_section, force_env, simpar, ^ 0xb15de4 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9189 0x9e52c0 tree_check ../../gcc/gcc/tree.h:2710 0x9e52c0 simplify_conversion_from_bitmask ../../gcc/gcc/tree-ssa-forwprop.c:1189 0x9ef3cd ssa_forward_propagate_and_combine ../../gcc/gcc/tree-ssa-forwprop.c:3552 0x9ef3cd execute ../../gcc/gcc/tree-ssa-forwprop.c:3661 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [/tmp/ccEVGVIu.ltrans20.ltrans.o] Error 1
[Bug lto/56706] [4.8/4.9 Regression] failure building CP2K at -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Depends on||59154 --- Comment #11 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- the ICE just mentioned is PR59154.
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #29 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- I've tried -fsanitize=leak and it works well, thanks! Concerning the speed, I'm still seeing about 20% slowdown (again, this is acceptable from my point of view). Under oprofile, the __sanitizer::internal_memset is near the top (see below), it this expected for -fsanitize=leak ? Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 9 samples %linenr info image name symbol name --- 18.1e-04 (no location information) cp2k.sopt __input_cp2k_poisson_MOD_create_multipole_section 740.0596 (no location information) libc-2.12.so register_printf_type 124031 99.9396 crtstuff.c:0liblsan.so.0.0.0 __sanitizer::internal_memset(void*, int, unsigned long) 1240319.6999 crtstuff.c:0liblsan.so.0.0.0 __sanitizer::internal_memset(void*, int, unsigned long) 124031 46.7440 crtstuff.c:0liblsan.so.0.0.0 __sanitizer::internal_memset(void*, int, unsigned long) 124031 46.7440 crtstuff.c:0liblsan.so.0.0.0 __sanitizer::internal_memset(void*, int, unsigned long) [self] 17279 6.5120 (no location information) no-vmlinux /no-vmlinux ---
[Bug fortran/59276] New: Incorrect error message with modules of different gfortran versions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59276 Bug ID: 59276 Summary: Incorrect error message with modules of different gfortran versions Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch This 'bug' might lead to some confusion. If an older version of gfortran (i.e. 4.8) reads a module generated with 4.9 the error message is: Fatal Error: File 'm1.mod' opened at (1) is not a GNU Fortran module file instead of the more useful variant one had with 4.8/4.7 Fatal Error: Wrong module version '10' (expected '9') for file 'm1.mod' opened at (1) I don't see how this can be fixed other than fixing the error message on the release branches into '... not a module file compatible with this version of GNU Fortran'.
[Bug fortran/54797] Gnu Fortran compiler does not recognize module file it created
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54797 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- there is actually some recent change that causes similar behavior: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59276
[Bug sanitizer/59286] New: segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
Bug ID: 59286
Summary: segfault in __sanitizer::StackDepotGet
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Running our tsan instrumented code, I'm seeing a segfault in tsan. I have no
suitable testcase for this yet (short of building CP2K), so I'm posting the
backtrace here in case this rings a bell / triggers some suggestions on what
might be going on. I'll try to do some further testing.
Program received signal SIGSEGV, Segmentation fault.
0x74a27428 in __sanitizer::StackDepotGet (id=8388952,
size=0x7ffcb8f8) at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:192
192 if (s-id == id) {
(gdb) bt
#0 0x74a27428 in __sanitizer::StackDepotGet (id=8388952,
size=0x7ffcb8f8) at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:192
#1 0x74a1d9de in __tsan::ScopedReport::AddLocation (this=0x800158,
this@entry=0x7ffcb9f0, addr=140737488140536, addr@entry=137748196274048,
size=140737321271672,
size@entry=8) at ../../../../gcc/libsanitizer/tsan/tsan_rtl_report.cc:339
#2 0x74a1ed30 in __tsan::ReportRace (thr=optimized out) at
../../../../gcc/libsanitizer/tsan/tsan_rtl_report.cc:697
#3 0x74a21e02 in __tsan_report_race_thunk () at
../../../../gcc/libsanitizer/tsan/tsan_rtl_amd64.S:122
#4 0x749ef9c8 in HandleRace (old=..., cur=..., shadow_mem=optimized
out, thr=optimized out) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:376
#5 MemoryAccessImpl (cur=..., shadow_mem=optimized out, kIsAtomic=optimized
out, kAccessIsWrite=optimized out, kAccessSizeLog=optimized out,
addr=optimized out,
thr=optimized out) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:460
#6 __tsan::MemoryAccess (thr=0x761f2780, pc=496049752, addr=82100428376,
kAccessSizeLog=8, kAccessIsWrite=true, kIsAtomic=true)
at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:531
#7 0x767e62c0 in timings::timeset (routinen=error reading variable:
Cannot access memory at address 0x3fe13824d8597625,
handle=error reading variable: Cannot access memory at address
0x3fe13824d8597005, _routinen=optimized out) at
/data/vjoost/clean/cp2k/cp2k/src/../src/timings.F:254
(gdb) print s
$1 = (__sanitizer::StackDesc *) 0x4d634810890c558b
(gdb) print s-id
Cannot access memory at address 0x4d634810890c5593
(gdb) print id
$2 = 8388952
(gdb) list
187CHECK_LT(idx, kTabSize);
188atomic_uintptr_t *p = depot.tab[idx];
189uptr v = atomic_load(p, memory_order_consume);
190StackDesc *s = (StackDesc*)(v ~1);
191for (; s; s = s-link) {
192 if (s-id == id) {
193*size = s-size;
194return s-stack;
195 }
196}
(gdb) print idx
$3 = 4476
(gdb) print kTabSize
$5 = 1048576
(gdb) print depot.tab[idx]
$6 = {val_dont_use = 140737321271672}
(gdb) print depot
[Bug sanitizer/59286] segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Kostya Serebryany from comment #1) does this happen with clang's tsan? This is a Fortran package, so trying clang is not really an option.
[Bug sanitizer/59286] segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Kostya Serebryany from comment #3) Can you post the exact command line to reproduce the failure? (We should have CP2K sources somewhere) The exact command line is rather easy: cd cp2k/tests/QS/regtest-hybrid-1 export OMP_NUM_THREADS=4 ; ../../../exe/test_tsan/cp2k.ssmp H2O-hybrid-pbe0.inp However, building a tsan instrumented CP2K is non-trivial, as it requires libgomp to be built with tsan (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561#c15 for a howto), and some of the dependent libraries must be built with tsan as well. I'm happy to help, but could take some time. Should I post detailed instructions? Meanwhile another CP2K input fails with: Unexpected mmap in InternalAllocator!
[Bug sanitizer/59286] segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #5)
However, building a tsan instrumented CP2K is non-trivial, as it requires
Maybe let's do some remote debugging then :)
We can give this a try, but I might need rather detailed instructions. I.e.
starting from a sample printf statement and a suggested line number. With my
current setup, I get the segfault in a new location:
Program received signal SIGSEGV, Segmentation fault.
__sanitizer::find (s=0x, s@entry=0x74c2e8b8,
stack=stack@entry=0x74d797b8, size=size@entry=19,
hash=hash@entry=1116003544)
at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:109
109if (s-hash == hash s-size == size) {
(gdb) bt 7
#0 __sanitizer::find (s=0x, s@entry=0x74c2e8b8,
stack=stack@entry=0x74d797b8, size=size@entry=19,
hash=hash@entry=1116003544)
at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:109
#1 0x735ae1a1 in __sanitizer::StackDepotPut (stack=0x74d797b8,
size=19)
at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:150
#2 0x73570e4d in __tsan::CurrentStackId (thr=0x,
pc=140737301157816) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:305
#3 0x735a1404 in __tsan::user_alloc (thr=0x74d79780,
pc=140737276073318, sz=24, align=optimized out)
at ../../../../gcc/libsanitizer/tsan/tsan_mman.cc:110
#4 0x7358d58c in __interceptor_malloc (size=24) at
../../../../gcc/libsanitizer/tsan/tsan_interceptors.cc:447
#5 0x757ba78c in timings::timestop (handle=339) at
/data/vjoost/clean/cp2k/cp2k/src/../src/timings.F:328
#6 0x776accf6 in dbcsr_error_handling::dbcsr_error_stop (handler=1,
error=...)
at
/data/vjoost/clean/cp2k/cp2k/src/../src/dbcsr_lib/dbcsr_error_handling.F:180
(More stack frames follow...)
(gdb) print s
$3 = (__sanitizer::StackDesc *) 0x
[Bug sanitizer/59286] segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #5)
Maybe let's do some remote debugging then :)
For the current setup, the crash is always in StackDepotGet
The following printfs:
StackDesc *s = (StackDesc*)(v ~1);
printf(Getting %p\n,s);
for (; s; s = s-link) {
if (s-id == id) {
*size = s-size;
return s-stack;
}
printf(Following %p\n,s-link);
}
Always crash at an output like:
Getting (nil)
Getting 0x70305eb0
Following 0xc004832c2
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x70461100 (LWP 24991)]
0x735ae4e0 in __sanitizer::StackDepotGet (id=4030474480, size=0x0) at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:196
196 if (s-id == id) {
(gdb) print s
$2 = (__sanitizer::StackDesc *) 0xc004832c2
so the s-link field containing something unexpected.
[Bug sanitizer/59286] segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
--- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #8)
Just insert more printfs everywhere you can :)
E.g. print everything around s-link = s2 in StackDepotPut
hmm I can write a lot of printfs, but it is not very targetted..
However, I think I got a little further. For this kind of crash:
Getting 0x7fffed22e328
Following 0x704b8a80
Following 0x40027bd6cd50653b
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffed2f5100 (LWP 9760)]
0x7fffebbae530 in __sanitizer::StackDepotGet (id=3978818064, size=0x0)
at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_stackdepot.cc:197
197 if (s-id == id) {
(gdb) print s
$3 = (__sanitizer::StackDesc *) 0x40027bd6cd50653b
I have put a hardware breakpoint on this field
break __sanitizer::StackDepotGet
awatch ((StackDesc*)0x704b8a80)-link
(which is the link that gets corrupted).
This breakpoint gets activated from CP2K at:
[Switching to Thread 0x7fffed3ec100 (LWP 9804)]
Hardware access (read/write) watchpoint 13: ((StackDesc*)0x704b8a80)-link
Value = (PTR TO - ( __sanitizer::StackDesc )) 0x40027bd6cd50653b
0x7fffee8811fe in hfx_load_balance_methods::estimate_basic (p=...)
at /data/vjoost/clean/cp2k/cp2k/src/../src/hfx_load_balance_methods.F:1829
1829 p1=p(1) ; p2=p(2) ; p3=p(3) ; p4=p(4)
(gdb) bt
#0 0x7fffee8811fe in hfx_load_balance_methods::estimate_basic (p=...)
at /data/vjoost/clean/cp2k/cp2k/src/../src/hfx_load_balance_methods.F:1829
#1 0x7fffee881020 in hfx_load_balance_methods::cost_model (nsa=1, nsb=1,
nsc=1, nsd=1, npgfa=6, npgfb=6,
npgfc=6, npgfd=6, ratio=-0.3026277383289448, p1=..., p2=..., p3=...)
at /data/vjoost/clean/cp2k/cp2k/src/../src/hfx_load_balance_methods.F:1817
#2 0x7fffee87ee8c in hfx_load_balance_methods::estimate_block_cost
(natom=3, nkind=2, list_ij=...,
list_kl=..., set_list_ij=..., set_list_kl=..., iatom_start=1, iatom_end=1,
jatom_start=1, jatom_end=1,
katom_start=1, katom_end=1, latom_start=1, latom_end=1, particle_set=...,
coeffs_set=..., coeffs_kind=...,
is_assoc_atomic_block_global=..., do_periodic=.FALSE., kind_of=...,
basis_parameter=..., pmax_set=...,
pmax_atom=..., pmax_blocks=0, cell=0x7d312d80, do_p_screening=.FALSE.,
map_atom_to_kind_atom=...,
eval_type=1, log10_eps_schwarz=-10, log_2=0.3010299956639812,
coeffs_kind_max0=1.1049525569372649,
use_virial=.FALSE., atomic_pair_list=...)
at /data/vjoost/clean/cp2k/cp2k/src/../src/hfx_load_balance_methods.F:2212
This is the 'correct' place for corruption, as this routine is only called for
those runs that segfault.
Potentially interesting is that this is also a routine that is somewhat special
in Fortran, i.e. a contained subroutine, which presumably is treated somewhat
special by the compiler (not sure about the C-like equivalent, maybe nested
functions or so ?)
[Bug sanitizer/59286] segfault in __sanitizer::StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286 --- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- well, maybe a more simple reason. If I export export OMP_STACKSIZE=32M (i.e. stack size for the threads), the segfault disappears... does that sound like a good reason (i.e. tsan instrumented binary might require more stack), or does this seem just lucky coincidence ?
[Bug sanitizer/59302] New: tsan: Unexpected mmap in InternalAllocator!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59302 Bug ID: 59302 Summary: tsan: Unexpected mmap in InternalAllocator! Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org One tsan test I'm doing fails with: Unexpected mmap in InternalAllocator apart from expecting a somewhat more useful output (e.g. Sanitizer internal error: Unexpected mmap in InternalAllocator ) Maybe this shouldn't happen ? I'm getting this with the following backtrace: [Switching to Thread 0x703ce100 (LWP 17517)] Breakpoint 1, Allocate (stat=optimized out, alignment=optimized out, size=optimized out, this=optimized out) at ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:948 948MapUnmapCallback().OnMap(map_beg, map_size); (gdb) bt #0 Allocate (stat=optimized out, alignment=optimized out, size=optimized out, this=optimized out) at ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:948 #1 Allocate (cleared=optimized out, alignment=optimized out, size=optimized out, cache=optimized out, this=optimized out) at ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:1187 #2 RawInternalAlloc (cache=0x7039e4c8, size=131080) at ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.cc:75 #3 __sanitizer::InternalAlloc (size=131072, cache=0x7039e4c8) at ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.cc:93 #4 0x735a6c6f in EnsureSize (size=4097, this=0x737dc310 __tsan::ctx_placeholder+64656) at ../../../../gcc/libsanitizer/tsan/tsan_vector.h:98 #5 PushBack (v=..., this=0x737dc310 __tsan::ctx_placeholder+64656) at ../../../../gcc/libsanitizer/tsan/tsan_vector.h:60 #6 HandleRacyStacks (thr=optimized out, addr_max=optimized out, addr_min=optimized out, traces=...) at ../../../../gcc/libsanitizer/tsan/tsan_rtl_report.cc:487 #7 __tsan::ReportRace (thr=optimized out) at ../../../../gcc/libsanitizer/tsan/tsan_rtl_report.cc:676 #8 0x735a9e82 in __tsan_report_race_thunk () at ../../../../gcc/libsanitizer/tsan/tsan_rtl_amd64.S:122 #9 0x73577a48 in HandleRace (old=..., cur=..., shadow_mem=optimized out, thr=optimized out) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:376 #10 MemoryAccessImpl (cur=..., shadow_mem=optimized out, kIsAtomic=optimized out, kAccessIsWrite=optimized out, kAccessSizeLog=optimized out, addr=optimized out, thr=optimized out) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:460 #11 __tsan::MemoryAccess (thr=0x7035b780, pc=542014296, addr=3378151234108248, kAccessSizeLog=8, kAccessIsWrite=true, kIsAtomic=true) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:531 #12 0x0004006f23be9d58 in ?? () #13 0x0fffc0d69de0 in ?? () #14 0x0008 in ?? () #15 0x in ?? () (gdb) cont Continuing. Unexpected mmap in InternalAllocator![Thread 0x703ce100 (LWP 17517) exited] [Thread 0x70462100 (LWP 17516) exited] [Thread 0x74cf6100 (LWP 17515) exited] [Thread 0x7fffeefff700 (LWP 17514) exited] [Inferior 1 (process 17510) exited with code 01]
[Bug sanitizer/59302] tsan: Unexpected mmap in InternalAllocator!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59302 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Kostya Serebryany from comment #1) This isn't expected to happen and so we did not write a better warning message. We may be able to fix it, but the underlying problem is in your tests: it has a race that tsan is trying to report and which is suppressed (probably because a similar races was reported before). How many race reports do you see before tsan crashes? Did you suppress any of those? yes, I have a suppression in place to workaround PR59194. As it is an atomic update in a hot loop, it will be triggered millions of times.
[Bug lto/56706] [4.8/4.9 Regression] failure building CP2K at -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Known to work||4.9.0 Known to fail|4.9.0 | --- Comment #12 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Building with 4.9.0 now works, 4.8.3 [gcc-4_8-branch revision 203695] still fails.
[Bug middle-end/58746] [4.9 Regression] Incorrect warning with -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58746 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Reduced : MODULE mathlib INTEGER, PARAMETER :: dp = 8 CONTAINS FUNCTION expint(n,x) REAL(dp) :: x, expint nm1=n-1 DO i=1,MAXIT IF(i.NE.nm1) THEN DO ii=1,nm1 psi=psi+1.0_dp/ii END DO del=fact*(-LOG(x)+psi) END IF expint=expint+del END DO END FUNCTION expint END MODULE USE mathlib REAL(KIND=dp), VOLATILE :: r=0.1_dp r = expint(1,r) END
[Bug middle-end/58746] [4.9 Regression] Incorrect warning with -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58746 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- this testcase gives the same error without LTO. Just -O2 is sufficient: INTEGER, PARAMETER :: dp = 8 REAL(KIND=dp), VOLATILE :: r=0.1_dp r = expint(1,r) CONTAINS FUNCTION expint(n,x) REAL(dp) :: x, expint INTEGER :: maxit=100 nm1=n-1 DO i=1,MAXIT IF(i.NE.nm1) THEN DO ii=1,nm1 psi=psi+1.0_dp/ii END DO del=fact*(-LOG(x)+psi) END IF expint=expint+del END DO END FUNCTION expint END
[Bug middle-end/57904] [4.9 Regression] Bogus(?) invokes undefined behavior warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- this is the same/similar issue as PR58746, which also triggers this warning but even without -m32 on x86_64.
[Bug fortran/34740] -fbounds-check with TRANSFER misses out of bounds in array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34740 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2009-03-29 08:22:06 |2013-11-27 CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- right... tripped over this in CP2K. Is found by g95. I notice that the code: SUBROUTINE S1() INTEGER, ALLOCATABLE, DIMENSION(:) :: a CHARACTER, ALLOCATABLE, DIMENSION(:) :: b ALLOCATE(a(20),b(20)) write(6,*) SIZE(a),SIZE(b) a=TRANSFER(b,a) write(6,*) SIZE(a),SIZE(b) END SUBROUTINE CALL S1() END already does the right reallocation of a, so I'd guess some of the base work has been done to produce a runtime error with -fcheck=bounds on SUBROUTINE S1() INTEGER, POINTER, DIMENSION(:) :: a CHARACTER, POINTER, DIMENSION(:) :: b ALLOCATE(a(20),b(20)) write(6,*) SIZE(a),SIZE(b) a=TRANSFER(b,a) write(6,*) SIZE(a),SIZE(b) END SUBROUTINE CALL S1() END
[Bug debug/54694] [4.7/4.8/4.9 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2012-09-25 00:00:00 |2013-11-28 CC||Joost.VandeVondele at mat dot ethz ||.ch Component|preprocessor|debug Known to work||4.4.7 Summary|internal compiler error: in |[4.7/4.8/4.9 Regression] |dwarf2out_frame_debug_expr, |internal compiler error: in |at dwarf2out.c:2387 |dwarf2out_frame_debug_expr, ||at dwarf2out.c:2387 Known to fail||4.7.0, 4.8.0, 4.9.0 --- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- works with a gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) fails with trunk. seems like a debug rather than preprocessor problem.
[Bug regression/59320] ftree-vrp breaks simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
||.ch
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to David Kaufmann from comment #5)
Created attachment 31320 [details]
preprocessor output
the buggy function is on line 18136, but it does not seem to have been
changed.
static unsigned char dash_list[16][2]
static int ndash_dot = 4;
nd=ndash_dot;
for (il =0; ilnd; il ++){
dash_list[op][il] = ...
}
so clearly ilnd == 1
[Bug regression/59320] ftree-vrp breaks simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320
--- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to David Kaufmann from comment #9)
(In reply to Joost VandeVondele from comment #7)
(In reply to David Kaufmann from comment #5)
Created attachment 31320 [details]
preprocessor output
the buggy function is on line 18136, but it does not seem to have been
changed.
static unsigned char dash_list[16][2]
static int ndash_dot = 4;
nd=ndash_dot;
for (il =0; ilnd; il ++){
dash_list[op][il] = ...
}
so clearly ilnd == 1
i am not sure, that probably is another bug. (as dash_list[op]-size is only
two, but dash_list[op][0], dash_list[op][1] and dash_list[op][3] get set.)
no weird behavior of vrp. given the size of dash_list (2) it correctly
establishes the range on the value, i.e. that il must be either 0 or 1 (any
other value would trigger out-of-bounds, which can't happen in a valid C
program). All the rest is a consequence of this. So, the bug is in the C
program, not the compiler.
[Bug middle-end/59336] New: definition in block 317 does not dominate use in block 316
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59336 Bug ID: 59336 Summary: definition in block 317 does not dominate use in block 316 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch During an LTO build of CP2K, the following internal error happens with gcc trunk: make.out14-/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/mc_ge_moves.F: In function 'mc_ge_swap_move': make.out14-/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/mc_ge_moves.F:452:0: error: definition in block 317 does not dominate use in block 316 make.out14- SUBROUTINE mc_ge_swap_move(mc_par,force_env,bias_env,moves, make.out14- ^ make.out14-for SSA_NAME: vect_cst_.6470_7306 in statement: make.out14-vect__5004.6467_1300 = vect_cst_.6470_7306 - vect_cst_.6473_6797; make.out14-/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/mc_ge_moves.F:452:0: internal compiler error: verify_ssa failed make.out14-0xaad07c verify_ssa(bool) make.out14-../../gcc/gcc/tree-ssa.c:1096 make.out14-0x8448ae execute_function_todo make.out14-../../gcc/gcc/passes.c:1844 make.out14-0x844f2b execute_todo make.out14-../../gcc/gcc/passes.c:1877 make.out14-Please submit a full bug report, make.out14-with preprocessed source if appropriate. make.out14-Please include the complete backtrace with any bug report. make.out14-See http://gcc.gnu.org/bugs.html for instructions. make.out14-make[3]: *** [/tmp/cc6S2X6S.ltrans24.ltrans.o] Error 1 any suggestion on how to turn this into a testcase ?
[Bug middle-end/59336] definition in block 317 does not dominate use in block 316
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59336 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- How to reproduce svn checkout -r13372 svn://svn.code.sf.net/p/cp2k/code/trunk/cp2k cp2k cd cp2k/makefiles/ # check compiler version/libs are correct cat ../arch/PR59336.sdbg make -j32 ARCH=PR59336 VERSION=sdbg
[Bug libgomp/59337] New: surprising OMP error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337 Bug ID: 59337 Summary: surprising OMP error message Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch CC: jakub at gcc dot gnu.org cat test.f90 !$OMP ATOMIC i=-i END gfortran -fopenmp test.f90 test.f90:2.2: i=-i 1 Error: !$OMP ATOMIC assignment operator must be +, *, -, /, .AND., .OR., .EQV. or .NEQV. at (1) The caret is pointing at a '-', and the error message is saying it must be one. It appear that the proper way to write this is !$OMP ATOMIC i=0-i END but that is not so obvious from the error messsage. Maybe it could be worded as '... must be one of the binary operators '
[Bug tree-optimization/59336] [4.9 Regression] definition in block 317 does not dominate use in block 316
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59336 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Richard Biener from comment #2) I suppose it doesn't happen without LTO? correct.
[Bug libgomp/59337] surprising OMP error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jakub Jelinek from comment #2) creating extensions there is IMHO undesirable, especially when it will unlikely work with other compilers. I agree with that, the compilers I tested all rejected this. I think it is a flaw in the standard.
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Thanks, fixed!
[Bug fortran/59344] New: warning for needless pointer attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59344 Bug ID: 59344 Summary: warning for needless pointer attribute Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch In many cases, using variables with a POINTER attribute is neither necessary nor beneficial. I wonder if the Fortran FE could generate a warning for variables with the POINTER attribute that could as well be ALLOCATABLE without changing the semantics of the program. my guess would be that it is sufficient to track if a local variables with the pointer attribute has been 1) part of a pointer assignment (lhs/rhs) 2) passed to a procedure with an explicit interface and pointer attribute 3) ? Such a warning would be useful to clean codes of pointer 'abuse'
[Bug fortran/59345] New: _gfortran_internal_pack on compiler generated temps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59345 Bug ID: 59345 Summary: _gfortran_internal_pack on compiler generated temps Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch There is a missed optimization on compiler generated temporaries. Basically: SUBROUTINE S1(A) REAL :: A(3) CALL S2(-A) END SUBROUTINE leads to an optimized tree that contains calls to _gfortran_internal_pack _gfortran_internal_unpack __builtin_free which should not be needed as generated temps are known to be contiguous (in particular in this case, where it is generated on the stack). This would help to fully resolve PR38318 .
[Bug regression/59320] ftree-vrp breaks simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320 --- Comment #14 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Manuel López-Ibáñez from comment #13) Will -fsanitize=undefined catch these? If so, perhaps the message shown before reporting a bug should mention trying this first. I guess -fsanitize=address would catch the out-of-bounds access, but I don't think the message should become too complex (it is already a bit narrow and C-centric, for example '-fno-strict-aliasing' means nothing for Fortran programs), and furthermore that option would only be available for a recent gcc.
[Bug c/56600] loop goes indefinite when non-loop integer variable overflows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56600 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch Resolution|INVALID |DUPLICATE --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- *** This bug has been marked as a duplicate of bug 56463 ***
[Bug c++/59370] aggressive-loop-optimizations causes infinite loop due to integer overflow within loop body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59370 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||Joost.VandeVondele at mat dot ethz ||.ch Resolution|--- |DUPLICATE --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Duplicate bug, more details in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56463 *** This bug has been marked as a duplicate of bug 56463 ***
[Bug c/56463] infinite loop when having integer overflow in a simple accumulator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56463 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||john2.718281828459045235360 ||287 at gmail dot com --- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- *** Bug 59370 has been marked as a duplicate of this bug. ***
[Bug c/56463] infinite loop when having integer overflow in a simple accumulator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56463 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||mskyeong at naver dot com --- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- *** Bug 56600 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/59020] [4.9 Regression] internal compiler error: in maybe_add_or_update_dep_1, at sched-deps.c:933
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59020 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- The original testcase seems fixed indeed.
[Bug lto/56706] [4.8 Regression] failure building CP2K at -flto -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Summary|[4.8/4.9 Regression]|[4.8 Regression] failure |failure building CP2K at|building CP2K at -flto -O2 |-flto -O2 | --- Comment #13 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- The 4.9 problem is gone, not sure which revision fixed this, the only thing I noticed was this comment. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375#c195 and I have now a couple of LTO builds as part of our daily gcc tester, so I'll notice quickly if it regresses. Not sure if it is worth keeping the bug open for 4.8, I guess there will be other issues popping up with 4.8 anyway.
[Bug fortran/59395] [4.8 Regression] internal compiler error (memory access error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59395 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch Known to work||4.7.2, 4.9.0 Summary|internal compiler error |[4.8 Regression] internal |(memory access error) |compiler error (memory ||access error) Known to fail||4.8.3 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- fails with 4.8.3, works with trunk and 4.7
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #39 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Sergey Matveev from comment #37) I've patched LSan to use the real memset(). At least on my machine this brought no performance improvement compared to kcc's latest change (just FYI - not trying to make any point). After the latest sanitizer merge, I see a significant reduction in the overhead of -fsanitize=leak (overhead went down from ~20% to 5%). Nice!
[Bug sanitizer/59061] Port leaksanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #41 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Kostya Serebryany from comment #40) Is there anything else left in this bug? If not, please close this one and open another for the next problem(s) I'll close it as soon as libbacktrace is used with sanitizer in trunk (see comment #12), but if Jakob feels this is covered by e.g. PR59136, this one can be closed, indeed.
[Bug sanitizer/59188] [4.9 Regression] lib64/libtsan.so: undefined reference to `sigsetjmp'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Kostya Serebryany from comment #11) planing next merge from llvm to gcc in ~1 week. Fixed in current trunk. Thanks!
[Bug ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #13 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jan Hubicka from comment #11) Fortran fronend should probably stop using builtin_expect where we can derive the same info from noreturn (as it seems to be the case here), but it is not always. Actually, I would argue that the middle-end should be smart enough to give a branch that is guaranteed to never return a negligible probability (independent of the builtin_expect). It can only be mis-predicted once.
[Bug sanitizer/59454] New: blacklisting sanitized functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59454 Bug ID: 59454 Summary: blacklisting sanitized functions Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Currently there is no option to 'blacklist' functions from sanitization(?) in Fortran. Would be useful to have. For discussion: see thread at http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00640.html
[Bug middle-end/58290] [4.9 Regression] error: virtual definition of statement not up-to-date
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58290 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jakub Jelinek from comment #7) I've looked at this some more and it seems Richard's change was the right fix for this, so I've committed the testcase and am closing this. Thanks. I notice that you're writing your own testcases, if this would be for copyright reasons, I extract most of my reports from our GPLed code (CP2K), so there would be no need for this. Of course, I don't mind if you have other reasons.
[Bug rtl-optimization/54269] New: [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 Bug #: 54269 Summary: [4.8 Regression] memory usage too large when optimizing Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch Created attachment 28019 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28019 gzipped testcase. The attached testcase requires +- 10Gb resident memory to compile with: gfortran -c -O3 -funroll-all-loops -march=native -ffree-form -D__LIBINT hfx_contraction_methods.F using current trunk. I believe this is a recent regression in trunk. 4.7 needs 500Mb. From a very quick gdb session, I guess this is some rtl thing.
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-15 09:57:13 UTC --- seems like it is triggered by unrolling, using gfortran -O2 -funroll-loops -ffree-form -D__LIBINT hfx_contraction_methods.F is enough. A bt at the first point where memory seems to go up is: #1 0x007176de in df_scan_verify () at ../../gcc/gcc/df-scan.c:4540 #2 0x00706245 in df_verify () at ../../gcc/gcc/df-core.c:1645 #3 df_analyze () at ../../gcc/gcc/df-core.c:1206 #4 0x008a211b in iv_analysis_loop_init (loop=0x7f4b0ece63b8) at ../../gcc/gcc/loop-iv.c:299 #5 0x008a56ba in get_simple_loop_desc (loop=0x7f4b0ece63b8) at ../../gcc/gcc/loop-iv.c:2973 #6 0x008a8c70 in decide_peel_once_rolling (flags=2) at ../../gcc/gcc/loop-unroll.c:337 #7 peel_loops_completely (flags=2) at ../../gcc/gcc/loop-unroll.c:248 #8 unroll_and_peel_loops (flags=2) at ../../gcc/gcc/loop-unroll.c:164 #9 0x0089cc98 in rtl_unroll_and_peel_loops () at ../../gcc/gcc/loop-init.c:370
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-15 10:59:38 UTC --- (In reply to comment #2) Well, that's ENABLE_CHECKING code. Are you sure 4.7 built with --enable-checking=yes does not exhibit this behavior? I'm pretty sure this was not observed 3 weeks ago on trunk. Just to make sure, I'm doing a new trunk build with --enable-checking=no.
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-15 11:37:51 UTC --- (In reply to comment #2) Well, that's ENABLE_CHECKING code. Are you sure 4.7 built with --enable-checking=yes does not exhibit this behavior? it looks like --enable-checking is key. --enable-checking=no leads to about 1Gb, while --enable-checking=yes leads to about 10Gb mem usage.
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-16 05:29:46 UTC --- 4.7 configured with --enable-checking=yes also needs 1.0Gb. for a checking enable compiler, time went from 25s with 4.7 to 1m27s with 4.8
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-22 07:40:26 UTC --- Fixed for current trunk, maybe a dup of PR54332
[Bug rtl-optimization/54269] [4.8 Regression] memory usage too large when optimizing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269 --- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-22 07:43:30 UTC --- Fixed for current trunk, maybe a dup of PR54332
[Bug tree-optimization/53852] [4.8 Regression] -ftree-loop-linear: large compile time / memory usage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-22 11:58:00 UTC --- simplified testcase and some analysis: SUBROUTINE build_d_tensor_gks(d5f,v,d5) INTEGER, PARAMETER :: dp=8 REAL(KIND=dp), DIMENSION(3, 3, 3, 3, 3), INTENT(OUT) :: d5f REAL(KIND=dp), DIMENSION(3), INTENT(IN) :: v REAL(KIND=dp), INTENT(IN) :: d5 INTEGER :: k1, k2, k3, k4, k5 REAL(KIND=dp) :: w d5f = 0.0_dp DO k1=1,3 DO k2=1,3 DO k3=1,3 DO k4=1,3 DO k5=1,3 d5f(k5,k4,k3,k2,k1)=d5f(k5,k4,k3,k2,k1)+ v(k1)*v(k2)*v(k3)*v(k4)*v(k5)*d5 ENDDO w=v(k1)*v(k2)*v(k3)*d4 d5f(k1,k2,k3,k4,k4)=d5f(k1,k2,k3,k4,k4)+w d5f(k1,k2,k4,k3,k4)=d5f(k1,k2,k4,k3,k4)+w d5f(k1,k4,k2,k3,k4)=d5f(k1,k4,k2,k3,k4)+w d5f(k4,k1,k2,k3,k4)=d5f(k4,k1,k2,k3,k4)+w d5f(k1,k2,k4,k4,k3)=d5f(k1,k2,k4,k4,k3)+w ! d5f(k1,k4,k2,k4,k3)=d5f(k1,k4,k2,k4,k3)+w ! d5f(k4,k1,k2,k4,k3)=d5f(k4,k1,k2,k4,k3)+w ! d5f(k1,k4,k4,k2,k3)=d5f(k1,k4,k4,k2,k3)+w ! d5f(k4,k1,k4,k2,k3)=d5f(k4,k1,k4,k2,k3)+w ! d5f(k4,k4,k1,k2,k3)=d5f(k4,k4,k1,k2,k3)+w ENDDO ENDDO ENDDO ENDDO END SUBROUTINE build_d_tensor_gks the issue is that the compile time grows exponentially in the number of uncommented lines of the d5f=d5f+w type: 1 0m1.112s 2 0m4.448s 3 0m11.513s 4 0m21.514s 5 0m35.529s
[Bug fortran/25708] Module loading is not good at all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Depends on||40958 --- Comment #21 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-24 14:00:40 UTC --- I did another timing experiment on compiling CP2K. I found that on my server, compiling with -fsyntax-only is as fast as just compiling at -O0. I believe the reason for this is that module reading is dominating the compile time. In CP2K each module is included only once per file, so I think it is the efficiency of reading the module that matters most. My guess would be that the human readable format of the .mod file is the source of most inefficiency. Is it still important to the development of gfortran that the .mod file is in this form ? If I count the number of times a module is used, and multiply that with the size, I have about 1Gb of .mod files being parsed per CP2K compile (for about 35Mb of Fortran).
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #70 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-28 11:28:06 UTC --- (In reply to comment #69) Is there still a problem here? for current trunk and the original testcase, timings are reasonable at -O0 -O1 -O2, but very long at -O3 (60min): report.O0.txt: TOTAL : 38.78 0.8939.67 691166 kB report.O1.txt: TOTAL : 70.04 1.1371.22 634523 kB report.O2.txt: TOTAL : 204.51 1.16 205.71 691522 kB the biggest consumers are -O0: integrated RA : 10.36 reload : 5.16; -O1: tree PTA: 7.77 integrated RA : 13.36 -O2: expand vars : 83.15 tree PTA: 35.04 -O3: (also needs about 4Gb of memory) ??? not yet finished (60min)
[Bug middle-end/38474] slow compilation at -O0 due to expand's temp slot goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474 --- Comment #71 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-08-28 14:54:54 UTC --- The -O3 compile is 3h later still running and needs 20Gb of RAM. The issue seems now to be variable_tracking_main #0 0x00b7b8ce in dataflow_set_preserve_mem_locs(void**, void*) () #1 0x00e76168 in htab_traverse_noresize () #2 0x00b770e0 in dataflow_set_clear_at_call(dataflow_set_def*) () #3 0x00b7c613 in vt_emit_notes() () #4 0x00b847ea in variable_tracking_main() () #5 0x008e8acf in execute_one_pass(opt_pass*) ()
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortr ||an/2012-08/msg00150.html --- Comment #82 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-04 12:22:12 UTC --- URL for the current version of the patch added.
[Bug fortran/54389] [F2003/F2008 difference] PURE functions and pointer dummy arguments / DECL_PURE_P issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54389 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 10:00:46 UTC --- This revision causes CP2K to produce wrong results at -O1 and above. I don't have a reduced testcase, other than compiling and building CP2K, but found this by bisection.
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 11:41:12 UTC --- the two revisions lead to a lot of changes, all these files differ in their disassembled form: 1admm_methods.o Files f1 and f2 differ 2atom_fit.o Files f1 and f2 differ 3atom_pseudo.o Files f1 and f2 differ 9cp_ddapc_methods.o Files f1 and f2 differ 10cp_fm_basic_linalg.o Files f1 and f2 differ 11cp_ma_interface.o Files f1 and f2 differ 12cp_parser_inpp_methods.o Files f1 and f2 differ 13cp_parser_methods.o Files f1 and f2 differ 14dbcsr_dist_operations.o Files f1 and f2 differ 15dbcsr_example_3.o Files f1 and f2 differ 16dbcsr_index_operations.o Files f1 and f2 differ 17dbcsr_internal_operations.o Files f1 and f2 differ 18dbcsr_iterator_operations.o Files f1 and f2 differ 19dbcsr_operations.o Files f1 and f2 differ 20dbcsr_performance_multiply.o Files f1 and f2 differ 21dbcsr_test_add.o Files f1 and f2 differ 22dbcsr_test_methods.o Files f1 and f2 differ 23dbcsr_test_multiply.o Files f1 and f2 differ 24dbcsr_transformations.o Files f1 and f2 differ 25dbcsr_work_operations.o Files f1 and f2 differ 26efield_utils.o Files f1 and f2 differ 27et_coupling.o Files f1 and f2 differ 28f77_interface.o Files f1 and f2 differ 29fp_methods.o Files f1 and f2 differ 30helium_io.o Files f1 and f2 differ 31hfx_types.o Files f1 and f2 differ 32input_cp2k.o Files f1 and f2 differ 33lgrid_types.o Files f1 and f2 differ 34ma_affinity.o Files f1 and f2 differ 35mltfftsg.o Files f1 and f2 differ 36molsym.o Files f1 and f2 differ 37orbital_transformation_matrices.o Files f1 and f2 differ 38pair_potential.o Files f1 and f2 differ 39parallel_rng_types.o Files f1 and f2 differ 40paw_proj_set_types.o Files f1 and f2 differ 41preconditioner.o Files f1 and f2 differ 42pw_methods.o Files f1 and f2 differ 43pw_poisson_methods.o Files f1 and f2 differ 44pw_poisson_types.o Files f1 and f2 differ 45pw_pool_types.o Files f1 and f2 differ 46qs_gspace_mixing.o Files f1 and f2 differ 47qs_integrate_potential.o Files f1 and f2 differ 48qs_ks_methods.o Files f1 and f2 differ 49qs_neighbor_lists.o Files f1 and f2 differ 50qs_neighbor_list_types.o Files f1 and f2 differ 51qs_rho0_methods.o Files f1 and f2 differ 52qs_rho_methods.o Files f1 and f2 differ 53qs_scf_block_davidson.o Files f1 and f2 differ 54qs_scf_diagonalization.o Files f1 and f2 differ 55qs_scf.o Files f1 and f2 differ 56qs_vxc.o Files f1 and f2 differ 57restraint.o Files f1 and f2 differ 58rtp_admm_methods.o Files f1 and f2 differ 59rt_propagation_methods.o Files f1 and f2 differ 60sap_kind_types.o Files f1 and f2 differ 61scp_hartree_1center.o Files f1 and f2 differ 62se_core_matrix.o Files f1 and f2 differ 63se_fock_matrix_coulomb_ga.o Files f1 and f2 differ 64se_fock_matrix_coulomb_mpi.o Files f1 and f2 differ 65semi_empirical_expns3_methods.o Files f1 and f2 differ 66semi_empirical_par_utils.o Files f1 and f2 differ 67task_list_methods.o Files f1 and f2 differ 68thermostat_mapping.o Files f1 and f2 differ 69xc.o Files f1 and f2 differ
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 20:11:24 UTC --- some progress.. the object file that leads to wrong results is parallel_rng_types.o. I'll see if I can get some further insight.
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 20:26:49 UTC --- (In reply to comment #3) (In reply to comment #2) some progress.. the object file that leads to wrong results is parallel_rng_types.o. I'll see if I can get some further insight. It seems that - for some reason - IMPLICIT_PURE is only set for functions. (Or at least that's here the case for a simple test case.) If you produce a module, have a look at the .mod file and search for IMPLICIT_PURE. In my example I have something like: 3 's' 'm' '' 1 ((PROCEDURE [...] FUNCTION IMPLICIT_PURE) [...] where s is the name of my function and m is the name of the module. Then, check whether that procedure could be PURE or has to be IMPURE. yes, I think from looking at the optimized dumps, I can see that a function that is called twice in the correct version is called only once in the wrong version. I think I might be able to reduce it to a testcase. (If you care, the function is rn53 which calls rn32 only once, so I guess that's the issue).
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 20:46:05 UTC --- Created attachment 28179 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28179 testcase
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 20:50:40 UTC --- The testcase illustrates the issue, compiling as gfortran -c -O1 test.f90 -fdump-tree-optimized shows that rn32 is only called once from rn53, whereas the proper number would be 2 or 3. So I guess rn32 is incorrectly marked as pure.
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-12 20:58:23 UTC --- (In reply to comment #6) So I guess rn32 is incorrectly marked as pure. which indeed is also visible in the .mod file: 'rn32' 'parallel_rng_types' '' 1 ((PROCEDURE UNKNOWN-INTENT MODULE-PROC DECL UNKNOWN 0 0 FUNCTION IMPLICIT_PURE ALWAYS_EXPLICIT)
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #11 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-13 12:31:03 UTC --- (In reply to comment #10) Draft patch (replaces the one in comment 9): --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -13567,6 +13572,5 @@ gfc_impure_variable (gfc_symbol *sym) proc = sym-ns-proc_name; - if (sym-attr.dummy gfc_pure (proc) -((proc-attr.subroutine sym-attr.intent == INTENT_IN) - || -proc-attr.function)) + if (sym-attr.dummy + ((proc-attr.subroutine sym-attr.intent == INTENT_IN) + || proc-attr.function)) return 1; this one fixes the error seen with CP2K.
[Bug fortran/54556] [4.8 Regression] Marking implicitly pure variables as DECL_PURE_P leads to wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556 --- Comment #16 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-14 05:57:51 UTC --- (In reply to comment #15) FIXED on the trunk - and on the 4.6/4.7 branch. Sorry for the breakage! Thank you and other gcc experts for regularly fixing issues quickly and professionally, while steadily improving the quality of the compiler!
[Bug tree-optimization/54634] New: [4.8 Regression] miscompilation with -O3 -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54634 Bug #: 54634 Summary: [4.8 Regression] miscompilation with -O3 -ftree-loop-distribution Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch Created attachment 28227 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28227 testcase sources The attached sources are miscompiled with current trunk ([trunk revision 191430]) at -O3 -ftree-loop-distribution. To reproduce gfortran -O3 -ftree-loop-distribution -ffree-form other.F mathconstants.F orbital_pointers.F orbital_symbols.F orbital_transformation_matrices.F main.F ; ./a.out which outputs wrong values (as compared to -O0) and shows a valgrind warning (not present at -O0). The miscompiled file is orbital_transformation_matrices.F, most likely the routine create_spherical_harmonics (which seems inlined). If I cat at files in a single .F file, the error also disappears, which might hint at some ipa thing ? 4.7 branch ([gcc-4_7-branch revision 190437]) is doing fine.
[Bug tree-optimization/54634] [4.8 Regression] miscompilation with -O3 -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54634 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-20 10:15:57 UTC --- (In reply to comment #1) Retry with PR54629 fix? after applying the patch mentioned above, the testcase still fails. The failure is also older than the commit mentioned in PR54629
[Bug tree-optimization/54634] [4.8 Regression] miscompilation with -O3 -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54634 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-20 13:06:50 UTC --- (In reply to comment #4) Ah, binomial () is pure. In this case, it was presumably triggered by Tobias' changes for PR54389. binomial() has not been declared pure in the source, but most likely correctly declared 'implicitly pure' but the Fortran frontend.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #83 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-26 06:42:59 UTC --- Mikael, any progress on this one (BTW, the PR is not yet assigned)? It would be great to have LTO work with Fortran in 4.8 (especially with all the inlining improvements). However, I would guess that this is stage 1 material, and I'm assuming stage 1 is nearing its end.
[Bug go/54749] New: libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54749 Bug #: 54749 Summary: libbacktrace Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: joost.vandevond...@mat.ethz.ch On a testcase that makes the compiler run out-of-memory (by setting ulimit to ulimit -m 8388608 ulimit -v 8388608 ulimit -d 8388608 ulimit -t 600 and running the full testcase of PR53852) I get the following stacktrace, which is a bit ugly: GNU MP: Cannot allocate memory (size=8) In function 'build_d_tensor_gks': H�D$A��H�H�D$H�H�D$ H�CH�D$(H�kH�Cv,H��H�l$HH�\$@L�d$PL�l$XL�t$`H��h �Aborted mmap: Cannot allocate memory failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information failed to read executable information Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [semi_empirical_int_gks.o] Error 1 make[2]: Target `_progr' not remade because of errors. make[2]: Leaving directory `/data/vjoost/gnu/cp2k/cp2k/obj/gfortran-test12/sopt' make[1]: *** [build] Error 2 make[1]: Leaving directory `/data/vjoost/gnu/cp2k/cp2k/makefiles'
[Bug rtl-optimization/54751] New: [4.8 Regression] slow compile time with rtl loop unroller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54751 Bug #: 54751 Summary: [4.8 Regression] slow compile time with rtl loop unroller Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch Created attachment 28299 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28299 gzipped testcase. compiling the attached testcase need ~10x more time with current 4.8 trunk than with 4.7. I believe this is a recent regression. A typical stack trace looks like #0 0x006a7a02 in df_ref_equal_p(df_ref_d*, df_ref_d*) () #1 0x006a7af5 in df_refs_verify(vec_tdf_ref_d**, df_ref_d**, bool) () #2 0x006abf3f in df_insn_refs_verify(df_collection_rec*, basic_block_def*, rtx_def*, bool) () #3 0x006aea2a in df_bb_verify(basic_block_def*) () #4 0x006aed40 in df_scan_verify() () #5 0x0069e155 in df_analyze() () #6 0x0083b1dd in iv_analysis_loop_init(loop*) () #7 0x0083e685 in get_simple_loop_desc(loop*) () #8 0x00841265 in unroll_and_peel_loops(int) () #9 0x00835cd7 in rtl_unroll_and_peel_loops() () #10 0x00881107 in execute_one_pass(opt_pass*) () compile flags: gfortran -c -cpp -O2 -ftree-vectorize -funroll-loops -ffast-math test.f90 (needs about 10min (gcc 4.8) or 1min (gcc 4.7) on my machine, removing -funroll-loops reduces that to 1m20s (4.8) or 28s (4.7))
[Bug middle-end/54749] libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54749 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-29 17:34:04 UTC --- (In reply to comment #1) You filed this against the go component, but it seems that Go is not involved. Is that right? This is just about a backtrace printed after a run of the Fortran compiler? yes, unclear what the proper component was for libbacktrace... I didn't consider this middle end either (and I was under the impression that go and libbracktrace had something in common). The problem is not the fact that this particular run crashes, but the fact that the trace should deal with the mmap out-of-mem more nicel (i.e. one line of error).
[Bug fortran/54758] New: accessing gcc builtins from fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54758 Bug #: 54758 Summary: accessing gcc builtins from fortran Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch I would like to experiment with prefetching in Fortran code (beyond -fprefetch-loop-arrays). A convenient way to do this would be access the gcc_builtins. I tried this the following way: INTERFACE SUBROUTINE builtin_prefetch(a) BIND(C,name=__builtin_prefetch) USE ISO_C_BINDING, ONLY: C_FLOAT REAL(KIND=C_FLOAT), dimension(*) :: a END SUBROUTINE END INTERFACE real*4 :: data(100) DO i=1,100 CALL builtin_prefetch(data(i)) data(i)=0 ENDDO END but it didn't work... test.f90:(.text+0x36): undefined reference to `__builtin_prefetch' no surprise, I guess, but it would be cool if it did.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #86 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-09-30 12:30:43 UTC --- (In reply to comment #84) LTO might work for many codes, as using allocatables in derived types was not standard Fortran90 (IIRC) and appears needed to trigger the bug. Anyway, since most people will use released versions of gcc, this checking error will be hidden behind --enable-checking=release. Only very few people will be able to locate and in particular reduce wrong code generation that only happens with LTO, so I wouldn't expect bug reports for actual wrong code generation very quickly. Meanwhile a shorter testcase for 4.8, using gfortran -flto -O0. TYPE t REAL, DIMENSION(:), ALLOCATABLE :: r END TYPE t TYPE t_p TYPE(t), POINTER :: d_t END TYPE t_p REAL, DIMENSION(:), POINTER:: d TYPE(t_p) :: x d=x%d_t%r END
[Bug rtl-optimization/54751] [4.8 Regression] slow compile time with rtl loop unroller
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54751 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-10-02 10:39:41 UTC --- More reasonable with -enable-checking=release 4.8(checking=yes):~10min 4.8(checking=release): 1min28s. 4.7 : 0min58s maybe some of the checking is a bit excessive in this case.
[Bug fortran/51727] Changing module files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||simonb at google dot com --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-10-05 18:16:41 UTC --- Also reported here: http://gcc.gnu.org/ml/gcc/2012-10/msg00075.html this is the source of recompilation cascades sometimes seen in CP2K as well. I'm wondering if a very naive hack like sorting .mod content (like in cat old.mod 1 | sort -s new.mod) could not paper over this problem sufficiently well to make it irrelevant in reality.
[Bug middle-end/37150] vectorizer misses some loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37150 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2009-08-06 07:54:57 |2012-10-06 7:54:57 --- Comment #13 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-10-06 10:38:57 UTC --- reconfirming this with current trunk ifort:1.02s gfortran 4.8: 2.01s gfortran -ffast-math -march=native -O3 -v PR37150.f90 -march=corei7 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx
