Hi Jakub, hi all,
let me quickly comment on 'has_device_addr' with Fortran arrays
and with an array section (i.e. regarding your comment quoted
at the very bottom of this email).
Unfortunately, the OpenMP specification is rather unclear
what has_device_addr means for C/C++ array sections and in
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
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 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
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
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 25.01.22 12:44, Jakub Jelinek via Fortran wrote:
Apparently something we (at least I) have totally missed, we clearly have a
problem with the IEEE modules for the dual -mabi={ibm,ieee}longdouble.
We have:
__ieee_arithmetic_MOD_ieee_class_16;
__ieee_arithmetic_MOD_ieee_support_da
On 25.01.22 21:56, FX via Fortran wrote:
What I wonder is: if those conditions failed, then the struct they define
should have been empty, and therefore the code shouldn’t compile anyway (that
was the intent).
Wouldn't it make more sense to add '#else' / '#error ""' in that case?
Tobias
Hi Andre,
your patch breaks bootstrapping:
../../repos/gcc/gcc/fortran/trans-array.cc: In function ‘tree_node*
structure_alloc_comps(gfc_symbol*, tree, tree, int, int, int,
gfc_co_subroutines_args*)’:
../../repos/gcc/gcc/fortran/trans-array.cc:9200:42: error: ‘cdesc’ may be used
uninitialized
Already during parsing, the allocatable character array assignment
x = (x)
is converted to two gfc_codes with EXEC_ASSIGN, namely:
ASSIGN z1:_F.DA0(FULL) (parens z1:x(FULL))
ASSIGN z1:x(FULL) z1:_F.DA0(FULL)
But the current code expects only one gfc_code - as parse.c does some
checks, th
; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 6d4981350168f1eb3f72149bd7e05b9ba6bec1fd
Author: Tobias Burnus
Date: Fri Feb 4 14:51:01 2022 +0100
libgomp.fortran/allocate-1.f90: Minor cleanup
esellschaft: München; Registergericht
München, HRB 106955
commit f62156eab7b757d1ee03a11d5c96c72bd3de079c
Author: Tobias Burnus
Date: Fri Feb 4 17:31:21 2022 +0100
libgomp.fortran/allocate-1.f90: Fix minor cleanup
libgomp/ChangeLog:
* testsuite/libgomp.fortran/allocate-1.
On 10.02.22 11:07, Roger Sayle wrote:
The fix is to tweak trans-common.cc to respect the target's NO_DOT_IN_LABEL
(and NO_DOLLAR_IN_LABEL) when generating internal equiv.%d symbols.
In general, I think the patch is okay – but as '_' is a valid identifier
and with -fdollar-ok '$' is valid as we
As found by Marcel, the 'depend' clause was differently handled in
'omp depobj(...) depend(...)' and in 'omp task depend(...)'.
The problem was that for a scalar pointer, depobj depended
on the pointer address - while task depended on the pointer-target address.
If one now combines depobj and di
On 15.02.22 11:56, Jakub Jelinek wrote:
On Tue, Feb 15, 2022 at 11:26:12AM +0100, Tobias Burnus wrote:
As found by Marcel, the 'depend' clause was differently handled in
'omp depobj(...) depend(...)' and in 'omp task depend(...)'.
As Marcel reported, there
Hi Jakub, hi Abid, hi all,
On 21.02.22 16:50, Jakub Jelinek via Fortran wrote:
The thing is, omp_requires_mask was added for C/C++ from the C/C++ notion of
translation units (and a question is how does that cope with C++20 modules),
with the assumption that once certain #pragma omp requires is s
Hi Jakub,
On 21.02.22 18:47, Jakub Jelinek wrote:
Where ME is involved is
!$omp requires atomic_default_mem_order(whatever) vs.
!$omp declare variant ...atomic_default_mem_order(whatever).
Ups, missed that case. (Also because there wasn't 'declare variant' when
implementing 'requires' in Fortr
Hi,
On 24.02.22 08:57, Bertini, Denis Dr. via Fortran wrote:
Additonnaly i ran interactively my test program without slurm on with just one
MPI process on
I think you either use Open MPI or MPICH. Can you try setting the environment
variable
when invoking MPI by adding the -x or -env (-envli
Hi Denis,
On 24.02.22 09:15, Bertini, Denis Dr. via Fortran wrote:
I can try that but on our cluster we are bound to use
srun (slurm).
Do you know how to use the same functionality with srun
to set the environment variables.
I didn't – but the manual did: srun --export=...
See: https://slu
On 28.02.22 22:37, Jakub Jelinek via Fortran wrote:
On Mon, Feb 28, 2022 at 09:45:10PM +0100, Mikael Morin wrote:
Lesson learned today: expressions don’t have a corank.
Does pr104131-2.f90 really need to be rejected?
In my reading of the spec, pr104131-2.f90 is _valid_ (in newer OMP). At
least
First, thanks for looking into the standard. I think the information is
too much spread through the standard. I keep searching for restrictions,
find them at 5 places and miss another 5. With OpenMP 5.2, it became
even worse.
On 01.03.22 09:16, Jakub Jelinek wrote:
As there is no explicit allowi
The problem is that inside the main program,
y = f(z)
where the the result of z is
type(t) :: z(size(x%a))
and 'x' is a dummy argument.
'x' looses the attr.dummy in gfc_add_interface_mapping
and this leads to an additional indirect ref in
gfc_maybe_dereference_var - but after the first indire
Pre-remark: Related NULL, there some accepts-invalid issues, not addressed in
this
patch. See https://gcc.gnu.org/PR104819
This patch fixes an ICE (12 regression) with NULL() that has no MOLD argument.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschri
; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit e3ca3e7993696affe95a3ea24c2b133c14a056e4
Author: Tobias Burnus
Date: Mon Mar 7 17:20:52 2022 +0100
Fortran: Fix typos
gcc/fortran/ChangeLog
Hi Thomas & Jakub,
found when working on the deep-mapping patch* with OpenMP code
(and part of that patch) but it already shows up in an existing
OpenACC testcase. I think it makes sense to fix it already for GCC 12.
Problem: Also for unallocated allocatables, their size was
calculated - the 'if
Fix SIZEOF handling.
I have to admit that I do understand what the current code does,
but do not understand what the previous code did. However, it
still passes the testsuite - and also some code which did ICE
now compiles :-)
While writing the testcase, I did find two issues:
* Passing a CLASS
commit c0134b7383992aab5c1a91440dbdd8fbb747169c
Author: Tobias Burnus
Date: Mon Mar 7 22:11:33 2022 +0100
Fortran: Fix gfc_maybe_dereference_var [PR104430][PR99585]
PR fortran/99585
PR fortran/104430
gcc/fortran/ChangeLog:
* trans-expr.cc
Hi Harald,
On 08.03.22 22:44, Harald Anlauf wrote:
Am 07.03.22 um 15:16 schrieb Tobias Burnus:
Pre-remark: Related NULL, there some accepts-invalid issues, not
addressed in this
patch. See https://gcc.gnu.org/PR104819
This patch fixes an ICE (12 regression) with NULL() that has no MOLD
Hi Thomas, hi all,
(Updated patch attached – only changes the goacc testcases.
I intent to commit the patch tomorrow, unless more comments come up.)
On 10.03.22 10:00, Thomas Schwinge wrote:
[OpenACC testcases:]
I recently added that checking in ... [...] to document the status quo.
(1), as y
Minor remark to the test:
On 11.03.22 13:30, Marcel Vollweiler wrote:
+ int d = omp_get_default_device ();
...
+ int shared_mem = 0;
+ #pragma omp target map (alloc: shared_mem) device (d)
+shared_mem = 1;
+ if (omp_target_is_accessible (p, sizeof (int), d) != shared_mem)
+__builti
This patch addresses a side issue found when looking at PR103039.
Namely instead of printing:
55 | !$omp parallel firstprivate(tt)
| 1
Error: ASSOCIATE name ‘__tmp_INTEGER_4’ in FIRSTPRIVATE clause at (1)
With the patch, the error is:
Error: Associate na
SELECT TYPE, SELECT RANK and ASSOCIATE have
associate-name => selector
and create a pointer to the selector.
GCC was fixed to handle CLASS properly in
class(t) :: var
!$omp ... firstprivate(var)
As a side effect, firstprivate(assoc_name) now also gets
handled that way, effectively trying to
As reported in the PR103560. The patch is a slightly modified version
of the patch proposed by the bug reporter (with pseudonym?) Carlos Une.
The problem seems to be that 'stat ("./", ...)' fails with MinGW while
'stat (".", ...)' works. Besides, I think it makes sense to defer the
usage of '/' u
On 25.03.22 09:57, Jakub Jelinek via Fortran wrote:
On the gfortran.dg/pr103691.f90 testcase the Fortran ICE emits
static real(kind=4) a[0] = {[0 ... -1]=2.0e+0};
That is an invalid RANGE_EXPR where the maximum is smaller than the minimum.
The following patch fixes that. If TYPE_MAX_VALUE is
Hi Harald,
On 27.03.22 21:44, Harald Anlauf via Fortran wrote:
when assigning character pointers, we have a check for same length,
which however does not trigger for character pointers within a
structure constructor.
The attached patch extends the character checks slightly to fix
this loophole.
Hi Harald,
On 28.03.22 22:03, Harald Anlauf via Fortran wrote:
All current cases of printing a HOST_WIDE_INT in gcc/fortran/ use
'sprintf', and I did not find any other use of %wd/%wu. So the
mentioned implementation is not really stressed yet... ;-)
That's all your fault ;-)
(Your commit
ht
Hi Γιωργος,
On 29.03.22 22:26, Γιωργος Μελλιος via Fortran wrote:
I am looking forward to applying for GCC so I was checking the project
ideas list. I got interested in the Fortran - run-time argument checking
project and I would like to learn some more information about it in order
to start doi
Trivial fix – after finding the issue. The LOOP directive and
several LOOP/DO/SIMD combined directives were missing in the
check. As the PR shows, this leads to an ICE on invalid code.
OK?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
Mün
For
omp parallel shared(array_desc_var)
the shared-variable is passed to the generated function as
argument - and replaced by a DECL_VALUE_EXPR inside the parallel region.
If inside the parallel region, a
omp target data has_device_addr(array_descr_var)
is used, the latter generates a
omp
Found another issue – applied to OG11 as attached. Will include it in
the mainline patch once Stage1.
(However, I intent to split the original patch (+ follow ups) into
smaller pieces for mainline incorporation.)
Tobias
On 02.03.22 23:20, Tobias Burnus wrote:
Some testing found an issue in
LGTM - however:
On 26.04.22 14:38, Mikael Morin wrote:
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3698,7 +3698,8 @@ non_negative_strides_array_p (tree expr)
if (DECL_P (expr)
&& DECL_LANG_SPECIFIC (expr))
if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR
4.22 15:47, Tobias Burnus wrote:
Found another issue – applied to OG11 as attached. Will include it in
the mainline patch once Stage1.
(However, I intent to split the original patch (+ follow ups) into
smaller pieces for mainline incorporation.)
Tobias
On 02.03.22 23:20, Tobias Burnus wrote:
So
Hi Jakub,
On 04.05.22 14:03, Jakub Jelinek wrote:
On Wed, Apr 20, 2022 at 03:19:38PM +0200, Tobias Burnus wrote:
--- a/gcc/omp-low.cc
+++ b/gcc/omp-low.cc
@@ -13656,26 +13656,30 @@ lower_omp_target (gimple_stmt_iterator *gsi_p,
omp_context *ctx)
new_var = lookup_decl (var, ctx
Hi,
On 05.05.22 11:33, Jakub Jelinek via Gcc-patches wrote:
On Mon, Mar 14, 2022 at 04:42:14PM +0100, Marcel Vollweiler wrote:
+interface
+ function omp_target_is_accessible (ptr, size, device_num) bind(c)
+use, intrinsic :: iso_c_binding, only : c_ptr, c_size_t, c_
On 05.05.22 10:30, Jakub Jelinek via Fortran wrote:
+ memcpy_t *a = args;
+ int ret = omp_target_memcpy_copy (a->dst, a->src, a->length, a->dst_offset,
+a->src_offset, a->dst_devicep,
+a->src_devicep);
+ if (ret)
+gomp_fatal (
Dear all, dear Jakub,
this patch handles (for target regions)
firstprivate(array_descriptor)
by not only firstprivatizing the descriptor but also the data
it points to. This is done by turning it in omp-low.cc the clause
into
firstprivate(descr) firstprivate(descr.data)
and then attaching the
, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit ee954d940c41614c75be11b9d1de9079c37044d7
Author: Tobias Burnus
Date: Thu May 12 10:39:58 2022 +0200
Fortran: Fix
Based on sollve_vv's
tests/4.5/target_teams_distribute/test_target_teams_distribute_nowait.F90
As discussed, for simple pointers – like here with nondescriptor array,
instead of alloc:a + pointer assign, a firstprivate + pointer assign makes
more sense.
It also avoids the race exposed by the so
This adds omp_all_memory handling to Fortran, following C/C++ and shamelessly
coping
the C testcases and adapting them to Fortran.
OK?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäft
On 16.05.22 09:51, Toon Moene wrote:
Interesting question. We don't do that yet, as far as I know.
Forwarded Message
From: 陈刚
I want to use fp16 in fortran, does gfortran support the fp16?
I think adding fp16 to the compiler itself is not that difficult – it is
"just" handli
On 17.05.22 12:09, Thomas König wrote:
be might complement to the QP support for POWER in gcc 12, and I have actually
thought about doing. The library has its gotchas, though - I do not suppose we
can count on fp16 support for trigonometrics and similar, for example,
I think that mostly depen
On 17.05.22 15:55, Jakub Jelinek via Gcc-patches wrote:
This patch adds support for inoutset depend-kind in depend
clauses.
While this patch adds the Fortran FE bits and converts the C/C++
testcase changes for Fortran.
Bootstrapped/regtested on x86_64-linux.
OK for trunk?
Tobias
-
Hi Jakub,
On 19.05.22 15:59, Jakub Jelinek wrote:
I guess ok like this for now, but handling the further deep copy cases
(allocatable members of derived types) wouldn't be very nice, I think
generally we need a target hook to handle the stuff that is target specific
and express it say in further
8af266501795dd76d05faef498dbd3472a01b305
Author: Tobias Burnus
Date: Fri May 27 13:12:45 2022 +0200
Fortran: Fix OpenMP clause name in error message
gcc/fortran/ChangeLog:
* openmp.cc (gfc_check_omp_requires): Fix clause name in error.
gcc/testsuite/ChangeLog
This patch adds the Fortran support to the just-committed C/C++ support for the
'enter' clause.
The 'TO'/'ENTER' usage is first stored in a linked list – and
then as attribute to the symbol. I am not sure how to handle it best.
I did went for adding an ENTER_LIST but kept only using the single a
On 28.05.22 22:25, Harald Anlauf via Fortran wrote:
the PR rightfully complained that we did not differentiate errors on
ALLOCATE(...,stat=,errmsg=) for failures from allocation of already
allocated objects or insufficient virtual memory.
It is even worse: The error message states the wrong reas
Simple patch. Testcases based on the C/C++ commit.
For allocate, I found an unrelated bug which prevented me from adding
the associated testcase: https://gcc.gnu.org/PR105836
Tested on x86-64 (w/o offloading).
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; A
The OpenMP requires directive may only be placed in the specification part of
a program unit (except it happens via the USE of a module).
But the target directive ancestor-requires-'reverse_offload' only checked
the current namespace.
OK for mainline?
Tobias
-
Siemens Electronic
On 27.06.22 15:30, Jakub Jelinek via Gcc-patches wrote:
Ok, here is an updated patch that uses _Float128/_Complex _Float128 for all
of GFC_REAL_{16,17}_IS_FLOAT128, but still uses q/Q suffixes on literal
constants etc. when using libquadmath and f128/F128 otherwise.
This patch also includes the
On 29.06.22 14:13, Jakub Jelinek via Fortran wrote:
My recent gfortran + libgfortran patch apparently broke (some?) aarch64
builds. While it is desirable to use just _Float128 rather than __float128,
we only want to use it (and e.g. define HAVE_FLOAT128) on targets where
_Float128 is supported a
On 29.06.22 14:15, Jakub Jelinek via Fortran wrote:
My patch apparently left some __float128 uses in libgfortran
that could use _Float128 instead, the following patch changes that.
Ok for trunk?
LGTM. Thanks!
Tobias
2022-06-29 Jakub Jelinek
* mk-kinds-h.sh: Change __float128 to _F
On 28.06.22 22:36, Harald Anlauf via Gcc-patches wrote:
the simplification of EXTENDS_TYPE_OF() did not handle the
situation that one of its arguments were a CLASS variable
that was improperly declared. NULL pointer dereference.
The fix is obvious. Steve found a similar solution, which
is why
Dear Harald, dear all,
On 29.06.22 21:54, Harald Anlauf via Fortran wrote:
a CLASS entity cannot have the PARAMETER attribute.
This is detected in some situations, but in others
we ICE because we never reach the existing check.
Adding a similar check when handling the declaration
improves error
I initially thought that I need another set of macros - and started with
this cleanup. I then realized that I don't.
However, I still wonder whether this cleanup makes sense even if only
4 macros are affected.
OK for mainline - or should I put that patch into the bin?
Tobias
-
S
Needed a break and some success. Hence, I implemented this useful and simple
OpenMP 5.2
feature.
OK for trunk?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung
This patch adds support for the OpenMP 5.2 syntax for the linear clause,
following the C/C++ patch. The testcases are modified versions from the
C/C++ ones, plus one added one for duplicated modifiers.
At least to me it is not quite clear when
linear ( var : ref)
refers to a variable 'ref' and
Hi Jakub,
thanks for the comment & spec referral. I have now updated the patch –
and included the new C/Fortran testcase.
On 04.07.22 16:53, Jakub Jelinek via Fortran wrote:
See OpenMP 5.2 [59:31-34]:
A modifier that is an expression must neither lexically match the name of a
simple modifier
d
On 04.07.22 19:20, Jakub Jelinek wrote:
Perhaps you could avoid some code duplication by doing it like:
bool close_paren = gfc_match ("val )") == MATCH_YES;
if (close_paren || gfc_match ("val , ") == MATCH_YES)
Done!
Good idea! I was thinking of things
Testcase wise, the run-time testcase libgomp.fortran/examples-4/simd-2.f90
checks essentially the same, except that it uses an array-descriptor array
(assumed shape) while this testcase uses an assumed-size array.
I decided for an extra compile-time only testcase, but it could be also be
moved to
This patch fixes two issues – the first was reported to me by email but it
also shows up in the official OpenMP examples (see PR).
Namely: Inside a module, 'gfc_match(" ( %s )")' fails as the symbol is already
host associated. (The symbol is the current procedure name.)
Solution: Match with pass
Fixed subject line: "absent linear" should be "absent linear step" in the
subject line;
i.e. with "step" added: "Fortran: OpenMP fix declare simd inside modules and absent
linear step [PR106566]"
I have also decided to move the 'step = 1' to openmp.cc, which also set it
before with
the old pre
On 16.08.22 16:31, Jakub Jelinek via Gcc-patches wrote:
The following patch is a revival of the
https://gcc.gnu.org/legacy-ml/gcc-patches/2014-10/msg00771.html
patch. While trunk configured against recent glibc and with linker
--as-needed support doesn't really need to link against -lquadmath
an
On 17.08.22 15:09, Jakub Jelinek wrote:
On Tue, Aug 16, 2022 at 04:45:07PM +0200, Tobias Burnus wrote:
Fortran: OpenMP fix declare simd inside modules and absent linear step
[PR106566]
...
LGTM.
+! { dg-final { scan-tree-dump-times "__attribute__\\(\\(omp declare simd
\\(linear\\(
This patch is about error diagnostic + an ICE for invalid code.
Before the patch, gfortran/f951 showed:
...
Error: 'ancestor' device modifier not preceded by 'requires' directive with
'reverse_offload' clause
18 | end block
| 1
Error: Expecting END PROGRAM statement at (1)
gfortran: in
Dear Harald,
On 23.08.22 22:29, Harald Anlauf via Fortran wrote:
the simplification of the size of an array with a bad decl
should not be successful. Improve the error recovery for
such a situation.
[...]
Regtested on x86_64-pc-linux-gnu.
The PR is marked as a 12/13 regression. Will therefor
I did run into some issues related to this; those turned out to be
unrelated, but I end ended up implementing this feature.
Side remark: 'omp parallel workshare' seems to actually permit 'nowait'
now, but I guess that's an unintended change due to the
syntax-representation change. Hence, it is no
(Patch + RFC.)
OpenMP 5.2 has 'ompx' and (for fixed source form Fortran) 'omx'
as sentinel to provide a defined namespace for vendor extensions.
The behavior when encountering an unknown directive with ompx/omp sentinel
(or an unknown clause with ompx_ prefix) is implementation defined. For unkn
On 13.09.22 23:04, Julian Brown wrote:
This patch implements OpenMP 5.0 "declare mapper" support for C++.
And to complete list of patches belonging to this set, Julian had posted
the associated Fortran patch set in June:
[PATCH 0/6] OpenMP 5.0: Fortran "declare mapper" support
https://gcc.gnu.
In several cases, one just wants to have the address where an object starts
without requiring the detour via 'c_loc' and the (locally) required 'target'
attribute.
In principle, type(*),dimension(*) of TS29113 permits this, except that
'dimension(*)' only permits arrays and array elements but n
Hi Martin,
On 20.09.22 14:02, Martin Liška wrote:
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
@@ -455,9 +455,7 @@ version 2.6, @uref{https://www.openacc.org/}). See
The Fortran 95 standard specifies in Part 2 (ISO/IEC 1539-2:2000)
varying length character strings. Wh
Hi Martin,
On 20.09.22 14:24, Martin Liška wrote:
On 9/20/22 14:17, Tobias Burnus wrote:
Instead of removing the links, can we rather replace it by an updated link?
[...]
Thanks for the archeological work you did.
Sure, what about the suggested patch?
LGTM. Thanks!
Tobias
Hello Paul-Antoine, hi all,
On 21.09.22 23:18, Paul-Antoine Arras wrote:
Here is a patch that fixes an ICE in gfortran triggered by an invalid end
statement at the end of an OMP metadirective:
Remark for other reads of this email: This only applies to OG12 as mainline
does not have the follo
Hi Julian and Jakub, hi all,
On 23.09.22 09:29, Julian Brown wrote:
How about this version? (Re-tested.)
[...]
* * *
Some more generic (pre)remarks – not affecting the patch code,
but possibly the commit log message:
This follows OMP 5.0, 2.19.7.1 "map Clause":
which is also in "OMP 5.2, 5
Hi Paul-Antoine, hi all,
On 28.09.22 15:47, Paul-Antoine Arras wrote:
Here is a revised patch resulting from your comments.
The only issue that I could not easily fix is the following code
triggering an ICE: [...]
I filed a PR on Bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107067
Is i
On 29.09.22 14:59, Julian Brown wrote:
On Wed, 28 Sep 2022 17:17:30 +0200 Tobias Burnus
wrote:
I don't see immediately whether some cases can still reach
omp_accumulate_sibling_list – if so, a testcase would be nice, or
whether that error_at can now be removed.
This version of the
While has_device_addr has been implemented (in GCC 12), updating
use_device_ptr for Fortran was missed.
This patch fixes it: Removing the restrictions and mapping to
has_device_addr where applicable.
For use_device_ptr something similar was done, albeit I think
this has no semantic effect.
And
On 30.09.22 12:41, Tobias Burnus wrote:
Fortran: Update use_device_ptr for OpenMP 5.1 [PR105318]
The following two lines slipped in – which I have now removed in my version of
the patch:
--- a/gcc/testsuite/gfortran.dg/gomp/is_device_ptr-1.f90
+++ b/gcc/testsuite/gfortran.dg/gomp
Hi Jakub,
On 30.09.22 13:04, Jakub Jelinek via Fortran wrote:
On Fri, Sep 30, 2022 at 12:41:19PM +0200, Tobias Burnus wrote:
And 'device(omp_initial_device)' printed a warning in Fortran.
(BTW: C/C++ silently accepts any negative value.)
I think that is what the standard wants.
E
Hi Julian,
On 30.09.22 15:30, Julian Brown wrote:
i = 1; j = 2
map (foo(i)%dt_ptr(1:3), foo(j)%dt_ptr)
Good catch! In that gfc_dep_resolver considers those terms to have a
dependency, and that triggers the mapping node transformation. But I
don't think OpenMP allows you to write this: IIUC
On 30.09.22 15:30, Julian Brown wrote:
On Fri, 23 Sep 2022 14:10:51 +0200 Tobias Burnus
<mailto:tob...@codesourcery.com> wrote:
...
I added n->expr->expr_type == EXPR_VARIABLE to the condition -- I think
that should suffice for now?
Yes.
A similar mean way to write code would
This patch adds '!$omp assume' and '!$omp assumes' support.
None of the directives is used after resolution.
When we actually start using for 'assumes', it has to be stored in .mod
files. The other question is how to handle 'holds()' expressions with 'assumes'.
-fopenmp-simd: I used a longer wor
Hi Jakub,
On 04.10.22 12:19, Jakub Jelinek wrote:
On Sun, Oct 02, 2022 at 07:47:18PM +0200, Tobias Burnus wrote:
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -2749,9 +2749,9 @@ have support for @option{-pthread}. @option{-fopenmp}
implies
@opindex fopenmp-simd
@cindex OpenMP SIMD
Hi Jakub,
On 04.10.22 14:58, Jakub Jelinek via Gcc-patches wrote:
On Tue, Oct 04, 2022 at 02:26:13PM +0200, Tobias Burnus wrote:
On Sun, Oct 02, 2022 at 07:47:18PM +0200, Tobias Burnus wrote:
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
OK?
Ok, thanks.
Committed as
https
Minor update to just posted patch: the table did not revert all strings where a
substring directive name existed, i.e. 'target' vs. 'target update', 'assume'
vs. 'assumes'. Now fixed. Otherwise unchanged:
Tobias
On 05.10.22 13:19, Tobias Burnus wro
Same as for C/C++, albeit a tiny bit longer patch.
I don't know whether it makes sense to handle – in the long run – the
case of se.pre/se.post being nonempty – and, if so, how.
OK for mainline?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 806
On 06.10.22 14:17, Jakub Jelinek wrote:
On Thu, Oct 06, 2022 at 12:55:01PM +0200, Tobias Burnus wrote:
I don't know whether it makes sense to handle – in the long run – the
case of se.pre/se.post being nonempty – and, if so, how.
I think it is essential not to throw those away,
if se.p
Hi Jakub,
On 11.10.22 14:24, Jakub Jelinek wrote:
There is another issue besides what I wrote in my last review,
and I'm afraid I don't know what to do about it, hoping Tobias
has some ideas.
The problem is that without the allocate-stmt associated allocate directive,
Fortran allocatables are ea
On 11.10.22 16:15, Jakub Jelinek wrote:
I think the most common case is:
integer, allocatable :: var(:)
!$omp allocators allocator(my_alloc) ! must be in same scope as decl of 'var'
...
! optionally: deallocate(var)
end ! of scope: block/subroutine/... - automatic deallocation
So you talk her
schaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 3760dd553eed21ac5614cf0d0841ca984b4361e2
Author: Tobias Burnus
Date: Fri Oct 14 18:34:49 2022 +0200
gfortran.dg/c-interop/deferred-chara
Long introduction - but the patch is rather simple: Don't use kind=1
as type where kind=4 should be used.
Long introduction + background, feel free to skip.
This popped up for libgomp/testsuite/libgomp.fortran/struct-elem-map-1.f90
which uses kind=4 characters –
1 - 100 of 638 matches
Mail list logo
