This patch adds support for 'omp loop' to gfortran including the combined
constructs. It also fixes some splitting issues with clauses in
combined constructs.
It does not attempt to clean up all remaining Fortran issues with
clauses in combined constructs (cf. below + PR).
* * *
Since 'paralle
On Wed, 2 Jun 2021 13:59:05 +0200
Richard Biener wrote:
> On Wed, Jun 2, 2021 at 12:47 PM Julian Brown
> wrote:
> >
> > For historical reasons, it seems that extract_base_bit_offset
> > unnecessarily used two different ways to strip
> > ARRAY_REF/INDIRECT_REF nodes from component accesses. I ver
Maybe so. If people don't want to have their mail mistaken for phishing
attacks they should avoid writing it to look like one. Things like "to confirm
this is not spam" are utterly meaningless. A "forms.gle" URL I have only seen
in fraudulent emails; ditto google/forms URLs. And in particula
I am not sure that your diagnosis is correct: the survey was announcement
by Stack Overflow. See https:// stackoverflow.blog/ 2021/ 05/
25/the-2021-developer-survey-is-now-open/
?utm_source=Iterable&utm_medium=email&utm_campaign=the_overflow_newsletter
(to avoid an embedded link just in case, I hav
That sure looks like a phishing attack. The .gle link is a major red flag.
I'm not going there and I would recommend everyone else avoid it too.
paul
> On Jun 1, 2021, at 11:02 PM, Dev Survey via Fortran
> wrote:
>
> Dear All,
> I have attached a survey form so that I can better un
On Wed, Jun 2, 2021 at 12:47 PM Julian Brown wrote:
>
> For historical reasons, it seems that extract_base_bit_offset
> unnecessarily used two different ways to strip ARRAY_REF/INDIRECT_REF
> nodes from component accesses. I verified that the two ways of performing
> the operation gave the same re
This patch reworks indirect struct handling in gimplify.c (i.e. for
struct components mapped with "mystruct->a[0:n]", "mystruct->b", etc.),
for OpenACC. The key observation leading to these changes was that
component mappings of references-to-structures is already implemented
and working, and indi
This patch is a second attempt at refactoring struct component mapping
handling for OpenACC/OpenMP during gimplification, after the patch I
posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2018-November/510503.html
And improved here, post-review:
https://gcc.gnu.org/pipermail/gcc-patch
For historical reasons, it seems that extract_base_bit_offset
unnecessarily used two different ways to strip ARRAY_REF/INDIRECT_REF
nodes from component accesses. I verified that the two ways of performing
the operation gave the same results across the whole testsuite (and
several additional benchm
It never makes sense for a GOMP_MAP_ATTACH_DETACH mapping to survive
beyond gimplify.c, so this patch rewrites such mappings to GOMP_MAP_ATTACH
or GOMP_MAP_DETACH unconditionally (rather than checking for a list
of types of OpenACC or OpenMP constructs), in cases where it hasn't
otherwise been done
This is a merge to the og11 branch of the patch series posted for
mainline here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570396.html
and for the og10 branch here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570810.html
Re-tested with offloading to NVPTX. I will push to the
11 matches
Mail list logo
