Early ping for this patch.
(I still plan to review Harald's pending patch soon, unless someone
beats me:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580810.html )
On 01.10.21 02:43, Tobias Burnus wrote:
Hi all,
this patch fixes a bunch of issues with CLASS.
* * *
Side rema
Hi Sandra,
On 06.10.21 23:37, Sandra Loosemore wrote:
This patch is for PR fortran/54753, to add a diagnostic for violations
of this constraint in the 2018 standard:
C839 If an assumed-size or nonallocatable nonpointer assumed-rank
array is an actual argument that corresponds to a dummy arg
Hi Chung-Lin,
On 07.10.21 15:59, Chung-Lin Tang wrote:
this patch add support for "strictly-structured blocks" introduced in
OpenMP 5.1,
basically allowing BLOCK constructs to serve as the body for directives:
!$omp target
block
...
end block
[!$omp end target] !! end directive is optional
Hi Sandra
On 08.10.21 18:58, Sandra Loosemore wrote:
I concur that that should be in a separate PR.
It's PR102641 now.
Thanks.
OK to commit v2 of the patch (attached)?
OK – thanks for the patch!
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 20
, Tobias Burnus wrote:
Hi all,
attached is the updated version. Changes:
* Handle noncontiguous arrays – with BIND(C), (g)Fortran needs to make it
contiguous in the caller but also handle noncontiguous in the callee.
* Fixes/handle 'character(len=*)' with BIND(C); those always use
Hi Harald,
On 10.10.21 21:27, Harald Anlauf via Fortran wrote:
just some random remarks from initially browsing your patch.
Thanks for browsing the patch :-)
- leftover from debugging?
Yes.
- code that could be shortened/made slightly more readable:
...
Is there a reason to not use strcmp (c
PING**2
On 06.10.21 12:24, Tobias Burnus wrote:
Early ping for this patch.
I do note that Harald browsed the patch (thanks!) and had two remarks,
cf. https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581256.html
(I intent to fix the two nits – as mentioned in the reply to Harald's
I recently saw that 'ancestor:' wasn't handled in -fdump-parse-tree.
I also did run once into an ICE for the swap flag in atomics when
dumping. – This fixes the two.
Additionally, I changed 'ancestor' to a bit field.
Comments? If not, I will commit it later today.
Tobias
-
Sieme
tigated.
(**) There are still some 'xfail' in comments (outside dg-*)
whose tests now pass. And those where for two bugs in the same
statement, only one is reported - and the other only after fixing
the first one, which is fine.
On 09.10.21 23:48, Tobias Burnus wrote:
Hi all,
attach
Dear all, hello Harald,
On 12.10.21 22:50, Harald Anlauf wrote:
while working on a fix for PR102685, I encountered issues with the testsuite.
...
(1) gfortran.dg/derived_constructor_char_1.f90
The constructor is shorter than the array component txt in DT t5.
Commit r0-101989.
@Tobias: can you
Hi Harald, dear all,
On 14.10.21 23:27, Harald Anlauf via Fortran wrote:
the attached patch adds a check for the shape of arrays in derived type
constructors. This brings it in line with other major brands.
...
In developing the patch I encountered a difficulty with testcase
dec_structure_6.f90
This patch fixes two issues:
First, to print 'CLASS(t2)' instead of:
Error: Type mismatch in argument ‘x’ at (1); passed CLASS(__class_MAIN___T2_a)
to TYPE(t)
Additionally,
class(t2) = class(t) ! 't2' extends 't'
class(t2) = class(any)
was wrongly accepted.
OK?
Tobias
-
Hi Honza,
On 16.10.21 20:23, Jan Hubicka via Gcc-patches wrote:
FAIL: gfortran.dg/deferred_type_param_6.f90 -O1 execution test
FAIL: gfortran.dg/deferred_type_param_6.f90 -Os execution test
Sorry for the breakage. This time it seems like bug in Fortran FE
which was previously latent:
__
obias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 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 6920d5a1a283
Anschrift: Arnulfstraße 201, 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 ff0eec94e87dfb7dc387f120ca5ade2707aecf50
Author: Tobias Burnus
Date: Tue Oct 19 16:38:5
; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit d4044db034b40c275b5f287d5854a102d22e07c0
Author: Tobias Burnus
Date: Wed Oct 20 08:32:16 2021 +0200
gfortran.dg/bind-c-contiguous
Hi Sandra,
On 20.10.21 22:03, Sandra Loosemore wrote:
The one that was most concerning was an ICE when calling the SHAPE
intrinsic with an assumed-rank class type argument ... In this case,
SHAPE was calling a library function and trying to copy the array
contents to a temporary, which is really
pending issues and be quicker in
future.
Tobias
PS: Old and probably current but incomplete pending patch list:
On 21.06.21 17:21, José Rui Faustino de Sousa wrote:
On 21/06/21 12:37, Tobias Burnus wrote:
Thus: Do you have a list of patches pending review?
https://gcc.gnu.org/pipermail/fortran
Hi José, hi Fortraners,
triage of all listed patches:
On 21.06.21 17:21, José Rui Faustino de Sousa wrote:
https://gcc.gnu.org/pipermail/fortran/2021-April/055924.html
PR100040 - Wrong code with intent out assumed-rank allocatable
PR100029 - ICE on subroutine call with allocatable polymorphi
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
ter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 24e99e6ec1cc57f3660c00ff677c7feb16aa94d2
Author: Tobias Burnus
Date: Fri Oct 22 23:23:06 2021 +0200
Fortran: Avoid running into assert with -fcheck= + UB
Author: Tobias Burnus
Date: Sat Oct 23 00:04:43 2021 +0200
Fortran: Change XFAIL to PASS
Replace dg-excess-errors by dg-error/warning and dg-prune-output for
more fine-grained output handling and to avoid XPASS.
gcc/testsuite/ChangeLog:
* gfortran.dg
Hi Steve,
On 23.10.21 18:31, Steve Kargl via Fortran wrote:
Do you know how to run a single libgomp.fortran test? I tried
% gmake check-fortran RUNTESTSFLAGS="gomp.exp=async_io.f90"
but this runs all the testcases.
First, it should be RUNTESTFLAGS= (test not tests).
Additionally, gomp.exp (
Hi Steve, hi Gerald,
@Gerald: Do you see those issues as well? Or do you have an idea what
could go wrong?
@Gerald (and unrelated to the topic below): Can you provide more log
data regarding the failing gfortran.dg tests? (Esp. excess errors but
also the ICE.)
On 23.10.21 20:00, Tobias
Hi Thomas,
On 25.10.21 07:47, Thomas Koenig via Fortran wrote:
what you're doing seems a useful clean-up, thanks.
One point for discussion:
-match
+static match
gfc_match_label (void)
I have generally understood that the gfc_ prefix is for global variables
and functions only. We do not alw
ft: München; Registergericht
München, HRB 106955
commit a31a3d0421f0cf1f7eefacfec8cbf37e7f91600d
Author: Tobias Burnus
Date: Tue Oct 26 10:53:53 2021 +0200
Fortran: Fix character(len=cst) dummies with bind(C) [PR102885]
PR fortran/102885
gcc/fortran/ChangeLog:
On 25.10.21 00:30, Bernhard Reutner-Fischer via Fortran wrote:
From: Bernhard Reutner-Fischer
gfc_constructor_expr_foreach and gfc_constructor_swap were just stubs.
gcc/fortran/ChangeLog:
* constructor.c (gfc_constructor_get_base): Make static.
(gfc_constructor_expr_foreach, (gfc_co
On 25.10.21 00:30, Bernhard Reutner-Fischer via Fortran wrote:
From: Bernhard Reutner-Fischer
This makes some trans* functions static and deletes declarations of
functions that either do not exist anymore like gfc_get_function_decl
or that are unused like gfc_check_any_c_kind.
gcc/fortran/Cha
On 25.10.21 00:30, Bernhard Reutner-Fischer via Gcc-patches wrote:
From: Bernhard Reutner-Fischer
gfc_match_small_int_expr was unused, delete it.
gfc_match_gcc_unroll should use gfc_match_small_literal_int and then
(but wasn't in this patch)
gfc_match_small_int can be deleted since it will b
On 25.10.21 00:30, Bernhard Reutner-Fischer via Fortran wrote:
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* trans-array.c (gfc_trans_scalarized_loop_end): Make static.
* trans-array.h (gfc_trans_scalarized_loop_end,
gfc_conv_tmp_ref, gfc_conv_array_transpose): Dele
On 25.10.21 00:30, Bernhard Reutner-Fischer via Gcc-patches wrote:
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* trans-stmt.h (gfc_trans_deallocate_array): Delete.
OK. Thanks!
Tobias
---
gcc/fortran/trans-stmt.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/for
On 25.10.21 00:30, Bernhard Reutner-Fischer via Fortran wrote:
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* trans-types.h (gfc_convert_function_code): Delete.
OK.
Tobias
---
gcc/fortran/trans-types.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/fortran/tran
Dear Harald, dear all,
On 24.10.21 21:00, Harald Anlauf via Fortran wrote:
I've created PR 102917 for tracking this issue and packaged
the attached patch.
Regtested on x86_64-pc-linux-gnu. OK mainline?
OK. I wonder whether a valid len/kind example should be added which uses
such a PDT with n
Dear Harald, hi all,
On 22.10.21 21:36, Harald Anlauf via Fortran wrote:
the recently introduced shape validation for array components
in DT constructors did not properly deal with invalid code
created by ingenious testers.
Obvious solution: replace the gcc_assert by a suitable error message.
On 26.10.21 21:40, Harald Anlauf via Fortran wrote:
we were missing a conflict check for PDT KIND and LEN type parameters:
F2018: 7.5.3.1 Type parameter definition statement
R732 type-param-def-stmt is
integer-type-spec, type-param-attr-spec :: type-param-decl-list
R734 type-param-
Just the Fortran FE work + Fortranized version for the C tests.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
Found this when looking at the num_teams patch – and when
converting clauses-1.c to clauses-1.f90.
OK?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank T
On 11.11.21 19:01, Jakub Jelinek wrote:
On Thu, Nov 11, 2021 at 06:11:23PM +0100, Tobias Burnus wrote:
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
...
+ matchs ("end distribute parallel do simd", gfc_match_omp_end_nowait,
...
+ matcho ("end distrib
On 12.11.21 13:02, Jakub Jelinek wrote:
3) anything combined with target allows it
... and puts it on 'target' as it shouldn't be on 'for' or 'do' in
'target ... parallel do/for ...', I'd guess.
Updated patch attach.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrif
The basic support was lying around here already for too long.
TODO at some point: Update the trans-openmp.c part to handle compare +
extend the testcases even more, especially when compare works.
OK?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201
Hi Harald, hi Chung-Lin,
On 29.11.21 21:21, Harald Anlauf wrote:
I think you need to check the following:
allocate(c, source=h(3))
write(*,*) lbound(c,1), ubound(c,1) ! prints 1 3
...
pure function h(i) result(r)
integer, value, intent(in) :: i
integer, allocatable :: r(:)
allocate(r(3
On 29.11.21 22:11, Harald Anlauf wrote:
"A whole array is a named array or a structure component whose final
part-ref is an array component name; no subscript list is appended."
I think in "h(3)" there is not really a named array – thus I read it as
if the "Otherwise ... result value is 1" appl
This is a RFC/WIP patch about:
(A) OpenMP (C/C++/Fortran)
omp target map(iterator(i=n:m),to : x(i))
(B) Fortran:
(1) omp target map(to : dt_var, class_var)
(2) omp parallel allocator(my_alloc) firstprivate(class_var)
(3) call co_reduce(dt_coarray, my_func)
The problem with (A) is that t
On 06.12.21 16:16, Jakub Jelinek wrote:
I think there is no reason why the 3 arrays passed to GOMP_target_ext
(etc., for target data {, enter, exit} too and because this
affects to and from clauses as well, target update as well)
need to be constant size.
We do a lot of sorting of the map clauses
Some Sunday work ...
Implement the 'compare' part in trans-openmp of OpenMP 5.1's atomic changes
plus a couple of bugfixes throughout.
OK?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Gesch
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
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
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
Patches gfc_conv_procedure_call (+ called functions).
Found via OpenMP_VV which uses rather pointlessly 'if
(omp_is_initial_device() .eqv. .true.)' – instead of using 'if (omp_…())'.
This failed with an ICE as the middle end did not like 'if (
== )' comparisons.
The initial idea was to crea
GCC does not really handle mapping of polymorphic variables - and OpenMP
6 will also make it implementation defined. (While explicitly permitting
it with data-sharing clauses.)
This matches essentially what is in GCC, except that 'private' (and
other privatizations) are not properly handled.
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
Hi Andre,
first, thanks a lot for all your proof reading of patches! That's indeed
helpful and reviewing (with offical LGTM stamp or as bystander) is a
problem, you help to reduce it! :-)
Andre Vehreschild wrote:
@@ -821,6 +821,23 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
+ if (s
Now committed as r15-4104-ga8caeaacf499d5.
With a wording improvement in the commit log and avoiding an XPASS for
C++ by excluding c++98 from the xfail in dg-bogus... xfail.
Tobias
Tobias Burnus wrote:
'omp allocate' permits to use a different (specified) allocator and
alignmen
'omp allocate' permits to use a different (specified) allocator and
alignment for both stack/automatic and static/saved variables; the latter
takes only predefined allocators. Currently, only C and Fortran are
support for stack/automatic variables; static variables are rejected
before the attached
Committed as r15-4127-gb95ad25f9c9376
Hi Thomas,
Thomas Schwinge wrote:
On 2024-10-07T17:07:05+0200, Tobias Burnus wrote:
If anyone can reproduce this, I would be interested in the excess errors.
gfortran: fatal error: cannot read spec file 'libgomp.spec': No such file
or
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
*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
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
Sometimes waiting a bit leads to better code …
Tobias Burnus wrote:
...
[I guess, we eventually want to add support for more builtins. For
instance, acc_on_device would be a candidate, but I could imagine some
additional builtins.]
I have now implemented acc_on_device and I think the new
I forgot to update the subject line. To make it easier to find (patch
archeology), now with proper subject line …
Tobias Burnus wrote:
Sometimes waiting a bit leads to better code …
Tobias Burnus wrote:
...
[I guess, we eventually want to add support for more builtins. For
instance
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).
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
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
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
_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 Paul,
Am 23.09.24 um 10:26 schrieb Paul Richard Thomas:
In addition to Andre's remarks, could you please tell us, when you
resubmit, if this is a complete F2023 implementation of do concurrent.
If not, what is missing?
Regarding missing parts: still to do is actually privatizing (with or
wi
Hi Andre,
Andre Vehreschild wrote:
Could you also please specify the commit SHA your patch is supposed to apply
to? At current mainline's HEAD it has several rejects which makes reviewing
harder.
I just tried and here it applies cleanly on mainline, except that I get
a bunch of:
Hunk #1 suc
Hi all,
as a background – Anuj, did this as part of his Google Summer of Code
project (thanks!).
As I looked as various drafts, I would be happy if someone else could
have a look as well, as I probably start skipping over things and,
hence, as miss potential issues …
A bit hidden in the patch i
Add support of the 'self_maps' clause in 'omp requires',
an OpenMP 6 feature but added here mostly as part of the
on-going improvement of the unified-shared memory (USM) handling.
Comments, remarks concerns before I commit it?
* * *
Regarding USM, there is on one hand the hardware:
- some hard
Now committed as r15-3799-gcdb9aa0f623ec7 /
https://gcc.gnu.org/r15-3799-gcdb9aa0f623ec7
Tobias
Am 21.09.24 um 01:33 schrieb Tobias Burnus:
Hi Thomas, hello all,
the attached follow-up patch does:
* It fixes an issue (thinko) related to Fortran and \0 terminated,
which fails for at least
Hi all,
I have now downloaded the file at
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663534.html (by
copying it from the browser, not the source code to avoid '>
This file had had to fix spurious line breaks like:
@@ -5171,7 +5171,7 @@ index_interchange (gfc_code **c, int
*wal
OpenMP mandates that when certain clauses are used with 'omp requires'
that in all compilation units this requires clause appears.
Those clauses influence the offloading behavior (+ potentially codegen);
hence, the must requires must match for those claues when device code is
involved. That's
But no must.
Ok for mainline. Thanks for the patch.
- Andre
On Sat, 21 Sep 2024 23:37:33 +0200
Tobias Burnus wrote:
Add support of the 'self_maps' clause in 'omp requires',
an OpenMP 6 feature but added here mostly as part of the
on-going improvement of the unified-shared m
Hi all,
in order to know and potentially re-use a specific offload device
(reproducibility,
affinity wise close to a CPU (socket), …) a mapping between an (universal?)
unique
identifier and the OpenMP device number is useful. Thus, TR13 added support for
it.
This is a collateral patch caused
Hi Thomas, hello all,
the attached follow-up patch does:
* It fixes an issue (thinko) related to Fortran and \0 terminated,
which fails for at least substring strings.
* Includes some minor fixes, e.g. ensuring the device is initialized
in omp_get_uid_from_device, the superfluous 'omp_', or
/
(routine + nvptx/gcn offload specific) which makes it easier to read.
Thanks,
Tobias
Tobias Burnus wrote:
Minor update – addressing the issues that Andre raised (thanks!):
'Add.' → 'New functions.' in the ChangeLog for 'fortran.c' and
otherwise libgomp.texi changes,
Hi all,
I thought it makes sense to have a look at what went into GCC 15 to
update the Fortran section. However, while several bugs were fixed
(and extended some features a tiny bit) [hooray!], I did not really
see many newsworthy features.
Comments, remarks to, approval of the attached wwwdocs
Hi Andre,
thanks for reading the patch + commenting.
Andre Vehreschild wrote:
in the changelog of libgomp:
* fortran.c (omp_get_uid_from_device_,
omp_get_uid_from_device_8_): Add.
"Add." what? Can you be more specific, i.e. is it just a dummy or prototype?
Neither. It is a f
or the GPUs, which should help to reduce confusion.
Any additional comments or suggestions?
Tobias
Tobias Burnus wrote:
in order to know and potentially re-use a specific offload device
(reproducibility,
affinity wise close to a CPU (socket), …) a mapping between an
(universal?) unique
id
Hi
now committed the following as r15-3856-gfcff9c3dad4f35 with two
testcase additions (and improved changelog wording).
Tobias Burnus wrote:
OpenMP mandates that when certain clauses are used with 'omp requires'
that in all compilation units this requires clause appears.
Tho
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:
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
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,
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
actually does not happen,
i.e. in that sense the code is "fine" as it does not crash. Still,
having NULL + some offset is not the best pointee.)
Committed asr15-7366-g3a5882707df50e Tobias
commit 3a5882707df50ed29905b3c47cbaa0868ea248c9
Author: Tobias Burnus
Date: Wed Feb 5 08:44:41
Hi Sandra, hello world,
Sandra Loosemore wrote:
gcc/fortran/ChangeLog
PR middle-end/107067
* parse.cc (parse_omp_do): Diagnose missing "OMP END METADIRECTIVE"
after loop.
(parse_omp_structured_block): Likewise for strictly structured block.
(parse_omp_meta
For an example output, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113067#c2
Fixed in commit r15-7376-g6f95af4f22b641 which also fixes the testsuite
issue (off by one) of my previous commit for PR118745, ups!
Tobias
commit 6f95af4f22b641fbb3509f1436bce811d4e4acad
Author: Tobias Burnus
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
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 Damian,
Damian Rouson wrote:
As shown below, using associate eliminates the first error, but I'm
still confused by the remaining error message. Are locality
specifiers actually supported yet?
The lion share of support is in, but not not yet the code-generation
changes.
For local and lo
This was seemingly forgotten when UNROLL/TILE was added.
Committed asr15-7220-g7cd133a6e4b042 as obvious. Tobias
commit 7cd133a6e4b04262620489dbf4b4e3ae5e96c95f
Author: Tobias Burnus
Date: Mon Jan 27 00:35:17 2025 +0100
Fortran: In openmp.cc, uncomment unroll/tile lines of
-Authored-By: Tobias Burnus
Co-Authored-By: Paul-Antoine Arras
Smaller items:
* uncommenting "metadirective" inside gfc_omp_directives.
I believe this has already been done locally.
* OpenMP permits (optional) commas as separators between clauses (and since 6.0
also between the
Hi,
John Campbell wrote:
Would it be easier to consider "DO CONCURRENT with LOCAL / LOCAL_INIT" as a
special case of !$OMP PARALLEL DO, so utilise this existing implementation ?
I think I want to handle by default a bare 'do concurrent' with a code
separate from OpenMP, but using the normal
Hi Sandra,
Sandra Loosemore wrote:
* Unless it is quickly fixable, we agreed on deferring the bogus message
"Error: ‘target’ construct with nested ‘teams’ construct contains
directives
outside of the ‘teams’ construct"
to a new PR. That's for:
OpenMP_VV's
tests/5.0/metadirect
Hi all,
I noticed that the do-concurrent locality specifiers are tracked in
https://gcc.gnu.org/PR101602
I have now added a comment to point to the GCC 15 commit. And added a
note that LOCAL/LOCAL_INIT are not yet handled.
* * *
BTW: I have tried to implement LOCAL/LOCAL_INIT, but it turne
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:
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,
(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:
501 - 600 of 640 matches
Mail list logo
