Re: Async I/O patch with compilation fix
David, I will take the "thank you for restoring bootstrap for AIX" as implied in your e-mail. Second, the patch that you applied is unacceptable. ASYNC_IO already is set to zero for AIX. There is a clear procedure for this something that you deem "unacceptable": Submit a patch (for which I promise a fast review) or, if you feel that the patch is simple and obvious, commit it yourself and announce it to the fortran and gcc-patches mailing list. Thomas
Re: Async I/O patch with compilation fix
Thomas, Once the plural.c file has been re-generated incorrectly using the local Yacc, it must be deleted and checked out again. Did you pull it fresh from the repository in your AIX tree after the incorrect checkout? Thanks, David On Wed, Aug 22, 2018 at 5:30 PM Thomas Koenig wrote: > Hi David, > > > This patch broke bootstrap on AIX again. This is completely > unacceptable. > > Again, sorry for the breakage. > > I faced quite some challenges trying to get bootstrap to > work on gcc119. Despite quite a few e-mails (plus hints in a PR) > that I received, none of the hints for bootstrap I got actually got > it to work. I finally gave up after four or five different failures, > and the patch was committed because every test > that _could_ be run did show no failure. > > Had we received instructions that work for bootstrapping on AIX, > we would have tested the patch there. > > If it were possible to add instructions that do work for AIX > bootstrapping to the compile farm wiki, that would be great. > > If you (or somebody else who has the requisite AIX fu) could test > patches that are known to be difficult, that would also be > great. > > As long as we have no other solution, it is probably best to #ifdef out > AIX any additional pthread-related functionality for libgfortran that > might be coming along. That can always be integrated later, if somebody > can re-implement POSIX condition variables for libgfortran from what > AIX provides. > > Let's talk about how to proceed at the GNU cauldron, over a beer. > Both Nicolas and I will be there. > > In the meantime, I have committed the following patch (r263788) as > obvious after regression-testing on Linux both with ASYNC_IO set > to 1 and to 0. Let me know how that works out. > > 2018-08-22 Thomas Koenig > > * async.h: Set ASYNC_IO to zero if _AIX is defined. > (struct adv_cond): If ASYNC_IO is zero, the struct has no members. > (async_unit): If ASYNC_IO is zero, remove unneeded members. > > 2018-08-22 Thomas Koenig > > * gfortran.texi: Mention that asynchronous I/O does > not work on systems which lack condition variables, such > as AIX. > > Regards > > Thomas >
Re: Async I/O patch with compilation fix
Thomas,
After your complaint about bootstrap on gcc119, I tried it again. My
bootstrap worked correctly. I used exactly the public instructions.
Others have been able to bootstrap on gcc119. The problem is local to
you. Does your environment have any special variables?
You can see the bootstrap in /scratch/dje/GCC
Second, the patch that you applied is unacceptable. ASYNC_IO already is
set to zero for AIX. I refuse to accept this patch as correct or complete.
Third, the problem from the beginning has been __gthread_cond_t. The
earlier patch had
struct adv_cond
{
int pending;
__gthread_mutex_t lock;
__gthread_cond_t signal;
};
with __gthread_cond_t clearly not protected by #if ASYNC_IO. This is
visible by inspection. Without a bootstrap, this patch should have been
visually checked that all uses of __gthread_cond_t were protected.
Similarly one can test this / confirm this on any system by setting
ASYNC_IO to 0 and ensuring that __gthread_cond_t is not declared. This
simply is sloppy work.
Please fix this correctly. The current kludge is not acceptable.
Thanks, David
On Wed, Aug 22, 2018 at 5:30 PM Thomas Koenig wrote:
> Hi David,
>
> > This patch broke bootstrap on AIX again. This is completely
> unacceptable.
>
> Again, sorry for the breakage.
>
> I faced quite some challenges trying to get bootstrap to
> work on gcc119. Despite quite a few e-mails (plus hints in a PR)
> that I received, none of the hints for bootstrap I got actually got
> it to work. I finally gave up after four or five different failures,
> and the patch was committed because every test
> that _could_ be run did show no failure.
>
> Had we received instructions that work for bootstrapping on AIX,
> we would have tested the patch there.
>
> If it were possible to add instructions that do work for AIX
> bootstrapping to the compile farm wiki, that would be great.
>
> If you (or somebody else who has the requisite AIX fu) could test
> patches that are known to be difficult, that would also be
> great.
>
> As long as we have no other solution, it is probably best to #ifdef out
> AIX any additional pthread-related functionality for libgfortran that
> might be coming along. That can always be integrated later, if somebody
> can re-implement POSIX condition variables for libgfortran from what
> AIX provides.
>
> Let's talk about how to proceed at the GNU cauldron, over a beer.
> Both Nicolas and I will be there.
>
> In the meantime, I have committed the following patch (r263788) as
> obvious after regression-testing on Linux both with ASYNC_IO set
> to 1 and to 0. Let me know how that works out.
>
> 2018-08-22 Thomas Koenig
>
> * async.h: Set ASYNC_IO to zero if _AIX is defined.
> (struct adv_cond): If ASYNC_IO is zero, the struct has no members.
> (async_unit): If ASYNC_IO is zero, remove unneeded members.
>
> 2018-08-22 Thomas Koenig
>
> * gfortran.texi: Mention that asynchronous I/O does
> not work on systems which lack condition variables, such
> as AIX.
>
> Regards
>
> Thomas
>
Re: Async I/O patch with compilation fix
Hi David,
This patch broke bootstrap on AIX again. This is completely unacceptable.
Again, sorry for the breakage.
I faced quite some challenges trying to get bootstrap to
work on gcc119. Despite quite a few e-mails (plus hints in a PR)
that I received, none of the hints for bootstrap I got actually got
it to work. I finally gave up after four or five different failures,
and the patch was committed because every test
that _could_ be run did show no failure.
Had we received instructions that work for bootstrapping on AIX,
we would have tested the patch there.
If it were possible to add instructions that do work for AIX
bootstrapping to the compile farm wiki, that would be great.
If you (or somebody else who has the requisite AIX fu) could test
patches that are known to be difficult, that would also be
great.
As long as we have no other solution, it is probably best to #ifdef out
AIX any additional pthread-related functionality for libgfortran that
might be coming along. That can always be integrated later, if somebody
can re-implement POSIX condition variables for libgfortran from what
AIX provides.
Let's talk about how to proceed at the GNU cauldron, over a beer.
Both Nicolas and I will be there.
In the meantime, I have committed the following patch (r263788) as
obvious after regression-testing on Linux both with ASYNC_IO set
to 1 and to 0. Let me know how that works out.
2018-08-22 Thomas Koenig
* async.h: Set ASYNC_IO to zero if _AIX is defined.
(struct adv_cond): If ASYNC_IO is zero, the struct has no members.
(async_unit): If ASYNC_IO is zero, remove unneeded members.
2018-08-22 Thomas Koenig
* gfortran.texi: Mention that asynchronous I/O does
not work on systems which lack condition variables, such
as AIX.
Regards
Thomas
Index: gcc/fortran/gfortran.texi
===
--- gcc/fortran/gfortran.texi (Revision 263752)
+++ gcc/fortran/gfortran.texi (Arbeitskopie)
@@ -1509,7 +1509,8 @@
Asynchronous I/O is supported if the program is linked against the
POSIX thread library. If that is not the case, all I/O is performed
-as synchronous.
+as synchronous. On systems which do not support pthread condition
+variables, such as AIX, I/O is also performed as synchronous.
On some systems, such as Darwin or Solaris, the POSIX thread library
is always linked in, so asynchronous I/O is always performed. On other
Index: libgfortran/io/async.h
===
--- libgfortran/io/async.h (Revision 263752)
+++ libgfortran/io/async.h (Arbeitskopie)
@@ -29,7 +29,7 @@
__gthread_cond_t and __gthread_equal / __gthread_self. Check
this. */
-#if defined(__GTHREAD_HAS_COND) && defined(__GTHREADS_CXX0X)
+#if defined(__GTHREAD_HAS_COND) && defined(__GTHREADS_CXX0X) && !defined(_AIX)
#define ASYNC_IO 1
#else
#define ASYNC_IO 0
@@ -328,21 +328,18 @@
struct adv_cond
{
+#if ASYNC_IO
int pending;
__gthread_mutex_t lock;
__gthread_cond_t signal;
+#endif
};
typedef struct async_unit
{
+ pthread_mutex_t io_lock; /* Lock for doing actual I/O. */
pthread_mutex_t lock; /* Lock for manipulating the queue structure. */
- pthread_mutex_t io_lock; /* Lock for doing actual I/O. */
- struct adv_cond work;
- struct adv_cond emptysignal;
- struct st_parameter_dt *pdt;
- pthread_t thread;
- struct transfer_queue *head;
- struct transfer_queue *tail;
+ bool empty;
struct
{
int waiting;
@@ -351,7 +348,13 @@
struct adv_cond done;
} id;
- bool empty;
+#if ASYNC_IO
+ struct adv_cond work;
+ struct adv_cond emptysignal;
+ struct st_parameter_dt *pdt;
+ pthread_t thread;
+ struct transfer_queue *head;
+ struct transfer_queue *tail;
struct {
const char *message;
@@ -361,7 +364,7 @@
int family;
bool fatal_error;
} error;
-
+#endif
} async_unit;
void init_async_unit (gfc_unit *);
Re: Async I/O patch with compilation fix
Thomas, This patch broke bootstrap on AIX again. This is completely unacceptable. In file included from */nasfarm/edelsohn/src/src/libgfortran/runtime/error.c:28*: */nasfarm/edelsohn/src/src/libgfortran/io/async.h:333:3:* *error: *unknown type name '*__gthread_cond_t*' 333 | *__gthread_cond_t* signal; | *^~~~* make[1]: *** [Makefile:2594: error.lo] Error 1 - David On Tue, Aug 21, 2018 at 3:42 PM Thomas Koenig wrote: > Hi everybody, > > Nicolas has committed the patch as r263750. > > PR 87048 now traces the armeb regression, which is > assumed to resurface now. Let's really try and fix > that one before 9.0 :-) > > Regards > > Thomas >
Re: Async I/O patch with compilation fix
Hi everybody, Nicolas has committed the patch as r263750. PR 87048 now traces the armeb regression, which is assumed to resurface now. Let's really try and fix that one before 9.0 :-) Regards Thomas
Re: Async I/O patch with compilation fix
Hi Christophe, Hi, This is done by +#if defined(__GTHREAD_HAS_COND) && defined(__GTHREADS_CXX0X) && !defined(__ARMEB__) +#define ASYNC_IO 1 +#else +#define ASYNC_IO 0 +#endif I tried this version of the patch, and I'm still seeing the regression on array_constructor_8.f90. Urgh... Could you run gcc -dM foo.h with an empty foo.h in your target environment to see if __ARMEB__ is actually defined? If it is not, what other macro or combination of macros could be used? At the moment, and with the data you posted in the PR, it seems that this might be a library problem. Calling different library functions with or without the patch seems to be an indication of that. Currently, this patch holds up other major work :-( What I would propose is to commit the patch as given in https://gcc.gnu.org/ml/fortran/2018-08/msg7.html and open a PR for the strange armeb failure (if the test for the macros above does not a promising approach). Let us then fix this PR before the 9.0 release. Regards Thomas
Re: Async I/O patch with compilation fix
On Fri, 17 Aug 2018 at 17:41, Thomas Koenig wrote: > > Hi Christophe, > Hi, > sorry that this took so long, but a holiday followed by a > business trip seven timezones away can do that :-) > Sorry, I am on holidays too, and not back yet :) > > I applied this patch, and again I still see regressions on > > armeb-none-linux-gnueabihf > > --with-cpu cortex-a9 > > --with-fpu neon-fp16 > > The info that you supplied in the PR indicates some sort of library > problem exposed by the patch, possibly by including gthr.h. > > All Nicolas and I could come up with was to remove the async I/O > functionality from armeb-* and by xfailing the tests. > > This is done by > > +#if defined(__GTHREAD_HAS_COND) && defined(__GTHREADS_CXX0X) && > !defined(__ARMEB__) > +#define ASYNC_IO 1 > +#else > +#define ASYNC_IO 0 > +#endif > > If somebody comes up with something more fine-grained for the > feature test, we can put this in now or later. > > Regression-tested on x86_64-pc-linux-gnu (which showed that > xfail lines in the testsuite aren't wildly inaccurate). > > So, I'd appreciate testing. If this passes, this will be > committed ASAP. > I tried this version of the patch, and I'm still seeing the regression on array_constructor_8.f90. I didn't try to run the new tests (I only applied the patch part) I'll try to investigate the PR a bit more when I'm back at the office (e/o August) Christophe > Regards > > Thomas >
Re: Async I/O patch with compilation fix
Hi Christophe,
sorry that this took so long, but a holiday followed by a
business trip seven timezones away can do that :-)
I applied this patch, and again I still see regressions on
armeb-none-linux-gnueabihf
--with-cpu cortex-a9
--with-fpu neon-fp16
The info that you supplied in the PR indicates some sort of library
problem exposed by the patch, possibly by including gthr.h.
All Nicolas and I could come up with was to remove the async I/O
functionality from armeb-* and by xfailing the tests.
This is done by
+#if defined(__GTHREAD_HAS_COND) && defined(__GTHREADS_CXX0X) &&
!defined(__ARMEB__)
+#define ASYNC_IO 1
+#else
+#define ASYNC_IO 0
+#endif
If somebody comes up with something more fine-grained for the
feature test, we can put this in now or later.
Regression-tested on x86_64-pc-linux-gnu (which showed that
xfail lines in the testsuite aren't wildly inaccurate).
So, I'd appreciate testing. If this passes, this will be
committed ASAP.
Regards
Thomas
Index: gcc/fortran/gfortran.texi
===
--- gcc/fortran/gfortran.texi (Revision 263618)
+++ gcc/fortran/gfortran.texi (Arbeitskopie)
@@ -879,8 +879,7 @@ than @code{(/.../)}. Type-specification for array
@item Extensions to the specification and initialization expressions,
including the support for intrinsics with real and complex arguments.
-@item Support for the asynchronous input/output syntax; however, the
-data transfer is currently always synchronously performed.
+@item Support for the asynchronous input/output.
@item
@cindex @code{FLUSH} statement
@@ -1183,6 +1182,7 @@ might in some way or another become visible to the
* Files opened without an explicit ACTION= specifier::
* File operations on symbolic links::
* File format of unformatted sequential files::
+* Asynchronous I/O::
@end menu
@@ -1486,6 +1486,20 @@ program main
end program main
@end smallexample
+@node Asynchronous I/O
+@section Asynchronous I/O
+@cindex input/output, asynchronous
+@cindex asynchronous I/O
+
+Asynchronous I/O is supported if the program is linked against the
+POSIX thread library. If that is not the case, all I/O is performed
+as synchronous.
+
+On some systems, such as Darwin or Solaris, the POSIX thread library
+is always linked in, so asynchronous I/O is always performed. On other
+sytems, such as Linux, it is necessary to specify @option{-pthread},
+@option{-lpthread} or @option{-fopenmp} during the linking step.
+
@c -
@c Extensions
@c -
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c (Revision 263618)
+++ gcc/fortran/trans-decl.c (Arbeitskopie)
@@ -698,7 +698,8 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
&& CLASS_DATA (sym)->ts.u.derived->attr.has_dtio_procs)))
TREE_STATIC (decl) = 1;
- if (sym->attr.volatile_)
+ /* Treat asynchronous variables the same as volatile, for now. */
+ if (sym->attr.volatile_ || sym->attr.asynchronous)
{
TREE_THIS_VOLATILE (decl) = 1;
TREE_SIDE_EFFECTS (decl) = 1;
Index: gcc/fortran/trans-io.c
===
--- gcc/fortran/trans-io.c (Revision 263618)
+++ gcc/fortran/trans-io.c (Arbeitskopie)
@@ -438,10 +438,9 @@ gfc_build_io_library_fndecls (void)
get_identifier (PREFIX("st_iolength")), ".w",
void_type_node, 1, dt_parm_type);
- /* TODO: Change when asynchronous I/O is implemented. */
parm_type = build_pointer_type (st_parameter[IOPARM_ptype_wait].type);
iocall[IOCALL_WAIT] = gfc_build_library_function_decl_with_spec (
- get_identifier (PREFIX("st_wait")), ".X",
+ get_identifier (PREFIX("st_wait_async")), ".w",
void_type_node, 1, parm_type);
parm_type = build_pointer_type (st_parameter[IOPARM_ptype_filepos].type);
@@ -1527,7 +1526,7 @@ gfc_trans_wait (gfc_code * code)
mask |= IOPARM_common_err;
if (p->id)
-mask |= set_parameter_value (, var, IOPARM_wait_id, p->id);
+mask |= set_parameter_ref (, _block, var, IOPARM_wait_id, p->id);
set_parameter_const (, var, IOPARM_common_flags, mask);
Index: gcc/testsuite/gfortran.dg/f2003_inquire_1.f03
===
--- gcc/testsuite/gfortran.dg/f2003_inquire_1.f03 (Revision 263618)
+++ gcc/testsuite/gfortran.dg/f2003_inquire_1.f03 (Arbeitskopie)
@@ -7,10 +7,12 @@ logical :: vpending
open(10, file='mydata_f2003_inquire_1', asynchronous="yes", blank="null", &
& decimal="comma", encoding="utf-8", sign="plus")
+write (10,*, asynchronous="yes", id=vid) 'asdf'
+wait (10)
+
inquire(unit=10, round=sround, sign=ssign, size=vsize, id=vid, &
& pending=vpending, asynchronous=sasynchronous, decimal=sdecimal, &
& encoding=sencoding)
-
if (ssign.ne."PLUS") STOP 1
if
Re: Async I/O patch with compilation fix
On Sat, 4 Aug 2018 at 00:42, Thomas König wrote: > > Hi Cristophe, > > this is seriously weird - there is not even an I/O statement in that test > case. > > One question: Is this real hardware or an emulator? I'm using QEMU > Also, Could you try a few things? > > Run the test case manually. Do you still fail? Yes. > Is there an error if the executable is run under valgrind? I don't know how to do that with qemu, nor if valgrind supports armeb? > If you have two compilers, one with the patch and one without: Is there a > difference in the generated files for > > -dump-tree-original, -fdump-tree-optimized and -S? I posted a few comments in the associated PR: - the .s files are the same with /without the patch, so I suppose the problem comes from the runtime libraries - I've attached both execution traces and output from objdump on the statically linked executable, so as to hopefully include all the code executed > Regards, Thomas
Re: Async I/O patch with compilation fix
Hi Cristophe, this is seriously weird - there is not even an I/O statement in that test case. One question: Is this real hardware or an emulator? Also, Could you try a few things? Run the test case manually. Do you still fail? Is there an error if the executable is run under valgrind? If you have two compilers, one with the patch and one without: Is there a difference in the generated files for -dump-tree-original, -fdump-tree-optimized and -S? Regards, Thomas
Re: Async I/O patch with compilation fix
On Thu, 2 Aug 2018 at 19:05, Nicolas Koenig wrote: > > On Thu, Aug 02, 2018 at 05:42:46PM +0200, Christophe Lyon wrote: > > On Thu, 2 Aug 2018 at 13:35, Nicolas Koenig > > wrote: > > > > > > > > > Hello everyone, > > > > > > Here is an updated version of the patch that hopefully fixes the > > > compilation > > > problems by disabling async I/O if conditions are not supported by the > > > target. > > > > > > I would appreciate if people could test it on systems on which it failed > > > before. As for the array_constructor_8.f90 failure reported in the PR, why > > > it fails is beyond me, it doesn't even use I/O. Maybe/Probably something > > > unrelated? > > > > > > > Hi, > > I'm probably missing something obvious, but after applying this patch > > on top of r263136, the builds fail while building libgfortran: > > /tmp/9271913_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgfortran/runtime/error.c:28:10: > > fatal error: async.h: No such file or directory > > #include "async.h" > > ^ > > compilation terminated. > > make[3]: *** [error.lo] Error 1 > > > > Hi, > > It wasn't you who missed something obvious. Typing `svn add` is hard. > Here is a version of the patch with the two new files. > OK, I applied this patch, and again I still see regressions on armeb-none-linux-gnueabihf --with-cpu cortex-a9 --with-fpu neon-fp16 FAIL: gfortran.dg/array_constructor_8.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/array_constructor_8.f90 -O3 -g execution test gfortran.log contains: STOP 2 STOP 2 Christophe > Nicolas > > > > Nicolas > > > > > > > > > 2018-08-02 Nicolas Koenig > > > Thomas Koenig > > > > > > PR fortran/25829 > > > * gfortran.texi: Add description of asynchronous I/O. > > > * trans-decl.c (gfc_finish_var_decl): Treat asynchronous variables > > > as volatile. > > > * trans-io.c (gfc_build_io_library_fndecls): Rename st_wait to > > > st_wait_async and change argument spec from ".X" to ".w". > > > (gfc_trans_wait): Pass ID argument via reference. > > > > > > 2018-08-02 Nicolas Koenig > > > Thomas Koenig > > > > > > PR fortran/25829 > > > * gfortran.dg/f2003_inquire_1.f03: Add write statement. > > > * gfortran.dg/f2003_io_1.f03: Add wait statement. > > > > > > 2018-08-02 Nicolas Koenig > > > Thomas Koenig > > > > > > PR fortran/25829 > > > * Makefile.am: Add async.c to gfor_io_src. > > > Add async.h to gfor_io_headers. > > > * Makefile.in: Regenerated. > > > * gfortran.map: Add _gfortran_st_wait_async. > > > * io/async.c: New file. > > > * io/async.h: New file. > > > * io/close.c: Include async.h. > > > (st_close): Call async_wait for an asynchronous unit. > > > * io/file_pos.c (st_backspace): Likewise. > > > (st_endfile): Likewise. > > > (st_rewind): Likewise. > > > (st_flush): Likewise. > > > * io/inquire.c: Add handling for asynchronous PENDING > > > and ID arguments. > > > * io/io.h (st_parameter_dt): Add async bit. > > > (st_parameter_wait): Correct. > > > (gfc_unit): Add au pointer. > > > (st_wait_async): Add prototype. > > > (transfer_array_inner): Likewise. > > > (st_write_done_worker): Likewise. > > > * io/open.c: Include async.h. > > > (new_unit): Initialize asynchronous unit. > > > * io/transfer.c (async_opt): New struct. > > > (wrap_scalar_transfer): New function. > > > (transfer_integer): Call wrap_scalar_transfer to do the work. > > > (transfer_real): Likewise. > > > (transfer_real_write): Likewise. > > > (transfer_character): Likewise. > > > (transfer_character_wide): Likewise. > > > (transfer_complex): Likewise. > > > (transfer_array_inner): New function. > > > (transfer_array): Call transfer_array_inner. > > > (transfer_derived): Call wrap_scalar_transfer. > > > (data_transfer_init): Check for asynchronous I/O. > > > Perform a wait operation on any pending asynchronous I/O > > > if the data transfer is synchronous. Copy PDT and enqueue > > > thread for data transfer. > > > (st_read_done_worker): New function. > > > (st_read_done): Enqueue transfer or call st_read_done_worker. > > > (st_write_done_worker): New function. > > > (st_write_done): Enqueue transfer or call st_read_done_worker. > > > (st_wait): Document as no-op for compatibility reasons. > > > (st_wait_async): New function. > > > * io/unit.c (insert_unit): Use macros LOCK, UNLOCK and TRYLOCK; > > > add NOTE where necessary. > > > (get_gfc_unit): Likewise. > > > (init_units): Likewise. > > > (close_unit_1):
Re: Async I/O patch with compilation fix
On Thu, Aug 02, 2018 at 05:42:46PM +0200, Christophe Lyon wrote: > On Thu, 2 Aug 2018 at 13:35, Nicolas Koenig wrote: > > > > > > Hello everyone, > > > > Here is an updated version of the patch that hopefully fixes the compilation > > problems by disabling async I/O if conditions are not supported by the > > target. > > > > I would appreciate if people could test it on systems on which it failed > > before. As for the array_constructor_8.f90 failure reported in the PR, why > > it fails is beyond me, it doesn't even use I/O. Maybe/Probably something > > unrelated? > > > > Hi, > I'm probably missing something obvious, but after applying this patch > on top of r263136, the builds fail while building libgfortran: > /tmp/9271913_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgfortran/runtime/error.c:28:10: > fatal error: async.h: No such file or directory > #include "async.h" > ^ > compilation terminated. > make[3]: *** [error.lo] Error 1 > Hi, It wasn't you who missed something obvious. Typing `svn add` is hard. Here is a version of the patch with the two new files. Nicolas > > Nicolas > > > > > > 2018-08-02 Nicolas Koenig > > Thomas Koenig > > > > PR fortran/25829 > > * gfortran.texi: Add description of asynchronous I/O. > > * trans-decl.c (gfc_finish_var_decl): Treat asynchronous variables > > as volatile. > > * trans-io.c (gfc_build_io_library_fndecls): Rename st_wait to > > st_wait_async and change argument spec from ".X" to ".w". > > (gfc_trans_wait): Pass ID argument via reference. > > > > 2018-08-02 Nicolas Koenig > > Thomas Koenig > > > > PR fortran/25829 > > * gfortran.dg/f2003_inquire_1.f03: Add write statement. > > * gfortran.dg/f2003_io_1.f03: Add wait statement. > > > > 2018-08-02 Nicolas Koenig > > Thomas Koenig > > > > PR fortran/25829 > > * Makefile.am: Add async.c to gfor_io_src. > > Add async.h to gfor_io_headers. > > * Makefile.in: Regenerated. > > * gfortran.map: Add _gfortran_st_wait_async. > > * io/async.c: New file. > > * io/async.h: New file. > > * io/close.c: Include async.h. > > (st_close): Call async_wait for an asynchronous unit. > > * io/file_pos.c (st_backspace): Likewise. > > (st_endfile): Likewise. > > (st_rewind): Likewise. > > (st_flush): Likewise. > > * io/inquire.c: Add handling for asynchronous PENDING > > and ID arguments. > > * io/io.h (st_parameter_dt): Add async bit. > > (st_parameter_wait): Correct. > > (gfc_unit): Add au pointer. > > (st_wait_async): Add prototype. > > (transfer_array_inner): Likewise. > > (st_write_done_worker): Likewise. > > * io/open.c: Include async.h. > > (new_unit): Initialize asynchronous unit. > > * io/transfer.c (async_opt): New struct. > > (wrap_scalar_transfer): New function. > > (transfer_integer): Call wrap_scalar_transfer to do the work. > > (transfer_real): Likewise. > > (transfer_real_write): Likewise. > > (transfer_character): Likewise. > > (transfer_character_wide): Likewise. > > (transfer_complex): Likewise. > > (transfer_array_inner): New function. > > (transfer_array): Call transfer_array_inner. > > (transfer_derived): Call wrap_scalar_transfer. > > (data_transfer_init): Check for asynchronous I/O. > > Perform a wait operation on any pending asynchronous I/O > > if the data transfer is synchronous. Copy PDT and enqueue > > thread for data transfer. > > (st_read_done_worker): New function. > > (st_read_done): Enqueue transfer or call st_read_done_worker. > > (st_write_done_worker): New function. > > (st_write_done): Enqueue transfer or call st_read_done_worker. > > (st_wait): Document as no-op for compatibility reasons. > > (st_wait_async): New function. > > * io/unit.c (insert_unit): Use macros LOCK, UNLOCK and TRYLOCK; > > add NOTE where necessary. > > (get_gfc_unit): Likewise. > > (init_units): Likewise. > > (close_unit_1): Likewise. Call async_close if asynchronous. > > (close_unit): Use macros LOCK and UNLOCK. > > (finish_last_advance_record): Likewise. > > (newunit_alloc): Likewise. > > * io/unix.c (find_file): Likewise. > > (flush_all_units_1): Likewise. > > (flush_all_units): Likewise. > > * libgfortran.h (generate_error_common): Add prototype. > > * runtime/error.c: Include io.h and async.h. > > (generate_error_common): New function. > > > > 2018-08-02 Nicolas Koenig > > Thomas Koenig > > > > PR fortran/25829 > > * testsuite/libgomp.fortran/async_io_1.f90: New test. > > *
Re: Async I/O patch with compilation fix
On Thu, 2 Aug 2018 at 13:35, Nicolas Koenig wrote: > > > Hello everyone, > > Here is an updated version of the patch that hopefully fixes the compilation > problems by disabling async I/O if conditions are not supported by the target. > > I would appreciate if people could test it on systems on which it failed > before. As for the array_constructor_8.f90 failure reported in the PR, why > it fails is beyond me, it doesn't even use I/O. Maybe/Probably something > unrelated? > Hi, I'm probably missing something obvious, but after applying this patch on top of r263136, the builds fail while building libgfortran: /tmp/9271913_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgfortran/runtime/error.c:28:10: fatal error: async.h: No such file or directory #include "async.h" ^ compilation terminated. make[3]: *** [error.lo] Error 1 > Nicolas > > > 2018-08-02 Nicolas Koenig > Thomas Koenig > > PR fortran/25829 > * gfortran.texi: Add description of asynchronous I/O. > * trans-decl.c (gfc_finish_var_decl): Treat asynchronous variables > as volatile. > * trans-io.c (gfc_build_io_library_fndecls): Rename st_wait to > st_wait_async and change argument spec from ".X" to ".w". > (gfc_trans_wait): Pass ID argument via reference. > > 2018-08-02 Nicolas Koenig > Thomas Koenig > > PR fortran/25829 > * gfortran.dg/f2003_inquire_1.f03: Add write statement. > * gfortran.dg/f2003_io_1.f03: Add wait statement. > > 2018-08-02 Nicolas Koenig > Thomas Koenig > > PR fortran/25829 > * Makefile.am: Add async.c to gfor_io_src. > Add async.h to gfor_io_headers. > * Makefile.in: Regenerated. > * gfortran.map: Add _gfortran_st_wait_async. > * io/async.c: New file. > * io/async.h: New file. > * io/close.c: Include async.h. > (st_close): Call async_wait for an asynchronous unit. > * io/file_pos.c (st_backspace): Likewise. > (st_endfile): Likewise. > (st_rewind): Likewise. > (st_flush): Likewise. > * io/inquire.c: Add handling for asynchronous PENDING > and ID arguments. > * io/io.h (st_parameter_dt): Add async bit. > (st_parameter_wait): Correct. > (gfc_unit): Add au pointer. > (st_wait_async): Add prototype. > (transfer_array_inner): Likewise. > (st_write_done_worker): Likewise. > * io/open.c: Include async.h. > (new_unit): Initialize asynchronous unit. > * io/transfer.c (async_opt): New struct. > (wrap_scalar_transfer): New function. > (transfer_integer): Call wrap_scalar_transfer to do the work. > (transfer_real): Likewise. > (transfer_real_write): Likewise. > (transfer_character): Likewise. > (transfer_character_wide): Likewise. > (transfer_complex): Likewise. > (transfer_array_inner): New function. > (transfer_array): Call transfer_array_inner. > (transfer_derived): Call wrap_scalar_transfer. > (data_transfer_init): Check for asynchronous I/O. > Perform a wait operation on any pending asynchronous I/O > if the data transfer is synchronous. Copy PDT and enqueue > thread for data transfer. > (st_read_done_worker): New function. > (st_read_done): Enqueue transfer or call st_read_done_worker. > (st_write_done_worker): New function. > (st_write_done): Enqueue transfer or call st_read_done_worker. > (st_wait): Document as no-op for compatibility reasons. > (st_wait_async): New function. > * io/unit.c (insert_unit): Use macros LOCK, UNLOCK and TRYLOCK; > add NOTE where necessary. > (get_gfc_unit): Likewise. > (init_units): Likewise. > (close_unit_1): Likewise. Call async_close if asynchronous. > (close_unit): Use macros LOCK and UNLOCK. > (finish_last_advance_record): Likewise. > (newunit_alloc): Likewise. > * io/unix.c (find_file): Likewise. > (flush_all_units_1): Likewise. > (flush_all_units): Likewise. > * libgfortran.h (generate_error_common): Add prototype. > * runtime/error.c: Include io.h and async.h. > (generate_error_common): New function. > > 2018-08-02 Nicolas Koenig > Thomas Koenig > > PR fortran/25829 > * testsuite/libgomp.fortran/async_io_1.f90: New test. > * testsuite/libgomp.fortran/async_io_2.f90: New test. > * testsuite/libgomp.fortran/async_io_3.f90: New test. > * testsuite/libgomp.fortran/async_io_4.f90: New test. > * testsuite/libgomp.fortran/async_io_5.f90: New test. > * testsuite/libgomp.fortran/async_io_6.f90: New test. > * testsuite/libgomp.fortran/async_io_7.f90: New test.
