http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #50 from Joost VandeVondele
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #48 from Jakub Jelinek 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 (asa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
Joost VandeVondele changed:
What|Removed |Added
Attachment #29019|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #46 from Joost VandeVondele
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 remov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #45 from Kostya Serebryany 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #44 from Joost VandeVondele
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 ge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #43 from Kostya Serebryany 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #42 from Joost VandeVondele
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 ti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #41 from Kostya Serebryany 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-buffe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #40 from Joost VandeVondele
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #39 from Joost VandeVondele
2012-12-21 08:02:23 UTC ---
Created attachment 29019
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29019
objdump of the offending routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #38 from H.J. Lu 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #37 from Jack Howarth 2012-12-20
17:42:04 UTC ---
H.J.,
How are you working around PR55371 in your
--with-build-config=bootstrap-asan builds?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #36 from H.J. Lu 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #35 from Jack Howarth 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #34 from Joost VandeVondele
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 wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
Jack Howarth changed:
What|Removed |Added
CC||howarth at nitro dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #32 from Joost VandeVondele
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 crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #31 from Joost VandeVondele
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-poi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #30 from Joost VandeVondele
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 crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #29 from Joost VandeVondele
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 DescribeAdd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #28 from Jakub Jelinek 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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #27 from Kostya Serebryany 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,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
Joost VandeVondele changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #25 from Kostya Serebryany 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #24 from Joost VandeVondele
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 debugg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #23 from Jakub Jelinek 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 *,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #22 from Joost VandeVondele
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #21 from Jakub Jelinek 2012-12-19
08:52:43 UTC ---
(In reply to comment #17)
> For whatever reason the fortran code is touching asan's shadow:
> Address 0x16742e2c is located in the high shadow area.
>
> What is __qs_e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #20 from Kostya Serebryany 2012-12-19
08:51:54 UTC ---
For whatever reason the fortran code is touching asan's shadow:
Address 0x16742e2c is located in the high shadow area.
What is __qs_environment_MOD_qs_init doing?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #19 from Joost VandeVondele
2012-12-19 08:48:47 UTC ---
(In reply to comment #17)
> For whatever reason the fortran code is touching asan's shadow:
> Address 0x16742e2c is located in the high shadow area.
>
> What is _
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #18 from Jakub Jelinek 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
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #17 from Kostya Serebryany 2012-12-19
08:37:21 UTC ---
For whatever reason the fortran code is touching asan's shadow:
Address 0x16742e2c is located in the high shadow area.
What is __qs_environment_MOD_qs_init doing?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #16 from Joost VandeVondele
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 testcas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #15 from Joost VandeVondele
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=addres
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #14 from Jakub Jelinek 2012-12-10
13:41:16 UTC ---
(In reply to comment #11)
> > >> ./a.out | python ./asan_symbolize.py
> > I> =
> ==45957== ERROR: AddressSaniti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #13 from Joost VandeVondele
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_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #12 from Kostya Serebryany 2012-12-10
13:28:12 UTC ---
Does pure addr2line work?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #11 from Joost VandeVondele
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. Al
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #10 from Kostya Serebryany 2012-12-10
13:20:51 UTC ---
>> ./a.out | python ./asan_symbolize.py
It should be
./a.out 2>&1 | python ./asan_symbolize.py
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #9 from Joost VandeVondele
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 pytho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
Kostya Serebryany changed:
What|Removed |Added
CC||kcc at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #7 from Joost VandeVondele
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 hav
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
--- Comment #6 from Jakub Jelinek 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-intrin
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 s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Co
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
50 matches
Mail list logo
