Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
current trunk (r230637) crashes with
> cat bug.f90
MODULE dbcsr_geev
INTEGER, PARAMETER :: real_8=8
CONTAINS
SUBROUTINE dbcsr_dgeev(jobvl,jobvr,matrix,ndim,evals,revec,le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68453
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401
--- Comment #6 from Joost VandeVondele
---
(In reply to Mikael Morin from comment #5)
> (In reply to Joost VandeVondele from comment #4)
> > In the original post I suggested that I already looked at the code,
>
> What changes did you try?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401
--- Comment #8 from Joost VandeVondele
---
(In reply to Mikael Morin from comment #7)
> (In reply to Joost VandeVondele from comment #6)
> > (In reply to Mikael Morin from comment #5)
> > > (In reply to Joost VandeVondele from comment #4)
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401
Joost VandeVondele changed:
What|Removed |Added
Status|WAITING |NEW
CC|
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
Between r230516 and r230587, I run into an ICE, but it triggers only with
-fprofile-use making
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68401
--- Comment #4 from Joost VandeVondele
---
(In reply to Dominique d'Humieres from comment #3)
> I am still not convinced. IMO enhancements have only two realistic status:
> WONTFIX or ASSIGNED.
not sure, project that do not engage with their
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
as an enhancement, it would be very nice if the error message:
'Allocation would exceed memory limit'
could be improved to read
'Allocation of bytes would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #28 from Joost VandeVondele
---
(In reply to Richard Biener from comment #27)
> Sth like
>
> Index: gcc/tree-ssa.c
> ===
> --- gcc/tree-ssa.c (revision 230404)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #21 from Joost VandeVondele
---
(In reply to Markus Trippelsdorf from comment #20)
> I haven't seen this issue since Jason's GC related C++ patches went in:
> r230201 and r230202.
>
> But of course this may well be another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68324
Joost VandeVondele changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
current trunk:
> gfortran -c -O2 -floop-nest-optimize bug.f90
bug.f90:27:0:
SUBROUT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68335
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68283
Joost VandeVondele changed:
What|Removed |Added
Keywords||ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68283
--- Comment #8 from Joost VandeVondele
---
(In reply to Dominique d'Humieres from comment #6)
> For some reason, the ICE requires to use at least -O.
yes, I noticed this as well, I think this is one of the fortran frontend
optimization passes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68279
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
with gcc version 6.0.0 20151110 (experimental) [trunk revision 230080] (GCC)
> gfortran -c -O2 -floop-nest-optim
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
autoreducing a testcase I ran into this ice with current trunk:
> gfortran -c -g -O3 -cpp bug.f90
[...]
f951: internal compiler error: gfc_variable_attr():
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66756
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68251
--- Comment #8 from Joost VandeVondele
---
Created attachment 36671
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36671=edit
reduced testcase
thanks, the issue is fixed indeed. Attached is the reduced testcase, about 1000
lines remain,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #16 from Joost VandeVondele
---
Just another valgrind trace below. The bug is very sensitive, I have now a
non-lto case and it is a relatively small file that causes a crash. However,
just moving the file to a different directory is
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
Nightly build of CP2K failed with: sorry, unimplemented: reverse storage order
for BLKmode , between good r229944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68251
--- Comment #3 from Joost VandeVondele
---
Created attachment 36667
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36667=edit
partially reduced testcase
I attach a partially reduced testcase, reduction will continue for a while.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68251
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68117
--- Comment #14 from Joost VandeVondele
---
(In reply to Markus Trippelsdorf from comment #13)
> *** Bug 68127 has been marked as a duplicate of this bug. ***
just FYI, for me (PR68127) the issue pops up in a non-deterministic way, I
don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55099
--- Comment #5 from Joost VandeVondele
---
(In reply to Dominique d'Humieres from comment #4)
> Improving the message will be quite trivial once an agreement is found about
> the improvement. Would the addition of "This name has not been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #11 from Joost VandeVondele
---
(In reply to Dominique d'Humieres from comment #10)
> A few comments:
>
> (1) Why do you want to use PURE in this context?
because this is a pure procedure ?
Comment 7 is not too the point (indeed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67982
--- Comment #8 from Joost VandeVondele
---
(In reply to dominiq from comment #7)
> Author: dominiq
> Date: Tue Nov 3 18:03:38 2015
> New Revision: 229716
thanks... just doing this myself :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68127
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67982
--- Comment #5 from Joost VandeVondele
---
(In reply to Dominique d'Humieres from comment #4)
> > Otherwise this might need bisection.
>
> Note that I cannot do easily the bissection on darwin due to a lot of
> bootstrap failures in the range
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
trunk started failing between r229401 and r229470 to build CP2K with -flto and
-fprofile-generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68078
Joost VandeVondele changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #2 from Joost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56471
Joost VandeVondele changed:
What|Removed |Added
Last reconfirmed|2013-06-29 00:00:00 |2015-10-24
CC|
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
The following testcase:
> cat test.f90
TYPE foo
INTEGER, DIMENSION(1) :: data=42
END TYPE
TYPE(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
There are uses for retaining unused static functions even if optimising, e.g.
coverage testing. Right now these function are removed at -O1 and there is no
flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68002
Joost VandeVondele changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67982
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
The following code illustrates an incorrect -Wunused-function warning:
> cat test.f90
MODULE base
INTERFACE
SUBROUTINE bar_int()
END SUBROUTINE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67696
Joost VandeVondele changed:
What|Removed |Added
Target||x86_64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67518
--- Comment #2 from Joost VandeVondele
---
yes, on current trunk this doesn't fail anymore, not sure if it has gone latent
or was fixed with some of the recent activity.
Unfortunately, I seemingly still have a wrong code case, which I have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52332
Joost VandeVondele changed:
What|Removed |Added
CC||lkrupp at gcc dot gnu.org
---
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
The backtrace printed on abort can contain demangled names, instead of the
Fortran symbols. In the example below, cp__b becomes
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
With gcc 5.2 I see:
> gfortran -c -g -O2 -Wuninitialized -cpp bug.f90
bug.f90:15:0:
DIMENSION(:, :, :) :: work
^
Warn
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
The C(++) preprocessor that is invoked on .F90 files can change Fortran
strings, leading to unexpected results. While it is OK to remove things that
are truly C comments
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
The testcase below triggers a bug in graphite and leads to:
> gfortran -c -floop-nest-optimize -O2 -ffast-math bug.f90
/data/vjoost/toolchain-trunk/build/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457
--- Comment #3 from Joost VandeVondele
---
(In reply to Ian Lance Taylor from comment #2)
> If other compilers can print a backtrace when mmap fails, then I think they
> must be recording all necessary information in loadable sections. When no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67457
--- Comment #6 from Joost VandeVondele
---
(In reply to Ian Lance Taylor from comment #4)
> I committed a patch that should produce a more graceful fallback when out of
> memory. Please see if it helps your situation.
Great! Not sure how you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #26 from Joost VandeVondele
---
(In reply to Janne Blomqvist from comment #25)
> Fixed on trunk, closing.
Thanks!
: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
gfortran on trunk uses libbacktrace to print backtraces on error. In an
out-of-memory situation, libbacktrace will fail to print a backtrace and
segfault instead. While having something
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
The testcase below leads to spurious output at compile time, even though no
warning (or error) is emitted. This started
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67460
--- Comment #3 from Joost VandeVondele
---
(In reply to Manuel López-Ibáñez from comment #2)
> Again a problem caused by buffering. Some warnings converted into error may
> get buffered and then discarded but that doesn't reset
>
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
For 4.9 and earlier a gfortran compiled binary would print a clear error
message if an allocate would fail like in:
> cat test.f90
INTEGER, POINTER, DIMENS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53379
--- Comment #21 from Joost VandeVondele
---
(In reply to Janne Blomqvist from comment #11)
> Looking at the frontend, calls to runtime_error_at are generated from
> gfc_trans_runtime_check() and gfc_trans_runtime_error(). I went through
> calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Last reconfirmed|2013-02-03 00:00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67219
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67303
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66761
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67303
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
URL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66761
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
URL
: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: jakub at gcc dot gnu.org
Target Milestone: ---
After compiling libgomp with -fsanitize=thread, the following testcase triggers
a warning, which might indicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
--- Comment #26 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
One more datapoint on the .smod / .mod issue.
I ran into the first package that fails to build with 6.0 because of this.
libxc (version 2.2.2, Tobias Burnus
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
The following testcase leads to an incorrect conversion warning (and a failed
CP2K build) with gcc 6.0, while 5.1 compiles fine
cat bug.f90
MODULE kinds
IMPLICIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: jakub at gcc dot gnu.org
Target Milestone: ---
After compiling libgomp with -fsanitize=thread, the following testcase triggers
a warning, which might indicate
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
After building libgfortran with -fsanitize=thread (see below) any Fortran
program that opens a file fails with:
cat test.f90
OPEN(10,FILE=foo.bar
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
Recent (last few days) regression :
cat bug.f90
SUBROUTINE matmul_test ( ntim,len)
INTEGER, PARAMETER :: dp=8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66352
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66352
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Depends
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
recent regression (last day):
gcc version 6.0.0 20150522 (experimental) [trunk revision 223512] (GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66251
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #32 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Thomas Koenig from comment #31)
If the middle end is not up to this, should we be looking at doing loop
blocking in the Fortran front end, at least
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
cat bug.f90
MODULE qs_integrate_potential_low
INTEGER, PARAMETER :: dp = 8
TYPE cell_type
REAL(KIND=8) :: h_inv(3,3)
END TYPE
TYPE(cell_type), POINTER
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
Target Milestone: ---
cat test.f90
REAL*8, ALLOCATABLE :: a(:,:), b(:,:), v(:)
ALLOCATE(a(N,N),b(N,N),v(N))
DO i=1,N
v = MATMUL(a,b(:,i))
ENDDO
END
gfortran -O2 test.f90
test.f90:6:0:
v = MATMUL
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Summary|Inquire on internal units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933
--- Comment #13 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Jerry DeLisle from comment #12)
(In reply to Joost VandeVondele from comment #11)
See patch here:
https://gcc.gnu.org/ml/gcc-patches/2015-01
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933
--- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Jerry DeLisle from comment #8)
You might notice that we redefined existence to be whether or not it is
connected. Units get connected when opened so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933
--- Comment #11 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Jerry DeLisle from comment #10)
It occurs to me another possible interpretation of what a unit existence
might be.
Behind the scenes when opening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
Hi Jerry,
thanks for the fix, but this seems to break code to find a free unit, like
such:
MODULE M
CONTAINS
FUNCTION get_unit_number(file_name) RESULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63926
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470
--- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
Possibly fixed by (?) :
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00640.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Known to work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64260
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432
--- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
reading the standard, indeed it seems like count_rate can be real as well...
same rules here *4 - _4 *8 - _8.
As a side remark the following generates a slightly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60414
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50865
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591
--- Comment #7 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Dominique d'Humieres from comment #6)
what about applying this to stage 1 4.9 ?
Too late for 5.0? Note that the patch in comment 3 may have
Assignee: unassigned at gcc dot gnu.org
Reporter: Joost.VandeVondele at mat dot ethz.ch
somewhere between r218726 and r218773 (1day) code compiled linked with
FCFLAGS = -flto=jobserver -ffree-form -cpp
LDFLAGS = $(FCFLAGS) -O3 -funroll-loops -ffast-math -march=native
-fuse-linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Summary|program result depends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
The following is a test program that illustrates the issue:
cat test.f90
SUBROUTINE gemm(C,A,B,N)
REAL*8 :: A(N,N), B(N,N),C(N,N)
C=0
DO i=1,N
DO j=1,N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
some similarity with the problem discussed PR55916, except that this case
doesn't require __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Ondrej Bilka from comment #7)
That looks like invalid bug. Fortran allows reassociate a+(b+c) into (a+b)+c
which give different result. You will get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
A variation on the testcase, to indicate how this behavior leads to conflicts
with the Fortran language standard. A routine declared 'PURE' and called with
all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38220
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|RESOLVED
101 - 200 of 713 matches
Mail list logo
