[Bug fortran/55341] New: address-sanitizer and Fortran

[Bug fortran/55341] New: address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

             Bug #: 55341
           Summary: address-sanitizer and Fortran
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: Joost.VandeVondele@mat.ethz.ch


Hardly a bug, rather a feature... it seems '-faddress-sanitizer' works with
Fortran seemingly out-of-the-box. Great!

could it be documented a being for c/c++/Fortran ?

Both these testcases work ('fail') as expected:

PROGRAM TEST_ASAN_01
  INTEGER :: A(10)
  i=-1
  A(i)=0
END PROGRAM


PROGRAM TEST_ASAN_02
  INTEGER, POINTER :: x1,x2,x3
  ALLOCATE(X1)
  X2=>X1
  DEALLOCATE(X1)
  X2=0
END PROGRAM

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Joost.VandeVondele at mat
                   |                            |dot ethz.ch

--- Comment #1 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-11-15 14:02:47 UTC ---
Trying -faddress-sanitizer on CP2K leads to the following failure:

> cat bug.f90 
MODULE qs_environment_types
 TYPE rt_prop_type
    INTEGER,DIMENSION(:,:),ALLOCATABLE    :: orders
 END TYPE rt_prop_type
  TYPE qs_environment_type
    TYPE(rt_prop_type),POINTER            :: rtp
  END TYPE qs_environment_type
CONTAINS
  SUBROUTINE set_qs_env(qs_env,rtp)
    TYPE(qs_environment_type), POINTER    :: qs_env
    TYPE(rt_prop_type), OPTIONAL, POINTER :: rtp
    IF (PRESENT(rtp)) qs_env%rtp=rtp
  END SUBROUTINE set_qs_env
END MODULE qs_environment_types


> gfortran -O0 -faddress-sanitizer bug.f90 
bug.f90: In function ‘set_qs_env’:
bug.f90:9:0: error: type mismatch in binary expression
   SUBROUTINE set_qs_env(qs_env,rtp)
 ^
unsigned long

integer(kind=8)

unsigned long

_182 = _181 - 1;

bug.f90:9:0: error: type mismatch in binary expression
unsigned long

integer(kind=8)

unsigned long

_206 = _205 - 1;

bug.f90:9:0: internal compiler error: verify_gimple failed
0x9a47ac verify_gimple_in_cfg(function*)
    ../../gcc/gcc/tree-cfg.c:4728
0x8dad97 execute_function_todo
    ../../gcc/gcc/passes.c:1979
0x8db75d execute_todo
    ../../gcc/gcc/passes.c:2008
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.

[Bug fortran/55341] address-sanitizer and Fortran

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org 2012-11-16 10:27:43 UTC ---
(In reply to comment #1)
> Trying -faddress-sanitizer on CP2K leads to the following failure:

Slightly reduced test case:

MODULE m
  TYPE t
    INTEGER, DIMENSION(:), ALLOCATABLE :: orders
  END TYPE
CONTAINS
  SUBROUTINE s
    TYPE(t) :: x, y
    x = y
  END SUBROUTINE
END MODULE m

[Bug fortran/55341] address-sanitizer and Fortran

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-16 10:54:25 UTC ---
Looks like a FE bug to me.

[Bug fortran/55341] address-sanitizer and Fortran

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-11-16
         AssignedTo|unassigned at gcc dot       |jakub at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-16 10:55:53 UTC ---
Created attachment 28707
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28707
gcc48-pr55341.patch

Untested fix.  memcpy's last argument is size_type_node, i.e. unsigned C
size_t, while in several places the FE was calling memcpy with a signed type of
the argument instead.

[Bug fortran/55341] address-sanitizer and Fortran

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org 2012-11-17 12:15:45 UTC ---
(In reply to comment #4)
> Untested fix.  memcpy's last argument is size_type_node, i.e. unsigned C
> size_t, while in several places the FE was calling memcpy with a signed type of
> the argument instead.

This fixes the ICE and regtests cleanly on x86_64-unknown-linux-gnu. Looks good
to me!

[Bug fortran/55341] address-sanitizer and Fortran

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-17 13:03:01 UTC ---
Author: jakub
Date: Sat Nov 17 13:02:56 2012
New Revision: 193585

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193585
Log:
    PR fortran/55341
    * trans-intrinsic.c (gfc_conv_intrinsic_transfer): Convert last
    argument to memcpy to size_type_node type.
    * trans-stmt.c (gfc_conv_elemental_dependencies): Likewise.
    * trasn-array.c (duplicate_allocatable): Likewise.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/fortran/trans-stmt.c

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #7 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-10 12:37:00 UTC ---
I'm wondering, is asan not supposed to print out a backtrace with file names
and line numbers... right now (trunk of today) I get a trace with just
addresses, I somehow have the feeling this was different in an earlier version
:

gfortran -g -fsanitize=address asan_test.f90 ; ./a.out
=================================================================
==19529== ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7fff503d6a98 at pc 0x400922 bp 0x7fff503d6a60 sp 0x7fff503d6a58
WRITE of size 4 at 0x7fff503d6a98 thread T0
    #0 0x400921 (/data/vjoost/gnu/bugs/a.out+0x400921)
    #1 0x400942 (/data/vjoost/gnu/bugs/a.out+0x400942)
    #2 0x400978 (/data/vjoost/gnu/bugs/a.out+0x400978)
    #3 0x351661ecdc (/lib64/libc-2.12.so+0x1ecdc)
Address 0x7fff503d6a98 is located at offset 24 in frame <test_asan_01> of T0's
stack:
  This frame has 1 object(s):
    [32, 72) 'a'

[Bug fortran/55341] address-sanitizer and Fortran

[kcc at gcc dot gnu.org]

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

Kostya Serebryany <kcc at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kcc at gcc dot gnu.org

--- Comment #8 from Kostya Serebryany <kcc at gcc dot gnu.org> 2012-12-10 12:45:37 UTC ---
Joost: 
http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#Call_stack

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #9 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-10 13:19:24 UTC ---
(In reply to comment #8)
> Joost: 
> http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer#Call_stack

No luck, even with -fno-omit-frame-pointer and the python script :

> rm -f ./a.out ; gfortran -g -O0 -fsanitize=address -fno-omit-frame-pointer asan_test.f90 ; ./a.out | python ./asan_symbolize.py

=================================================================
==43068== ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7fff7a574fb8 at pc 0x400922 bp 0x7fff7a574f80 sp 0x7fff7a574f78
WRITE of size 4 at 0x7fff7a574fb8 thread T0
    #0 0x400921 (/data/vjoost/gnu/bugs/a.out+0x400921)
    #1 0x400942 (/data/vjoost/gnu/bugs/a.out+0x400942)
    #2 0x400978 (/data/vjoost/gnu/bugs/a.out+0x400978)
    #3 0x351661ecdc (/lib64/libc-2.12.so+0x1ecdc)
Address 0x7fff7a574fb8 is located at offset 24 in frame <test_asan_01> of T0's
stack:
  This frame has 1 object(s):
    [32, 72) 'a'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
Shadow byte and word:
  0x1fffef4ae9f7: f1

[Bug fortran/55341] address-sanitizer and Fortran

[kcc at gcc dot gnu.org]

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

--- Comment #10 from Kostya Serebryany <kcc at gcc dot gnu.org> 2012-12-10 13:20:51 UTC ---
>> ./a.out | python ./asan_symbolize.py
It should be 
  ./a.out 2>&1  | python ./asan_symbolize.py

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #11 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-10 13:26:31 UTC ---
(In reply to comment #10)
> >> ./a.out | python ./asan_symbolize.py
> It should be 
>   ./a.out 2>&1  | python ./asan_symbolize.py

not good yet, line numbers are 0. Also happens for a C testcase.

Also addr2line seems not happy:

addr2line -e ./a.out 0x400921
??:0

> gfortran -g -O0 -fsanitize=address -fno-omit-frame-pointer asan_test.f90 ; ./a.out 2>&1 | python ./asan_symbolize.py
=================================================================
==45957== ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7fff9752bdd8 at pc 0x400922 bp 0x7fff9752bda0 sp 0x7fff9752bd98
WRITE of size 4 at 0x7fff9752bdd8 thread T0
    #0 0x400921 in test_asan_01_ ??:0
    #1 0x400942 in MAIN__ asan_test.f90:0
    #2 0x400978 in main ??:0
    #3 0x351661ecdc in ?? ??:0
Address 0x7fff9752bdd8 is located at offset 24 in frame <test_asan_01> of T0's
stack:

[Bug fortran/55341] address-sanitizer and Fortran

[kcc at gcc dot gnu.org]

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

--- Comment #12 from Kostya Serebryany <kcc at gcc dot gnu.org> 2012-12-10 13:28:12 UTC ---
Does pure addr2line work?

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #13 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-10 13:33:12 UTC ---
(In reply to comment #12)
> Does pure addr2line work?

No, the following (-gdwarf-3) does work:

gfortran -gdwarf-3 -O0 -fsanitize=address -fno-omit-frame-pointer asan_test.f90
; ./a.out 2>&1 | python ./asan_symbolize.py

I guess the binutils is not quite up-to-date, I'm using a relatively recent
2.22
> addr2line --version
GNU addr2line (GNU Binutils) 2.22

[Bug fortran/55341] address-sanitizer and Fortran

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-10 13:41:16 UTC ---
(In reply to comment #11)
> > >> ./a.out | python ./asan_symbolize.py
> > I> =================================================================
> ==45957== ERROR: AddressSanitizer: stack-buffer-underflow on address
> 0x7fff9752bdd8 at pc 0x400922 bp 0x7fff9752bda0 sp 0x7fff9752bd98
> WRITE of size 4 at 0x7fff9752bdd8 thread T0
>     #0 0x400921 in test_asan_01_ ??:0
>     #1 0x400942 in MAIN__ asan_test.f90:0
>     #2 0x400978 in main ??:0
>     #3 0x351661ecdc in ?? ??:0
> Address 0x7fff9752bdd8 is located at offset 24 in frame <test_asan_01> of T0's
> stack:

That means your addr2line is too old.
You need at least addr2line with
http://sourceware.org/ml/binutils-cvs/2012-04/msg00119.html
changes to cope with GCC 4.8 emitted DWARF 4.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #15 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-10 13:56:02 UTC ---
(In reply to comment #14)
> That means your addr2line is too old.

OK, with binutils 2.23.1 things work as expected. In particular:

> gfortran -g -O0 -fsanitize=address asan_test.f90 ; ./a.out 2>&1 | python ./asan_symbolize.py
=================================================================
==35214== ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7fff37dfe8b8 at pc 0x400922 bp 0x7fff37dfe880 sp 0x7fff37dfe878
WRITE of size 4 at 0x7fff37dfe8b8 thread T0
    #0 0x400921 in test_asan_01_ /data/vjoost/gnu/bugs/asan_test.f90:4
    #1 0x400942 in MAIN__ /data/vjoost/gnu/bugs/asan_test.f90:7
    #2 0x400978 in main /data/vjoost/gnu/bugs/asan_test.f90:8
    #3 0x351661ecdc in ?? ??:0

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #16 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-19 08:17:15 UTC ---
After testing on CP2K, I believe that ASAN yields a false positive (current
trunk). It is obviously hard to be sure, but the indications are 

First, the code and testcase runs without error with valgrind (when compiled
without -fsanitize=address). 
Second, the error happens after the last statement in the subroutine and is of
'unknown' type
Third, the invalid write has size 1, which is a very unusual length in Fortran,
as almost no data types have that length.

While I can provide build instructions for CP2K (and the sources are public of
course), I can't reduce this to a small runtime testcase. Is it sufficient to
upload the object/disassembly for the involved subroutine for this to be
investigated ?

I can copy and paste commands in gdb if you have suggestions...

Meanwhile, the error message reads:

==49256== ERROR: AddressSanitizer: unknown-crash on address 0x1ffff6742e2c at
pc 0x7ff6d8e6e11d bp 0x7fffb3a16b80 sp 0x7fffb3a16b58
WRITE of size 1 at 0x1ffff6742e2c thread T0
    #0 0x7ff6d8e6e11c in __interceptor_memset _asan_rtl_
    #1 0x1c93a5f in __qs_environment_MOD_qs_init
/data/vjoost/gnu/cp2k/cp2k/src/../src/qs_environment.F:210
    #2 0xe4f
Address 0x1ffff6742e2c is located in the high shadow area.
Stats: 415M malloced (231M for red zones) by 484132 calls
Stats: 0M realloced by 0 calls
Stats: 282M freed by 427077 calls
Stats: 264M really freed by 150081 calls
Stats: 418M (107040 full pages) mmaped in 357 calls
  mmaps   by size class: 7:294840; 8:24564; 9:22506; 10:9198; 11:18615;
12:6656; 13:5632; 14:96; 15:16; 16:8; 18:2; 21:7; 23:1; 24:2; 25:2; 26:2;
  mallocs by size class: 7:335835; 8:33268; 9:33156; 10:17186; 11:24103;
12:20433; 13:19971; 14:147; 15:11; 16:5; 18:2; 21:7; 23:1; 24:2; 25:3; 26:2;
  frees   by size class: 7:320047; 8:18657; 9:20241; 10:16584; 11:11547;
12:19913; 13:19948; 14:124; 15:2; 16:5; 21:6; 23:1; 25:1; 26:1;
  rfrees  by size class: 7:43981; 8:18546; 9:20241; 10:16454; 11:11497;
12:19531; 13:19693; 14:124; 15:2; 16:4; 21:6; 25:1; 26:1;
Stats: malloc large: 33 small slow: 11758
==49256== ABORTING

[Bug fortran/55341] address-sanitizer and Fortran

[kcc at gcc dot gnu.org]

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

--- Comment #17 from Kostya Serebryany <kcc at gcc dot gnu.org> 2012-12-19 08:37:21 UTC ---
For whatever reason the fortran code is touching asan's shadow:
  Address 0x1ffff6742e2c is located in the high shadow area.

What is __qs_environment_MOD_qs_init doing? 
Is it normally touching that region of address space?

[Bug fortran/55341] address-sanitizer and Fortran

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-19 08:42:40 UTC ---
(In reply to comment #16)
> After testing on CP2K, I believe that ASAN yields a false positive (current
> trunk). It is obviously hard to be sure, but the indications are 
> 
> First, the code and testcase runs without error with valgrind (when compiled
> without -fsanitize=address). 

Those are very weak indications.  Valgrind doesn't report out of bounds array
accesses on the stack and similar errors (unless they are uninitialized stack
area reads + use of that uninitialized data), asan does.

> Second, the error happens after the last statement in the subroutine and is of
> 'unknown' type
> Third, the invalid write has size 1, which is a very unusual length in Fortran,
> as almost no data types have that length.

And this is no reason at all, for most string/memory intrinsics asan
instruments them just by pretending they are writes (resp. reads or both) from
the first and last byte of the area, i.e. with size 1.
The backtrace clearly shows that it is memset.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #19 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-19 08:48:47 UTC ---
(In reply to comment #17)
> For whatever reason the fortran code is touching asan's shadow:
>   Address 0x1ffff6742e2c is located in the high shadow area.
> 
> What is __qs_environment_MOD_qs_init doing? 
> Is it normally touching that region of address space?

Well, certainly the code is not trying to do anything fancy (i.e. writing to
specific addresses or so), it is plain Fortran code. 

qs_init is doing the initialization of our simulation code, it is mostly a
bunch of calls to other subroutines doing init as well (which makes difficult
to extract as a small testcase).

Is the shadow area checked regularly ? If not, I could try to trigger the
checking more often to try and narrow the issue.

[Bug fortran/55341] address-sanitizer and Fortran

[kcc at gcc dot gnu.org]

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

--- Comment #20 from Kostya Serebryany <kcc at gcc dot gnu.org> 2012-12-19 08:51:54 UTC ---
For whatever reason the fortran code is touching asan's shadow:
  Address 0x1ffff6742e2c is located in the high shadow area.

What is __qs_environment_MOD_qs_init doing? 
Is it normally touching that region of address space?

[Bug fortran/55341] address-sanitizer and Fortran

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-19 08:52:43 UTC ---
(In reply to comment #17)
> For whatever reason the fortran code is touching asan's shadow:
>   Address 0x1ffff6742e2c is located in the high shadow area.
> 
> What is __qs_environment_MOD_qs_init doing? 
> Is it normally touching that region of address space?

Ah, it could be the clearing of the stack shadow area.  If there are just a few
stores needed or if it is non-contiguous enough,
          clear_storage (shadow_mem, GEN_INT (last_size >> ASAN_SHADOW_SHIFT),
                         BLOCK_OP_NORMAL);
is expanded as piece-wise stores, but if the shadow memory area is too big,
depending on the target CPU it can be also expanded as memset function call.

So, to fix this, either libasan should for memset ignore any diagnostics for
stores into shadow memory area, or I'll need to force somehow that memset is
never generated for it, or we could have a non-instrumented memset alternative
in libasan and we could call that.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #22 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-19 08:59:03 UTC ---
(In reply to comment #18)
> And this is no reason at all, for most string/memory intrinsics asan
> instruments them just by pretending they are writes (resp. reads or both) from
> the first and last byte of the area, i.e. with size 1.
> The backtrace clearly shows that it is memset.

The memset is also a bit surprising. The error is reported after the last line
of the subroutine is executed, and the line number also just refers to the
subroutine declaration. The -fdump-tree-* of qs_environment.F constain a single
__builtin_memset, and its line number info is 889.

[Bug fortran/55341] address-sanitizer and Fortran

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-19 09:03:13 UTC ---
Example testcase:

void bar (char *, char *, char *, char *, char *, char *, char *, char *, char
*, char *,
          char *, char *, char *, char *, char *, char *, char *, char *, char
*, char *,
          char *, char *, char *, char *, char *, char *, char *, char *, char
*, char *);

int
foo (void)
{
  char c0, c1, c2, c3, c4, c5, c6, c7, c8, c9;
  char d0, d1, d2, d3, d4, d5, d6, d7, d8, d9;
  char e0, e1, e2, e3, e4, e5, e6, e7, e8, e9;
  bar (&c0, &c1, &c2, &c3, &c4, &c5, &c6, &c7, &c8, &c9,
       &d0, &d1, &d2, &d3, &d4, &d5, &d6, &d7, &d8, &d9,
       &e0, &e1, &e2, &e3, &e4, &e5, &e6, &e7, &e8, &e9);
  return 0;
}

on powerpc64-linux with -O2 -fsanitize=address, or on say x86_64-linux with -O2
-fsanitize=address -mstringop-strategy=libcall
These want to clear 244 bytes of consecutive shadow memory upon return from the
function.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #24 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-19 09:06:38 UTC ---
(In reply to comment #23)
> Example testcase:

looks definitely like what Fortran subroutines with 100 optional arguments
might generate...

Amazingly efficient debugging :-)

[Bug fortran/55341] address-sanitizer and Fortran

[kcc at gcc dot gnu.org]

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

--- Comment #25 from Kostya Serebryany <kcc at gcc dot gnu.org> 2012-12-19 10:32:29 UTC ---
>> So, to fix this, either libasan should for memset ignore any diagnostics for
>> stores into shadow memory area, 

That's not a good choice. I remember actually catching a bug or two when a
program was reading wild addresses and hitting the shadow. 

>> or I'll need to force somehow that memset is never generated for it, 

This is imho the best choice. 

>> or we could have a non-instrumented memset alternative in libasan and we could call that.

That's doable too, although it will look strange and I'd prefer to avoid this.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-p
                   |                            |atches/2012-12/msg01178.htm
                   |                            |l

--- Comment #26 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-19 14:09:54 UTC ---
with Jakob's patch (http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01178.html),
the code runs further, now stopping on another error which seems to be in asan
shadow, and also triggering some kind of an asan internal assert:

=================================================================
==32737== ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff5c9ec638 at pc 0x4468bb bp 0x7fff5c9ec610 sp 0x7fff5c9ec608
WRITE of size 8 at 0x7fff5c9ec638 thread T0
    #0 0x4468ba in __cp_log_handling_MOD_cp_int_to_string
/data/vjoost/gnu/cp2k/cp2k/src/../src/cp_log_handling.F:882
==32737== AddressSanitizer CHECK failed:
../../../../gcc/libsanitizer/asan/asan_report.cc:149 "((name_end)) != (0)"
(0x0, 0x0)
    #0 0x7feaeae78d83 in AsanCheckFailed _asan_rtl_
    #1 0x7feaeae7d3b3 in _ZN11__sanitizer11CheckFailedEPKciS1_yy
/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libsanitizer/sanitizer_common/../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common.cc:49
Stats: 415M malloced (231M for red zones) by 484257 calls
Stats: 0M realloced by 0 calls
Stats: 282M freed by 427195 calls
Stats: 264M really freed by 150081 calls
Stats: 418M (107040 full pages) mmaped in 357 calls
  mmaps   by size class: 7:294840; 8:24564; 9:22506; 10:9198; 11:18615;
12:6656; 13:5632; 14:96; 15:16; 16:8; 18:2; 21:7; 23:1; 24:2; 25:2; 26:2;
  mallocs by size class: 7:335865; 8:33279; 9:33157; 10:17200; 11:24104;
12:20478; 13:19994; 14:147; 15:11; 16:5; 18:2; 21:7; 23:1; 24:2; 25:3; 26:2;
  frees   by size class: 7:320075; 8:18667; 9:20241; 10:16596; 11:11548;
12:19958; 13:19970; 14:124; 15:2; 16:5; 21:6; 23:1; 25:1; 26:1;
  rfrees  by size class: 7:43981; 8:18546; 9:20241; 10:16454; 11:11497;
12:19531; 13:19693; 14:124; 15:2; 16:4; 21:6; 25:1; 26:1;
Stats: malloc large: 33 small slow: 11769

[Bug fortran/55341] address-sanitizer and Fortran

[kcc at gcc dot gnu.org]

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

--- Comment #27 from Kostya Serebryany <kcc at gcc dot gnu.org> 2012-12-19 14:29:12 UTC ---
This time it looks like a valid error report (stack buffer overflow), but asan
crashes while reporting it. 

Take a look at DescribeAddressIfStack in asan/asan_report.cc,
and see what does asan receive as frame_descr

A small reproducer would really help me here.

[Bug fortran/55341] address-sanitizer and Fortran

[jakub at gcc dot gnu.org]

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

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-12-19 14:33:13 UTC ---
I'd say as a first step try to make sure -lasan is linked at the very
beginning, before all other libraries, there are numerous libasan crashes if it
is not so.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #29 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-19 14:36:00 UTC ---
(In reply to comment #27)
> This time it looks like a valid error report (stack buffer overflow), but asan
> crashes while reporting it. 
> 
> Take a look at DescribeAddressIfStack in asan/asan_report.cc,
> and see what does asan receive as frame_descr
> 
> A small reproducer would really help me here.

If I extract the subroutine where this happens and call it with the same
arguments there is no asan error. This will make it more difficult to get to a
small reproducer.

Interestingly, if I compile the full code with -g -O0 -fsanitize=address
instead of '-g -O1 -fsanitize=address -march=native' asan does not report an
error.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #30 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-19 15:57:11 UTC ---
(In reply to comment #28)
> I'd say as a first step try to make sure -lasan is linked at the very
> beginning, before all other libraries, there are numerous libasan crashes if it
> is not so.

Unfortunately, this makes no difference.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #31 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-19 16:08:14 UTC ---
(In reply to comment #27)
> This time it looks like a valid error report (stack buffer overflow), but asan
> crashes while reporting it. 


If I add -fno-omit-frame-pointer, the stack trace becomes better. the check now
fails in what I believe would be a gfortran provided routine (__MAIN or
similar). The invalid write of size 8 has become one of size 4:

WRITE of size 4 at 0x7fff2faeb270 thread T0
    #0 0x4472d9 in __cp_log_handling_MOD_cp_int_to_string
/data/vjoost/gnu/cp2k/cp2k/src/../src/cp_log_handling.F:882
    #1 0x6419b5 in __input_section_types_MOD_section_vals_get_subs_vals
/data/vjoost/gnu/cp2k/cp2k/src/../src/input_section_types.F:1103 (discriminator
2)
    #2 0x48a77b in __f77_interface_MOD_create_force_env
/data/vjoost/gnu/cp2k/cp2k/src/../src/f77_interface.F:817
    #3 0x41566a in __cp2k_runs_MOD_cp2k_run
/data/vjoost/gnu/cp2k/cp2k/src/../src/cp2k_runs.F:307
    #4 0x4167f2 in __cp2k_runs_MOD_run_input
/data/vjoost/gnu/cp2k/cp2k/src/../src/cp2k_runs.F:1133
    #5 0x407289 in cp2k /data/vjoost/gnu/cp2k/cp2k/src/../src/cp2k.F:285
    #6 0x40751a in main /data/vjoost/gnu/cp2k/cp2k/src/../src/cp2k.F:41
    #7 0x351661ecdc in ?? ??:0
==70361== AddressSanitizer CHECK failed:
../../../../gcc/libsanitizer/asan/asan_report.cc:149 "((name_end)) != (0)"
(0x0, 0x0)
    #0 0x7f068f37bd83 in AsanCheckFailed _asan_rtl_
    #1 0x7f068f3803b3 in _ZN11__sanitizer11CheckFailedEPKciS1_yy
/data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libsanitizer/sanitizer_common/../../../../gcc/libsanitizer/sanitizer_common/sanitizer_common.cc:49

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #32 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-19 18:00:34 UTC ---
(In reply to comment #28)
> I'd say as a first step try to make sure -lasan is linked at the very
> beginning, before all other libraries, there are numerous libasan crashes if it
> is not so.

Is there a way to build gcc so that libgfortran is asan-instrumented ? I start
suspecting that maybe the error is due to something that's happening in the
gfortran runtime, and that's only detected once the code returns to CP2K.

[Bug fortran/55341] address-sanitizer and Fortran

[howarth at nitro dot med.uc.edu]

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

Jack Howarth <howarth at nitro dot med.uc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at nitro dot
                   |                            |med.uc.edu

--- Comment #33 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-12-19 20:59:14 UTC ---
(In reply to comment #32)
> (In reply to comment #28)
> > I'd say as a first step try to make sure -lasan is linked at the very
> > beginning, before all other libraries, there are numerous libasan crashes if it
> > is not so.
> 
> Is there a way to build gcc so that libgfortran is asan-instrumented ? I start
> suspecting that maybe the error is due to something that's happening in the
> gfortran runtime, and that's only detected once the code returns to CP2K.

Using--with-build-config=bootstrap-asan should do that for you.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #34 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-20 16:14:46 UTC ---
(In reply to comment #33)
> Using--with-build-config=bootstrap-asan should do that for you.

Seems like I'm doing something wrong, this fails for me after configuring with:

../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install
--enable-languages=c,c++,fortran --disable-multilib --enable-plugins
--disable-werror --with-build-config=bootstrap-asan

/data/vjoost/gnu/binutils-2.23.1/install/bin/ld: error:
/data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.a(asan_new_delete.o):
multiple definition of 'operator new(unsigned long)'
/data/vjoost/gnu/binutils-2.23.1/install/bin/ld:
/data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(new_op.o):
previous definition here
/data/vjoost/gnu/binutils-2.23.1/install/bin/ld: error:
/data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.a(asan_new_delete.o):
multiple definition of 'operator delete(void*)'
/data/vjoost/gnu/binutils-2.23.1/install/bin/ld:
/data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(del_op.o):
previous definition here
collect2: error: ld returned 1 exit status
make[3]: *** [xgcc] Error 1
make[3]: *** Waiting for unfinished jobs....
/data/vjoost/gnu/binutils-2.23.1/install/bin/ld: error:
/data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.a(asan_new_delete.o):
multiple definition of 'operator new(unsigned long)'
/data/vjoost/gnu/binutils-2.23.1/install/bin/ld:
/data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(new_op.o):
previous definition here
/data/vjoost/gnu/binutils-2.23.1/install/bin/ld: error:
/data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.a(asan_new_delete.o):
multiple definition of 'operator delete(void*)'
/data/vjoost/gnu/binutils-2.23.1/install/bin/ld:
/data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(del_op.o):
previous definition here
collect2: error: ld returned 1 exit status
make[3]: *** [xg++] Error 1

[Bug fortran/55341] address-sanitizer and Fortran

[howarth at nitro dot med.uc.edu]

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

--- Comment #35 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-12-20 16:41:58 UTC ---
(In reply to comment #34)

You might try https://github.com/mirrors/gcc/tree/hjl/asan. Perhaps H.J. still
has some patches from his branch that are not committed into gcc trunk.

[Bug fortran/55341] address-sanitizer and Fortran

[hjl.tools at gmail dot com]

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

--- Comment #36 from H.J. Lu <hjl.tools at gmail dot com> 2012-12-20 17:31:04 UTC ---
(In reply to comment #34)
> (In reply to comment #33)
> > Using--with-build-config=bootstrap-asan should do that for you.
> 
> Seems like I'm doing something wrong, this fails for me after configuring with:
> 
> ../gcc/configure --prefix=/data/vjoost/gnu/gcc_trunk/install
> --enable-languages=c,c++,fortran --disable-multilib --enable-plugins
> --disable-werror --with-build-config=bootstrap-asan
> 
> /data/vjoost/gnu/binutils-2.23.1/install/bin/ld: error:
> /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libsanitizer/asan/.libs/libasan.a(asan_new_delete.o):
> multiple definition of 'operator new(unsigned long)'
> /data/vjoost/gnu/binutils-2.23.1/install/bin/ld:
> /data/vjoost/gnu/gcc_trunk/obj/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(new_op.o):

This is PR 55374.

[Bug fortran/55341] address-sanitizer and Fortran

[howarth at nitro dot med.uc.edu]

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

--- Comment #37 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-12-20 17:42:04 UTC ---
H.J.,
   How are you working around PR55371 in your
--with-build-config=bootstrap-asan builds?

[Bug fortran/55341] address-sanitizer and Fortran

[hjl.tools at gmail dot com]

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

--- Comment #38 from H.J. Lu <hjl.tools at gmail dot com> 2012-12-20 17:49:44 UTC ---
(In reply to comment #37)
> H.J.,
>    How are you working around PR55371 in your
> --with-build-config=bootstrap-asan builds?

I configure GCC with --disable-werror.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #39 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-21 08:02:23 UTC ---
Created attachment 29019
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29019
objdump of the offending routine

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #40 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-21 08:03:49 UTC ---
After getting an asan instrumented libgfortran to work (thanks hjl, jakub), I'm
still getting the error message.

==66645== ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff28abdbf0 at pc 0x4472da bp 0x7fff28abdbc0 sp 0x7fff28abdbb8
WRITE of size 4 at 0x7fff28abdbf0 thread T0
    #0 0x4472d9 in __cp_log_handling_MOD_cp_int_to_string
/data/vjoost/gnu/cp2k/cp2k/src/../src/cp_log_handling.F:882
    #1 0x6419b5 in __input_section_types_MOD_section_vals_get_subs_vals
/data/vjoost/gnu/cp2k/cp2k/src/../src/input_section_types.F:1103 (discriminator
2)
    #2 0x48a77b in __f77_interface_MOD_create_force_env
/data/vjoost/gnu/cp2k/cp2k/src/../src/f77_interface.F:817
    #3 0x41566a in __cp2k_runs_MOD_cp2k_run
/data/vjoost/gnu/cp2k/cp2k/src/../src/cp2k_runs.F:307
    #4 0x4167f2 in __cp2k_runs_MOD_run_input
/data/vjoost/gnu/cp2k/cp2k/src/../src/cp2k_runs.F:1133
    #5 0x407289 in cp2k /data/vjoost/gnu/cp2k/cp2k/src/../src/cp2k.F:285
    #6 0x40751a in main /data/vjoost/gnu/cp2k/cp2k/src/../src/cp2k.F:41
    #7 0x351661ecdc in ?? ??:0
==66645== AddressSanitizer CHECK failed:
../../../../gcc/libsanitizer/asan/asan_report.cc:149 "((name_end)) != (0)"
(0x0, 0x0)
    #0 0x7fadc8913d83 in AsanCheckFailed _asan_rtl_

The subroutine is sufficiently simple to be 'sure' there is nothing wrong
there:

  FUNCTION cp_int_to_string(i) RESULT(res)
    INTEGER, INTENT(in)                      :: i
    CHARACTER(len=6)                         :: res

    INTEGER                                  :: iostat
    REAL(KIND=dp)                            :: tmp_r

    IF (i>999999 .OR. i<-99999) THEN
       tmp_r=i
       WRITE (res,fmt='(es6.1)',iostat=iostat) tmp_r
    ELSE
       WRITE (res,fmt='(i6)',iostat=iostat) i   ! line 882
    END IF
    IF (iostat/=0) THEN
       PRINT *,"cp_int_to_string ioerror",iostat
       CALL print_stack(cp_logger_get_default_unit_nr())
    END IF
  END FUNCTION cp_int_to_string

so I'm still thinking the cause is elsewhere (also because -O0 and -O1 show
differences in behavior). I'm attaching the objdump of the module, in case this
is useful. I can also provide build instructions for our package and how to
reproduce the bug, but it is not a small reproducer, unfortunately.

[Bug fortran/55341] address-sanitizer and Fortran

[kcc at gcc dot gnu.org]

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

--- Comment #41 from Kostya Serebryany <kcc at gcc dot gnu.org> 2012-12-21 08:11:19 UTC ---
Wild guess: does Fortran have any custom unwinding mechanism (like exceptions
in C++ or longjmp in C)?
For C/C++ we've spent quite some time to get rid of false stack-buffer-overflow
reports caused by exceptions and longjmp.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #42 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-21 08:18:39 UTC ---
(In reply to comment #41)
> Wild guess: does Fortran have any custom unwinding mechanism (like exceptions
> in C++ or longjmp in C)?
> For C/C++ we've spent quite some time to get rid of false stack-buffer-overflow
> reports caused by exceptions and longjmp.

Fortran doesn't have those naturally, but I don't know if they are generated
somehow by the FE. The -fdump-tree-original of the offending routine looks very
innocent C-like:

cp_int_to_string (character(kind=1)[1:6] & __result, integer(kind=4) .__result,
integer(kind=4) & restrict i)
{
  integer(kind=4) iostat;
  real(kind=8) tmp_r;

  if ((unsigned int) *i + 99999 > 1099998)
    {
      tmp_r = (real(kind=8)) *i;
      {
        struct __st_parameter_dt dt_parm.1;

        dt_parm.1.common.filename =
&"/data/vjoost/gnu/cp2k/cp2k/src/../src/cp_log_handling.F"[1]{lb: 1 sz: 1};
        dt_parm.1.common.line = 880;
        dt_parm.1.internal_unit = (character(kind=1) *) __result;
        dt_parm.1.internal_unit_len = 6;
        dt_parm.1.internal_unit_desc = 0B;
        dt_parm.1.common.unit = 0;
        iostat = 0;
        dt_parm.1.common.iostat = &iostat;
        dt_parm.1.format = &"(es6.1)"[1]{lb: 1 sz: 1};
        dt_parm.1.format_len = 7;
        dt_parm.1.common.flags = 20512;
        _gfortran_st_write (&dt_parm.1);
        _gfortran_transfer_real_write (&dt_parm.1, &tmp_r, 8);
        _gfortran_st_write_done (&dt_parm.1);
      }
    }
  else
    {
      {
        struct __st_parameter_dt dt_parm.2;

        dt_parm.2.common.filename =
&"/data/vjoost/gnu/cp2k/cp2k/src/../src/cp_log_handling.F"[1]{lb: 1 sz: 1};
        dt_parm.2.common.line = 882;
        dt_parm.2.internal_unit = (character(kind=1) *) __result;
        dt_parm.2.internal_unit_len = 6;
        dt_parm.2.internal_unit_desc = 0B;
        dt_parm.2.common.unit = 0;
        iostat = 0;
        dt_parm.2.common.iostat = &iostat;
        dt_parm.2.format = &"(i6)"[1]{lb: 1 sz: 1};
        dt_parm.2.format_len = 4;
        dt_parm.2.common.flags = 20512;
        _gfortran_st_write (&dt_parm.2);
        _gfortran_transfer_integer_write (&dt_parm.2, (integer(kind=4) *) i,
4);
        _gfortran_st_write_done (&dt_parm.2);
      }
    }
  L.2:;
  if (iostat != 0)
    {
      {
        struct __st_parameter_dt dt_parm.3;

        dt_parm.3.common.filename =
&"/data/vjoost/gnu/cp2k/cp2k/src/../src/cp_log_handling.F"[1]{lb: 1 sz: 1};
        dt_parm.3.common.line = 885;
        dt_parm.3.common.flags = 128;
        dt_parm.3.common.unit = 6;
        _gfortran_st_write (&dt_parm.3);
        _gfortran_transfer_character_write (&dt_parm.3, &"cp_int_to_string
ioerror"[1]{lb: 1 sz: 1}, 24);
        _gfortran_transfer_integer_write (&dt_parm.3, &iostat, 4);
        _gfortran_st_write_done (&dt_parm.3);
      }
      {
        integer(kind=4) D.2050;

        D.2050 = cp_logger_get_default_unit_nr (0B, 0B, 0B);
        print_stack (&D.2050);
      }
    }
  L.3:;
}

[Bug fortran/55341] address-sanitizer and Fortran

[kcc at gcc dot gnu.org]

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

--- Comment #43 from Kostya Serebryany <kcc at gcc dot gnu.org> 2012-12-21 08:23:09 UTC ---
false stack-buffer-overflow reports may appear if you have stack unwinding
*somewhere*, not necessary in this routine.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #44 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-22 20:53:41 UTC ---
I have made a some more progress in understanding the failure. I all compile
with
FCFLAGS  = -O1 -g -ffree-form -fsanitize=address -fno-omit-frame-pointer
$(DFLAGS)
I get a binary that passes all our tests (a few thousand tests, and 1MLOC of
code). So I'd say asan works in principle.

However, if I add '-march=corei7' I start seeing many failures:
FCFLAGS  = -O1 -g -ffree-form -fsanitize=address -march=corei7
-fno-omit-frame-pointer $(DFLAGS)

I've also been able to find a single object file that can induce the failures,
but unfortunately the diff in the corresponding .s files is still very large
(~1Mb). The point of failure is not in the object, but in a routine called
after a routine from this object finishes.

[Bug fortran/55341] address-sanitizer and Fortran

[kcc at gcc dot gnu.org]

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

--- Comment #45 from Kostya Serebryany <kcc at gcc dot gnu.org> 2012-12-23 07:44:32 UTC ---
>> The point of failure is not in the object, 
>> but in a routine called after a routine from this object finishes.

What if you remove -fsanitize=address for that single object? 

Your explanation sounds like we are missing some of the return statements in
that routine. Consider this code: 

  foo();
  bar();

foo is the guilty routine, bar is the routine where a failure happens. 

- foo is entered, asan poisons redzones between all stack objects in foo. 
- foo exits, all redzones should be unpoisoned. But due to some bug this does
not happen. 
- bar enters and some of bar's stack variables have the same addresses as
redzones in foo, which are still poisoned. BOOM. 

Just speculating...

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #46 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-23 19:45:10 UTC ---
(In reply to comment #45)
> >> The point of failure is not in the object, 
> >> but in a routine called after a routine from this object finishes.
> 
> What if you remove -fsanitize=address for that single object? 

Indeed no abort if I drop '-fsanitize=address' from that module. 

> Your explanation sounds like we are missing some of the return statements in
> that routine. 
> Just speculating...

could indeed be that this is what happens. What is surprising is that this
seems related to the '-march=corei7' flag.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #29019|0                           |1
        is obsolete|                            |

--- Comment #47 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-24 11:53:57 UTC ---
Created attachment 29041
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29041
good and bad version of the asm of
__qs_dispersion_pairpot_MOD_calculate_dispersion_pairpot

two asm files for the routine that appears to be problematic (
__qs_dispersion_pairpot_MOD_calculate_dispersion_pairpot), compiled once with
and once without -march=native

I'm not particularly versed in asm, but this part of the diff seems like it
could be significant, it is just before the return of the subroutine, and could
be some difference in unpoisoning ?:

35418,35423d35699
<       movq    -10392(%rbp), %rdx
<       movl    $724, %esi
<       testb   $1, %dl
<       je      .L66
<       movb    $0, (%rdx)
< .LVL2656:
35425,35426c35701,35702
<       leaq    1(%rax), %rdx
<       movb    $-45, %sil
---
>       addq    $724, %rax
> .LVL2645:
35428,35460c35704,35708
<       testb   $2, %dl
<       je      .L67
<       movw    $0, (%rdx)
<       addq    $2, %rdx
<       subl    $2, %esi
< .L67:
<       testb   $4, %dl
<       je      .L68
<       movl    $0, (%rdx)
<       addq    $4, %rdx
<       subl    $4, %esi
< .L68:
<       movl    %esi, %eax
<       shrl    $3, %eax
<       movl    %eax, %ecx
<       movl    $0, %eax
<       movq    %rdx, %rdi
<       rep stosq
<       movq    %rdi, %rdx
<       testb   $4, %sil
<       je      .L69
<       movl    $0, (%rdi)
<       addq    $4, %rdx
< .L69:
<       testb   $2, %sil
<       je      .L70
<       movw    $0, (%rdx)
<       addq    $2, %rdx
< .L70:
<       testb   $1, %sil
<       je      .L71
<       movb    $0, (%rdx)
< .L71:
---
>       movq    -10392(%rbp), %rbx
>       movl    $0, (%rbx)
>       addq    $4, -10392(%rbp)
>       cmpq    %rax, -10392(%rbp)
>       jb      .L66
35653c35901

[Bug fortran/55341] address-sanitizer and Fortran

[jakub at gcc dot gnu.org]

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

--- Comment #48 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-08 17:02:13 UTC ---
Author: jakub
Date: Tue Jan  8 17:01:58 2013
New Revision: 195025

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195025
Log:
    PR fortran/55341
    * asan.c (asan_clear_shadow): New function.
    (asan_emit_stack_protection): Use it.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/asan.c

[Bug fortran/55341] address-sanitizer and Fortran

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #49 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-08 17:17:26 UTC ---
Fixed.

[Bug fortran/55341] address-sanitizer and Fortran

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #50 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2013-01-08 17:26:19 UTC ---
(In reply to comment #49)
> Fixed.

Thanks, for fixing this issue.

Shouldn't the PR be kept open to look into what I'm rather sure is a
miscompilation as discussed in comment #44 to #47 ?