This is a new version of the previously-posted series:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603103.html
This version rearranges the patches so the already-approved first two
patches come first -- albeit with some XFAILs -- and alters how Fortran
array-descriptor mappings work
This patch trivially adds braces and reindents the
OMP_CLAUSE_TO/OMP_CLAUSE_FROM/OMP_CLAUSE__CACHE_ stanza in
c_finish_omp_clause and finish_omp_clause, in preparation for the
following patch (to clarify the diff a little).
2022-09-13 Julian Brown
gcc/c/
* c-typeck.cc (c_finish_omp_cla
This patch adds support for non-constant component offsets in "map"
clauses for OpenMP (and the equivalants for OpenACC), which are not able
to be sorted into order at compile time. Normally struct accesses in
such clauses are gathered together and sorted into increasing address
order after a "GOM
Implementing the "omp declare mapper" functionality, I noticed some
cases where handling of derived type members that are pointers doesn't
seem to be quite right. At present, a type such as this:
type T
integer, pointer, dimension(:) :: arrptr
end type T
type(T) :: tvar
[...]
!$omp ta
On Tue, Oct 11, 2022 at 07:42:43 -0400, Ben Boeckel wrote:
> On Mon, Oct 10, 2022 at 17:04:09 -0400, Jason Merrill wrote:
> > Can we share utf8 parsing code with decode_utf8_char in pretty-print.cc?
>
> I can look at factoring that out. I'll have to decode its logic to see
> how much overlap there
On Thu, Oct 13, 2022 at 13:08:46 -0400, David Malcolm wrote:
> On Mon, 2022-10-10 at 16:21 -0400, Jason Merrill wrote:
> > David Malcolm would probably know best about JSON wrangling.
>
> Unfortunately our JSON output doesn't make any guarantees about the
> ordering of keys within an object, so th
On Tue, 18 Oct 2022 03:39:03 -0700
Julian Brown wrote:
> This patch is an extension and rewrite/rethink of the following two
> patches:
(This one is already approved, apart from minor fixes, rebasing and
testsuite tweaks, so I don't think it needs re-review, but I'm holding
off committing it unt
Hi Julian!
On 2022-10-14T13:38:56+, Julian Brown wrote:
> This patch prevents compiler-generated artificial variables from being
> treated as privatization candidates for OpenACC.
>
> The rationale is that e.g. "gang-private" variables actually must be
> shared by each worker and vector spawn
On Tue, 18 Oct 2022 16:46:07 +0200
Thomas Schwinge wrote:
> Hi Julian!
>
> On 2022-10-14T13:38:56+, Julian Brown
> wrote:
> ..., but to my surprised, that did fire in one occasion:
>
> > --- a/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90
> > +++ b/libgomp/testsuite/libgomp.o
Dear all,
Jose posted a patch here that was never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html
I could not find any issues with his patch, it works as advertised
and fixes the reported problem.
As his testcases did not reliably fail without the patch but rather
rando
I intended to add the updated patch but forgot, so here it is...
Am 18.10.22 um 22:41 schrieb Harald Anlauf via Fortran:
Dear all,
Jose posted a patch here that was never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-April/055933.html
I could not find any issues with his patch, it w
11 matches
Mail list logo
