[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #48 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Roland Schulz from comment #47) What is the advantage of a TSAN instrumented libgomp over one with --disable-linux-futex? I would be happy to know

[Bug fortran/61180] New: surprising -Wsurprising warning

Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch To my surprise, -Wsurprising produces surprising warnings. The issue is the following: MODULE M1 TYPE foo_type INTEGER, POINTER, DIMENSION(:) :: data END TYPE CONTAINS FUNCTION get_data(foo

[Bug fortran/61181] New: -Wunused-but-set-variable for Fortran

Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch I guess this is a feature request, the following code : cat bug.f90 SUBROUTINE TEST(j) INTEGER :: i,j i=1 j=0 END SUBROUTINE does not produce a warning for i being an 'unused-but-set

[Bug fortran/61180] surprising -Wsurprising warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61180 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC

[Bug fortran/61028] [4.9/4.10 Regression] -g3 -g leads to spurious warnings

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61028 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC

[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #45 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Roland Schulz from comment #44) Is there a way to compile libgomp to not get false positives for omp-atomic? yes, this is fixed in gcc for 4.9.0 see

[Bug driver/61028] New: [4.9/4.10 Regression] -g3 -g leads to spurious warnings

Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch With gcc 4.9 and 4.10 the following leads to unexpected warnings. It is triggered by the sequence '-g3 -g' cat test.F #if 1 WRITE(6,*) Hello, world

[Bug fortran/41137] inefficient zeroing of an array

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137 --- Comment #18 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Dominique d'Humieres from comment #17) With -O3, I get the same timings for the test in comment 1 since gcc 4.6.4. Could this PR be closed as FIXED

[Bug tree-optimization/60766] [4.8/4.9 Regression] Wrong optimization with -O2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60766 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC

[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621 --- Comment #13 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Joost VandeVondele from comment #12) Both compilers fail to notice that S32 is basically the same code hand-unrolled. with gcc 4.9 ./a.out

[Bug lto/56706] [4.8 Regression] failure building CP2K at -flto -O2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2013-10-25 00:00:00

[Bug middle-end/60426] New: [4.9 Regression] ICE near expand_builtin_int_roundingfn_2

Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Between r208300 and r208339 LTO compiles of cp2k start failing with the backtrace below. This happens for several files, all traces lead to a NINT

[Bug middle-end/60426] [4.9 Regression] ICE near expand_builtin_int_roundingfn_2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60426 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC

[Bug lto/60427] [4.9 Regression] r208312 causes ICE and wrong code for Fortran with -flto

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC

[Bug middle-end/60426] [4.9 Regression] ICE near expand_builtin_int_roundingfn_2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60426 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|NEW

[Bug fortran/52651] Fortran testsuite ICEs with -flto

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52651 Bug 52651 depends on bug 45586, which changed state. Bug 45586 Summary: [4.8 Regression] ICE non-trivial conversion at assignment http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 What|Removed |Added

[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 Status|REOPENED

[Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #43 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Emil Styrke from comment #42) Anyway, after manually fixing up the install it seems to work alright. If this looks like a reasonable way forward

[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 #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- This issue has disappeared between r206594 and r206615. Maybe fixed by r206599 ?

[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 #12 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jakub Jelinek from comment #11) Author: jakub Date: Mon Jan 13 07:56:40 2014 New Revision: 206572 URL: http://gcc.gnu.org/viewcvs?rev=206572root

[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 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed

[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 #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jakub Jelinek from comment #7) That said, during stage3 I'll look at how costly would be to use there __atomic_load_n with MEMMODEL_RELAXED. any

[Bug sanitizer/59061] Port leaksanitizer

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED

[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

[Bug sanitizer/59454] New: blacklisting sanitized functions

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[Bug libgomp/59337] New: surprising OMP error message

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

[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

[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

[Bug fortran/59344] New: warning for needless pointer attribute

: 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

[Bug fortran/59345] New: _gfortran_internal_pack on compiler generated temps

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

[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

[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

[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

[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

[Bug middle-end/59336] New: definition in block 317 does not dominate use in block 316

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[Bug sanitizer/59302] New: tsan: Unexpected mmap in InternalAllocator!

: 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

[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

[Bug sanitizer/59286] New: segfault in __sanitizer::StackDepotGet

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

[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

[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

[Bug fortran/59276] New: Incorrect error message with modules of different gfortran versions

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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[Bug sanitizer/59188] New: [4.9 Regression] lib64/libtsan.so: undefined reference to `sigsetjmp'

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

[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

[Bug libgomp/59194] New: tsan detects race for real variables in an OMP reduction clause

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

[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

[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

[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

[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

[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

[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

[Bug middle-end/38318] moving the allocation of temps out of loops.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC

[Bug middle-end/38318] moving the allocation of temps out of loops.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Marc Glisse from comment #7) (In reply to Joost VandeVondele from comment #6) Marc, I think your recently posted patch: http://gcc.gnu.org/ml/gcc

[Bug middle-end/38318] moving the allocation of temps out of loops.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318 --- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Marc Glisse from comment #9) Ok. If you used __builtin_abort instead of _gfortran_os_error, I think my current patch would handle it. It is hard

[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

[Bug middle-end/59059] [4.9 Regression] internal compiler error: tree check: expected integer_cst, have nop_expr in tree_int_cst_lt, at tree.c:6931

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59059 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC

[Bug sanitizer/59061] New: Port leaksanitizer

: 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 Clearly an enhancement request, but it would be great to have

[Bug sanitizer/59061] Port leaksanitizer

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC

[Bug fortran/59060] Accepts invalid ? Missing component data value for component D1 of TYPE(T2)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59060 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Thanks, I indeed start thinking gfortran has it right. As a small variant: MODULE M1 TYPE T1 INTEGER, PRIVATE :: I=0 END TYPE T1 TYPE T2 TYPE(T1) :: D1

[Bug fortran/59060] Accepts invalid ? Missing component data value for component D1 of TYPE(T2)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59060 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED

[Bug sanitizer/59061] Port leaksanitizer

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Kostya Serebryany from comment #1) It should be there already: triggering my report was indeed some vague memory that the recent merge would bring

[Bug sanitizer/59061] Port leaksanitizer

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- That's great... works even for Fortran code :-) One more question the docs mention: In performance-critical scenarios, LSan can also be used without ASan

<    1   2   3   4   5   6   7   8   >