Hello, I was implementing lock/unlock on the library side when I found a possible problem in the patch:
if (is_lock_type == GFC_CAF_CRITICAL) + reg_type = sym->attr.artificial ? GFC_CAF_CRITICAL : GFC_CAF_LOCK_STATIC; + else + reg_type = GFC_CAF_COARRAY_STATIC; the if statement cannot be true since is_lock_type is a boolean and GFC_CAF_CRITICAL is 4. Using if (is_lock_type) it produces the right result for the lock registration. Regards Alessandro 2014-07-28 14:37 GMT-06:00 Tobias Burnus <bur...@net-b.de>: > This patch implements -fcoarray=lib support for CRITICAL blocks and includes > some preparatory work for locking. In particular: > > * Updated the documentation for locking/critical, minor cleanup. The patch > goes on top of the unreviewed patch > https://gcc.gnu.org/ml/fortran/2014-07/msg00155.html > * Add libcaf_single implementation for lock/unlock > * Add lock/unlock calls for CRITICAL > * Register static/SAVEd locking variables and locking variables for critical > sections. > > Build and currently regtesting on x86-64-gnu-linux. > OK when it regtested successfully? > > * * * > > Still to be done as follow up: > * Handling the registering of lock-type components in statically allocated > derived types > * Handling the registering of lock-type variables and components with > allocate and with implicit/explicit deallocate > * Calling lock/unlock function for those > * Test case for locking and critical blocks > > Other coarray to-do items: > * Type-conversion test case missing > * Vector subscript library implementation + test cases > * Extending the documentation > * Issues with striding for coarray components of derived types > * Nonallocatable polymophic coarrays and select type/associated > * Allocatable/pointer components of coarrays; co_reduce and co_broadcast > > Tobias
