On 05/02/2022 19:09, Hafiz Abid Qadeer wrote:
> On 04/02/2022 11:25, Hafiz Abid Qadeer wrote:
>> On 04/02/2022 09:46, Thomas Schwinge wrote:
>>
>>>
>>> Abid, are you going to address these? I think it does make sense if the
>>> C/C++ and Fortran test cases match as much as feasible.
>>>
>> Sure. I
On 04/02/2022 11:25, Hafiz Abid Qadeer wrote:
> On 04/02/2022 09:46, Thomas Schwinge wrote:
>
>>
>> Abid, are you going to address these? I think it does make sense if the
>> C/C++ and Fortran test cases match as much as feasible.
>>
> Sure. I will do that.
The attached patch address those issue
On 04.02.22 16:33, Thomas Schwinge wrote:
Maybe removed locally, I can't tell ;-) -- but it's still in the
commit that you pushed. See below.
Also, a commented-out '!$omp barrier'; not sure what that one is about.
I shall not do commits after one week of 6h+/day virtual OpenMP
Face2Face meeting
Hi Tobias!
On 2022-02-04T14:57:07+0100, Tobias Burnus wrote:
> On 04.02.22 10:37, Thomas Schwinge wrote:
>>> I have attached a patch (not commited), which silences the three kind of
>>> warnings and fixes the interface issue.
>>> TODO: commit it.
>> Still "TODO: commit it" ;-) -- and while I have
Hi Thomas,
On 04.02.22 10:37, Thomas Schwinge wrote:
I have attached a patch (not commited), which silences the three kind of
warnings and fixes the interface issue.
TODO: commit it.
Still "TODO: commit it" ;-) -- and while I haven't reviewed the changes
in detail, I did spot one item that shou
On 04/02/2022 09:46, Thomas Schwinge wrote:
>
> Abid, are you going to address these? I think it does make sense if the
> C/C++ and Fortran test cases match as much as feasible.
>
Sure. I will do that.
> However: really (a) remove 'omp_alloctrait (omp_atk_pool_size, 8192)'
> altogether, or ins
Hi!
On 2022-01-31T19:13:09+, Hafiz Abid Qadeer wrote:
> On 25/01/2022 10:32, Tobias Burnus wrote:
>> On 25.01.22 10:19, Thomas Schwinge wrote:
I am trying to figure out if the problem you observed
is a general one or just specific to fortran testcase.
>>> So, unless the '-fsanitize=
Hi Tobias!
On 2022-01-24T09:45:48+0100, Tobias Burnus wrote:
> On 21.01.22 18:43, Tobias Burnus wrote:
>> On 21.01.22 18:15, Thomas Schwinge wrote:
>>> 11 | integer(c_int) function is_64bit_aligned (a) bind(C)
>>> Warning: Variable ‘a’ at (1) is a dummy argument of the BIND(C)
>>
On 25/01/2022 10:32, Tobias Burnus wrote:
> On 25.01.22 10:19, Thomas Schwinge wrote:
>>> I am trying to figure out if the problem you observed
>>> is a general one or just specific to fortran testcase.
>> So, unless the '-fsanitize=thread' issues are bogus -- unlikely ;-) -- it
>> seems a latent i
On 25.01.22 10:19, Thomas Schwinge wrote:
I am trying to figure out if the problem you observed
is a general one or just specific to fortran testcase.
So, unless the '-fsanitize=thread' issues are bogus -- unlikely ;-) -- it
seems a latent issue generally, now fatal with
'libgomp.fortran/allocat
Hi!
On 2022-01-24T12:54:27+, Hafiz Abid Qadeer wrote:
> On 24/01/2022 08:45, Tobias Burnus wrote:
>> On 21.01.22 18:15, Thomas Schwinge wrote:
>>> I'm seeing this test case randomly/non-deterministically FAIL to execute,
>>> differently on different systems and runs, for example: [...]
>>> I'
On 24/01/2022 08:45, Tobias Burnus wrote:
> On 21.01.22 18:43, Tobias Burnus wrote:
>> On 21.01.22 18:15, Thomas Schwinge wrote:
>>> 11 | integer(c_int) function is_64bit_aligned (a) bind(C)
>>> Warning: Variable ‘a’ at (1) is a dummy argument of the BIND(C)
>>> procedure ‘is_64bi
On 21.01.22 18:43, Tobias Burnus wrote:
On 21.01.22 18:15, Thomas Schwinge wrote:
11 | integer(c_int) function is_64bit_aligned (a) bind(C)
Warning: Variable ‘a’ at (1) is a dummy argument of the BIND(C)
procedure ‘is_64bit_aligned’ but may not be C interoperable
[-Wc-binding-ty
On 21.01.22 18:15, Thomas Schwinge wrote:
source-gcc/libgomp/testsuite/libgomp.fortran/allocate-1.f90:11:47:
11 | integer(c_int) function is_64bit_aligned (a) bind(C)
| 1
Warning: Variable ‘a’ at (1) is a dummy argume
Hi Abid!
On 2022-01-11T22:31:54+, Hafiz Abid Qadeer wrote:
> From d1fb55bff497a20e6feefa50bd03890e7a903c0e Mon Sep 17 00:00:00 2001
> From: Hafiz Abid Qadeer
> Date: Fri, 24 Sep 2021 10:04:12 +0100
> Subject: [PATCH] [gfortran] Add support for allocate clause (OpenMP 5.0).
&g
On 14/01/2022 12:20, Tobias Burnus wrote:
> On 14.01.22 12:55, Jakub Jelinek via Fortran wrote:
>> If we want to check intptr_t, we should guard the dg-error with
>> "" { target { lp64 || llp64 } }
>> or so.
>
> Well, if we want to use intptr_t, we could use be explicitly as with:
>
> use iso_c
On 14.01.22 12:55, Jakub Jelinek via Fortran wrote:
If we want to check intptr_t, we should guard the dg-error with
"" { target { lp64 || llp64 } }
or so.
Well, if we want to use intptr_t, we could use be explicitly as with:
use iso_c_binding, only: c_intptr_t
! use omp_lib, only: omp_allo
On Fri, Jan 14, 2022 at 12:45:54PM +0100, Tobias Burnus wrote:
> On 14.01.22 10:10, Thomas Schwinge wrote:
> > > + integer :: x
> > > ...
> > > + !$omp parallel allocate (0: x) private(x) ! { dg-error "Expected
> > > integer expression of the 'omp_allocator_handle_kind' kind at .1." }
> > We do
Hi all,
On 14.01.22 10:10, Thomas Schwinge wrote:
+ integer :: x
...
+ !$omp parallel allocate (0: x) private(x) ! { dg-error "Expected integer
expression of the 'omp_allocator_handle_kind' kind at .1." }
We do for x86_64 default '-m64', but for '-m32' and '-mx32' compilation,
we're not see
Hi Abid!
(Remember to CC for 'gcc/fortran/' etc. changes.)
On 2022-01-11T22:31:54+, Hafiz Abid Qadeer wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/gomp/allocate-2.f90
> @@ -0,0 +1,45 @@
> +! { dg-do compile }
> +
> +module omp_lib_kinds
> + use iso_c_binding, only: c_int, c_in
On Tue, Jan 11, 2022 at 10:31:54PM +, Hafiz Abid Qadeer wrote:
> + gfc_omp_namelist *n;
> + for (n = *head; n; n = n->next)
Better
for (gfc_omp_namelist *n = *head; n; n = n->next)
as we are in C++ and n isn't used after the loop.
> + /* non-composite co
OMP_LIST_TO ? OMP_LIST_LINK : OMP_LIST_NUM))
> for (n = c->lists[list]; n; n = n->next)
> if (n->sym)
> n->sym->mark = 0;
> else if (n->u.common->head)
> n->u.common->head->mark = 0;
> So, a question is if the above won't just crash if
On Thu, Nov 18, 2021 at 07:30:36PM +, Hafiz Abid Qadeer wrote:
> + if (gfc_match (" : ") != MATCH_YES)
> + {
> + /* If no ":" then there is no allocator, we backtrack
> + and read the variable list. */
> + gfc_free_expr (alloca
ut on more than one construct, and then if has_dup_allocate is set, do
> more detailed processing. And finally then {,c_}finish_omp_clauses
> diagnoses what you are trying above, but only on each leaf construct
> separately.
>
> Now, Fortran is performing the splitting of clauses on
On Tue, Nov 02, 2021 at 05:27:14PM +0100, Jakub Jelinek via Gcc-patches wrote:
> I'm not sure this is what the standard says, certainly C/C++ FE do this
> quite differently for combined/composite constructs.
> In particular, we first split the clauses to the individual leaf constructs
> in c_omp_sp
On Fri, Oct 22, 2021 at 02:05:02PM +0100, Hafiz Abid Qadeer wrote:
> This patch adds support for OpenMP 5.0 allocate clause for fortran. It does
> not
> yet support the allocator-modifier as specified in OpenMP 5.1. The allocate
> clause is already supported in C/C++.
>
> gcc/fortran/ChangeLog:
>
Hi all,
On 22.10.21 15:05, Hafiz Abid Qadeer wrote:
This patch adds support for OpenMP 5.0 allocate clause for fortran. It does not
yet support the allocator-modifier as specified in OpenMP 5.1. The allocate
clause is already supported in C/C++.
I think the following shouldn't block the accept
This patch adds support for OpenMP 5.0 allocate clause for fortran. It does not
yet support the allocator-modifier as specified in OpenMP 5.1. The allocate
clause is already supported in C/C++.
gcc/fortran/ChangeLog:
* dump-parse-tree.c (show_omp_clauses): Handle OMP_LIST_ALLOCATE.
28 matches
Mail list logo
