This is the mail archive of the
mailing list for the GCC project.
Re: PING â Re: [Patch, Fortran] -fcoarray=lib - support CRITICAL, prepare for locking support
- From: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: Alessandro Fanfarillo <fanfarillo dot gcc at gmail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Thu, 14 Aug 2014 11:33:26 +0200
- Subject: Re: PING â Re: [Patch, Fortran] -fcoarray=lib - support CRITICAL, prepare for locking support
- Authentication-results: sourceware.org; auth=none
- References: <53D6B479 dot 7020905 at net-b dot de> <CAHqFgjX2c3=5uVekNMLwpzmpzW6bDOK6kezxREXKjv2wrgr0iw at mail dot gmail dot com> <53E1CF2D dot 2 at net-b dot de>
Dear Tobias, dear all,
This patch and the documentation patch are OK for trunk.
On 6 August 2014 08:46, Tobias Burnus <email@example.com> wrote:
> * PING * â of the patch with the obvious change mentioned by Alessandro
> (i.e. using "if(is_lock_type)")?
> On 1 August 2014 21:57, Alessandro Fanfarillo wrote:
>> 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 :
>> + 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
>> 2014-07-28 14:37 GMT-06:00 Tobias Burnus <firstname.lastname@example.org>:
>>> This patch implements -fcoarray=lib support for CRITICAL blocks and
>>> some preparatory work for locking. In particular:
>>> * Updated the documentation for locking/critical, minor cleanup. The
>>> goes on top of the unreviewed patch
>>> * Add libcaf_single implementation for lock/unlock
>>> * Add lock/unlock calls for CRITICAL
>>> * Register static/SAVEd locking variables and locking variables for
>>> 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
>>> 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
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy