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=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=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
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=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=51727
--- Comment #32 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-11-09 10:05:18 UTC ---
If you can use the additional free time to walk over to my
brother's office, then please say 'Hi' to him. Otherwise the faculty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55238
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 #30 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-11-09 07:31:28 UTC ---
(In reply to comment #29)
I committed the C-only version of the patch as the issues mentioned in comment
#27 couldn't be addressed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
URL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55099
Bug #: 55099
Summary: Surprising 'PROCEDURE attribute conflicts with INTENT
attribute' error
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55099
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54991
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31119
--- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-10-20 14:59:08 UTC ---
(In reply to comment #7)
Hi,
can someone fortran aware please double-check that the tests
* gfortran.dg/bounds_check_9.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54991
Bug #: 54991
Summary: [LRA] internal compiler error: in lra_assign, at
lra-assigns.c:1361
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54991
--- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-10-19 18:58:31 UTC ---
Created attachment 28495
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28495
testcase, including source, .mod and .gcda files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54967
Bug #: 54967
Summary: [4.8 Regression] ICE in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:55
Classification: Unclassified
Product: gcc
Version: 4.8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54967
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
--- Comment #25 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-10-15 14:14:12 UTC ---
Just to provide some additional numbers on how important this patch is for
practical development (and of course to +1 on backports
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
--- Comment #18 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-10-13 08:13:14 UTC ---
(In reply to comment #14)
Created attachment 28425 [details]
Patch for testing
thanks... now repeated CP2K compiles give
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
--- Comment #23 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-10-13 12:28:12 UTC ---
(In reply to comment #22)
Created attachment 28440 [details]
patch that doesn't use c++
I've tested the patch with (an older
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
--- Comment #24 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-10-13 12:45:11 UTC ---
(In reply to comment #23)
I've tested the patch with (an older version of) the 4.7 branch, and it works
fine for CP2K
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37150
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2009-08-06 07:54:57
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-10-06 12:42:13 UTC ---
(In reply to comment #3)
2012-10-06 Tobias Schlüter t...@gcc.gnu.org
PR fortran/51727
* module.c (write_generic): Traverse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
--- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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 Joost.VandeVondele at mat dot ethz.ch
2012-10-06 12:47:19 UTC ---
Created attachment 28374
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28374
good module
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-10-06 12:48:39 UTC ---
The main difference between 'good' and 'bad' seems to be the 'header' lines
bad:
()
(('arch_topology
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
--- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-10-06 12:52:09 UTC ---
(In reply to comment #3)
Created attachment 28372 [details]
Candidate patch
actually... looking at the patch, don't you need
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54751
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
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 Joost.VandeVondele at mat dot ethz.ch
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
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54749
--- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #83 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54634
--- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54634
--- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #11 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #16 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54389
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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 Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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 Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54556
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
URL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #70 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #71 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Depends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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 Joost.VandeVondele at mat dot ethz.ch
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269
--- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54269
--- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
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=53852
Bug #: 53852
Summary: -ftree-loop-linear: large compile time / memory usage
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-07-04 12:17:47 UTC ---
To fill in the X, 130 Gb is not sufficient for this testcase.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53835
Bug #: 53835
Summary: in tree isl / cloog build fails
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51179
--- Comment #11 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-06-30 11:26:59 UTC ---
It looks like this problem is solved in the current 4.7 and 4.8 branches. At
least on an avx machine, the best performance found by the code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47657
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47341
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2011-01-18 11:21:06
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40194
--- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-06-29 14:14:16 UTC ---
this testcase now looks optimized (at least the optimized dump contains return
1; as expected). I guess this can be closed ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40282
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41737
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47298
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2008-01-23 11:27:01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41737
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46532
--- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-06-29 18:46:13 UTC ---
*** Bug 41737 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-06-28 11:58:20 UTC ---
Janne, have you had a chance to look at this ? For larger matrices MATMMUL is
really slow. Anything that includes even the most basic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #60 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-06-15 15:26:20 UTC ---
(In reply to comment #59)
There should be no compile performance problems in expand anymore.
The alias stmt walker as used from IPA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #12 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-06-06 11:32:08 UTC ---
It doesn't quite seem to work for this simple Fortran testcase yet
SUBROUTINE S(a,N)
INTEGER :: N,a(N)
a=1
END SUBROUTINE S
(works
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081
--- Comment #14 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-06-06 11:54:22 UTC ---
(In reply to comment #13)
Well, you can't transform this to a memset ;)
blush
things work as advertised for correct testcases... thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Summary|[4.5/4.6/4.7/4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-05-30 12:31:18 UTC ---
(In reply to comment #2)
Well, I think this is a valgrind issue and not a real leak. Whether you
want to optimize code for the non-NULL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-05-30 14:37:09 UTC ---
(In reply to comment #4)
You say not doing free (0) leaks memory? What OS is this on?
I'm observing on a Linux box that :
MODULE TEST
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #53 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-05-29 07:45:36 UTC ---
For the original testcase I have for trunk (gcc version 4.8.0 20120516
(experimental) [trunk revision 187595] (GCC)) very reasonable times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53521
Bug #: 53521
Summary: Memory leak with zero sized array constructor
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700
--- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-05-07 19:04:29 UTC ---
(In reply to comment #7)
Has the situation improved?
current trunk LTO seems to fail on CP2K with:
/data/vjoost/clean/cp2k/cp2k/src/../src
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53217
Bug #: 53217
Summary: [4.8 Regression] internal compiler error: verify_ssa
failed
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53217
--- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-05-03 18:38:27 UTC ---
The following testcase causes an ICE with current trunk (4.8)
MODULE xc_cs1
INTEGER, PARAMETER :: dp=KIND(0.0D0)
REAL(KIND=dp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52325
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-02-22 06:49:41 UTC ---
(In reply to comment #2)
Submitted patch (pending review):
http://gcc.gnu.org/ml/fortran/2012-02/msg00089.html
OK ;-)
this would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52325
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2012-02-22 06:53:09 UTC ---
(In reply to comment #2)
Submitted patch (pending review):
http://gcc.gnu.org/ml/fortran/2012-02/msg00089.html
and a nitpick
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51298
--- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2011-12-15 09:44:46 UTC ---
similarly, does this only affect power7, or potentially also other targets such
as x86_64 (interlagos?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51355
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51346
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51089
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51355
Bug #: 51355
Summary: [4.7 Regression] cgraph_add_edge_to_call_site_hash, at
cgraph.c:765
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708
--- Comment #17 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2011-11-30 19:50:37 UTC ---
Janne's lseek patch:
http://gcc.gnu.org/ml/fortran/2011-11/msg00251.html
has further nice results on CP2K (CP2K_2009-05-01.f90)
Thomas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25708
--- Comment #18 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2011-12-01 07:29:25 UTC ---
Janne's latest patch now effectively 'removes' lseek:
26.840.108906 0242658 madvise
20.120.081608
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
2011-11-28 14:24:02 UTC ---
Just for reference, compiling CP2K_2009-05-01.f90 results in 684 modules,
stracing yields something like 12000 calls to open, and 148'847'399
601 - 700 of 713 matches
Mail list logo
