Hi Nicolas,
> Here is the next version of the async I/O patch. It adds the documentation,
> renames the testcases, uses "gthr.h", follows the style guidelines and has
> been regression tested cleanly.
>
> As for adding additional flags, I think it would be better to follow ifort
> to minimize
Hey everyone,
Here is the next version of the async I/O patch. It adds the
documentation, renames the testcases, uses "gthr.h", follows the style
guidelines and has been regression tested cleanly.
As for adding additional flags, I think it would be better to follow
ifort to minimize
On 2018-06-11 11:24 AM, Rainer Orth wrote:
Hi John,
On 2018-06-03 2:59 PM, Nicolas Koenig wrote:
Since the implementation relies on pthreads, it would be great if
somebody could try the patch on non-linux targets, to see whether it
causes any problems there.
I tried it on
Hi John,
> On 2018-06-03 2:59 PM, Nicolas Koenig wrote:
>> Since the implementation relies on pthreads, it would be great if
>> somebody could try the patch on non-linux targets, to see whether it
>> causes any problems there.
> I tried it on hppa64-hp-hpux11.11. The gomp support mostly works on
On 2018-06-03 2:59 PM, Nicolas Koenig wrote:
Since the implementation relies on pthreads, it would be great if
somebody could try the patch on non-linux targets, to see whether it
causes any problems there.
I tried it on hppa64-hp-hpux11.11. The gomp support mostly works on
this target.
I
>>> FAIL: gfortran.dg/f2003_inquire_1.f03 -O1 execution test
>
> This seems to be a bug in the test suite. It tries to find out whether an id
> is pending that is never initialized.
>
>>> FAIL: gfortran.dg/f2003_io_1.f03 -O*
>
> And another bug in the test suite. This time the wait
Hi Nicolas,
a few other nits:
* The current patch has a large number of GNU Coding Style violations,
many catched by contrib/check_GNU_style.{sh,py}.
* Others are partially pre-existing (additional blank before formal
paramater name as in
+destroy_adv_cond (struct adv_cond * ac)
and
Hi Jakub,
>> I do note that if one has, say, 8 files and only one
>> file uses async IO, then during linking of the 8 *.o
>> files to make the final execute -lpthread must be added.
>> How doesn't gfortran communicate that to the loader?
>
> ELF doesn't a way to do this, you'd need to add a
On Tue, Jun 05, 2018 at 11:47:21PM -0700, Steve Kargl wrote:
> I have not looked at the source code, but do have a question.
> With -fopenmp, gfortran automatically adds -lpthread to
> the command line. Is it possible during the parsing
Even if it wouldn't, libgomp.so.1 depends on
On 06/04/2018 11:21 PM, JonY wrote:
> On 06/03/2018 06:59 PM, Nicolas Koenig wrote:
>> Hello everyone,
>>
>> this patch adds asynchronous I/O support. Thomas and I finally finished
>> a feature-complete and debugged version, so here it is. In order to use
>> asynchronous I/O, it is still necessary
On Wed, Jun 06, 2018 at 08:34:57AM +0300, Janne Blomqvist wrote:
> On Wed, Jun 6, 2018 at 3:43 AM, Jerry DeLisle wrote:
>
> > On 06/05/2018 06:58 AM, Rainer Orth wrote:
> >
> >> Hi Nicolas,
> >>
> >> Because they were originally intended for the gfortran test suite, but I
> >>> couldn't run it
On Wed, Jun 6, 2018 at 3:43 AM, Jerry DeLisle wrote:
> On 06/05/2018 06:58 AM, Rainer Orth wrote:
>
>> Hi Nicolas,
>>
>> Because they were originally intended for the gfortran test suite, but I
>>> couldn't run it there because of libpthread. I will change the numbering
>>> scheme.
>>>
>>
>> the
On 06/05/2018 06:58 AM, Rainer Orth wrote:
Hi Nicolas,
Because they were originally intended for the gfortran test suite, but I
couldn't run it there because of libpthread. I will change the numbering
scheme.
the way that libpthread dependency is currently handled seems weird to
me: right
Hi Nicolas,
> Because they were originally intended for the gfortran test suite, but I
> couldn't run it there because of libpthread. I will change the numbering
> scheme.
the way that libpthread dependency is currently handled seems weird to
me: right now it is only dragged in via -fopenmp,
On 06/03/2018 06:59 PM, Nicolas Koenig wrote:
> Hello everyone,
>
> this patch adds asynchronous I/O support. Thomas and I finally finished
> a feature-complete and debugged version, so here it is. In order to use
> asynchronous I/O, it is still necessary to link against libpthread,
> libgomp or
Hi Dominique and Rainer,
First of all thanks for testing!
Hi Dominique, Nicolas,
I have applied your patch on top of revision r261130 on
x86_64-apple-darwin17 (SSD with APFS file system).
I've tried it on i386-pc-solaris2.11 and sparc-sun-solaris2.11.
I also see two regressions
FAIL:
Hi Nicolas,
> P.S.: I would very much recommend removing the #undef DEBUG in async.h. I
> have to admit, I am quite proud of the debug printouts. They even build a
> data structure in the background telling you were a locked mutex was
> locked.
however, doing so breaks quite a number of tests in
Hi Dominique, Nicolas,
> I have applied your patch on top of revision r261130 on
> x86_64-apple-darwin17 (SSD with APFS file system).
I've tried it on i386-pc-solaris2.11 and sparc-sun-solaris2.11.
> I also see two regressions
>
> FAIL: gfortran.dg/f2003_inquire_1.f03 -O1 execution test
>
>
Hi Nicolas,
I have applied your patch on top of revision r261130 on x86_64-apple-darwin17
(SSD with APFS file system).
The only remaining failure on my own tests is for the test (pr35840)
write(10,*, asynchronous="Y"//"E"//trim("S "))
end
giving at run time
At line 1 of file pr35840.f90
Hello everyone,
this patch adds asynchronous I/O support. Thomas and I finally finished
a feature-complete and debugged version, so here it is. In order to use
asynchronous I/O, it is still necessary to link against libpthread,
libgomp or another library linked against any of the
20 matches
Mail list logo
