http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318
--- Comment #12 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Marc Glisse from comment #11)
So S2 cannot call free (or realloc) on the pointer and then exit or call
longjmp or do an infinite loop or anything
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #7)
-fno-omit-frame-pointer: that may or may not be a good idea, I don't know.
I seem to need it to get good backtraces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #17 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Sergey Matveev from comment #16)
Under the current behavior -fsanitize=address,leak is equivalent to
-fsanitize=address.
We've considered other
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #19 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #18)
I don't think we've measured pure-lsan slowdown, but I expect it to be small.
asan/lsan bring in a different
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #21 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #20)
I our simulation code, it looks like the overhead for leak checking is about
20%. I haven't done very careful
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
URL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55439
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: jakub at gcc dot gnu.org
This seems either a bug in libgomp or tsan, not clear which one.
To reproduce, libgomp must
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
actually it seems more general an issue, the following:
SUBROUTINE S1(m)
REAL :: m
!$OMP ATOMIC
m=m+1.0
END
REAL :: m
m=0.0
!$OMP PARALLEL
CALL S1(m)
!$OMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Jakub Jelinek from comment #4)
I bet tsan complains because the load is
not atomic, but does it really matter?
I think there are (at least) two
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Jakub Jelinek from comment #4)
I bet tsan complains because the load is
not atomic, but does it really matter? If we read garbage there, compare
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59194
--- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Jakub Jelinek from comment #7)
And the problem with that is? Because the arithmetics is based on the value
we've read, it shouldn't be a problem.
Ah
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229
--- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
reducing..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #97 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Richard Biener from comment #89)
I believe the correct solution will involve implementing the proposal for
introducing explicit restrict tags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59215
--- Comment #18 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Jonathan Wakely from comment #17)
But I can't test it yet because libtsan is giving me undefined references to
sigsetjmp.
workaround in PR59188
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706
--- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Richard Biener from comment #8)
Waiting for analysis.
Analysis by whom, and if me, what can I do ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56063
--- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
Frederic, are you still looking into this one ? I still believe this would be
progress.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706
--- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
So, after the change from fat to slim lto, I've added the CP2K SVN repo to use
gcc-ar (so that the instructions in comment #1 should still work).
Now, the issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Depends
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #29 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
I've tried -fsanitize=leak and it works well, thanks!
Concerning the speed, I'm still seeing about 20% slowdown (again, this is
acceptable from my point of view
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
This 'bug' might lead to some confusion.
If an older version of gfortran (i.e. 4.8) reads a module generated with 4.9
the error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54797
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
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
Running our tsan instrumented code, I'm seeing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
--- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #3)
Can you post the exact command line to reproduce the failure?
(We should have CP2K sources somewhere)
The exact
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #5)
However, building a tsan instrumented CP2K is non-trivial, as it requires
Maybe let's do some remote debugging
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #5)
Maybe let's do some remote debugging then :)
For the current setup, the crash is always in StackDepotGet
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
--- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #8)
Just insert more printfs everywhere you can :)
E.g. print everything around s-link = s2 in StackDepotPut
hmm I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59286
--- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
well, maybe a more simple reason. If I export
export OMP_STACKSIZE=32M
(i.e. stack size for the threads), the segfault disappears... does that sound
like a good
: 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
One tsan test I'm doing fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59302
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
Known to work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58746
--- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
Reduced :
MODULE mathlib
INTEGER, PARAMETER :: dp = 8
CONTAINS
FUNCTION expint(n,x)
REAL(dp) :: x, expint
nm1=n-1
DO i=1,MAXIT
IF(i.NE.nm1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58746
--- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
this testcase gives the same error without LTO. Just -O2 is sufficient:
INTEGER, PARAMETER :: dp = 8
REAL(KIND=dp), VOLATILE :: r=0.1_dp
r = expint(1,r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34740
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2009-03-29 08:22:06
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320
--- Comment #10 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to David Kaufmann from comment #9)
(In reply to Joost VandeVondele from comment #7)
(In reply to David Kaufmann from comment #5)
Created attachment
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
During an LTO build of CP2K, the following internal error happens with gcc
trunk:
make.out14-/data/vjoost/gnu/cp2k/cp2k/makefiles/../src
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59336
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: jakub at gcc dot gnu.org
cat test.f90
!$OMP ATOMIC
i=-i
END
gfortran -fopenmp test.f90
test.f90:2.2:
i=-i
1
Error: !$OMP ATOMIC assignment operator must
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59336
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Richard Biener from comment #2)
I suppose it doesn't happen without LTO?
correct.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
In many cases, using variables with a POINTER attribute is neither necessary
nor beneficial. I wonder if the Fortran FE could generate a warning for
variables with the POINTER attribute
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
There is a missed optimization on compiler generated temporaries. Basically:
SUBROUTINE S1(A)
REAL :: A(3)
CALL S2(-A)
END SUBROUTINE
leads to an optimized tree that contains
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320
--- Comment #14 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Manuel López-Ibáñez from comment #13)
Will -fsanitize=undefined catch these? If so, perhaps the message shown
before reporting a bug should mention
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56600
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59370
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56463
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56463
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59020
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56706
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Summary|[4.8/4.9 Regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59395
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #39 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Sergey Matveev from comment #37)
I've patched LSan to use the real memset(). At least on my machine this
brought no performance improvement compared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #41 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Kostya Serebryany from comment #40)
Is there anything else left in this bug?
If not, please close this one and open another for the next problem(s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
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
Currently there is no option to 'blacklist' functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58290
--- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Jakub Jelinek from comment #7)
I've looked at this some more and it seems Richard's change was the right
fix for this, so I've committed the testcase
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=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=25708
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Depends
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=45586
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
URL
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=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=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=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=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=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=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=51727
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
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
101 - 200 of 713 matches
Mail list logo
