Hi All,
Hi Liu,
I appreciate your prompt work very much!
You immediate found the origin of problem and how to fix.
It is amazing!
0) After applying this patch to winpthreads (and building & installing it)
the output is consistently reproducible. I also checked FPU control words
in OMP t
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 pr
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
d it here intact except for the
name of the attachment.
转发的消息
主题: Re: [Mingw-w64-public] a possible bug in mingw-w64
日期: Tue, 11 Aug 2020 16:58:05 +0900
发件人: Takashi Inoue
收件人: Liu Hao
Hi Liu,
I did attached actually.
I don't know why but my attachments
tend to be dro
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
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 wi
akashi
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 p
st,
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 p
nd 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 i
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,
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(dy
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
13 matches
Mail list logo
