http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55469
--- Comment #9 from Joost VandeVondele
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 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852
Joost VandeVondele changed:
What|Removed |Added
CC||grosser at gcc dot gnu.org
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
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56244
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
||Joost.VandeVondele at mat
||dot ethz.ch
--- Comment #4 from Joost VandeVondele
2013-02-18 18:21:08 UTC ---
(In reply to comment #2)
> Created attachment 29483 [details]
> 3 *.f90 files and script to run them
confirm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56378
--- Comment #5 from Joost VandeVondele
2013-02-18 18:48:28 UTC ---
simplified testcase:
module t
use, intrinsic :: iso_c_binding
interface fvec2vec
module procedure int_fvec2vec
end interface
contains
function int_fvec2vec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309
--- Comment #48 from Joost VandeVondele
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 with -gdwarf-3 , with some luck
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: P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56674
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
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
CC||Joost.VandeVondele at mat
||dot ethz.ch
Resolution||FIXED
--- Comment #3 from Joost VandeVondele
2013-03-22 07:01:03 UTC ---
fixed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56688
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Joost VandeVondele changed:
What|Removed |Added
Last reconfirmed|2012-12-13 09:36:18 |2012-03-24
--- Comment #93
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
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706
Joost VandeVondele changed:
What|Removed |Added
Known to work||4.7.2
Summary|fa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37150
--- Comment #15 from Joost VandeVondele
2013-03-27 12:53:16 UTC ---
Created attachment 29738
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29738
maybe smaller testcase version ?
Attached is what I think is roughly the smallest ker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591
--- Comment #5 from Joost VandeVondele
2013-03-29 06:13:38 UTC ---
(In reply to comment #3)
> Untested (but successfully compiled) patch:
>
> --- a/gcc/fortran/options.c
> +++ b/gcc/fortran/options.c
> @@ -170,4 +170,6 @@ gfc_init_opti
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
Joost VandeVondele changed:
What|Removed |Added
Summary|TSAN: Fortran/OMP yields|TSAN: provide a TSAN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56063
--- Comment #9 from Joost VandeVondele
2013-03-29 08:12:23 UTC ---
(In reply to comment #7)
> What I could do is to hide the calendar button and add a "Now" link instead.
I think this would be really appreciated.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021
Joost VandeVondele changed:
What|Removed |Added
Depends on||37150
--- Comment #16 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56378
Joost VandeVondele changed:
What|Removed |Added
Summary|[4.6/4.7/4.8/4.9|[4.6/4.7/4.8 Regression]
CC||Joost.VandeVondele at mat
||dot ethz.ch
--- Comment #5 from Joost VandeVondele
2013-03-29 08:29:53 UTC ---
still versioning for trunk 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708
--- Comment #22 from Joost VandeVondele
2013-03-29 08:33:31 UTC ---
Improved in part by
http://gcc.gnu.org/ml/fortran/2013-03/msg00143.html
as r197124 for 4.9.0
CC||Joost.VandeVondele at mat
||dot ethz.ch
--- Comment #22 from Joost VandeVondele
2013-03-29 08:40:06 UTC ---
Still affects trunk 4.9.0
values => d(:)%value
^
0x99687f crash_signal
../../gcc/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119
Joost VandeVondele changed:
What|Removed |Added
Last reconfirmed|2011-11-14 00:00:00 |2013-03-29
--- Comment #10
CC||Joost.VandeVondele at mat
||dot ethz.ch
Known to fail||4.9.0
--- Comment #16 from Joost VandeVondele
2013-03-29 08:58:42 UTC ---
(In reply to comment #6)
> Function is sta
CC||Joost.VandeVondele at mat
||dot ethz.ch
--- Comment #2 from Joost VandeVondele
2013-03-29 09:04:29 UTC ---
and 4.9.0
CC||Joost.VandeVondele at mat
||dot ethz.ch
Resolution||FIXED
--- Comment #11 from Joost VandeVondele
2013-03-29 09:07:25 UTC ---
Fixed.
CC||Joost.VandeVondele at mat
||dot ethz.ch
Resolution||DUPLICATE
--- Comment #2 from Joost VandeVondele
2013-03-29 09:11:10 UTC ---
This is at best a dup of PR40362, and likely
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362
--- Comment #15 from Joost VandeVondele
2013-03-29 09:11:10 UTC ---
*** Bug 50175 has been marked as a duplicate of this bug. ***
CC||Joost.VandeVondele at mat
||dot ethz.ch
Resolution||FIXED
--- Comment #2 from Joost VandeVondele
2013-03-29 09:13:28 UTC ---
seems fixed.
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: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56776
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
CC||Joost.VandeVondele at mat
||dot ethz.ch
--- Comment #12 from Joost VandeVondele
2013-03-29 09:27:23 UTC ---
comment #11 still fails on 4.9 trunk.
CC||Joost.VandeVondele at mat
||dot ethz.ch
Blocks||38654
--- Comment #14 from Joost VandeVondele
2013-03-29 09:46:53 UTC ---
The code in comment #0 is actually a frontend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
CC||Joost.VandeVondele at mat
||dot ethz.ch
Resolution||FIXED
--- Comment #10 from Joost VandeVondele
2013-03-29 10:20:31 UTC ---
The original problem is fixed. The problem in
CC||Joost.VandeVondele at mat
||dot ethz.ch
Depends on||34640
Resolution||DUPLICATE
Known to fail||4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34640
Joost VandeVondele changed:
What|Removed |Added
Blocks||39304
CC|
CC||Joost.VandeVondele at mat
||dot ethz.ch
--- Comment #21 from Joost VandeVondele
2013-03-29 10:50:49 UTC ---
So, the testcase in comment #14 is indeed still (4.9.0) yielding the 324
multiplies for subroutine S2
CC||Joost.VandeVondele at mat
||dot ethz.ch
Blocks||51119
Summary|missing transformations |graphite with loop blocking
|lead to poorly optimized
CC||Joost.VandeVondele at mat
||dot ethz.ch
Resolution||FIXED
--- Comment #3 from Joost VandeVondele
2013-03-29 11:09:49 UTC ---
testcase doesn't compile with trunk anymo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56770
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56816
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
||2013-04-08
CC||Joost.VandeVondele at mat
||dot ethz.ch
Known to work||4.7.2
Summary|Incorrect SUM evaluation, |[4.8/4.9 Regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
--- Comment #11 from Joost VandeVondele
2013-04-17 19:36:45 UTC ---
With these patches in, parallel compilation of multi-file cp2k becomes
significantly faster. Time for a full build goes from 70s to 50s. I think that
in a parallel build t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57071
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57071
--- Comment #4 from Joost VandeVondele
2013-04-26 07:12:04 UTC ---
(In reply to comment #3)
> As James Van Buskirk pointed out, the algorithm will fail if k < 0.
note that in the case of k being a loop index, there will be pretty good r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57089
Bug #: 57089
Summary: [4.9 Regression] ICE in verify_loop_structure, at
cfgloop.c:1647
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160
Bug #: 57160
Summary: short-circuit IF only with -ffrontend-optimize
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancemen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
Bug #: 57192
Summary: [4.9 Regression] miscompilation at -O3
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
--- Comment #3 from Joost VandeVondele
2013-05-07 18:54:55 UTC ---
(In reply to comment #2)
> Created attachment 30047 [details]
> Proposed patch
I'll give it a try.
Meanwhile, this might be an easy way to get the testcase (and rena
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
--- Comment #4 from Joost VandeVondele
2013-05-07 19:01:56 UTC ---
BTW, on trunk:
../../gcc/gcc/gimple-ssa-strength-reduction.c: In function ‘void
analyze_candidates_and_replace()’:
../../gcc/gcc/gimple-ssa-strength-reduction.c:3394:17: warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
--- Comment #5 from Joost VandeVondele
2013-05-07 19:16:31 UTC ---
Current trunk (without the patch) seems to fix also the original problem. At
least for this case, the proposed patch seems not necessary. I think the bug
can be closed as f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
Joost VandeVondele changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
--- Comment #10 from Joost VandeVondele
2013-05-08 06:18:54 UTC ---
(In reply to comment #9)
> On x86_64-apple-darwin10.8.0 at revision 198697 with the patch at
> http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00367.html the test executes
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
--- Comment #12 from Joost VandeVondele
2013-05-08 13:03:59 UTC ---
Reduced testcase that still triggers the valgrind warning during compilation:
MODULE orbital_pointers
INTEGER, DIMENSION(:,:), ALLOCATABLE :: soset
CONTAINS
SUBR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
--- Comment #16 from Joost VandeVondele
---
(In reply to Bill Schmidt from comment #15)
> I was able to download your code, and I can't reproduce the problem on
> powerpc64-unknown-linux-gnu with current trunk.
I still see the valgrind warning f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57192
Joost VandeVondele changed:
What|Removed |Added
Status|REOPENED|RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269
Bug #: 54269
Summary: [4.8 Regression] memory usage too large when
optimizing
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269
--- Comment #1 from Joost VandeVondele
2012-08-15 09:57:13 UTC ---
seems like it is triggered by unrolling, using
gfortran -O2 -funroll-loops -ffree-form -D__LIBINT hfx_contraction_methods.F
is enough. A bt at the first point where memory seems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269
--- Comment #3 from Joost VandeVondele
2012-08-15 10:59:38 UTC ---
(In reply to comment #2)
> Well, that's ENABLE_CHECKING code. Are you sure 4.7 built with
> --enable-checking=yes does not exhibit this behavior?
I'm pretty sure this was not ob
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269
--- Comment #4 from Joost VandeVondele
2012-08-15 11:37:51 UTC ---
(In reply to comment #2)
> Well, that's ENABLE_CHECKING code. Are you sure 4.7 built with
> --enable-checking=yes does not exhibit this behavior?
it looks like --enable-checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269
--- Comment #5 from Joost VandeVondele
2012-08-16 05:29:46 UTC ---
4.7 configured with --enable-checking=yes also needs < 1.0Gb.
for a checking enable compiler, time went from 25s with 4.7 to 1m27s with 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269
--- Comment #7 from Joost VandeVondele
2012-08-22 07:43:30 UTC ---
Fixed for current trunk, maybe a dup of PR54332
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852
--- Comment #5 from Joost VandeVondele
2012-08-22 11:58:00 UTC ---
simplified testcase and some analysis:
SUBROUTINE build_d_tensor_gks(d5f,v,d5)
INTEGER, PARAMETER :: dp=8
REAL(KIND=dp), DIMENSION(3, 3, 3, 3, 3), &
INTENT(OUT) :
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708
Joost VandeVondele changed:
What|Removed |Added
Depends on||40958
--- Comment #21 from Joost Van
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #70 from Joost VandeVondele
2012-08-28 11:28:06 UTC ---
(In reply to comment #69)
> Is there still a problem here?
for current trunk and the original testcase, timings are reasonable at -O0 -O1
-O2, but very long at -O3 (>60min):
re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #71 from Joost VandeVondele
2012-08-28 14:54:54 UTC ---
The -O3 compile is 3h later still running and needs >20Gb of RAM. The issue
seems now to be variable_tracking_main
#0 0x00b7b8ce in dataflow_set_preserve_mem_locs(void*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Joost VandeVondele changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/fortr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54389
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #1 from Joost VandeVondele
2012-09-12 11:41:12 UTC ---
the two revisions lead to a lot of changes, all these files differ in their
disassembled form:
1admm_methods.o Files f1 and f2 differ
2atom_fit.o Files f1 and f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #2 from Joost VandeVondele
2012-09-12 20:11:24 UTC ---
some progress.. the object file that leads to wrong results is
parallel_rng_types.o. I'll see if I can get some further insight.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #4 from Joost VandeVondele
2012-09-12 20:26:49 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > some progress.. the object file that leads to wrong results is
> > parallel_rng_types.o. I'll see if I can get some further
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #5 from Joost VandeVondele
2012-09-12 20:46:05 UTC ---
Created attachment 28179
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28179
testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #6 from Joost VandeVondele
2012-09-12 20:50:40 UTC ---
The testcase illustrates the issue, compiling as
gfortran -c -O1 test.f90 -fdump-tree-optimized
shows that rn32 is only called once from rn53, whereas the proper number would
be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #7 from Joost VandeVondele
2012-09-12 20:58:23 UTC ---
(In reply to comment #6)
> So I guess rn32 is incorrectly marked as pure.
which indeed is also visible in the .mod file:
'rn32' 'parallel_rng_types' '' 1 ((PROCEDURE UNKNOWN-INT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #11 from Joost VandeVondele
2012-09-13 12:31:03 UTC ---
(In reply to comment #10)
> Draft patch (replaces the one in comment 9):
>
> --- a/gcc/fortran/resolve.c
> +++ b/gcc/fortran/resolve.c
> @@ -13567,6 +13572,5 @@ gfc_impure_varia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #16 from Joost VandeVondele
2012-09-14 05:57:51 UTC ---
(In reply to comment #15)
> FIXED on the trunk - and on the 4.6/4.7 branch. Sorry for the breakage!
Thank you and other gcc experts for regularly fixing issues quickly and
profe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54634
Bug #: 54634
Summary: [4.8 Regression] miscompilation with -O3
-ftree-loop-distribution
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54634
--- Comment #2 from Joost VandeVondele
2012-09-20 10:15:57 UTC ---
(In reply to comment #1)
> Retry with PR54629 fix?
after applying the patch mentioned above, the testcase still fails. The failure
is also older than the commit mentione
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54634
--- Comment #5 from Joost VandeVondele
2012-09-20 13:06:50 UTC ---
(In reply to comment #4)
> Ah, binomial () is pure.
In this case, it was presumably triggered by Tobias' changes for PR54389.
binomial() has not been declared pure in th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #83 from Joost VandeVondele
2012-09-26 06:42:59 UTC ---
Mikael, any progress on this one (BTW, the PR is not yet assigned)? It would be
great to have LTO work with Fortran in 4.8 (especially with all the inlining
improvements).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54749
Bug #: 54749
Summary: libbacktrace
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54751
Bug #: 54751
Summary: [4.8 Regression] slow compile time with rtl loop
unroller
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54749
--- Comment #2 from Joost VandeVondele
2012-09-29 17:34:04 UTC ---
(In reply to comment #1)
> You filed this against the "go" component, but it seems that Go is not
> involved. Is that right? This is just about a backtrace printed after
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54758
Bug #: 54758
Summary: accessing gcc builtins from fortran
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #86 from Joost VandeVondele
2012-09-30 12:30:43 UTC ---
(In reply to comment #84)
LTO might work for many codes, as using allocatables in derived types was not
standard Fortran90 (IIRC) and appears needed to trigger the bug.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54751
--- Comment #4 from Joost VandeVondele
2012-10-02 10:39:41 UTC ---
More reasonable with -enable-checking=release
4.8(checking=yes):~10min
4.8(checking=release): 1min28s.
4.7 : 0min58s
maybe some of the ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
Joost VandeVondele changed:
What|Removed |Added
CC||simonb at google dot com
-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37150
Joost VandeVondele changed:
What|Removed |Added
Last reconfirmed|2009-08-06 07:54:57 |2012-10-06 7:54:57
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
--- Comment #4 from Joost VandeVondele
2012-10-06 12:42:13 UTC ---
(In reply to comment #3)
>
> 2012-10-06 Tobias Schlüter
>
> PR fortran/51727
> * module.c (write_generic): Traverse tree in left-to-right order.
If tested that thi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
--- Comment #5 from Joost VandeVondele
2012-10-06 12:46:36 UTC ---
Created attachment 28373
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28373
bad module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
--- Comment #6 from Joost VandeVondele
2012-10-06 12:47:19 UTC ---
Created attachment 28374
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28374
good module
1 - 100 of 713 matches
Mail list logo
