On Fri, Sep 21, 2018 at 10:33 AM Toon Moene wrote:
> On 09/20/2018 10:01 PM, Thomas Koenig wrote:
>
> > Hi Damian,
> >
> >> On a related note, two Sourcery Institute developers have attempted to
> >> edit
> >> the GCC build system to make the downloading and building of
> OpenCoarrays
> >> automa
On 09/20/2018 10:01 PM, Thomas Koenig wrote:
Hi Damian,
On a related note, two Sourcery Institute developers have attempted to
edit
the GCC build system to make the downloading and building of OpenCoarrays
automatically part of the gfortran build process. Neither developer
succeeded.
We ad
On Thu, Sep 20, 2018 at 1:01 PM Thomas Koenig wrote:
>
> We addressed integrating OpenCoarray into the gcc source tree at the
> recent Gcc summit during the gfortran BoF session.
>
I agree with keeping it as a separate code base, but comments from some
gfortran developers on the gfortran mailing
Hi Damian,
On a related note, two Sourcery Institute developers have attempted to edit
the GCC build system to make the downloading and building of OpenCoarrays
automatically part of the gfortran build process. Neither developer
succeeded.
We addressed integrating OpenCoarray into the gcc sou
On 20/09/18 16:56, Janne Blomqvist wrote:
Ok, looks good.
Thanks.
There are some other remaining incorrect uses of integer_type_node (at
least one visible in the diff), but that can be done as a separate patch
(not saying you must do it as a precondition for anything, though it
would of cou
On Wed, Sep 19, 2018 at 7:24 PM Andrew Stubbs wrote:
> On 05/09/18 19:07, Janne Blomqvist wrote:
> > The argument must be of type size_type_node, not sizetype. Please instead
> > use
> >
> > size = build_zero_cst (size_type_node);
> >
> >
> >> * trans-intrinsic.c (conv_intrinsic_event_qu
On Wed, Sep 19, 2018 at 3:30 PM Andrew Stubbs wrote:
>
> If you want to port your tool to GCN that would be cool, but I suspect
> non-trivial.
>
To clarify, OpenCoarrays is not a tool. It is the parallel ABI required to
create executable programs capable of executing in multiple images as
requi
On 19/09/18 22:18, Damian Rouson wrote:
Has this been tested in multi-image execution using OpenCoarrays? If
not, I would be glad to assist with installing OpenCoarrays so that it
can be part of the testing process.
It's been tested with the GCC testsuite -- the same suite that found the
is
Has this been tested in multi-image execution using OpenCoarrays? If not,
I would be glad to assist with installing OpenCoarrays so that it can be
part of the testing process.
On a related note, two Sourcery Institute developers have attempted to edit
the GCC build system to make the downloading
On 05/09/18 19:07, Janne Blomqvist wrote:
The argument must be of type size_type_node, not sizetype. Please instead
use
size = build_zero_cst (size_type_node);
* trans-intrinsic.c (conv_intrinsic_event_query): Convert computed
index to a size_t type.
Using integer_type_no
Please send fortran patches to the fortran list as well!
On Wed, Sep 5, 2018 at 7:54 PM Toon Moene wrote:
>
>
>
> Forwarded Message
> Subject: [PATCH 08/25] Fix co-array allocation
> Date: Wed, 5 Sep 2018 12:49:40 +0100
> From: a...@codesourcery.
The Fortran front-end has a bug in which it uses "int" values for "size_t"
parameters. I don't know why this isn't problem for all 64-bit architectures,
but GCN ends up with the data in the wrong argument register and/or stack slot,
and bad things happen.
This patch corrects the issue by setting
12 matches
Mail list logo
