Hi Julian,
If I understand Deepak's comment (on OpenMP.org's omp-lang list, sorry
it is a nonpublic list) correctly, the following wording implies that a
'from: s.w[z:4]' for a pointer 's.w' also implies a mapping of 's.w' -
if 's' is used inside the target region and, thus, gets implicitly mappe
On Wed, 7 Dec 2022 15:54:42 +0100
Tobias Burnus wrote:
> Hi Julian,
>
> If I understand Deepak's comment (on OpenMP.org's omp-lang list, sorry
> it is a nonpublic list) correctly, the following wording implies that
> a 'from: s.w[z:4]' for a pointer 's.w' also implies a mapping of
> 's.w' - if '
Hi Julian,
On 07.12.22 16:16, Julian Brown wrote:
On Wed, 7 Dec 2022 15:54:42 +0100 Tobias Burnus wrote:
If I understand Deepak's comment (on OpenMP.org's omp-lang list, sorry
it is a nonpublic list) correctly, the following wording implies that
a 'from: s.w[z:4]' for a pointer 's.w' also impl
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 35
On Wed, 26 Oct 2022 12:39:39 +0200
Tobias Burnus wrote:
> The ICE seems to be because gcc/fortran/trans-openmp.cc's
> gfc_split_omp_clauses mishandles this as the dump shows the following:
>
>#pragma omp target firstprivate(a) map(tofrom:a)
> #pragma omp parallel firstprivate(a)
>
> Hi Julian,
>
> I had a first quick lock at this patch, I should have a closer look
> later. However, I stumbled over the following:
>
> On 20.10.22 18:14, Julian Brown wrote:
> > typedef struct gfc_symbol
> > {
> > ...
> >struct gfc_symbol *old_symbol;
> >
> >unsigned mark:1, comp_mark:
Dear all,
we need to be careful about zero-sized arrays in arithmetic
reductions (unary & binary), as we otherwise may hit a NULL
pointer dereference on valid code.
The actual fix is straightforward, see attached patch.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 02a
On Wed, Dec 07, 2022 at 09:57:20PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> we need to be careful about zero-sized arrays in arithmetic
> reductions (unary & binary), as we otherwise may hit a NULL
> pointer dereference on valid code.
>
> The actual fix is straightforward, see atta
Other than Benson, I have received no sign of any interest from gfortran
developers to adopt a teaming/collaboration platform. I am a bit
disappointed. Maybe my intent was misunderstood. I am not suggesting
replacing the email approval process but there are many other features
of these platfo
On 12/8/22 04:54, Jerry D wrote:
Other than Benson, I have received no sign of any interest from gfortran
developers to adopt a teaming/collaboration platform. I am a bit
disappointed. Maybe my intent was misunderstood. I am not suggesting
replacing the email approval process but there are ma
10 matches
Mail list logo
