On Thu, 15 Dec 2022 16:46:50 +
Julian Brown wrote:
> On Thu, 15 Dec 2022 14:54:58 +
> Julian Brown wrote:
>
> > On Wed, 7 Dec 2022 17:31:20 +0100
> > Tobias Burnus wrote:
> >
> > > Hi Julian,
> > >
> > > I think this patch is OK; however, at least for gimplify.cc Jakub
> > > needs
On Thu, 15 Dec 2022 14:54:58 +
Julian Brown wrote:
> On Wed, 7 Dec 2022 17:31:20 +0100
> Tobias Burnus wrote:
>
> > Hi Julian,
> >
> > I think this patch is OK; however, at least for gimplify.cc Jakub
> > needs to have a second look.
>
> Thanks for the review! Here's a new version
On Wed, 7 Dec 2022 17:31:20 +0100
Tobias Burnus wrote:
> Hi Julian,
>
> I think this patch is OK; however, at least for gimplify.cc Jakub
> needs to have a second look.
Thanks for the review! Here's a new version that hopefully addresses
your comments. (The gimplify bits change a bit more in
Hi Julian,
I think this patch is OK; however, at least for gimplify.cc Jakub needs to have
a second look.
As remarked for the 2/4 patch, I believe mapping 'map(tofrom: var%f(2:3))'
should work
without explicitly mapping 'map(tofrom: var%f)'
(→ [TR11 157:21-26] (approx. [5.2 154:22-27], [5.1
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
