OpenMP's adjust_args clause to 'declare variant' can request to
convert a pointer to a device pointer in the call ('need_device_ptr').
The arguments are stored by their position in the argument list,
but if hidden arguments get added - like C++'s 'this' pointer,
the list if off by one. This patch
For declare_variant's 'adjust_args', the arguments for need_device_ptr
are referenced by argument number. This patch fixes that calculation
if hidden arguments due to return-by-reference calling exist.
Note: It only fixes the Fortran issue; the C++ issue still needs to be fixed.
Build + regteste
Hi Sandra,
Sandra Loosemore:
libgomp/ChangeLog
* libgomp.texi (OpenMP 5.0): Mark metadirective and declare variant
as implemented.
(OpenMP 5.1): Mark target_device as supported.
Add changed interaction between declare target and OpenMP context
and dynamic
Sandra Loosemore wrote:
gcc/testsuite/ChangeLog
* c-c++-common/gomp/adjust-args-6.c: New.
* c-c++-common/gomp/attrs-metadirective-1.c: New.
* c-c++-common/gomp/attrs-metadirective-2.c: New.
* c-c++-common/gomp/attrs-metadirective-3.c: New.
* c-c++-common/go
As shown in the PR, updating the function declaration
for _gfortran_pack_char could leak into the character
typespec back-end declaration to the the caller by
setting the backend declaration of the caller.
The problem is that that function returns a character string
and in trans-intrinsic.cc, we
Sandra Loosemore wrote:
Additional shared C/C++ testcases are included in a subsequent patch in this
series.
LGTM.
Thanks,
Tobias
gcc/cp/ChangeLog
PR middle-end/112779
PR middle-end/113904
* cp-tree.h (struct saved_scope): Add new field
x_processing_omp_trait
Sandra Loosemore wrote:
The code and test case previously implemented the OpenMP 5.0 spec,
which said in section 2.3.1:
"For functions within a declare target block, the target trait is added
to the beginning of the set..."
In OpenMP 5.1, this was changed to
"For device routines, the target tra
Sandra Loosemore wrote:
Additional shared C/C++ testcases are included in a subsequent patch in this
series.
LGTM – thanks for the patch!
Tobias
gcc/c-family/ChangeLog
PR middle-end/112779
PR middle-end/113904
* c-common.h (enum c_omp_directive_kind): Add C_OMP_DIR_ME
The innocent looking code in the testcase failed with a
surprising 'error: could not find variant declaration'.
It turned out that calling it involves a TARGET_EXPR that
the variant-resolving/checking routine did not handle.
Comments, remarks, suggestions before I commit it?
Tobias
OpenMP/C++:
Hi Sandra,
Sandra Loosemore wrote:
On 1/9/25 05:17, Tobias Burnus wrote:
A case where 'omp error' diagnostic should be delayed - and (here)
suppressed:
["should" in the sense it would be good not in the sense "shall".]
program_control/sources/error.1.c:1
Hi,
Thomas Schwinge wrote:
On 2021-11-06T00:51:59+0800, Chung-Lin Tang wrote:
On 2021/6/24 11:55 PM, Jakub Jelinek wrote:
On Fri, May 14, 2021 at 09:20:25PM +0800, Chung-Lin Tang wrote:
+ OMP_CLAUSE_MAP_IMPLICIT_P (clause) = 1;
As Thomas mentioned, there is now also OMP_CLAUSE_MAP_IMPL
Hi all,
Tobias Burnus wrote:
Tobias Burnus wrote:
Sandra Loosemore wrote:
This patch reimplements the middle-end support for "declare variant"
and extends the resolution mechanism to also handle metadirectives
(PR112779). It also adds partial support for dynamic selectors
(PR1
Hi PA,
Paul-Antoine Arras wrote:
I am not sure I am getting that part. Is this what you are suggesting?
Yes, something like that, but not quite, as you found out.
I think we need something like the following (untested):
diff --git gcc/fortran/openmp.cc gcc/fortran/openmp.cc
index 9d28dc
Hi PA,
Paul-Antoine Arras wrote:
Here is an updated patch following your suggestion.
Thanks. It is not clear whether you are just waiting
for test result or not before committing it as obvious.
Thus, just in case: LGTM.
Thanks,
Tobias
Hi PA,
Paul-Antoine Arras wrote:
Hi Thomas,
Added libgomp/testsuite/libgomp.fortran/dispatch-1.f90.
I see this new test case FAIL (execution test SIGSEGV) for most (but not
all) offloading configurations, both GCN and nvptx:
+PASS: libgomp.fortran/dispatch-1.f90 -O (test for excess
e
Andreas Schwab wrote:
This breaks m68k:
Same issue on GCN, hence I filed https://gcc.gnu.org/PR118418
If I look at the debugging output, see PR, it seems as if
the self-test function test_comparisons contains the assumption:
FALSE < TRUE
but if TRUE is -1, that assumption does not hold
(fo
Hi,
On 9/25/24 3:18 AM, Andre Vehreschild wrote:
@@ -3089,7 +3099,15 @@ typedef struct gfc_code
gfc_inquire *inquire;
gfc_wait *wait;
gfc_dt *dt;
- gfc_forall_iterator *forall_iterator;
+
+ struct
+ {
+ gfc_forall_iterator *forall_iterator;
+ gfc_expr_list *
Hi PA,
Paul-Antoine Arras wrote:
This amended patch checks the context and adds the suggested testcase.
LGTM - thanks!
Do not call cp_parser_omp_dispatch directly in cp_parser_pragma
This is a followup to
ed49709acda OpenMP: C++ front-end support for dispatch + adjust_a
Hi Thomas,
Thomas Koenig wrote:
Comments, remarks, suggestions?
I assume you regression-tested (you didn't say).
Yes, it was build with a bootstrapping configuration (with a
non-offloading compiler, but it shouldn't matter here) on
x86_64-gnu-linux and I did run "make check-fortran" in the
m
The first change is a simple, generic Fortran change.
Without it, external declarations have odd locations
(namely their input_location):
gcc/testsuite/gfortran.dg/gomp/dispatch-11.f90:67:46:
67 | !$omp dispatch interop(obj2, obj1) device(3)
|
Hi Sandra,
I had a first glance at your patch, albeit very superficial. I found one
issue reading the code - and observed some issues when running it against
some existing external tests.
I will have a deeper looker later, will now first do another iteration
on your main/middle-end patch #2, whi
ed after the loop.
commit 1bb367b5cdb9fa77733d87d97483fb57480ef6fe
Author: Tobias Burnus
Date: Thu Jan 9 01:36:49 2025 +0100
OpenMP: declare variant's append_args + dispatch interop fixes
For 'omp dispatch interop(obj)', call omp_get_interop_int to
obtain the device number. Add new error if no
Now committed as r15-6659-gd3ccd89fa0d34d – with an additional typo fix:
stipe → stripe (OpenMP 6.0 loop transformation directive).
Tobias
commit d3ccd89fa0d34d44226af47fe82c27ba7833fe65
Author: Tobias Burnus
Date: Tue Jan 7 16:43:30 2025 +0100
libgomp.texi: Minor update to
OpenMP 6 changed that omp_get_initial_device may not only return the
dynamic value of omp_get_num_devices() but also the constant value
omp_get_num_devices (== -1).
For now, GCC returns omp_get_num_devices() but we may want to change
this in the future as '-1' can be solved at compile time; in pa
Paul-Antoine Arras:
Add support to the Fortran parser for the new OpenMP syntax that allows a
comma after the directive name and between clauses of declare variant.
The C and C++ parsers already support this syntax so only a new test is added.
Note: only the optional comma between directive nam
Paul-Antoine Arras wrote:
This is a followup to
ed49709acda OpenMP: C++ front-end support for dispatch + adjust_args.
The call to cp_parser_omp_dispatch only belongs in cp_parser_omp_construct. In
cp_parser_pragma, handle PRAGMA_OMP_DISPATCH by calling cp_parser_omp_construct.
I think this cha
Hi PA,
Paul-Antoine Arras wrote:
On 06/01/2025 17:12, Paul-Antoine Arras wrote:
This is a followup to
084ea8ad584 OpenMP: middle-end support for dispatch + adjust_args.
This patch fixes a bug that caused arguments in an OpenMP dispatch
call to be
modified even when no variant substitution oc
Sandra Loosemore wrote:
[in https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669055.html ]
Presently, the code to handle OpenMP attribute-syntax pragmas in the C
front end assumes nothing else is messing with redirecting
parser->tokens, and makes no provision for restoring it from anythin
This came up in the context of dispatch patching, where the location
was very confusing (pointing to the first letter of the first variable).
The OpenMP variable-list parser has two modes, one is used to directly
parse a clause, in which case a tree node is created with the proper
location. And a
Hi Sandra,
Sandra Loosemore wrote:
After reimplementing late resolution of "declare variant", the
declare_variant_alt and calls_declare_variant_alt flags on struct
cgraph_node are no longer used by anything. For the purposes of
marking functions that need late resolution, the
has_omp_variant_co
Support the 'has_device_addr' clause with OpenMP's 'dispatch'
directive.
The testcase is even more questionable as the C/C++ testcase
(looking at it globally/semantically), but it tests (locally)
what it is supposed to test: namely, 'has_device_addr' does not
fulfill the 'is_device_ptr' property
Hi all and happy new year,
I think it makes sense to refer to Newlib 4.5.0 instead of referring
to two specific git commits.
Comments before I commit it?
Actually, due to GCC 15's -std=gnu23, 4.5.0 is recommended
in general as it features:
- fixes for building with gcc-15
besides
- fixe
Hi PA,
Paul-Antoine Arras wrote:
Folded everything in one patch. […]
Updated ChangeLog. […]
Thanks.
Rebased and amended accordingly. I believe I did the right thing but
please have a quick look to be sure.
...
Otherwise, LGTM. Thanks!
LGTM :-)
For libgomp.fortran/dispatch-3.f90, see just
Hi PA,
Paul-Antoine Arras wrote:
On 27/12/2024 19:52, Paul-Antoine Arras wrote:
Running adjust-args-10.f90 manually exhibited a bug that no other
testcase triggered. So I fixed the bug; then moved adjust-args-10.f90
to the libgomp testsuite, renamed it to dispatch-3.f90 and made it
dg-run.
I
Hi PA,
(next try, for some reasons, my original email disappeared.)
Paul-Antoine Arras wrote:
Replying to your last two messages here and attaching revised patches.
Regarding the C++ and ME patches:
==> 0003-C-fix.patch <==
Subject: [PATCH 3/4] C++ fix
==> 0004-ME-fixes.patch <==
Subject:
attached
commit).
Committed asr15-6373-ga104766914e98d
Tobias
commit a104766914e98ded9b991f1dac9ad22e815a3acc
Author: Tobias Burnus
Date: Thu Dec 19 17:27:41 2024 +0100
OpenMP: Add 'nec' as to the 'vendor' context-selector list
For unknown vendors using in a
p/OpenMP-Context-Selectors.html
now also lists any/cpu/nohost. (See attached patch.)
Thanks,
Tobias
[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671954.html
commit 570d4e4c68535ee4e5b2d82ad02a65fa1ec04112
Author: Tobias Burnus
Date: Thu Dec 19 16:06:21 2024 +0100
libgom
Hi Sandra, hi Jakub, hello world,
pre-remark: SA Sandra's patch is an updated post of her v4 version at
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669054.html
v4 (and, hence, v5) address Jakub's review comments to v3, i.e.
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660029
I now tried it again – with a patch-wise clean bootstrap and w/o
--enable-offload-targets=...
(i.e. on x86_64-gnu-linux with--enable-languages=c,c++,fortran,lto,objc, which enables bootstrap + m32
mulilib support).
I think I saw the same error previously but when trying to see the error again,
A x86_64-gnu-linux bootstrap which also builds -m32 now fails.
While I have local patches, they should not affect this,
hence, I fear that it has been caused by this patch.
Namely, if I do a bootstrap into an empty directory with:
$ /configure --prefix=...
--enable-languages=c,c++,fortra
Hi all, hello PA,
Tobias Burnus wrote:
Paul-Antoine Arras wrote:
See the revised patch attached and my comments below.
I have not looked in depth at the patch, but managed to
write C-ism code, which caused a segfault (due to a missing "call"),
Additional comments: Can you
Hi PA,
Paul-Antoine Arras wrote:
See the revised patch attached and my comments below.
First, for Fortran patches, please also CC fortran@ besides gcc-patches@.
The original patch email can be found at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671763.html
I have not looked in
This rather contained OpenMP patch does:
* 'interop' clause - some fixes (-Wunused),
* ICE fix related to omp_interop_t type check.
* Handle 'append_args' in C/C++ (depends on recently added
'dispatch' and utilizes the existing 'init' clause parser
of 'omp interop').
* Update gimplify for
OpenMP states for C++:
"Directives may not appear in constexpr functions or in constant expressions."
There is some support for this already in GCC, but not for [[omp::decl]]-type
of directives and it also doesn't work that well. For the example, for the
newly added testcase, the result with the
This simple patch improves the diagnostic and prepares for some future work.
Note: has_device_addr for C is permitted but pointless, for C++ it
requires some follow-up work to be useful.
For C, a hint that 'need_device_addr' it not valid has been added and
for 'has_device_addr' a middle-end warnin
I noticed that https://gcc.gnu.org/projects/cxx-status.html did not list
newer revisions of three proposals.
(I have on idea whether still newer exists or others should be updated
as well, but at least that's a start.)
OK?
Tobias
cxx-status.html: Update C++26 proposals to new revisions
Bum
Thomas Schwinge wrote:
That's a bug in 'libgomp/plugin/plugin-gcn.c:maybe_init_omp_async' (or
its users); the real user of 'GOMP_OFFLOAD_openacc_async_exec' does
handle the error condition:
Well, it does not really handle it: It also just calls 'fatal',
admittedly after unlocking but if the pro
In C, [[omp::decl]] wasn't supported and when discussing 'alignof' with Jakub,
he pointed out that there are corner cases (see commit log for one), which imply
that it is better that 'omp allocate align(…) doesn't affect 'alignof'.
The patch now removes the alignment handling from the FE (C and Fo
H Harald, hi Paul,
Harald Anlauf wrote:
Pushed as r15-5766 .
This caused a build fail; see also: https://gcc.gnu.org/PR117843
It looks as if a 'default: break;' is missing.
…/gcc/fortran/trans-io.cc: In function 'tree_node*
gfc_trans_transfer(gfc_code*)':
…/gcc/fortran/trans-io.cc:2662:24:
This patch depends on 'dispatch' (which is currently in mainline only
available for C/C++ but not Fortran) and it depends on the not-yet-committed
"[Patch] OpenMP: 'interop' construct - add C/C++ parser support, improve Fortran
parsing"
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/6687
Committed r15-5392-g884637b6362391 (as attached)
Albeit with a minor comment change as my new comment was slightly
misleading.
Tobias Burnus wrote:
This fixes a C23 error, causing a build fail: 'false'
should have been 'NULL'.
The NULL value is not really handled
This fixes a C23 error, causing a build fail: 'false'
should have been 'NULL'.
The NULL value is not really handled as the code calling
maybe_init_omp_async assumes that agent->omp_async_queue can be
dereferenced. Hence, besides fixing the false/NULL issue, it switches to
a 'fatal' error. Comme
Rather obvious fix, a bit hidden as CUDA_CALL hides the 'false',
but it actually just calls CUDA_CALL_ERET(NULL, FN, ...).
Committed as r15-5381-ge7e3d1838f7cfb.
Tobias
commit e7e3d1838f7cfb4a9fca711d735d8f5ea47d16dc
Author: Tobias Burnus
Date: Mon Nov 18 11:06:58 2024 +0100
Hi PA,
* I believe that all prep + middle end patches are approved and ready to go
* Pending for C and C++ are the three patches, attached to the email
I am hereby replying to - for the C and the C++ front end and the
common C/C++ testcases.
→ Those 3 patches LGTM - thanks!
Related but not
Hi,
Paul-Antoine Arras wrote:
This patch adds support for the `dispatch` construct and the
`adjust_args` clause to the Fortran front-end.
Handling of `adjust_args` across translation units is missing due
to PR115271.
First, can you add a run-time test?
[I think it helps to have at least one
Paul-Antoine Arras wrote:
OpenMP: common C/C++ testcases for dispatch + adjust_args
gcc/testsuite/ChangeLog:
...
libgomp/ChangeLog:
* testsuite/libgomp.c-c++-common/dispatch-1.c: New test.
* testsuite/libgomp.c-c++-common/dispatch-2.c: New test.
LGTM
uthor: Tobias Burnus
Date: Thu Nov 14 16:37:04 2024 +0100
projects/gomp/: Update for OpenMP 6.0 spec release
htdocs/projects/gomp/index.html:
* Refer to OpenMP 6.0 instead of TR 13.
* Add 6.0 spec to the (spec) release history.
---
htdocs/projects/gomp/index
Updated https://gcc.gnu.org/projects/gomp/ as now OpenMP 6.0 has been
released:
https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-6-0.pdf
Which is under spec releases and changing TR13 to OpenMP 6.0
Tobias
commit cb607960883c6528a1c43d4e59b80a626dc6a386
Author: Tobias Burnus
28854cf68dc4ad1ce5a72440d1422cb2bb02dd62
Author: Tobias Burnus
Date: Thu Nov 14 16:28:20 2024 +0100
libgomp.texi: Impl. Status - change TR13 to OpenMP 6.0 + fix routine typo
libgomp/
* libgomp.texi (OpenMP Implementation Status): Change TR13 to
OpenMP 6.0, now
Hi PA,
thanks for the updated patch!
Paul-Antoine Arras wrote:
OpenMP: C++ front-end support for dispatch + adjust_args
This patch adds C++ support for the `dispatch` construct and the `adjust_args`
clause. It relies on the c-family bits comprised in the corresponding C
f
_GOMP_UINTPTR_T_ENUM macro definitions.
Otherwise it is unchanged.
Tobias
Tobias Burnus wrote:
Background:
omp interop device(1) init(prefer_type("cuda"), targetsync: obj)
depend(inout: x) nowait
…
omp interop destroy(obj)
initializes the omp_interop_t / integer(omp_interop
Hi Thomas,
Thomas Schwinge wrote:
On 2023-09-08T11:04:24+0200, Tobias Burnus wrote:
On 02.08.23 19:00, Andrew Stubbs wrote:
The use of the PTX dynamic_smem_size feature means that low-latency allocator
will not work with the PTX 3.1 multilib.
Right: PTX '%dynamic_smem_size' was &
Background:
omp interop device(1) init(prefer_type("cuda"), targetsync: obj)
depend(inout: x) nowait
…
omp interop destroy(obj)
initializes the omp_interop_t / integer(omp_interop_kind) variable for device
'1'
and (thanks to 'targetsync') creates a stream object. 'obj' can then be used
I intent to commit the attached patch later today as obvious.
It is an older issue I never properly investigated before
but finally want to fix it.
The issue is that on systems (like my laptop) that have
Intel's E and P cores (hybrid x86); testing by Intel has
shown that spincount=1 is actually
g8473010807a264.
Thanks for the suggestion / review.
Tobias
PS: See
https://rocm.docs.amd.com/en/latest/conceptual/gpu-isolation.html for
details on ROCR_VISIBLE_DEVICES, GPU_DEVICE_ORDINAL, HIP_VISIBLE_DEVICES, …
commit 8473010807a264af35fb7cecad6f9406feab929f
Author: Tobias Burnus
Date: Mon Nov 1
Currently, for GCN, only one offload ISA is supported; this might lead
to errors when multiple different AMD GPUs are installed on the same system,
at least when using the "wrong" device/device number.
In case of the testsuite, this occurs for instance
with libgomp.c-c++-common/icv-9.c which iter
As there were no further remarks, I have now committed it as
r15-5017-ge52cfd4bc23de1 with minor changes:
* Referring to v6.0 not TR13 (same section numbers),
* fixed one item in the 5.2 to-do list:
'declare mapper with iterator and present modifiers' comes from Appendix B
and we had before a
I intended – but forgot – to actually attach the committed patch. Here
it is …
Tobias Burnus wrote:
As there were no further remarks, I have now committed it as
r15-5017-ge52cfd4bc23de1 with minor changes:
* Referring to v6.0 not TR13 (same section numbers),
* fixed one item in the 5.2 to-do
Hi PA,
Regarding the update middle end patch, included in this patch, i.e.
v4.3-0002-OpenMP-middle-end-support-for-dispatch-adjust_arg.patch:
@@ -4071,23 +4073,136 @@ gimplify_call_expr (tree *expr_p, gimple_seq *pre_p,
bool want_value)
[...]
+ if (flag_openmp && gimplify_omp_ct
Hi David
David Malcolm wrote:
On Fri, 2024-11-01 at 07:36 +0100, Tobias Burnus wrote:
Or you do the same as forhttps://gcc.gnu.org/PR115203 ; namely,
your commit
https://gcc.gnu.org/r15-866-g2dbb1c124c1e585dc413132d7a8d4be62c6b7baa
added: […]
+ disable_event_localization ();
Doing so for
Am 31.10.24 um 21:57 schrieb David Malcolm:
On Thu, 2024-10-31 at 11:36 -0700, Andrew Pinski wrote:
This is recorded as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117361 already.
I think one idea is to set LANG=C before doing the self-check. But I
will allow David and other think of better way
Hi Jakub,
Jakub Jelinek wrote:
+ if (TREE_CODE (variant) == INDIRECT_REF)
+variant = TREE_OPERAND (variant, 0);
+
variant = cp_get_callee_fndecl_nofold (variant);
I think this should be just
variant = cp_get_callee_fndecl_nofold (STRIP_REFERENCE_REF (variant));
instead.
… which cl
Tobias Burnus wrote:
Before the patch, the included testcase fails with:
declare-variant-9.C:4:29: error: could not find variant declaration
4 | #pragma omp declare variant(variant_fn) match(user={condition(1)})
| ^~
Comments, remarks
Before the patch, the included testcase fails with:
declare-variant-9.C:4:29: error: could not find variant declaration
4 | #pragma omp declare variant(variant_fn) match(user={condition(1)})
| ^~
Comments, remarks, suggestions before I commit it?
To
Hi,
Paul-Antoine Arras wrote:
On 24/10/2024 13:42, Tobias Burnus wrote:
But there is reason to move them to 5/7: I think we also need a run
test for C++ to make sure that it works, i.e. moving them to
libgomp.c-c++- common/ makes sense, which in turn requires the 4/7
C++ FE patch.
I still
Hi Andrew,
Am 28.06.24 um 12:24 schrieb Andrew Stubbs:
--- a/gcc/config/gcn/gcn.cc
+++ b/gcc/config/gcn/gcn.cc
@@ -70,6 +70,11 @@ static bool ext_gcn_constants_init = 0;
enum gcn_isa gcn_isa = ISA_GCN3; /* Default to GCN3. */
+/* Record whether the host compiler added "omp unifed memory
nack=no as they have XNACK
but do not have a well-working USM support.)
At the end, I settled on: Yes, both set the env var and warn.
But I forgot to remove all traces of the unused variable.
Appended the corrected patch …
Tobias
Tobias Burnus wrote:
While users can set HSA_XNACK themselves,
Hi Andrew,
Am 29.10.24 um 13:07 schrieb Andrew Stubbs:
On 29/10/2024 11:44, Tobias Burnus wrote:
This somewhat matches what is done in OG13 and in Andrew's patch at
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655951.html
albeit the code is somewhat different.
[For some reasons,
While users can set HSA_XNACK themselves, it is much more convenient if
the compiler sets it for them (at least if it is overriddable).
Some systems don't have XNACK, but for those that have it, the somewhat
newisher object code versions support three modes: unset (GCC: '-mxnack=any';
supporting
It happens from time to time that we run into asserts, esp. for OMP_CLAUSE_DECL.
The reason is that the comment for omp_clause_code implies that arguments
should be appended (misreading the "Don't reorder") and that there was
no crossref to those macros.
This patch adds comments both a generic c
Hi,
some more comments:
Paul-Antoine Arras wrote:
Here is an updated patch following these comments.
gcc/testsuite/ChangeLog:
* gcc.dg/gomp/adjust-args-1.c: New test.
* gcc.dg/gomp/dispatch-1.c: New test.
The ChangeLog misses to include libgomp/testsuite/
Hi PA;
only playing around quickly and glancing at the patch; I need to have a
real look at this later.
Paul-Antoine Arras:
This patch adds C++ support for the `dispatch` construct and the `adjust_args`
clause. It relies on the c-family bits comprised in the corresponding C front
end patch for
Committed attached patch as r15-4565-g0ecc45a88d7722. It removes
'terminal_width', an unused leftover before switching to the common
diagnostic, which I missed when doing the last cleanup. Best regards,
Tobias
commit 0ecc45a88d772268a3bd83af02759857da0826d4
Author: Tobias Burnus
D
Hi PA,
thanks for the update.
Paul-Antoine Arras wrote:
[…] Please find attached a revised patch.
LGTM, except:
* The update to builtins.cc's builtin_fnspec is lacking in the
changelog list.
* And the new testcase, new
gcc/testsuite/c-c++-common/gomp/dispatch-10.c, has to be put into 3/
David Malcolm wrote:
In order to handle various awkward parsing issues, the Fortran frontend
implements buffering of diagnostics, so that diagnostics reported to
global_dc can be either:
(a) immediately issued, or
(b) speculatively reported to global_dc, and stored in a buffer, to
either be issue
Regarding 202y:
I think it is in general useful to have an implementation of features
before the standard is released, also to find issues before the standard
is released.
The downside I currently see is that the none of the features is really
ready (in the sense that there are explicit edits).
Andrew Stubbs wrote:
I'm going to push the base patch shortly.
… which happened in commit r15-4540-ga6b26e5ea09779.
Updated patch attached.
Some more testing showed that there was an issue with the builtin
defines, which has been fixed and those have been extended as well.
In particular, it
Hi Andrew,
Andrew Stubbs wrote:
On 21/10/2024 20:49, Tobias Burnus wrote:
GCN_DEVICE field descriptions:
- 0 "name" (text, external)
+ 0 Generic flag/version (0 = non-generic, 1 to 255 = generic
version,
+ external)
I think this shou
I have now attached a proper version of my patch, which is relative to your
patch.
OK once your patch is in?
* * *
This adds -march=gfx10-3-generic and -march=gfx11-generic support to the
compiler,
permitting in principle to compile one binary for all gfx103x and gfx11xx GPUs,
respectively.
Hi Andrew,
it it looks good at a glance. We surely will need add more columns in
the future.
In particular, I would add a new first column for the generic version,
albeit currently unused; consider to include it already now.*
Tobias
(*) When eventually adding 'gfx-*-generic' support, more
This patch was motivated by David's talk at Cauldron – and by
getting rather bad locations for some diagnostics, where I wanted
to use the column number to ensure that all items are found.
The main problem was a missing gobbling of spaces, but still
ranges are way nicer. As gfortran uses the comm
*Patch ping*
Tobias Burnus wrote:
I noticed that several diagnostic strings were not tagged as translatable.
I fixed them by adding _ or G_ as prefix ( →gcc/ABOUT-GCC-NLS) and moved a single-use string to the message to
make it more readable. One error message did not quit fit the pattern
Minor follow-up comments:
Paul-Antoine Arras wrote:
This patch adds middle-end support for the `dispatch` construct and the
`adjust_args` clause. The heavy lifting is done in `gimplify_omp_dispatch` and
`gimplify_call_expr` respectively. For `adjust_args`, this mostly consists in
emitting a call
see attached.
by re-adding a testcase which actually tests the builtin.
Committed as r15-4388-gee4fdda70f1080.
Tobias
commit ee4fdda70f1080bba5e49cadebc44333e19edeb4
Author: Tobias Burnus
Date: Wed Oct 16 16:15:40 2024 +0200
Add libgomp.oacc-fortran/acc_on_device-1-4.f
Kind of u
Now pushed as r15-4298-g3269a722b7a036.
Thanks to Bernhard for some proof reading!
Tobias
Tobias Burnus wrote:
Anyone feeling like reviewing this patch? (Mainly the Fortran side?!?)
— Or should I declare it as OpenMP/(OpenACC) patch and just commit it?
→ https://gcc.gnu.org/pipermail/gcc
I noticed that several diagnostic strings were not tagged as translatable.
I fixed them by adding _ or G_ as prefix ( →gcc/ABOUT-GCC-NLS) and moved a single-use string to the message to make
it more readable. One error message did not quit fit the pattern, hence,
I modified it slightly, and a fe
Anyone feeling like reviewing this patch? (Mainly the Fortran side?!?) —
Or should I declare it as OpenMP/(OpenACC) patch and just commit it?
→ https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664985.html
Tobias
Tobias Burnus write:
I forgot to update the subject line. To make it easier
t for the full log):
* openmp.cc (resolve_omp_clauses): Diagnose polymorphic mapping.
* trans-openmp.cc (gfc_omp_finish_clause): Warn when
polymorphic variable is implicitly mapped.
Tobias
Tobias Burnus wrote:
GCC does not really handle mapping of polymo
This unifies the two locus to location_t conversion functions, preparing
for some changes I want to do later.
In principle, I had the patch this morning; however, the assert is now
exercised more often than before - and it triggered rather unexpected
when running the testsuite.
Turned out th
I found always error.cc rather confusing but I just realized that
we can reduce number of lines in that file by 40% - and remove a lot of
(apparent) complexity.
The removed code is from the old days, when gfortran handled a lot of
diagnostic itself, also because it wanted to show lines with caret
1 - 100 of 1251 matches
Mail list logo
