Alessandro Fanfarillo wrote:
In attachment the patch for gcc5-branch.
Commited as Rev. 231626.
Tobias
2015-12-10 10:03 GMT+01:00 Tobias Burnus :
Hi Alessandro (off list),
On Thu, Dec 10, 2015 at 09:44:16AM +0100, Alessandro Fanfarillo wrote:
Yes, the patch should be applied to GCC 5 too.
2015-12-09 23:16 GMT+01:00 Tobias Burnus :
> Thanks. Committed as r231476.
Thanks.
>
> Do we need to do anything about GCC 5 or is this only a GCC 6 issue?
>
Yes, the patch should be applied to GCC 5 too.
> That can be changed: Simply fill out the form and list me (burnus (at]
> gcc.gnu.org) as
Alessandro Fanfarillo wrote:
Done.
Thanks. Committed as r231476.
Do we need to do anything about GCC 5 or is this only a GCC 6 issue?
I have permission for contributing but I don't have write permission
on the repository.
That can be changed: Simply fill out the form and list me (burnus (at
Done.
I have permission for contributing but I don't have write permission
on the repository.
2015-12-09 8:23 GMT+01:00 Tobias Burnus :
> Alessandro Fanfarillo wrote:
>>
>> in attachment the new patch. I also checked the behavior with
>> move_alloc: it synchronizes right after the deregistration
On 08/12/15 09:25, Tobias Burnus wrote:
On Mon, Dec 07, 2015 at 02:09:22PM +, Matthew Wahab wrote:
I wonder whether using
__asm__ __volatile__ ("":::"memory");
would be sufficient as it has a way lower overhead than
__sync_synchronize().
I don't know anything about Fortran or coarrays and
Alessandro Fanfarillo wrote:
in attachment the new patch. I also checked the behavior with
move_alloc: it synchronizes right after the deregistration of the
destination.
I also noticed that __asm__ __volatile__ ("":::"memory") is called
before sync all and not after. It shouldn't be a problem, ri
Hi,
in attachment the new patch. I also checked the behavior with
move_alloc: it synchronizes right after the deregistration of the
destination.
I also noticed that __asm__ __volatile__ ("":::"memory") is called
before sync all and not after. It shouldn't be a problem, right?
2015-12-08 11:01 GM
Dear Alessandro, dear all,
On Mon, Dec 07, 2015 at 03:48:17PM +0100, Alessandro Fanfarillo wrote:
> Your patch fixes the issues. In attachment patch, test case and changelog.
Regarding the ChangeLog: Please include the added lines, only, and not the
change as patch. gcc/testsuite/ChangeLog change
On Mon, Dec 07, 2015 at 02:09:22PM +, Matthew Wahab wrote:
> >>I wonder whether using
> >>__asm__ __volatile__ ("":::"memory");
> >>would be sufficient as it has a way lower overhead than
> >>__sync_synchronize().
>
> I don't know anything about Fortran or coarrays and I'm curious
> whether thi
Your patch fixes the issues. In attachment patch, test case and changelog.
Thanks!
2015-12-07 11:06 GMT+01:00 Tobias Burnus :
> I wrote:
>> I wonder whether using
>>
>> __asm__ __volatile__ ("":::"memory");
>>
>> would be sufficient as it has a way lower overhead than
>> __sync_synchronize().
>
>
On 07/12/15 10:06, Tobias Burnus wrote:
I wrote:
I wonder whether using
__asm__ __volatile__ ("":::"memory");
would be sufficient as it has a way lower overhead than
__sync_synchronize().
Namely, something like the attached patch.
Regarding the original patch submission: Is there a reason t
I wrote:
> I wonder whether using
>
> __asm__ __volatile__ ("":::"memory");
>
> would be sufficient as it has a way lower overhead than
> __sync_synchronize().
Namely, something like the attached patch.
Regarding the original patch submission: Is there a reason that you didn't
include the test c
Hi,
2015-12-07 8:20 GMT+01:00 Tobias Burnus :
> Always - or only with optimization?
>
Only with optimization.
> I wonder whether using
>
> __asm__ __volatile__ ("":::"memory");
>
> would be sufficient as it has a way lower overhead than
> __sync_synchronize().
>
>
> That would be something like:
Dear Alessandro, dear all,
Alessandro Fanfarillo wrote:
currently, a coarray assignment in a program composed by a single
segment (without any sync statements) produces wrong results.
Always - or only with optimization?
Furthermore, a coarray code
compiled with an optimization flag higher th
14 matches
Mail list logo
