[Bug libgomp/95150] Some offloaded programs crash with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95150 --- Comment #4 from Chinoune --- after some tests, It looks like it fails with only with small sizes. The program doesn't crash when increasing matrices size. and It takes a shorter time to execute!.
[Bug libgomp/95150] Some offloaded programs crash with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95150 --- Comment #3 from Chinoune --- (In reply to Tobias Burnus from comment #1) > * You compilation uses "-O0" – I do not know whether that's intended. I didn't set any optimization flag, maybe the compiler default to "-O0". > > * I did not see any timeout message although it did take a while to run > with offloading. (See timing results below.) > I wonder what causes the problem you are seeing. > > You could try whether setting the environment variable > GOMP_DEBUG=1 > shows some useful details for the launch. > I have attached the output with GOMP_DEBUG=1 > * The OpenACC test case is wrong as "c" has to be "copy" not "copyout" > as the initial value is used (→ NaN) Thanks, I did observe after I reported the bug. I am using a Kepler (sm_35) Graphics card, if this helps.
[Bug libgomp/95150] Some offloaded programs crash with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95150 --- Comment #2 from Chinoune --- Created attachment 48546 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48546&action=edit debug ouput
[Bug libgomp/95150] New: Some offloaded programs crash with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95150 Bug ID: 95150 Summary: Some offloaded programs crash with openmp Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com CC: jakub at gcc dot gnu.org Target Milestone: --- This is the reduced program: $ cat matmul.F90 program main implicit none integer, parameter :: sp = selected_real_kind(6,37) integer, parameter :: l = 1024, m = 1024, n = 1024 real(sp), allocatable :: a(:,:), b(:,:), c(:,:) integer :: i, j, k, t1, t2 real(sp) :: tic ! call system_clock( t1, tic) ! allocate( a(l,m), b(m,n), c(l,n) ) ! call random_number(a) call random_number(b) c = 0._sp ! !$acc data copyin(a,b) copyout(c) !$acc parallel loop collapse(3) !$omp target teams distribute collapse(3) map( to:a,b ) map( tofrom:c) do j = 1, n do k = 1, m do i = 1, l c(i,j) = a(i,k)*b(k,j) + c(i,j) end do end do end do !$acc end data ! call system_clock(t2) print*, (t2-t1)/tic ! end program main This program compiles successfully with both OpenMP and OpenACC but it crashs with OpenMP after a short time of running, throwing this error message: $ gfortran-10 -fopenmp -foffload=nvptx-none="-lm -lgfortran" matmul.F90 -o test.x $ $ ./test.x libgomp: cuCtxSynchronize error: the launch timed out and was terminated The same message appears with gfortran-9
[Bug libgomp/94612] New: Failed to build simple examples with offloading.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94612 Bug ID: 94612 Summary: Failed to build simple examples with offloading. Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com CC: jakub at gcc dot gnu.org Target Milestone: --- $cat prod.f90 program main implicit none integer, parameter :: sp = selected_real_kind(6,37) integer, parameter :: n = 4096 real(sp), allocatable :: a(:), b(:), c(:), c2(:) integer :: i allocate( a(n), b(n), c(n) ) c = 0._sp call random_number(a) call random_number(b) !$omp target teams map(to: a, b) map(from: c) !$omp distribute parallel do do i = 1, n c(i) = a(i)*b(i) end do !$omp end target teams c2 = a*b print*, maxval( abs(c2-c) ) end program $ gfortran-10 prod.f90 -fopenmp -foffload=nvptx-none -o test.x lto1: internal compiler error: compressed stream: data error Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. mkoffload: fatal error: x86_64-linux-gnu-accel-nvptx-none-gcc-10 returned 1 exit status compilation terminated. lto-wrapper: fatal error: /usr/lib/gcc/x86_64-linux-gnu/10//accel/nvptx-none/mkoffload returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status System: Ubuntu 20.04 x86_64 $ gcc-10 -v Using built-in specs. COLLECT_GCC=gcc-10 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 10-20200411-0ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,amdgcn-amdhsa,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.1 20200411 (experimental) [master revision bb87d5cc77d:75961caccb7:f883c46b4877f637e0fa5025b4d6b5c9040ec566] (Ubuntu 10-20200411-0ubuntu1)
[Bug fortran/94464] [F08] coarrays shoud be enabled by default.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94464 Chinoune changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Chinoune --- won't fix
[Bug fortran/94464] New: [F08] coarrays shoud be enabled by default.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94464 Bug ID: 94464 Summary: [F08] coarrays shoud be enabled by default. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- Since "coarrays" is part of Standard Fortran and not an experimental feature or an extension, why putting it behind a flag? There would be a flag to disable it, maybe. "-fcoarray=single" should be the default.
[Bug fortran/94397] New: [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94397 Bug ID: 94397 Summary: [10 Regression] the compiler consider "type is( real(kind(1.)) )" as a syntax error. Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- Failed to build https://github.com/Goddard-Fortran-Ecosystem/pFUnit (which I successfully built last Monday 23-03-2020) this morning with gcc-git. This is the reduced code: $ cat type_is.f90 module m implicit none contains subroutine sub(a) class(*) :: a select type(a) type is ( real( kind(1.) ) ) a = 1. end select end subroutine sub end module m $ gfortran-10 -c type_is.f90 type_is.f90:7:32: 7 | type is ( real( kind(1.) ) ) |1 Error: Syntax error in TYPE IS specification at (1) type_is.f90:8:14: 8 | a = 1. | 1 Error: Expected TYPE IS, CLASS IS or END SELECT statement following SELECT TYPE at (1) $gfortran-10 --version GNU Fortran (GCC) 10.0.1 20200330 (experimental)
[Bug fortran/92736] Error when using a variable from a module in a submodule and its parent module.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92736 --- Comment #4 from Chinoune --- (In reply to Steve Kargl from comment #3) > On Sun, Dec 01, 2019 at 05:41:21AM +0000, chinoune.mehdi at hotmail dot com > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92736 > > > > --- Comment #2 from Chinoune --- > > (In reply to kargl from comment #1) > > > Not sure the code is conforming, and don't have time to > > > investigate (unless someone is willing to cough up $$). > > > > > > Workaround 1. Remove "use m1, only : i" in submodule(m2) > > > as 'i' is already available from module m2. > > > > > > Workaround 2. Use Fortran's renaming scheme. Thus, change > > > the submodule(m2) to 'Use m1, only : j=>i' > > > > You introduced a regression and it is your duty to fix it. > > When it comes to gfortran, I have no duty to you or anyone else. > I have neither the time nor now the inclination to look at this > bug (unless someone coughs up (price just went up ;)). With $$$ I can get a the best Fortran Compiler from Intel. Why should I pay you for just one little bug?! And I didn't complain about the bug, I did just report it. If you don't like people reporting bugs in open-source programs then you should better leave.
[Bug fortran/92736] Error when using a variable from a module in a submodule and its parent module.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92736 --- Comment #2 from Chinoune --- (In reply to kargl from comment #1) > Not sure the code is conforming, and don't have time to > investigate (unless someone is willing to cough up $$). > > Workaround 1. Remove "use m1, only : i" in submodule(m2) > as 'i' is already available from module m2. > > Workaround 2. Use Fortran's renaming scheme. Thus, change > the submodule(m2) to 'Use m1, only : j=>i' You introduced a regression and it is your duty to fix it. At least fix the ambiguous error message which doesn't tell anything about the problem. 15 | submodule(m2) s1 |1 16 | use m1, only : i | 2 Error: Symbol ‘i’ at (1) conflicts with the symbol at (2) does 'i' conflict with 'm2'?!
[Bug fortran/92736] New: Error when using a variable from a module in a submodule and its parent module.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92736 Bug ID: 92736 Summary: Error when using a variable from a module in a submodule and its parent module. Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- gfortran recently start to reject this code : module m1 implicit none integer, parameter :: i = 10 end module m1 module m2 use m1, only : i implicit none interface module subroutine sb1() end subroutine sb1 end interface end module m2 submodule(m2) s1 use m1, only : i implicit none contains module subroutine sb1 print*,"hello" end subroutine sb1 end submodule s1 gfortran-9 -c file.f90 15 | submodule(m2) s1 |1 16 | use m1, only : i | 2 Error: Symbol ‘i’ at (1) conflicts with the symbol at (2) The error message is not clear! I can compile it using gfortran 8.3.0 and 9.2.0, but it fails with 9.2.1 and 10.0 I think this is where it started failing : https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=274609 https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=274608
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 Chinoune changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Chinoune --- Thanks for fixing.
[Bug tree-optimization/91734] gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734 --- Comment #2 from Chinoune --- Replacing `if( az
[Bug tree-optimization/91734] New: gcc skip an if statement with "-O1 -ffast-math"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734
Bug ID: 91734
Summary: gcc skip an if statement with "-O1 -ffast-math"
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chinoune.mehdi at hotmail dot com
Target Milestone: ---
Building this program with gcc [8,9] "-O1 -ffast-math" makes the result
overflows.
#include
#include
#include
#include
void foo(float complex z, float *y){
float const sqrt_flt_min = sqrtf( FLT_MIN );
float az;
az = cabsf(z);
//az = cabsf(z/sqrt_flt_min) * sqrt_flt_min;
if( az [local count: 1073741824]:
cabs_17 = REALPART_EXPR ;
cabs_18 = cabs_17 * cabs_17;
cabs_19 = IMAGPART_EXPR ;
cabs_20 = cabs_19 * cabs_19;
cabs_21 = cabs_18 + cabs_20;
powroot_22 = __builtin_sqrtf (cabs_21);
_3 = (double) powroot_22;
__printf_chk (1, "az = %.8e\n", _3);
_4 = 1.0e+0 / powroot_22;
*y_10(D) = _4;
return;
}
;; Function main (main, funcdef_no=33, decl_uid=4154, cgraph_uid=34,
symbol_order=33) (executed once)
main ()
{
float y;
float y.0_1;
double _2;
[local count: 1073741824]:
foo (__complex__
(9.996826552253889678874634872052240552875446155667305e-20, 0.0), &y);
y.0_1 = y;
_2 = (double) y.0_1;
__printf_chk (1, "y = %.7e\n", _2);
y ={v} {CLOBBER};
return 0;
}
There is no if statement!
[Bug fortran/91337] gfortran skips an if statement with some mathematical optimisations with complex numbers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337 Chinoune changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Chinoune --- Sorry, It wasn't a bug. the compiler is not skipping the if statement. -fassociative-math : Allow re-association of operands in series of floating-point operations. This violates the ISO C and C++ language standard by possibly changing computation result. NOTE: re-ordering may change the sign of zero as well as ignore NaNs and inhibit or create underflow or overflow (and thus cannot be used on code that relies on rounding behavior like (x + 2**52) - 2**52. May also reorder floating-point comparisons and thus may not be used when ordered comparisons are required. -fassociative-math is enabled by -funsafe-math-optimizations .
[Bug fortran/91337] New: gfortran skips an if statement with some mathematical optimisations with complex numbers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337 Bug ID: 91337 Summary: gfortran skips an if statement with some mathematical optimisations with complex numbers. Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- I have encountered some underflows/overflows in my code compiled with -Ofast, and after investigations it seems like the complex abs gives zero with small numbers. So I added a workaround. but it didn't work: module m implicit none ! integer, parameter :: sp = selected_real_kind(6) real(sp), parameter :: tiny_sp = tiny(1._sp), sqrt_tiny = sqrt( tiny_sp ) ! contains subroutine sub(z,y) complex(sp), intent(in) :: z real(sp), intent(out) :: y real(sp) :: az ! az = abs(z) if( az
[Bug fortran/91296] New: ICE when passing complex number %re/%im as a procedure argument with -Waliasing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91296 Bug ID: 91296 Summary: ICE when passing complex number %re/%im as a procedure argument with -Waliasing. Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- This code throw an ICE module m implicit none integer, parameter :: sp = selected_real_kind(6) contains pure subroutine s(a,b,c) real(sp), intent(in) :: a, b real(sp), intent(out) :: c c = a + b end subroutine s end module m program test use m implicit none real(sp) :: a complex(sp) :: c c = (1._sp,1._sp) call s(c%re,c%im,a) print*,a end program test $ gfortran-9 -Waliasing -c test.f90 f951: internal compiler error: compare_actual_expr(): Bad component code Please submit a full bug report, with preprocessed source if appropriate. See for instructions.
[Bug fortran/89204] New: -floop-interchange has no effect on Fortran code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89204
Bug ID: 89204
Summary: -floop-interchange has no effect on Fortran code
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: chinoune.mehdi at hotmail dot com
Target Milestone: ---
On 7 Dec 2017 Bin Cheng had introduced a better implementation of
-floop-interchange
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00360.html
bou it looks like it doesn't affect Fortran
#define M 2048
int a[M][M], b[M][M], c[M][M];
void matrix_mul (int n)
{
for (int k = 0; k < n; k++)
for (int j = 0; j < n; j++)
for (int i = 0; i < n; i++)
c[i][j] = c[i][j] + a[i][k]*b[k][j];
}
static void init (int i)
{
for (int j = 0; j < M; j++)
{
a[i][j] = i;
b[i][j] = j;
c[i][j] = 0;
}
}
int main (void)
{
for (int i = 0; i < M; ++i)
init (i);
matrix_mul (M);
return 0;
}
gcc-8 -O2 -floop-interchange -fopt-info loop-interchange-7.c -o test
loop-interchange-7.c:11:7: note: loops interchanged in loop nest
time ./test
real
0m7.759s
user0m7.656s
sys 0m0.031s
module mod_
implicit none
integer, parameter :: m = 2048
integer :: a(m,m), b(m,m), c(m,m)
contains
subroutine matrix_mul(n)
integer, intent(in) :: n
integer :: i, j, k
do i = 1, n
do j = 1, n
do k = 1, n
c(i,j) = c(i,j) + a(i,k)*b(k,j)
end do
end do
end do
end subroutine matrix_mul
subroutine init(i)
integer, intent(in) :: i
integer :: j
a(i,:) = i
do j = 1, m
b(i,j) = j
end do
end subroutine init
end module mod_
program main
use mod_
implicit none
integer :: i
c = 0
do i = 1, m
call init(i)
end do
call matrix_mul(m)
end program main
gfortran-8 -O2 -floop-interchange -fopt-info loop-interchange-7.f90 -o test
time ./test
real
1m30.447s
user
1m30.266s
sys 0m0.063s
[Bug fortran/82567] [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82567 --- Comment #7 from Chinoune --- Fixed
[Bug fortran/82567] [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82567 Chinoune changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Chinoune --- Fixed
[Bug fortran/82568] New: ICE with do-loop inside BLOCK inside omp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82568 Bug ID: 82568 Summary: ICE with do-loop inside BLOCK inside omp Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- gfortran gives an internal compiler error with this code : PROGRAM OMP_BLOCK IMPLICIT NONE INTEGER :: I !,J !$OMP PARALLEL DO !PRIVATE(J) ! Declaring j outside of OMP and put it in private solves the problem DO I=1,2 BLOCK INTEGER :: J DO J=1,2 PRINT*,I,J END DO END BLOCK END DO END PROGRAM OMP_BLOCK tested with gfortran 6/7/8 Linux-64 and gfortran-7 MinGW-64
[Bug fortran/82567] New: [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82567 Bug ID: 82567 Summary: [6/7/8] gfortran takes a long time to compile a simple implied-do with -Optimization. Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- gfortran takes about 11s to compile this simple subroutine with -O1 : SUBROUTINE sub() IMPLICIT NONE INTEGER, PARAMETER :: n = 1 REAL, ALLOCATABLE :: x(:) REAL :: xc, h INTEGER :: i ALLOCATE( x(n) ) xc = 100. h = xc/n x = h*[(i,i=1,n)] ! Replacing the previous line with one of these lines gives faster compilation ! x = [(i*h,i=1,n)] ! x = (100./n) *[(i,i=1,n)] END SUBROUTINE sub time gfortran -O1 -c test.f90: real0m11.167s the time increases with n (-O1) : n| 1 | 2 | 3 | 4 - time | 11s | 25s | 43s | 1m7s and decrease with the level of optimization (n=2) : -Ox | -O1 | -O2 | -O3 | -Ofast --- time | 20s | 15s | 15s | 8s tested with gfortran 6/7/8 Linux-64 and gfortran-7 MinGW-64
[Bug fortran/82495] New: forall is very slow comparing to other compilers!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82495 Bug ID: 82495 Summary: forall is very slow comparing to other compilers! Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- This forall construct is very slow comparing to other compilers: PROGRAM FORALL_EXECUTION IMPLICIT NONE REAL, ALLOCATABLE :: A(:,:,:), B(:,:,:), C(:,:,:) INTEGER :: I, J, K REAL :: TIC INTEGER :: START, FINISH1, FINISH2, FINISH3, FINISH4, FINISH5, FINISH6 INTEGER, PARAMETER :: L = 1024, M = 512, N = 512 ALLOCATE(A(L,M,N), B(L,M,N), C(L,M,N) ) CALL RANDOM_NUMBER(A) CALL RANDOM_NUMBER(B) CALL RANDOM_NUMBER(C) CALL SYSTEM_CLOCK(START, TIC) FORALL(I=1:L, J=1:M, K=1:N) C(I,J,K) = A(I,J,K) + B(I,J,K) END FORALL CALL SYSTEM_CLOCK(FINISH1) PRINT*,'I,J,K ',(FINISH1-START)/TIC FORALL(I=1:L, K=1:N, J=1:M) C(I,J,K) = A(I,J,K) +B(I,J,K) END FORALL CALL SYSTEM_CLOCK(FINISH2) PRINT*,'I,K,J ',(FINISH2-FINISH1)/TIC FORALL(J=1:M, I=1:L, K=1:N) C(I,J,K) = A(I,J,K) +B(I,J,K) END FORALL CALL SYSTEM_CLOCK(FINISH3) PRINT*,'J,I,K ',(FINISH3-FINISH2)/TIC FORALL(J=1:M, K=1:N, I=1:L) C(I,J,K) = A(I,J,K) +B(I,J,K) END FORALL CALL SYSTEM_CLOCK(FINISH4) PRINT*,'J,K,I ',(FINISH4-FINISH3)/TIC FORALL(K=1:N, I=1:L, J=1:M) C(I,J,K) = A(I,J,K) +B(I,J,K) END FORALL CALL SYSTEM_CLOCK(FINISH5) PRINT*,'K,I,J ',(FINISH5-FINISH4)/TIC FORALL(K=1:N, J=1:M, I=1:L) C(I,J,K) = A(I,J,K) +B(I,J,K) END FORALL CALL SYSTEM_CLOCK(FINISH6) PRINT*,'K,J,I ',(FINISH6-FINISH5)/TIC END PROGRAM This program gives: MinGW 7.2.0 : -Ofast I,J,K 0.45309 I,K,J 0.53118 J,I,K9.34400082 J,K,I14.0630007 K,I,J24.0460014 K,J,I25.9690018 Ubuntu 7.2.0 : -Ofast I,J,K 0.45426 I,K,J 0.44115 J,I,K9.14200020 J,K,I13.2140007 K,I,J22.3860016 K,J,I24.7680016 But with other compilers: PGI Fortran 17.04 : -fast I,J,K0.5161750 I,K,J0.3963450 J,I,K0.2786350 J,K,I0.3162010 K,I,J0.3141180 K,J,I0.2789040 Flang : -Ofast I,J,K0.4740010 I,K,J0.2965370 J,I,K0.3045340 J,K,I0.4017220 K,I,J0.2853640 K,J,I0.3081510 Intel Fortran 18.0 : -fast I,J,K 0.437 I,K,J 0.391 J,I,K 0.281 J,K,I 0.360 K,I,J 0.328 K,J,I 0.281 I think this bug is independent of do-concurrent!
[Bug fortran/82471] do-concurrent is much slower than ordinary-do!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 --- Comment #5 from Chinoune --- I have just tried FORALL and it has the same problem : FORALL(K=1:N, J=1:M, I=1:L) is much slower than FORALL(I=1:L, J=1:M, K=1:N).
[Bug fortran/82471] do-concurrent is much slower than ordinary-do!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 --- Comment #4 from Chinoune --- (In reply to Dominique d'Humieres from comment #3) > DO CONCURRENT :8.1975 > DO CONCURRENT : 0.28409 > ORDINARY DO : 0.11604 > ARRAY DO : 0.11808 but with me it gives : MinGW: DO CONCURRENT 1 :11.1880007 DO CONCURRENT 2 : 0.14001 ORDINARY DO : 0.15705 ARRAY DO : 0.15603 Ubuntu: DO CONCURRENT 1 :11.5040007 DO CONCURRENT 2 : 0.14613 ORDINARY DO : 0.14409 ARRAY DO : 0.14307
[Bug fortran/82471] do concurrent is much slower the ordinary do!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 --- Comment #2 from Chinoune --- (In reply to Thomas Koenig from comment #1) > There is a subtle problem with your test case, it is the > ordering of the variables in the DO concurrent statement. > > > DO CONCURRENT( K=1:N, J=1:M, I=1:L) > C(I,J,K) = A(I,J,K) + B(I,J,K) > END DO > > This is probably not what you meant to write; this > will fail (with the variable bounds you gave above in > > ALLOCATE( A(L,M,N), B(L,M,N), C(L,M,N) ) > > if any of L, M or N has a different value. Why will it fail ?!. Could you please explain. > > If you write > > DO CONCURRENT( I=1:L, K=1:N, J=1:M) > > things are much faster. I know that DO CONCURRENT( I=1:L, J=1:M, K=1:N) is the fastest but I expected that do-concurrent work like ordinary-do by varying the last index in nested loops. And since the do-concurrent can run in any order I expected that the compiler will choose the best order. but it turns that do-concurrent is not portable at all. Intel Fortran Compiler works as I expected. So which order should I use!
[Bug fortran/82471] New: do concurrent is much slower the ordinary do!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 Bug ID: 82471 Summary: do concurrent is much slower the ordinary do! Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- in this example do-concurrent is much slower than ordinary-do : PROGRAM TEST_DO_SPEED IMPLICIT NONE REAL, ALLOCATABLE :: A(:,:,:), B(:,:,:), C(:,:,:) REAL :: TIC INTEGER :: T0, T1, T2 INTEGER :: I, J, K INTEGER, PARAMETER :: L = 512, M = 512, N = 512 ALLOCATE( A(L,M,N), B(L,M,N), C(L,M,N) ) CALL RANDOM_NUMBER(A) CALL RANDOM_NUMBER(B) CALL SYSTEM_CLOCK( T0, TIC) DO CONCURRENT( K=1:N, J=1:M, I=1:L) C(I,J,K) = A(I,J,K) +B(I,J,K) END DO CALL SYSTEM_CLOCK(T1) DO K=1,N DO J=1,M DO I=1,L C(I,J,K) = A(I,J,K) +B(I,J,K) END DO END DO END DO CALL SYSTEM_CLOCK(T2) PRINT*,"DO CONCURRENT : ",(T1-T0)/TIC PRINT*,"ORDINARY DO : ",(T2-T1)/TIC END PROGRAM Compiled with : -Ofast it gives Under MinGW-64 7.2.0 : DO CONCURRENT :13.0620003 ORDINARY DO : 0.23397 and under Ubuntu-16.04-64 7.2.0 : DO CONCURRENT :11.604 ORDINARY DO : 0.20804 It looks like with do-concurrent gfortran begin with the first index . I know that there is no obligations in Standard-Fortran. but at least make it act like the ordinary-do construct.
[Bug fortran/81877] New: [7 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81877 Bug ID: 81877 Summary: [7 Regression] Incorrect results with lto and -fipa-cp and -fipa-cp-clone Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- Created attachment 41991 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41991&action=edit the program which reproduce the bug with gcc >=7.0 (7.1.0 ,7.2.0 ) this program gives incorrect results with '-O2 -fipa-cp -fipa-cp-clone -flto'. I have reproduced this bug in Linux-64bit , MinGW-64bit ,Cygwin-64bit . I tried my best to minimize the program to reproduce the bug.
[Bug fortran/80304] Warn about variable redefinition in do-concurrent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80304 Chinoune changed: What|Removed |Added Attachment #41117|0 |1 is obsolete|| --- Comment #10 from Chinoune --- Created attachment 41129 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41129&action=edit modified test-program (In reply to Thomas Koenig from comment #9) > What you are doing is > > DO CONCURRENT( i=0:1 ,j=0:1) > a = a + add(i,j,abs(i-j)) > b = b + add2(i,j,abs(i-j)) > END DO > > This causes the variables a and b to be defined multiple > times in the loop. > > In the standard, this is given in 8.1.6.7 of J3/10-007: > > A variable that is referenced in an iteration shall either be previously > defined during that iteration, or > shall not be defined or become undefined during any other iteration. A > variable that is defined or becomes > undefined by more than one iteration becomes undefined when the loop > terminates. > > Conceptually, when parallelizing, you cannot depend on a having > any specific value during the loop execution, so the program > might read a in one thread, have it changed by another thread, > then add the value to it and store it back, losing what > was done by the other thread. > > You cannot do a sum like this with DO CONCURRENT. In OpenMP terms, > what you are attempting a reduction. > > It would be nice to warn about this, though. 1- Why 'b' has been calculated correctly while 'a' hasn't ?! .the only difference between the two functions is ( +1. ) 2- I attached a new modified test and it fails. 3- The test-program works well with gfortran-5 gfortran-6 and Intel Fortran 2017.
[Bug fortran/80304] [7 Regression] do-concurrent dosn't work well with gfortran 7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80304 --- Comment #8 from Chinoune --- (In reply to Thomas Koenig from comment #7) > Fun fact: -flto also fixes it. It fixes the first test not the second (comment #5)
[Bug fortran/80304] [7 Regression] do-concurrent dosn't work well with gfortran 7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80304 --- Comment #5 from Chinoune --- Created attachment 41124 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41124&action=edit the second test program This is another test which fails with all the optimizations directives (except -Og).
[Bug fortran/80304] [7 Regression] do-concurrent dosn't work well with gfortran 7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80304 --- Comment #2 from Chinoune --- (In reply to Dominique d'Humieres from comment #1) > WORKSFORME on x86_64-apple-darwin16 from 4.8 up to trunk (7.0): > >10.000 6. >10.000 6. >10.000 6. it works well without optimization. did you use the optimization directives : -Ox ( -O1,-O2,-O3 ..)
[Bug fortran/80305] New: print statement inside do-concurrent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80305 Bug ID: 80305 Summary: print statement inside do-concurrent Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- Created attachment 41118 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41118&action=edit the test program the compiler gives this error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f3615d254af in #1 0x7f3615d7ab96 in ??? #2 0x7f3615d3c97f in ??? #3 0x7f3615d3d4a5 in ??? #4 0x7f3615d66a48 in ??? #5 0x7f36169bb24b in data_transfer_init at ../../../libgfortran/io/transfer.c:2807 #6 0x400736 in ??? #7 0x4007cd in ??? #8 0x7f3615d1082f in ??? #9 0x400668 in ??? #10 0x in ??? Segmentation fault (core dumped) this error appears only with gfortran 7. build : Target: x86_64-pc-linux-gnu Configured with: ../configure --disable-multilib --prefix=/home/mehdi/gcc-7/ --program-suffix=-7 --enable-language=fortran --disable-bootstrap --with-system-zlib --with-arch=native Thread model:posix gcc version 7.0.1 20170402 (experimental) (GCC) cpu : haswell-i7
[Bug fortran/80304] New: do-concurrent dosn't work well with gfortran 7.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80304 Bug ID: 80304 Summary: do-concurrent dosn't work well with gfortran 7. Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- Created attachment 41117 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41117&action=edit the test program with gfortran my program generate different results with normal-do and do-concurrent loop with optimization (-O and up). while it gives the same results with gfortran 5.4.0 and gfortran 6.3.0 . my build : Target: x86_64-pc-linux-gnu Configured with: ../configure --disable-multilib --prefix=/home/mehdi/gcc-7/ --program-suffix=-7 --enable-language=fortran --disable-bootstrap --with-system-zlib --with-arch=native Thread model:posix gcc version 7.0.1 20170402 (experimental) (GCC) my cpu is intel Core i7-4700MQ ( haswell core-i7)
[Bug fortran/79154] omp declare simd in pure function?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79154 --- Comment #2 from Chinoune --- (In reply to kargl from comment #1) > (In reply to Chinoune from comment #0) > > Created attachment 40550 [details] > > the fortran program > > > > I tried to build the program (see attachment) with gfortran (5.4.0 > > linux,cygwin 6.2.0,6.3.0 mingw 6.2.0 linux ...) > > it gave me this error: > > test_simd.f90:6:6: > > > > !$omp declare simd(add) > > 1 > > Error: OpenMP directives at (1) may not appear in PURE or ELEMENTAL > > procedures > > AFAIK, GCC support OpenMP 4.0. On p. 26 of OpenMP 4.0 Standard, one > finds > > Restrictions > > The following restriction applies to all OpenMP directives: > · OpenMP directives may not appear in PURE or ELEMENTAL procedures. > > so you get the above error message. I'll note that OpenMP 4.5 Standard > states > Restrictions > > The following restriction applies to all OpenMP directives: > > Restrictions > > · OpenMP directives, except SIMD and declare target directives, > may not appear in pure > procedures. > > I'll further note that the GCC wiki page for OpenMP sugeests that > no one is actively working on $.5 support. gcc support full openmp 4.5 for c/c++ (see https://gcc.gnu.org/gcc-6/changes.html) and partially for fortran, so the omp simd declare must be accepted.
[Bug fortran/79154] New: omp declare simd in pure function?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79154 Bug ID: 79154 Summary: omp declare simd in pure function? Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: chinoune.mehdi at hotmail dot com Target Milestone: --- Created attachment 40550 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40550&action=edit the fortran program I tried to build the program (see attachment) with gfortran (5.4.0 linux,cygwin 6.2.0,6.3.0 mingw 6.2.0 linux ...) it gave me this error: test_simd.f90:6:6: !$omp declare simd(add) 1 Error: OpenMP directives at (1) may not appear in PURE or ELEMENTAL procedures
