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

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561

--- Comment #48 from Joost VandeVondele  
---
(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 that '--disable-linux-futex' is a suitable approach,
as that would be rather practical. However, my first idea would be that, since
libgomp is not sanitized, not all races in 'user land' would be detected. I'm
just guessing ...

[Bug fortran/61180] surprising -Wsurprising warning

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61180

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #2 from Joost VandeVondele  
---
(In reply to Dominique d'Humieres from comment #1)
> Why do you think the warnings are not needed?

I'm only suggesting that the warning is not needed for the first two
assignments. They are just correct, and clearly pointer assignment is not
intended (or possible in the first case).

The crash is for the 3rd case, where the warning is indeed correct (but it is
not documented that this check is done).

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

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61181

Bug ID: 61181
   Summary: -Wunused-but-set-variable for Fortran
   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

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-variable'

> gfortran -c -Wunused-but-set-variable bug.f90

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

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61180

Bug ID: 61180
   Summary: surprising -Wsurprising warning
   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

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) RESULT(res)
TYPE(foo_type) :: foo
INTEGER, POINTER, DIMENSION(:) :: res
res=>foo%data
  END FUNCTION
END MODULE M1

  USE M1
  TYPE(foo_type) :: foo
  INTEGER, DIMENSION(:), ALLOCATABLE :: data1
  INTEGER, DIMENSION(:), POINTER :: data2
  INTEGER, DIMENSION(:), POINTER :: data3
  ALLOCATE(data1(10))
  ALLOCATE(data2(10))
  ALLOCATE(foo%data(10))
  ! no warning needed...pointer assignment not possible
  data1=get_data(foo)
  ! no warning needed...pointer assignment not intended 
  data2(:)=get_data(foo) 
  ! warning possible, but not documented on 
  ! gfortran/Error-and-Warning-Options.html#Error-and-Warning-Options
  data3=get_data(foo)
END PROGRAM

warnings for the first two cases are presumably not needed, the 3rd case is not
documented

bug.f90:22.8:

  data1=get_data(foo)
1
Warning: POINTER-valued function appears on right-hand side of assignment at
(1)

The option has been added quite a while ago:

http://gcc.gnu.org/ml/fortran/2004-08/msg00220.html

maybe it should just be a bit restricted

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561

--- Comment #45 from Joost VandeVondele  
---
(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 PR59194 or r206572

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194#c11

I believe that some of the other aspects you're seeing with 4.8.2 might also be
fixed in 4.9 (not sure).

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61028

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
  Component|driver  |fortran

--- Comment #1 from Joost VandeVondele  
---
this seems Fortran specific, so changing component. The content of the Fortran
file doesn't matter, it is sufficient to compile with '-g3 -g -cpp'

[Bug fortran/41137] inefficient zeroing of an array

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137

--- Comment #18 from Joost VandeVondele  
---
(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 or did I miss something in the discussion?

However, the difference remains if the subroutines would be in separate files
(comment #14), in fact, with '-O3 -fno-ipa-cp -fno-inline' the timings remain
poor:

> ./a.out
  0.156975999
  0.65592

I think the issue is that the frontend could/should generate better code for
this.

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61028

Bug ID: 61028
   Summary: [4.9/4.10 Regression] -g3 -g leads to spurious
warnings
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  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!"
#endif
END

> gfortran -g3 -g -c -ffree-form test.F
Warning: :1: Illegal preprocessor directive
Warning: :2: Illegal preprocessor directive
Warning: :3: Illegal preprocessor directive
Warning: :4: Illegal preprocessor directive
[...]

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60766

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
  Known to fail|4.9.0   |4.7.2, 4.8.3

--- Comment #2 from Joost VandeVondele  
---
fails for me with the (old) 4.7, 4.8 branch, works with 4.9.

gcc version 4.7.2 20120816 (prerelease) [gcc-4_7-branch revision 190437] (GCC)
: fail
gcc version 4.8.3 20140315 (prerelease) [gcc-4_8-branch revision 208588] : fail
gcc version 4.9.0 20140405 (experimental) [trunk revision 209137] (GCC) : OK

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621

--- Comment #13 from Joost VandeVondele  
---
(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
 default loop  0.542918001 
 hand optimized loop  0.542917009 

so, some progress, both versions of the loop give the same performance. Still
not quite as good as ifort, however.

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706

Joost VandeVondele  changed:

   What|Removed |Added

   Last reconfirmed|2013-10-25 00:00:00 |2014-3-15

--- Comment #14 from Joost VandeVondele  
---
current 4.8 branch still fails as described in comment #0

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60426

Joost VandeVondele  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Joost VandeVondele  
---
yes, dup for sure

*** This bug has been marked as a duplicate of bug 60427 ***

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60427

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #2 from Joost VandeVondele  
---
*** Bug 60426 has been marked as a duplicate of this bug. ***

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60426

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #1 from Joost VandeVondele  
---
testcase:

> cat test.f90 
SUBROUTINE S1(a,b,N)
  REAL*8 :: a,b
  INTEGER :: N
  N=NINT(a/b)
END SUBROUTINE

CALL S1(1.0D0,2.0D0,i)
END

> gfortran -flto test.f90 
test.f90: In function ‘s1’:
test.f90:4:0: internal compiler error: Segmentation fault
   N=NINT(a/b)
 ^
0x9056cf crash_signal
../../gcc/gcc/toplev.c:337

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60426

Bug ID: 60426
   Summary: [4.9 Regression] ICE near
expand_builtin_int_roundingfn_2
   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

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 in
the code.

/data/vjoost/gnu/cp2k/cp2k/makefiles/../src/qs_scf_post_gpw.F:977:0: internal
compiler error: Segmentation fault
nmoloc(ispin) = NINT(nelectron/occupation(1))
 ^
0x9056cf crash_signal
../../gcc/gcc/toplev.c:337
0x57808b contains_struct_check
../../gcc/gcc/tree.h:2822
0x57808b build_call_nofold_loc
../../gcc/gcc/builtins.c:2695
0x580aa5 expand_builtin_int_roundingfn_2
../../gcc/gcc/builtins.c:2933
0x5a0ae0 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../gcc/gcc/builtins.c:5928
0x68da35 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10341
0x6991df store_expr(tree_node*, rtx_def*, int, bool)
../../gcc/gcc/expr.c:5337
0x69bf69 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5123
0x5bf2ea expand_call_stmt
../../gcc/gcc/cfgexpand.c:2257
0x5bf2ea expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3158
0x5bf2ea expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3310
0x5c0957 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5150
0x5c31f9 gimple_expand_cfg
../../gcc/gcc/cfgexpand.c:5729
0x5c31f9 execute
../../gcc/gcc/cfgexpand.c:5949
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[3]: *** [/tmp/ccvOjlYd.ltrans24.ltrans.o] Error 1

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

[Joost.VandeVondele at mat dot ethz.ch]

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

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586

Joost VandeVondele  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #103 from Joost VandeVondele  ---
(In reply to rguent...@suse.de from comment #102)
> On February 8, 2014 1:47:14 PM GMT+01:00, "pault at gcc dot gnu.org"
> >> Fixed on trunk.
> I don't intend to backport this.

Thus fixed for 4.9 & won't fix for earlier branches. Thanks!

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561

--- Comment #43 from Joost VandeVondele  
---
(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, I'd be happy to improve the patch
> after feedback or leave this embryo in the hands of someone more
> knowledgeable.

I would welcome such a solution very much. From looking at the patch, it seems
a relatively small amount of work for a significant benefit. I hope you get
some feedback&help from libgomp/sanitizer experts.

[Bug tree-optimization/59336] [4.9 Regression] definition in block 317 does not dominate use in block 316

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59336

--- Comment #5 from Joost VandeVondele  
---
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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194

--- Comment #12 from Joost VandeVondele  
---
(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=206572&root=gcc&view=rev
> Log:
>   PR libgomp/59194
>   * omp-low.c (expand_omp_atomic_pipeline): Expand the initial
>   load as __atomic_load_N if possible.
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/omp-low.c

I have verified that this patch fixes the reported issues. From my point of
view, the PR can be closed as fixed. Thanks!

[Bug sanitizer/59061] Port leaksanitizer

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061

Joost VandeVondele  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #42 from Joost VandeVondele  
---
(In reply to Joost VandeVondele from comment #41)
> 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.

I believe this now works nicely:

> gfortran -g1 -fsanitize=leak test.f90 ; ./a.out

=
==55523==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f5e57c63348 in __interceptor_malloc
../../../../gcc/libsanitizer/lsan/lsan_interceptors.cc:66   
#1 0x400862 in s1 /data/vjoost/gnu/bugs/test.f90:3
#2 0x4008be in MAIN__ /data/vjoost/gnu/bugs/test.f90:6
#3 0x4008f4 in main /data/vjoost/gnu/bugs/test.f90:7
#4 0x305321ecdc in __libc_start_main (/lib64/libc.so.6+0x305321ecdc)

SUMMARY: LeakSanitizer: 40 byte(s) leaked in 1 allocation(s)

thanks!

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194

--- Comment #10 from Joost VandeVondele  
---
(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 chance this could be looked at in the remaining part of stage3? I can
benchmark the patch on our application if this makes sense.

[Bug tree-optimization/59336] [4.9 Regression] definition in block 317 does not dominate use in block 316

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59336

Joost VandeVondele  changed:

   What|Removed |Added

   Last reconfirmed||2014-1-9

--- Comment #4 from Joost VandeVondele  
---
reconfirmed with current trunk

[Bug middle-end/58290] [4.9 Regression] error: virtual definition of statement not up-to-date

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58290

--- Comment #8 from Joost VandeVondele  
---
(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 sanitizer/59454] New: blacklisting sanitized functions

[Joost.VandeVondele at mat dot ethz.ch]

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 ipa/58721] [4.9 Regression] The subroutine perdida is no longer inlined in fatigue.f90

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #13 from Joost VandeVondele  
---
(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/59188] [4.9 Regression] lib64/libtsan.so: undefined reference to `sigsetjmp'

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188

Joost VandeVondele  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Joost VandeVondele  
---
(In reply to Kostya Serebryany from comment #11)
> planing next merge from llvm to gcc in ~1 week.

Fixed in current trunk. Thanks!

[Bug sanitizer/59061] Port leaksanitizer

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061

--- Comment #41 from Joost VandeVondele  
---
(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/59061] Port leaksanitizer

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061

--- Comment #39 from Joost VandeVondele  
---
(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 fortran/59395] [4.8 Regression] internal compiler error (memory access error)

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59395

Joost VandeVondele  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  
---
fails with 4.8.3, works with trunk and 4.7

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706

Joost VandeVondele  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  
---
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 rtl-optimization/59020] [4.9 Regression] internal compiler error: in maybe_add_or_update_dep_1, at sched-deps.c:933

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59020

Joost VandeVondele  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Joost VandeVondele  
---
The original testcase seems fixed indeed.

[Bug c/56463] infinite loop when having integer overflow in a simple accumulator

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56463

Joost VandeVondele  changed:

   What|Removed |Added

 CC||john2.718281828459045235360
   ||287 at gmail dot com

--- Comment #7 from Joost VandeVondele  
---
*** Bug 59370 has been marked as a duplicate of this bug. ***

[Bug c/56463] infinite loop when having integer overflow in a simple accumulator

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56463

Joost VandeVondele  changed:

   What|Removed |Added

 CC||mskyeong at naver dot com

--- Comment #8 from Joost VandeVondele  
---
*** Bug 56600 has been marked as a duplicate of this bug. ***

[Bug c++/59370] aggressive-loop-optimizations causes infinite loop due to integer overflow within loop body

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59370

Joost VandeVondele  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
 Resolution|--- |DUPLICATE

--- Comment #4 from Joost VandeVondele  
---
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/56600] loop goes indefinite when non-loop integer variable overflows

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56600

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
 Resolution|INVALID |DUPLICATE

--- Comment #4 from Joost VandeVondele  
---


*** This bug has been marked as a duplicate of bug 56463 ***

[Bug regression/59320] ftree-vrp breaks simple loops

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320

--- Comment #14 from Joost VandeVondele  
---
(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 fortran/59345] New: _gfortran_internal_pack on compiler generated temps

[Joost.VandeVondele at mat dot ethz.ch]

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 fortran/59344] New: warning for needless pointer attribute

[Joost.VandeVondele at mat dot ethz.ch]

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 sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063

Joost VandeVondele  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #23 from Joost VandeVondele  
---
Thanks, fixed!

[Bug libgomp/59337] surprising OMP error message

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #3 from Joost VandeVondele  
---
(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 tree-optimization/59336] [4.9 Regression] definition in block 317 does not dominate use in block 316

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59336

--- Comment #3 from Joost VandeVondele  
---
(In reply to Richard Biener from comment #2)
> I suppose it doesn't happen without LTO?

correct.

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

[Joost.VandeVondele at mat dot ethz.ch]

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 middle-end/59336] definition in block 317 does not dominate use in block 316

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59336

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #1 from Joost VandeVondele  
---
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 middle-end/59336] New: definition in block 317 does not dominate use in block 316

[Joost.VandeVondele at mat dot ethz.ch]

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 regression/59320] ftree-vrp breaks simple loops

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320

--- Comment #10 from Joost VandeVondele  
---
(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; il > dash_list[op][il] = ...
> > }
> > so clearly il 
> 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 regression/59320] ftree-vrp breaks simple loops

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #7 from Joost VandeVondele  
---
(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; il

[Bug debug/54694] [4.7/4.8/4.9 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694

Joost VandeVondele  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  
---
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 fortran/34740] -fbounds-check with TRANSFER misses out of bounds in array assignment

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34740

Joost VandeVondele  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  
---
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 middle-end/57904] [4.9 Regression] Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90)

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #6 from Joost VandeVondele  
---
this is the same/similar issue as PR58746, which also triggers this warning but
even without -m32 on x86_64.

[Bug middle-end/58746] [4.9 Regression] Incorrect warning with -Waggressive-loop-optimizations

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58746

--- Comment #2 from Joost VandeVondele  
---
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/58746] [4.9 Regression] Incorrect warning with -Waggressive-loop-optimizations

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58746

--- Comment #1 from Joost VandeVondele  
---
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 lto/56706] [4.8/4.9 Regression] failure building CP2K at -flto -O2

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706

Joost VandeVondele  changed:

   What|Removed |Added

  Known to work||4.9.0
  Known to fail|4.9.0   |

--- Comment #12 from Joost VandeVondele  
---
Building with 4.9.0 now works, 4.8.3 [gcc-4_8-branch revision 203695] still
fails.

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59302

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #2 from Joost VandeVondele  
---
(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 sanitizer/59302] New: tsan: Unexpected mmap in InternalAllocator!

[Joost.VandeVondele at mat dot ethz.ch]

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=, alignment=,
size=, this=)
at ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:948
948MapUnmapCallback().OnMap(map_beg, map_size);
(gdb) bt
#0  Allocate (stat=, alignment=, size=, this=)
at ../../../../gcc/libsanitizer/sanitizer_common/sanitizer_allocator.h:948
#1  Allocate (cleared=, alignment=,
size=, cache=, this=)
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=, addr_max=,
addr_min=, traces=...)
at ../../../../gcc/libsanitizer/tsan/tsan_rtl_report.cc:487
#7  __tsan::ReportRace (thr=) 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=, thr=) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:376
#10 MemoryAccessImpl (cur=..., shadow_mem=, kIsAtomic=, kAccessIsWrite=, kAccessSizeLog=, 
addr=, thr=) 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/59286] segfault in __sanitizer::StackDepotGet

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286

--- Comment #10 from Joost VandeVondele  
---
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/59286] segfault in __sanitizer::StackDepotGet

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286

--- Comment #9 from Joost VandeVondele  
---
(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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286

--- Comment #7 from Joost VandeVondele  
---
(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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286

--- Comment #6 from Joost VandeVondele  
---
(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=)
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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286

--- Comment #4 from Joost VandeVondele  
---
(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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #2 from Joost VandeVondele  
---
(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] New: segfault in __sanitizer::StackDepotGet

[Joost.VandeVondele at mat dot ethz.ch]

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=) 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=, thr=) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:376
#5  MemoryAccessImpl (cur=..., shadow_mem=, kIsAtomic=, kAccessIsWrite=, kAccessSizeLog=,
addr=, 
thr=) 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=, 
handle=, _routinen=) 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 fortran/54797] Gnu Fortran compiler does not recognize module file it created

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54797

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #6 from Joost VandeVondele  
---
there is actually some recent change that causes similar behavior:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59276

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

[Joost.VandeVondele at mat dot ethz.ch]

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 sanitizer/59061] Port leaksanitizer

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061

--- Comment #29 from Joost VandeVondele  
---
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 lto/56706] [4.8/4.9 Regression] failure building CP2K at -flto -O2

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706

Joost VandeVondele  changed:

   What|Removed |Added

 Depends on||59154

--- Comment #11 from Joost VandeVondele  
---
the ICE just mentioned is PR59154.

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706

--- Comment #10 from Joost VandeVondele  
---
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  for instructions.
make[2]: *** [/tmp/ccEVGVIu.ltrans20.ltrans.o] Error 1

[Bug web/56063] [bugzilla] last reconfirmed : now

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56063

--- Comment #10 from Joost VandeVondele  
---
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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706

--- Comment #9 from Joost VandeVondele  
---
(In reply to Richard Biener from comment #8)
> Waiting for analysis.

Analysis by whom, and if me, what can I do ?

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188

Joost VandeVondele  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2013-11-21
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #10 from Joost VandeVondele  
---
(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 fortran/45586] [4.8/4.9 Regression] ICE non-trivial conversion at assignment

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586

--- Comment #97 from Joost VandeVondele  
---
(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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215

--- Comment #18 from Joost VandeVondele  
---
(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 fortran/59229] [4.9.0 Regression] ICE in ix86_expand_set_or_movmem

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229

--- Comment #2 from Joost VandeVondele  
---
reducing..

[Bug fortran/59229] [4.9.0 Regression] ICE in ix86_expand_set_or_movmem

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229

Joost VandeVondele  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  
---
Confirmed... very satisfying to see that this single file 8 lines programs
are still bleeding edge.

[Bug sanitizer/59215] tsan: warning in shared_ptr_base.h

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #14 from Joost VandeVondele  
---
(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 libgomp/59194] tsan detects race for real variables in an OMP reduction clause

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194

--- Comment #8 from Joost VandeVondele  
---
(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 libgomp/59194] tsan detects race for real variables in an OMP reduction clause

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194

--- Comment #6 from Joost VandeVondele  
---
(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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194

--- Comment #5 from Joost VandeVondele  
---
(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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194

--- Comment #3 from Joost VandeVondele  
---
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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #2 from Joost VandeVondele  
---
(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] New: tsan detects race for real variables in an OMP reduction clause

[Joost.VandeVondele at mat dot ethz.ch]

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 sanitizer/59188] [4.9 Regression] lib64/libtsan.so: undefined reference to `sigsetjmp'

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #5 from Joost VandeVondele  
---
(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 sanitizer/59188] New: [4.9 Regression] lib64/libtsan.so: undefined reference to `sigsetjmp'

[Joost.VandeVondele at mat dot ethz.ch]

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/55439] ThreadSanitizer: handle atomic operations

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55439

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #3 from Joost VandeVondele  
---
Jakub, your patch went in trunk 1yr ago, should this be closed as fixed ?

[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063

Joost VandeVondele  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  
---
posted patch:

http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01389.html

[Bug sanitizer/59061] Port leaksanitizer

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061

--- Comment #21 from Joost VandeVondele  
---
(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/59061] Port leaksanitizer

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061

--- Comment #19 from Joost VandeVondele  
---
(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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061

--- Comment #17 from Joost VandeVondele  
---
(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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061

--- Comment #8 from Joost VandeVondele  
---
(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 middle-end/38318] moving the allocation of temps out of loops.

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318

--- Comment #12 from Joost VandeVondele  
---
(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 middle-end/38318] moving the allocation of temps out of loops.

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318

--- Comment #10 from Joost VandeVondele  
---
(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 for gcc to guess that
> _gfortran_os_error is safe. 

For the Fortran FE people (not me, I'm a user), but  _gfortran_os_error should
have an attribute like 'abort' or 'noreturn'. However, the compiler should also
be able to figure out this can never be called (if B is 'allocated on the
stack') in this subroutine.

> Er, no, I missed the call to s2. I would also need some attribute on s2 so
> the compiler knows that s2 doesn't do anything too weird. 

Actually, in Fortran, S2 can't do anything 'weird' with B, in the sense that
your optimization should certainly apply. Not so sure about the correct terms
here, but in approximate C-speak, B 'as a pointer' is guaranteed to be pointing
to exactly the same address, nothing has happened to its target, and no pointer
can be pointing to whatever B was pointing to

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318

--- Comment #8 from Joost VandeVondele  
---
(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-patches/2013-11/msg01049.html
> > could fix the problem with the testcase subroutine S1, even though 'moving
> > allocations out of loops' is more or less a side effect.
> 
> I don't speak fortran fluently so I tried compiling S1 with an unpatched
> compiler and -O2 -fdump-tree-optimized, but I don't see any call to malloc
> in there. Could you explain, with references to a dump, what the internal
> functions mean and where my patch might help?

Marc, looks like the fortran FE changed a lot since this bug was filed, and
there is no explicit allocate anymore, in fact the variable is created on stack
by the frontend... this is controlled by -fmax-stack-var-size=0 (putting it to
zero, will yield your __builtin_malloc() that I recalled, in the
PR38318.f90.003t.original dump). You have a precedent for getting the a
reasonable size (32768 for fortran).

The _gfortran_internal_(un)pack is a fortran FE thing, that guarantees that
memory is contiguous... clearly a missed frontend optimization in this case.

So now, the proper testcase would be:
> cat PR38318-3.f90
SUBROUTINE S1(N,A)
 REAL :: A(3)
 REAL, DIMENSION(:), ALLOCATABLE :: B
 DO I=1,N
   ALLOCATE(B(3))
   B=-A
   CALL S2(B)
   DEALLOCATE(B)
 ENDDO
END SUBROUTINE

which really should contain any call to _gfortran_runtime_error_at,
_gfortran_os_error, __builtin_malloc, __builtin_free if all were perfect, and
certainly not in the loop

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318

Joost VandeVondele  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org,
   ||Joost.VandeVondele at mat dot 
ethz
   ||.ch

--- Comment #6 from Joost VandeVondele  
---
Marc, I think your recently posted patch:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01049.html
could fix the problem with the testcase subroutine S1, even though 'moving
allocations out of loops' is more or less a side effect.

[Bug sanitizer/59061] Port leaksanitizer

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061

--- Comment #6 from Joost VandeVondele  
---
(In reply to Kostya Serebryany from comment #5)
> > That's great... works even for Fortran code :-)
> Wow! 

well, many thanks to those people making sanitizer happen, also in gcc.

> >  In performance-critical scenarios, LSan can also be used without ASan
> > instrumentation. 
> > 
> > But it is unclear from that description how that would work.. any hints ?
> 
> Clang supports -fsanitize=leak which simply links a standalone lsan library
> (no instrumentation at compile time required). 
> Perhaps gcc can add such option too. 

I agree that such an option would be useful (see also below).

For now, I put '-fsanitize=address' for the link step only, which has the same
effect. 

Additionally, it seems important to have -g -fno-omit-frame-pointer in the
options. Maybe gcc should add these options for best 'user experience', for
example as part of -fsanitize=address/leak. Power users can always override
with -fsanitize=leak -fomit-frame-pointer.

> But: we do not test -fsanitize=leak on anything other than tiny tests,
> so we truly support only the lsan+asan use case.

It would be great to have -fsanitize=leak robust. For our testing purposes we
can not have the overhead of -fsanitize=address (which for Fortran is largely,
but not completely, covered by -fcheck=bounds). Anyway, first test on our
codebase (~1Mloc) suggests it works well (modulo PR59063). I'll add
-fsanitize=x to my nightly gcc trunk tester.

> We'll need to update the wiki page to have this all explained in detail, 
> thanks for raising these questions.

One more example for the wiki, that's how we can run this with cp2k ;-)

time ASAN_OPTIONS="detect_leaks=1" ../../exe/Linux-x86-64-leaks/cp2k.sdbg C.inp
2>&1 | python /data/vjoost/gnu/bugs/asan_symbolize.py

[Bug sanitizer/59063] New: [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063

Bug ID: 59063
   Summary: [4.9 Regression] ASAN: segfault in
__interceptor_clock_gettime
   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

with -fsanitize=address the following code works on 4.8 branch bug segfaults
with 4.9

> cat test.f90 
  INTEGER, SAVE  :: count_max, count_rate
  CALL SYSTEM_CLOCK(count_rate=count_rate,count_max=count_max)
END 

> gfortran -fsanitize=address test.f90 ; ./a.out
ASAN:SIGSEGV
=
==48940==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x sp 0x7fff97430008 bp 0x7fff97430040 T0)
AddressSanitizer can not provide additional info.   
==48940==ABORTING

Under gdb the bt is:

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x76b76278 in __interceptor_clock_gettime (clk_id=,
tp=0x7fffd6e0)
at
../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:740
#2  0x76b1efbc in gf_gettime_mono (tck=,
fracsecs=, secs=)
at ../../../gcc/libgfortran/intrinsics/system_clock.c:98
#3  _gfortran_system_clock_4 (count=0x0, count_rate=0x600f60 ,
count_max=0x600fa0 )
at ../../../gcc/libgfortran/intrinsics/system_clock.c:147
#4  0x0040089d in MAIN__ ()
#5  0x004008d3 in main ()

[Bug sanitizer/59061] Port leaksanitizer

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061

--- Comment #4 from Joost VandeVondele  
---
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
instrumentation. 

But it is unclear from that description how that would work.. any hints ?

[Bug sanitizer/59061] Port leaksanitizer

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061

--- Comment #2 from Joost VandeVondele  
---
(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 leaksanitizer... I didn't see it mentioned on the list or doc changes or
so.

So, how does it work, is it part of -fsanitize=address (doesn't seem to do
that) or is there a new option -fsanitize=leaks ?

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59060

Joost VandeVondele  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Joost VandeVondele  
---
(In reply to Joost VandeVondele from comment #4)
> gfortran accepts this... this could be right again, since all components
> ultimately have a default initialization.

must have been a pilot error... I'm closing this as invalid.

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

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59060

--- Comment #4 from Joost VandeVondele  
---
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
 END TYPE T2
 TYPE(T2), PARAMETER :: D2
END MODULE M1

All of cray, intel and pgi complain about this along the lines:

bug.f90(8): error #6557: An =initialization-expr is missing; an initialization
expression is required when using the PARAMETER attribute.   [D2]
 TYPE(T2), PARAMETER :: D2
^

gfortran accepts this... this could be right again, since all components
ultimately have a default initialization.

[Bug sanitizer/59061] Port leaksanitizer

[Joost.VandeVondele at mat dot ethz.ch]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061

Joost VandeVondele  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
   Severity|normal  |enhancement