Re: [Mingw-w64-public] a possible bug in mingw-w64
在 2020/8/13 下午2:56, Takashi Inoue 写道: > Hi All, > > I made C version of sample code which demonstrate the problem(?). > I attach the code to this post. > I renamed files so that ML system does not remove files. > So, please rename back "cdemo.txt" to "cdemo.c" and > "Makefile.txt" to "Makefile." I'm sorry for this. > > With these two files, make produce cdemo.exe. > If you run cdemo.exe several times, I think, > you will get different "out.txt" at time to time, as I did. > > I see this behavior with mingw-w64 of x86-64 package of msys2. > I'm not sure whether this happens with other setup of mingw-w64. > So, I'm very grateful if you check behavior on your system and let me know, > especially if you have some other set up of mingw-w64. > > Thanks for this report. I believe this issue is caused by the x87 precision setting. I inserted a call to this function right before your `pow()`: void tell_precision(void) { const char* s; switch(_controlfp(0, 0) & _MCW_PC) { case _PC_24: s = "SINGLE"; break; case _PC_53: s = "DOUBLE"; break; case _PC_64: s = "EXTENDED"; break; default: s = ""; break; } printf("thread %u, precision %s\n", GetCurrentThreadId(), s); } and I got this output: thread 6264, precision DOUBLE thread 6264, precision DOUBLE thread 6264, precision DOUBLE thread 6264, precision DOUBLE thread 6264, precision DOUBLE thread 6264, precision DOUBLE thread 8792, precision EXTENDED thread 8792, precision EXTENDED thread 8792, precision EXTENDED thread 8792, precision EXTENDED thread 3928, precision DOUBLE thread 3928, precision DOUBLE thread 3928, precision DOUBLE thread 3928, precision DOUBLE thread 3928, precision DOUBLE thread 6264, precision DOUBLE thread 6264, precision DOUBLE thread 5160, precision DOUBLE thread 5160, precision DOUBLE thread 5160, precision DOUBLE thread 8792, precision EXTENDED Our `pow()` implementation calls `exp2l()` and `log2l()` without setting 64-bit precision accordingly. Right now I have had a idea in mind but don't have time to compose a patch. I will do that later today (~7hrs later). -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
Hi All, I made C version of sample code which demonstrate the problem(?). I attach the code to this post. I renamed files so that ML system does not remove files. So, please rename back "cdemo.txt" to "cdemo.c" and "Makefile.txt" to "Makefile." I'm sorry for this. With these two files, make produce cdemo.exe. If you run cdemo.exe several times, I think, you will get different "out.txt" at time to time, as I did. I see this behavior with mingw-w64 of x86-64 package of msys2. I'm not sure whether this happens with other setup of mingw-w64. So, I'm very grateful if you check behavior on your system and let me know, especially if you have some other set up of mingw-w64. Best, Takashi // // Demo of possible bug in "omp for schedule(dynamic,1)" of mingw-w64 // #include #include #include int main() { int i,j; double ai[6]; double a,b,c,x; double Mat[6][6]; FILE *output; ai[0] = 500.0; ai[1] = 50.0; ai[2] = 20.0; ai[3] = 10.0; ai[4] = 5.0; ai[5] = 1.0; output = fopen("out.txt","w"); #pragma omp parallel num_threads(4) #pragma omp for schedule(dynamic,1) private(i,j,a,b,c,x) for (j=0; j<6; j++) { for (i=j; i<6; i++) { a = ai[i]; b = ai[j]; c = a + b; x = pow(c,3.0/2.0); Mat[i][j] = x; Mat[j][i] = x; } } for (j=0; j<6; j++) { for (i=j; i<6; i++) { fprintf(output,"%d%d %1.16e\n", i+1,j+1,Mat[i][j]); } } fclose(output); return 0; } //-- .SUFFIXES: .c .o CC = gcc CFLAGS = -lm -fopenmp -O3 -Wall PROG1 = cdemo.exe OBJS1 = cdemo.o all: $(PROG1) clean: rm -f *.o *~ *.exe .c.o: $(CC) $(CFLAGS) -c $< -o $@ $(PROG1): $(OBJS1) $(CC) $(CFLAGS) $(OBJS1) -o $@ $(LIBS) ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
Hi All Or rather, would you please provide two operands to the power operator, which yield different results on mingw-w64 and FreeBSD etc.? This is difficult to do since this problem is that an execution file created with mingw-w64 does NOT provide definite number. Resulting number changes at time to time, when we execute several times. This is the first experience to me. It seems that, this strange behavior happens when we use operation ** in a do loop parallelized with "schedule(dynamic)". Somewhere in threading could be wrong. I will try to investigate more. Best, Takashi ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
在 2020/8/10 下午11:31, Takashi Inoue 写道: > Hi All, > > Finally, I found the minimal condition of my problem. > Attached very simple code reproduce the problem. > You will get different result(fort.99) at time to time. > > Essential point is combination of power operation(**) > and "omp do schedule(dynamic,chunk-size)". > If we have operation ** in a do loop parallelized > with schedule(dynamic), result becomes unstable. > I don't know fundamental origin of this problem. > But, I believe this is unexpected abnormal behavior. > > As I wrote, my mingw-w64 is a x86_64 package of msys2. > I have not tested other versions of mingw-w64 yet. > So, I would be grateful if you could test on your system. > > Any comments and suggestions will be appreciated. > You forgot to attach the program file. Would you please provide a C testcase instead? I know no FORTRAN, and I don't think many of us do. Or rather, would you please provide two operands to the power operator, which yield different results on mingw-w64 and FreeBSD etc.? Note in order to prevent round-off errors there should be at least 17 significant figures for IEEE 754 double-precision numbers. -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
Hi all, It seems that attaching two files is not accepted(?). I attach sample code alone to this mail. You can find Makefile in my previous mail. This very simple sample code hits a possible bug in mingw-w64. I would be grateful if you could test on your system. Best, Takashi - Hi All, Finally, I found the minimal condition of my problem. Attached very simple code reproduce the problem. You will get different result(fort.99) at time to time. Essential point is combination of power operation(**) and "omp do schedule(dynamic,chunk-size)". If we have operation ** in a do loop parallelized with schedule(dynamic), result becomes unstable. I don't know fundamental origin of this problem. But, I believe this is unexpected abnormal behavior. As I wrote, my mingw-w64 is a x86_64 package of msys2. I have not tested other versions of mingw-w64 yet. So, I would be grateful if you could test on your system. Any comments and suggestions will be appreciated. Best, Takashi ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
Hi All, Finally, I found the minimal condition of my problem. Attached very simple code reproduce the problem. You will get different result(fort.99) at time to time. Essential point is combination of power operation(**) and "omp do schedule(dynamic,chunk-size)". If we have operation ** in a do loop parallelized with schedule(dynamic), result becomes unstable. I don't know fundamental origin of this problem. But, I believe this is unexpected abnormal behavior. As I wrote, my mingw-w64 is a x86_64 package of msys2. I have not tested other versions of mingw-w64 yet. So, I would be grateful if you could test on your system. Any comments and suggestions will be appreciated. Best, Takashi .SUFFIXES: .f .o FORTRAN = gfortran FFLAGS = -fopenmp -O3 -Wall PROG1 = demo.exe OBJS1 = demo.o $(PROG1) : $(OBJS1) $(FORTRAN) $(FFLAGS) $(OBJS1) $(LIBS) -o $(PROG1) .f.o: $(FORTRAN) $(FFLAGS) -c $< clean: rm -f *.o *~ *.exe ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
在 2020/8/7 上午9:32, Takashi Inoue 写道: > Hi all, > > I did the check using mingw-w64 on msys2. > I got correct 1.9998 stably. > I repeated 10 times. > So, that issue seems not related with my problem. > Still, my problem is mystery for me. I'll invest more. > Any comments and suggestions will be appreciated. > Then I suggest you print all intermediate results and compare them with those on BSD, to find out since which step it went wrong. -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
Hi all, I did the check using mingw-w64 on msys2. I got correct 1.9998 stably. I repeated 10 times. So, that issue seems not related with my problem. Still, my problem is mystery for me. I'll invest more. Any comments and suggestions will be appreciated. Best, Takashi On 2020/08/07 0:37, Takashi Inoue wrote: Hi, Thank you for your interesting suggestion. I made a sample code. I attach. With GCC(gfortran) on FreeBSD, I get 1.9998 correctly. I'll check result of mingw-w64 as soon as I arrive at my office tomorrow, since I'm at home and the PC with mingw-w64 is there. Best, Takashi On 08/06/20 23:36, Liu Hao wrote: 在 2020/8/6 13:25, Takashi Inoue 写道: Hi, Did you compile your program with the i686 compiler or the x86_64 compiler? I suspect it has something to do with the floating-point environment. My windows is 64bit version widows 8.1. So, I installed x86_64 package via msys2 pacman. Would you please check the sum of 1.9998 and 1.1102230246251564e-16, in both the main thread and an OMP thread? IEEE-conforming double precision (with a 53-bit mantissa) arithmetic shall yield 1.9998, while a defective implementation (for example, if your FORTRAN compiler performs 64-bit addition with x87, rounds the result accordingly, then double-rounds it to 53-bit precision), you may get 2.0 [1]. The mingw-w64 CRT initializes the x87 control word to 64-bit precision, in contrast to MSVCRT which defaults to 53-bit precision, and may produce unexpected results under rare circumstances. [1]https://wandbox.org/permlink/v63VObkDke527VrJ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
Hi, Thank you for your interesting suggestion. I made a sample code. I attach. With GCC(gfortran) on FreeBSD, I get 1.9998 correctly. I'll check result of mingw-w64 as soon as I arrive at my office tomorrow, since I'm at home and the PC with mingw-w64 is there. Best, Takashi On 08/06/20 23:36, Liu Hao wrote: 在 2020/8/6 13:25, Takashi Inoue 写道: Hi, Did you compile your program with the i686 compiler or the x86_64 compiler? I suspect it has something to do with the floating-point environment. My windows is 64bit version widows 8.1. So, I installed x86_64 package via msys2 pacman. Would you please check the sum of 1.9998 and 1.1102230246251564e-16, in both the main thread and an OMP thread? IEEE-conforming double precision (with a 53-bit mantissa) arithmetic shall yield 1.9998, while a defective implementation (for example, if your FORTRAN compiler performs 64-bit addition with x87, rounds the result accordingly, then double-rounds it to 53-bit precision), you may get 2.0 [1]. The mingw-w64 CRT initializes the x87 control word to 64-bit precision, in contrast to MSVCRT which defaults to 53-bit precision, and may produce unexpected results under rare circumstances. [1] https://wandbox.org/permlink/v63VObkDke527VrJ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
Hi all I sent below. But, it seems not accepted. I'll try some other way. Although I wrote this, it seems that I could send. Please rename back Makefile.txt to Makefile and sample.txt to sample.f. I'm sorry for this. Now, I've learned that suffix has nothing to do with. Best, Takashi On 08/06/20 15:50, Takashi Inoue wrote: Hi all, I sent below. But, it seems not accepted. I'll try some other way. Best Takashi Hi All, Thank you for reply. > No attachment. >Try attachment as .txt. I'm sorry. In the previous mail, I attached a tar+gziped file sample.tgz. It seems, binary files are not accepted. Now, I try files with .txt. I renamed Makefile to Makefile.txt and sample.f to sample.txt. And I attach these two text files. I hope I can send this time. Best, Takashi On 08/06/20 06:53, NightStrike wrote: No attachment On Wed, Aug 5, 2020, 12:01 PM Takashi Inoue wrote: Hi All, This is my first post to here. Nice to meet you. I may found a bug in mingw-w64. In particular, it is in OpenMP schedule(dynamic, chunk-size). Let me ask your opinion. One of my fortran program with "!$omp do schedule(dynamic,1)" produce slightly different result at time to time. This does not happen with GCC on FreeBSD and NAG on Windows. So, I think nothing is wrong in my code. (But, I'm not 100% sure.) Mingw-w64 which I installed is the latest package for msys2. For those who are interested in this problem, I attach a sample code which reproduce the problem. (This may not be appropriate for mailing list. I'm sorry). If you run the program several times, you will get slightly different fort.99 at time to time. Perhaps this problem has root in POSIX threading in mingw-w64. Any comments and suggestions will be appreciated. Best, Takashi ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
Hi All, Thank you for reply. > No attachment. >Try attachment as .txt. I'm sorry. In the previous mail, I attached a tar+gziped file sample.tgz. It seems, binary files are not accepted. Now, I try files with .txt. I renamed Makefile to Makefile.txt and sample.f to sample.txt. And I attach these two text files. I hope I can send this time. Best, Takashi On 08/06/20 06:53, NightStrike wrote: No attachment On Wed, Aug 5, 2020, 12:01 PM Takashi Inoue wrote: Hi All, This is my first post to here. Nice to meet you. I may found a bug in mingw-w64. In particular, it is in OpenMP schedule(dynamic, chunk-size). Let me ask your opinion. One of my fortran program with "!$omp do schedule(dynamic,1)" produce slightly different result at time to time. This does not happen with GCC on FreeBSD and NAG on Windows. So, I think nothing is wrong in my code. (But, I'm not 100% sure.) Mingw-w64 which I installed is the latest package for msys2. For those who are interested in this problem, I attach a sample code which reproduce the problem. (This may not be appropriate for mailing list. I'm sorry). If you run the program several times, you will get slightly different fort.99 at time to time. Perhaps this problem has root in POSIX threading in mingw-w64. Any comments and suggestions will be appreciated. Best, Takashi ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public .SUFFIXES: .f .o FORTRAN = gfortran FFLAGS = -fopenmp -O3 -Wall PROG0 = sample.exe OBJS0 = sample.o $(PROG0) : $(OBJS0) $(FORTRAN) $(FFLAGS) $(OBJS0) $(LIBS) -o $(PROG0) .f.o: $(FORTRAN) $(FFLAGS) -c $< clean: rm -f *.o *~ *.exe c1-2-3-4-5-67-- c Example of possible bug in "omp do schedule(dynamic,1)" of mingw-w64 c1-2-3-4-5-67-- program Exsample implicit none integer NofSTO(1), Border(1) integer LM(2,5), NoPgf(5) integer Nolmn(5), lmn(3,3,5) double precision Zeta(3,1), Posi(3,1) double precision lmncf(3,5), ai(6,5), di(6,5) double precision Norm(5,5) double precision bohr integer i,j c1-2-3-4-5-67-- bohr = 0.52917721042381560d0 Zeta(1,1) = 7.66d0/bohr Zeta(2,1) = 2.25d0/bohr Zeta(3,1) = 0d0 NofSTO(1) = 5 Border(1) = 5 Posi(1,1) = 0d0 Posi(2,1) = 0d0 Posi(3,1) = 0d0 c1-2-3-4-5-67-- call makeLMlmn_STO3G(LM,NoPgf,Nolmn,lmn,lmncf) call makeKLMG_STO3G(Zeta(:,1),ai,di) call calcnorm(1,Posi,5,Border, & LM,NoPgf,Nolmn,lmn,lmncf,ai,di,Norm) do j=1,5 do i=1,5 write(99,*) i,j, Norm(i,j) end do end do end c1-2-3-4-5-67-- c1-2-3-4-5-67-- c Return matrix c1-2-3-4-5-67-- subroutine calcnorm(Natom,Posi,NofBase,Border, & LM,NoPgf,Nolmn,lmn,lmncf,ai,di,Norm) implicit none integer,intent(in):: Natom,NofBase,Border(Natom) integer,intent(in):: LM(2,NofBase),NoPgf(NofBase) integer,intent(in):: Nolmn(NofBase),lmn(3,3,NofBase) double precision, intent(in):: Posi(3,Natom),lmncf(3,NofBase) double precision, intent(in):: ai(6,NofBase),di(6,NofBase) double precision, intent(out):: Norm(NofBase,NofBase) double precision, parameter :: Pi = 3.1415926535897932d0 double precision XA(3),XB(3),XO(3) double precision alP,alQ,ciP,ciQ,NrP,NrQ double precision OvI,temp integer lmnP(3),lmnQ(3),Lp,Lq,Mp,Mq integer pp,qq,a,b,p,q integer i,j,ii,jj c1-2-3-4-5-67-- call zero1dim(3,XO) !$omp parallel num_threads(4) !$omp+private(pp,qq,i,j,ii,jj) !$omp+private(Lp,Mp,Lq,Mq,a,b,p,q) !$omp+private(XA,XB) !$omp+private(alP,NrP,ciP,lmnP) !$omp+private(alQ,NrQ,ciQ,lmnQ) !$omp+private(temp,OvI) !$omp do schedule(dynamic,1) do 20 qq=1, NofBase Lq = LM(1,qq) Mq = LM(2,qq) call pp2ap(Natom,Border,qq,b,q) do i=1,3 XB(i)=Posi(i,b) end do do 10 pp=qq, NofBase Lp = LM(1,pp) Mp = LM(2,pp) call pp2ap(Natom,Border,pp,a,p) do i=1,3 XA(i)=Posi(i,a) end do c temp = 0d0 do
Re: [Mingw-w64-public] a possible bug in mingw-w64
Hi all, I sent below. But, it seems not accepted. I'll try some other way. Best Takashi Hi All, Thank you for reply. > No attachment. >Try attachment as .txt. I'm sorry. In the previous mail, I attached a tar+gziped file sample.tgz. It seems, binary files are not accepted. Now, I try files with .txt. I renamed Makefile to Makefile.txt and sample.f to sample.txt. And I attach these two text files. I hope I can send this time. Best, Takashi On 08/06/20 06:53, NightStrike wrote: No attachment On Wed, Aug 5, 2020, 12:01 PM Takashi Inoue wrote: Hi All, This is my first post to here. Nice to meet you. I may found a bug in mingw-w64. In particular, it is in OpenMP schedule(dynamic, chunk-size). Let me ask your opinion. One of my fortran program with "!$omp do schedule(dynamic,1)" produce slightly different result at time to time. This does not happen with GCC on FreeBSD and NAG on Windows. So, I think nothing is wrong in my code. (But, I'm not 100% sure.) Mingw-w64 which I installed is the latest package for msys2. For those who are interested in this problem, I attach a sample code which reproduce the problem. (This may not be appropriate for mailing list. I'm sorry). If you run the program several times, you will get slightly different fort.99 at time to time. Perhaps this problem has root in POSIX threading in mingw-w64. Any comments and suggestions will be appreciated. Best, Takashi ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
Hi, Did you compile your program with the i686 compiler or the x86_64 compiler? I suspect it has something to do with the floating-point environment. My windows is 64bit version widows 8.1. So, I installed x86_64 package via msys2 pacman. Best, Takashi On 08/06/20 12:07, Liu Hao wrote: 在 2020/8/5 下午11:32, Takashi Inoue 写道: Hi All, This is my first post to here. Nice to meet you. Nice to meet you, too. I may found a bug in mingw-w64. In particular, it is in OpenMP schedule(dynamic, chunk-size). Let me ask your opinion. One of my fortran program with "!$omp do schedule(dynamic,1)" produce slightly different result at time to time. This does not happen with GCC on FreeBSD and NAG on Windows. So, I think nothing is wrong in my code. (But, I'm not 100% sure.) Mingw-w64 which I installed is the latest package for msys2. For those who are interested in this problem, I attach a sample code which reproduce the problem. (This may not be appropriate for mailing list. I'm sorry). If you run the program several times, you will get slightly different fort.99 at time to time. Perhaps this problem has root in POSIX threading in mingw-w64. Any comments and suggestions will be appreciated. (I know no Fortran and this is only personal speculation.) Did you compile your program with the i686 compiler or the x86_64 compiler? I suspect it has something to do with the floating-point environment. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
在 2020/8/5 下午11:32, Takashi Inoue 写道: > Hi All, > > This is my first post to here. Nice to meet you. > Nice to meet you, too. > I may found a bug in mingw-w64. > In particular, it is in OpenMP schedule(dynamic, chunk-size). > Let me ask your opinion. > > One of my fortran program with "!$omp do schedule(dynamic,1)" > produce slightly different result at time to time. > This does not happen with GCC on FreeBSD and NAG on Windows. > So, I think nothing is wrong in my code. (But, I'm not 100% sure.) > Mingw-w64 which I installed is the latest package for msys2. > > For those who are interested in this problem, > I attach a sample code which reproduce the problem. > (This may not be appropriate for mailing list. I'm sorry). > If you run the program several times, you will get slightly > different fort.99 at time to time. > Perhaps this problem has root in POSIX threading in mingw-w64. > > Any comments and suggestions will be appreciated. > (I know no Fortran and this is only personal speculation.) Did you compile your program with the i686 compiler or the x86_64 compiler? I suspect it has something to do with the floating-point environment. -- Best regards, LH_Mouse signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
On 8/5/20 9:53 PM, NightStrike wrote: > No attachment > Try attaching as .txt. signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] a possible bug in mingw-w64
No attachment On Wed, Aug 5, 2020, 12:01 PM Takashi Inoue wrote: > Hi All, > > This is my first post to here. Nice to meet you. > > I may found a bug in mingw-w64. > In particular, it is in OpenMP schedule(dynamic, chunk-size). > Let me ask your opinion. > > One of my fortran program with "!$omp do schedule(dynamic,1)" > produce slightly different result at time to time. > This does not happen with GCC on FreeBSD and NAG on Windows. > So, I think nothing is wrong in my code. (But, I'm not 100% sure.) > Mingw-w64 which I installed is the latest package for msys2. > > For those who are interested in this problem, > I attach a sample code which reproduce the problem. > (This may not be appropriate for mailing list. I'm sorry). > If you run the program several times, you will get slightly > different fort.99 at time to time. > Perhaps this problem has root in POSIX threading in mingw-w64. > > Any comments and suggestions will be appreciated. > > Best, > Takashi > > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public