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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469
Bug #: 55469
Summary: memory leak on read with istat.ne.0
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
--- Comment #33 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-11-29 07:30:58 UTC ---
(In reply to comment #31)
As for the backport, I think the patch is absolutely risk-free, and it should
have been approved for 4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-11-29 10:23:13 UTC ---
Is that for the more complete patch posted here:
http://gcc.gnu.org/ml/fortran/2012-11/msg00083.html
BTW, wrong PR number
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55213
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Bug #: 5
Summary: [4.8 Regression] miscompilation at -O2
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
Bug #: 55561
Summary: TSAN crashes for Fortran
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-02 10:11:34 UTC ---
(In reply to comment #4)
Hmm, this seems to be caused by
Forced statement unreachable: pretmp_516 = coef_x[pretmp_515];
Forced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-03 07:41:29 UTC ---
(In reply to comment #5)
Are you testing with all the pending unreviewed TSAN fixes?
Ah.. no, I will retest once they are in trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55585
Bug #: 55585
Summary: compile time hog at -O1 -fboundscheck -g
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55585
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55585
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-04 09:39:12 UTC ---
(In reply to comment #2)
It's probably the very many calls. At -O2 VRP runs and eventually removes
most of them.
Unfortunately
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55585
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-04 10:43:10 UTC ---
Interestingly, the magic switch is -fstrict-aliasing... 20x speedup. for a
Fortran code quite a surprise.
time gfortran -c -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591
Bug #: 55591
Summary: strict-aliasing Fortran
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55585
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-04 11:56:59 UTC ---
(In reply to comment #5)
GFortran could enable strict-aliasing unconditionally if it likes (even
at -O0).
I have now opened
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-10 12:43:42 UTC ---
Now, compilation seems to go fine, but I'm not figuring out how to do it
properly so it works at run time. I have:
gfortran -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-10 12:53:22 UTC ---
(In reply to comment #8)
gfortran -g -fsanitize=thread -fPIC -pie PR55561.f90
Thanks! yields the proper warning as expected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #11 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-10 12:59:09 UTC ---
(In reply to comment #10)
Is is a correct report? Or false positive?
This is a correct report for the testcase in comment #0 (as J
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
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 21 | python ./asan_symbolize.py
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #13 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-10 15:55:50 UTC ---
(In reply to comment #12)
That's great that gcc tsan works for Fortran/OpenMP out of the box!
I'm afraid it yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Summary|TSAN crashes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2011-07-09 09:36:18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #90 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-13 15:13:26 UTC ---
(In reply to comment #89)
Just to repeat, the ICEs are with checking enabled only (but possibly cover up
for wong-code).
I'm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594
--- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-14 08:47:14 UTC ---
(In reply to comment #7)
FWIW, you can get a backtrace by calling the ABORT intrinsic instead.
thanks... I'm using that now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
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
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 0x16742e2c is located
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
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
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/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
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
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55371
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-20 19:55:32 UTC ---
Thanks now bootstrap completes.
It seems to me that libgfortran is not built with -fsanitize=address despite
--with-build-config
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374
--- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-20 20:05:05 UTC ---
(In reply to comment #8)
(In reply to comment #7)
bootstrap-asan is for bootstrapping GCC with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55374
--- Comment #11 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-20 20:43:28 UTC ---
(In reply to comment #10)
cd obj*/x86_64*/libgfortran; make clean; \
make CFLAGS=-std=gnu99 -g -O2 -fsanitize=address
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789
Bug #: 55789
Summary: Needless realloc
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49241
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #15 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-25 19:30:15 UTC ---
(In reply to comment #13)
(In reply to comment #12)
That's great that gcc tsan works for Fortran/OpenMP out of the box!
I'm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #16 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-25 20:23:07 UTC ---
many things appear to work fine, but seemingly parallel do loops with a dynamic
schedule generate warnings in libgomp. I also seem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #17 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-26 19:34:29 UTC ---
Another testcase that yields warnings with a sanitized libgomp:
!$omp parallel default(none) private(i,j,k)
!$omp do collapse(3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #22 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-30 09:03:15 UTC ---
(In reply to comment #18)
The obvious solution to this seems to be that also the OMP runtime (libgomp)
must be compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #25 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-30 14:52:51 UTC ---
(In reply to comment #24)
For testing you can comment out first 2 lines of gomp_ptrlock_get(). That
should fix the race in libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #27 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-12-30 19:57:24 UTC ---
(In reply to comment #24)
For testing you can comment out first 2 lines of gomp_ptrlock_get(). That
should fix the race in libgomp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #28 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2013-01-01 17:13:39 UTC ---
(In reply to comment #26)
For config/linux/ptrlock the changes are:
[...]
Following your suggestions, I applied the following
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #32 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2013-01-07 21:35:25 UTC ---
(In reply to comment #30)
The formatting in the patch is wrong (multiple issues).
I've tried to fix them in the version below
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #34 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2013-01-10 11:26:23 UTC ---
(In reply to comment #33)
Can you sent it to review? You can also mention that it fixes issue 40362.
I had a closer look
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56054
Bug #: 56054
Summary: f951: internal compiler error: in gfc_free_namespace,
at fortran/symbol.c:3337
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56052
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56054
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50627
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Summary|Error recovery: ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12821
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2008-12-08 19:34:48
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56063
Bug #: 56063
Summary: last reconfirmed : now
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56063
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56159
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #41 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Richard Biener from comment #40)
What's the status on this?
I checked comment #34 and a number of the bugs marked as dup, and they all seem
to pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57461
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Richard Biener from comment #6)
I can't reproduce it with the reduced testcase, so fixed?
Magically fixed, also the original ones.. maybe add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58290
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
This appears to have been fixed / gone latent between r204377 and r204433 (~
Nov 6th.)
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
gcc version 4.9.0 20131106 (experimental) [trunk revision 204433] (GCC) yields
the following internal compiler error:
f951: internal compiler error: Segmentation fault
0x9fee4f
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Created attachment 31172
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31172action=edit
reduced testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59020
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
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
A recent regression, likely introduced between r204496
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Testcase:
MODULE M1
TYPE T1
INTEGER, PRIVATE :: I=0
END TYPE T1
TYPE T2
TYPE(T1) :: D1
END TYPE T2
TYPE(T2), PARAMETER :: D2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59060
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59059
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Clearly an enhancement request, but it would be great to have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59060
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
Thanks, I indeed start thinking gfortran has it right.
As a small variant:
MODULE M1
TYPE T1
INTEGER, PRIVATE :: I=0
END TYPE T1
TYPE T2
TYPE(T1) :: D1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59060
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #1)
It should be there already:
triggering my report was indeed some vague memory that the recent merge would
bring
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
That's great... works even for Fortran code :-)
One more question the docs mention:
In performance-critical scenarios, LSan can also be used without ASan
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
--- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Marc Glisse from comment #7)
(In reply to Joost VandeVondele from comment #6)
Marc, I think your recently posted patch:
http://gcc.gnu.org/ml/gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
--- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Marc Glisse from comment #9)
Ok. If you used __builtin_abort instead of _gfortran_os_error, I think my
current patch would handle it. It is hard
1 - 100 of 713 matches
Mail list logo
