[Bug rtl-optimization/56776] New: valgrind errors within ira

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56776 Bug #: 56776 Summary: valgrind errors within ira Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority:

[Bug rtl-optimization/56776] [4.8/4.9 Regression] valgrind errors within ira

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

[Bug fortran/45337] gfortran accepts pointer initialization of DT dummy arguments w/ INTENT(OUT)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45337 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2010-08-19 09:47:08

[Bug fortran/41137] inefficient zeroing of an array

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2009-11-01 16:21:21

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

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

[Bug fortran/40958] module files too large

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

[Bug fortran/36933] unneeded temporary with derived type containing an array as argument

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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

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

[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer

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

[Bug tree-optimization/40168] missing unrolling/scalarization/reassoc/free

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2009-12-18 14:45:13

[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2006-04-23 17:57:20

[Bug debug/35118] ICE in mem_loc_descriptor, at dwarf2out.c:8974

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

[Bug tree-optimization/56770] Partial sums loop optimization

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

[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel

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

[Bug middle-end/37150] basic-block vectorization misses some unrolled loops

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37150 --- Comment #15 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-27 12:53:16 UTC --- Created attachment 29738 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29738 maybe smaller testcase version ? Attached

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2012-12-13 09:36:18

[Bug lto/56706] New: failure building CP2K at -flto -O3

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706 Bug #: 56706 Summary: failure building CP2K at -flto -O3 Classification: Unclassified Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal

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

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

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

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

[Bug middle-end/56681] [4.9 Regression] internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:1008

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

[Bug tree-optimization/56688] Fortran save statement prevents loop vectorization.

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

[Bug fortran/56674] New: ICE in check_sym_interfaces

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56674 Bug #: 56674 Summary: ICE in check_sym_interfaces Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority:

[Bug fortran/56674] [4.7/4.8/4.9 Regression] ICE in check_sym_interfaces

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

[Bug middle-end/56681] New: [4.9 Regression] internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:1008

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56681 Bug #: 56681 Summary: [4.9 Regression] internal compiler error: tree check: expected ssa_name, have var_decl in verify_ssa, at tree-ssa.c:1008 Classification: Unclassified

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

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

[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #48 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-02-22 13:55:16 UTC --- (In reply to comment #47) Interestingly, the symbolization/debuginfo seems to be completely broken :( I've tried compiling

[Bug fortran/56378] gfortran internal compiler error

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

[Bug fortran/56378] gfortran internal compiler error

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56378 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-02-18 18:48:28 UTC --- simplified testcase: module t use, intrinsic :: iso_c_binding interface fvec2vec module procedure int_fvec2vec end

[Bug driver/56244] -O3 should imply -funroll-loops

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

[Bug tree-optimization/53852] [4.8 Regression] -ftree-loop-linear: large compile time / memory usage

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

[Bug driver/56244] New: -O3 should imply -funroll-loops

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56244 Bug #: 56244 Summary: -O3 should imply -funroll-loops Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug fortran/55469] memory leak on read with istat.ne.0

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469 --- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-02-07 05:57:43 UTC --- This http://gcc.gnu.org/ml/gcc/2013-02/msg00068.html seems the same/similar issue. Was there consensus about the patch ?

[Bug libgomp/56159] config/linux/ptrlock.c lacks acquire barrier

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

[Bug web/12821] dead link on onlinedocs/gccint/Top-Level.html

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

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

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

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

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

[Bug fortran/56054] New: f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3337

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

[Bug fortran/56052] [4.7/4.8 Regression] ICE in omp_add_variable, at gimplify.c:5606

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

[Bug fortran/50627] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct

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

[Bug fortran/56054] [4.6/4.7/4.8 Regression] f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.c:3337

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

[Bug fortran/50627] [4.6/4.7/4.8 Regression] Error recovery: ICE in gfc_free_namespace after diagnosing missing end of construct

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

[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives

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

[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives

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

[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives

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

[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives

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

[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives

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

[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives

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

[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives

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

[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55789] New: Needless realloc

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

[Bug fortran/49241] memory leak with lhs realloc of zero-sized array

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug sanitizer/55371] [asan] False -Werror=uninitialized

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

[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work

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

[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work

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

[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work

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

[Bug sanitizer/55374] [asan] -static-libasan -static-libstdc++ doesn't work

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55591] strict-aliasing Fortran

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

[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace

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

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2011-07-09 09:36:18

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

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

[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace

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

[Bug sanitizer/55561] TSAN: Fortran/OMP 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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug sanitizer/55561] TSAN crashes for Fortran

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

[Bug sanitizer/55561] TSAN crashes for Fortran

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

[Bug sanitizer/55561] TSAN crashes for Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug fortran/55341] address-sanitizer and Fortran

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

[Bug sanitizer/55561] TSAN crashes for Fortran

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

[Bug middle-end/55585] New: compile time hog at -O1 -fboundscheck -g

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

[Bug debug/55585] compile time hog at -O1 -fboundscheck -g

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

[Bug debug/55585] compile time hog at -O1 -fboundscheck -g

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

[Bug debug/55585] compile time hog at -O1 -fboundscheck -g

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

[Bug fortran/55591] New: strict-aliasing Fortran

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

[Bug debug/55585] compile time hog at -O1 -fboundscheck -g

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

[Bug sanitizer/55561] New: TSAN crashes for Fortran

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

[Bug sanitizer/55561] TSAN crashes for Fortran

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

[Bug middle-end/55555] [4.8 Regression] miscompilation at -O2 (tree-pre?)

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

[Bug sanitizer/55561] TSAN crashes for Fortran

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

[Bug middle-end/55555] New: [4.8 Regression] miscompilation at -O2

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

<    1   2   3   4   5   6   7   8   >