Re: [Mingw-w64-public] a possible bug in mingw-w64

2020-08-13 Thread Liu Hao
在 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

2020-08-13 Thread 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.

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

2020-08-12 Thread Takashi Inoue

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-08-11 Thread Liu Hao
在 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

2020-08-11 Thread Takashi Inoue

 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

2020-08-10 Thread 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.

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-08-06 Thread Liu Hao
在 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

2020-08-06 Thread 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.

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

2020-08-06 Thread Takashi Inoue

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

2020-08-06 Thread Takashi Inoue

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

2020-08-06 Thread Takashi Inoue

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

2020-08-06 Thread Takashi Inoue

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

2020-08-05 Thread 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.

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-08-05 Thread Liu Hao
在 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

2020-08-05 Thread JonY via Mingw-w64-public
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

2020-08-05 Thread NightStrike
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