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=64247
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #9 from Joost VandeVondele
---
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 intent(in) arguments having the same value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #8 from Joost VandeVondele
---
(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 same instability if you compile
> pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
Ondrej Bilka changed:
What|Removed |Added
CC||neleai at seznam dot cz
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
--- Comment #6 from Joost VandeVondele
---
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 #5 from Joost VandeVondele
---
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
DO k=1,N
C(i,j)=C(i,j)+A(k,i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64247
Joost VandeVondele changed:
What|Removed |Added
Summary|program result depends on |malloc alignment and -mavx
