* PING * – of the patch with the obvious change mentioned by Alessandro
(i.e. using "if(is_lock_type)")?
Tobias
On 1 August 2014 21:57, Alessandro Fanfarillo wrote:
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
