Re: [PATCH] fortran: allow character in conditional expression

Hi Yuao, Yuao Ma wrote: On Tue, Sep 16, 2025 at 5:11 PM Tobias Burnus wrote: PS: Already with the current code, we may run into the issue of passing an actual argument like '(cond ? "abc" : "cdfg")' to 'class(*)' – and I am not sure whether we handle

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Hi Yuao, Yuao Ma wrote: On Mon, Sep 8, 2025 at 10:54 PM Tobias Burnus wrote: BTW, just thinking about it: When simplifying, I wonder whether we want to have a special case for cond ? expr1 : expr1 Namely, condition is only known at runtime but both expressions are identically? I think

[Patch] libgomp: Add Fortran version of acc_copyout_finalize_async and acc_delete_finalize_async

I stumbled over the following: GCC misses* two OpenACC 2.5 functions in Fortran but not in C; actually, when looking deeper at it, .texi and .map already contain everything, just the actual implementation (in openacc.f90) and the interface (in openacc.f90 and in openacc_lib.h) were missing. The a

Re: [PATCH] fortran: allow character in conditional expression

Hi Yuao, Tobias Burnus wrote: For BT_DERIVED: (i) The type needs to be the same – or compatible ('SEQUENCE' attribute) I was referring to: "7.5.2.4 Determination of derived types": "Data entities also have the same type if they are declared with reference

Re: [PATCH] fortran: allow character in conditional expression

Hi Yuao, Yuao Ma wrote: The first cond-expr patch has been committed as r16-3848-gaf53cfeb8352b1. This patch inspired me to work on an even clearer feature: allowing cond-expr to use characters. The change is small; we just need to conditionally fill the string_length. ... Maybe OK for trunk?

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Yuao Ma wrote: I've got a quick question about the collapse clause in OpenMP. I've been looking at the standard, specifically section 6.4.5, and it says that the value of 'n' can't be greater than the loop nest depth. But it doesn't seem to specify what kind of expression you can use for 'n' in C

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Hi Yuao, Yuao Ma wrote: The following is might be an issue in the caller, but nonetheless it fails with conditionals (gfc_match_omp_clauses [openmp.cc:2611] calling gfc_extract_int) - while it works with arithmetic expressions and named constants. (Compile with '-fopenmp'.) ... !$omp do collap

Re: [patch][wwwdocs] gcc-16/changes.html: Update Fortran section

FYI: I have now committed it as 6c1d5b0f7d219dc11f32885b9931205e2fd6a015 Tobias Burnus wrote: attached is a patch to update the Fortran section of the GCC 16 release notes. […] https://gcc.gnu.org/gcc-16/changes.html Tobias

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Yuao Ma wrote: And the latter does not handle EXPR_CONDITIONAL. Thanks for the tip! It turns out that not only does gfc_traverse_expr fail to handle conditional expressions, but check_restricted and gfc_check_init_expr don't either. I've added all the necessary fixes, and the test case is now in

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Hi Yuao, Yuao Ma wrote: This time I use git format-patch. Hopefully fix the issue. Seem so :-) Do I read you patch correctly that you still want to improve it before committing the first version? I assume so because the changelog part of the patch is largely lacking (except for the summary li

Re: GFortran broken after f23bac62f46fc296a4d0526ef54824d406c3756c

Hi Andre, hi all, Andre Vehreschild wrote: I am experiencing a strange issue with gfortran. Compiling a simple program: $ cat end.f90 end $ gfortran end.f90 -o end f951: Fatal Error: Cannot open pre-included file '\xe0\xd4\xf2,' compilation terminated. From your description, it sounds as if y

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Hi Yuao, Yuao Ma wrote: Hi Tobias, I have some updates about this patch. First, some good news: 1. The patch has been bootstrapped and tested with no regressions. This was achieved by limiting the type with only one 'sorry' case. 2. The frontend parsing now considers outer parentheses. :-)

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Hi Yuao, Tobias Burnus wrote: Based on our previous discussion, we don't need to necessarily handle this in the current patch; I just wanted to highlight it. I will investigate how the argument-passing logic works. Yes, as long as there is a 'sorry' instead of producing wrong c

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Hi all, hi Yuao, Yuao Ma wrote: I mostly agree it looks okay. While I'm not that meticulous about diagnostics, I believe it should point to the '=' sign or the first character of the expression. Pointing to the middle, however, seems a bit odd. Looking at your patch, I understand what you mean

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Yuao Ma wrote: BTW, The current trunk seems to have some problems with diagnostic location: https://godbolt.org/z/bcrvn9xo4 In the last days, there were some diagnostic changes; possibly those caused an intermittent issue? Otherwise, it looks ok. Namely: The '1' points to the space after '='i

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Hi Yuao, Yuao Ma wrote: I addressed some review comments and included additional feedback. Thanks for the update. I know that the patch is incomplete, but as I started with bootstrapping, I start with the following. I bet the issues are known to you: First, your patch does not bootstrap* h

Re: [PATCH] fortran: add optional lower arg to c_f_pointer

Hi Yua, Yuao Ma wrote: I noticed that this patch was already committed as r16-3154-g587b8a62f50179! Sorry for the delay in committing. I committed it + wrote an email about it during my vacation, but seemingly, I forgot to hit "send". (I found it in my draft emails.) Tobias

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Hi Yuao, Yuao Ma wrote: Hi Paul, On 7/31/2025 6:02 AM, Paul Richard Thomas wrote: That's exactly how I had a mind to do it. You beat me to it 🙁 Just get on, polish the patch and add more tests. I've updated the patch with improvements to both the functionality and test cases. It should now

Re: [PATCH] fortran: add optional lower arg to c_f_pointer

Yuao Ma wrote: On 8/6/2025 10:57 PM, Yuao Ma wrote: On 8/6/2025 4:32 PM, Tobias Burnus wrote: Hi Yuao, thanks for your patch. I have two nits: * There is no diagnostic for -std=f2018 (or lower);    can you add the 'gfc_notify_std (GFC_STD_F2023' ? Done. Testcase added. Given th

Re: [PATCH] fortran: cleanup duplicate tests for c_f_pointer_shape_driver; nfc

Hi Yuao, thanks for the patch. — I have one nit: Yuao Ma wrote: This patch cleans up a duplicate test driver. Regression-tested. OK for trunk? ... Subject: [PATCH] fortran: cleanup duplicate tests for c_f_pointer_shape_driver; nfc '; nfc'? tests_2_driver and tests_4_driver are identical,

Re: [PATCH] fortran: add optional lower arg to c_f_pointer

Hi Yuao, thanks for your patch. I have two nits: * There is no diagnostic for -std=f2018 (or lower); can you add the 'gfc_notify_std (GFC_STD_F2023' ? * I have a minor documentation nit; current wording is at https://gcc.gnu.org/onlinedocs/gfortran/C_005fF_005fPOINTER.html Namely, ... Yu

Re: Questions on `scan` Intrinsic Implementation (For Fortran 2023 `split` procedure)

Hi Yuao, c8ef wrote: I'm currently working on implementing the `split` procedure, which was added in Fortran 2023. I am wondering whether we should implement it – for kind=1 (and at least  for set len=1) by a call to BUILT_IN_MEMCHR / BUILT_IN_MEMRCHR. For set len > 1, a loop around it has t

Re: [Patch] Fortran/OpenACC: Permit PARAMETER as 'var' in clauses (+ ignore)

Now, finally pushed as r16-2213-g451b6dbf475959. Tobias On June 27, 2025, Tobias Burnus wrote: Background: In real-world code, one can find: !$ACC DECLARE COPYIN(c1es, c2es, ...) as here for the ICON weather model. This clearly implies that other compilers accept and, potentially, require

Re: [PATCH] libgfortran: add fallback for trigonometric pi-based functions

On Sunday, July 6, 2025, Yuao Ma wrote: >>> Since I don't have root/sudo permissions on my devbox, I manually downloaded >>> and compiled the autoconf 2.69 tarball. This means there might be some minor >>> discrepancies compared to the version shipped with OS distributions. In principle, having a

[Patch] Fortran/OpenACC: Permit PARAMETER as 'var' in clauses (+ ignore)

Background: In real-world code, one can find: !$ACC DECLARE COPYIN(c1es, c2es, ...) as here for the ICON weather model. This clearly implies that other compilers accept and, potentially, require those. For better compatibility with real-world use, the just released OpenACC 3.4 now permits PARAME

Re: [PATCH] gcc: middle-end opt for trigonometric pi-based functions builtins

Hi Yuao, Yuao Ma wrote: >//but the testcases don't seem to be conditionalized on this. Would the >//new tests fail if gcc is built against an insufficiently recent version >//of mpfr, … The test case is indeed conditionalized, though in a different manner than you might expect. The condition

[Patch] Fortran/OpenACC: Add Fortran support for acc_attach/acc_detach

This patch adds the OpenACC routines acc_attach and acc_detach. However, in order to avoid the generation of a temporary, which breaks this feature, a special case had to be added to gfc_trans_call. Otherwise, I think it completes the Fortran additions of existing C/C++ functions, by adding this

[committed] OpenACC: Add 'if' clause to 'acc wait' directive

252cafa5045498a0e0c480ee6d48c136232 Author: Tobias Burnus Date: Mon Jun 23 23:24:56 2025 +0200 OpenACC: Add 'if' clause to 'acc wait' directive OpenACC 3.0 added the 'if' clause to four directives; this patch only adds it to 'acc wait'.

Re: [PATCH] fortran: add intrinsic doc for trig functions with half revolutions

Hi Yuao, Yuao Ma wrote: Fixed in this patch. Thinking about tex is always a pain... > Additionally, I think all "half-revolutions" should be "half revolutions" Thanks! I have another nit:     * intrinsic.texi: Add new doc. Reorder doc for atand. The first part is not really clear. I hav

Re: [PATCH] fortran: add intrinsic doc for trig functions with half-revolutions

Hi Yuao, Yuao Ma wrote: This patch is a follow-up to commit r16-938-ge8fdd55ec90749. In this patch, we add intrinsic documentation for the newly added trig functions with half-revolutions. We also reorder the documentation for `atand` to place it in correct alphabetical order. When I try to

Re: [PATCH] gcc: middle-end opt for trigonometric pi-based functions builtins

Joseph Myers wrote: On Sun, 1 Jun 2025, Yuao Ma wrote: For MPFR versions older than 4.2.0, we've included our own folding functions. I think the normal practice in GCC would be to avoid the optimizations when the MPFR support is absent, instead of working around the absence with possibly less a

[Patch] Fortran: gfc_simplify_{cospi,sinpi} - fix for MPFR < 4.2.0 (was: [PATCH] fortran: add constant input support for trig functions with half-revolutions)

Hi Harald, Harald Anlauf wrote: This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2: ../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr* gfc_simplify_cospi(gfc_expr*)': ../../gcc-trunk/gcc/fortran/simplify.cc:2305:3: error: 'mpfr_fmod_ui' was not declared in this scop

Re: [PATCH] fortran: add constant input support for trig functions with half-revolutions

Hi Yuao, Yuao Ma wrote: […] Done. LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749. Thanks for the patch! Tobias

Re: [PATCH] fortran: add constant input support for trig functions with half-revolutions

Yuao Ma wrote: PR113152 If you run your patch through ./contrib/gcc-changelog/git_email.py 0001-fortran-add-constant-input-support-for-trig-function.patch you will notice that the PR is not recognized. The format as mentioned before is "PR component/number". Namely: "PR fortran/113

Re: [PATCH] fortran: add constant input support for trig functions with half-revolutions

Hi, Yuao Ma wrote: I'm pretty swamped for the next couple of days Same issue here - hence, I haven't completed the review ... You're absolutely right that the best way to keep changes minimal is to just rename the `*resolve*` function. I missed the -gfc_resolve_trigd, +gfc_resolve_trig, c

Re: [PATCH] fortran: add constant input support for trig functions with half-revolutions

Hi Yuao, first comments, I still need to look again at some changes, especially at simplify.cc. Yuao Ma wrote: This patch introduces constant input support for trigonometric functions, including those involving half-revolutions. Both valid and invalid inputs have been thoroughly tested, as

[Patch] OpenMP/Fortran: Fix allocatable-component mapping of derived-type array comps

The testcase was found when looking at mapping fails with SPEC HPC's 619.clvleaf_s; however, the variant fixed by the attached patch only showed up when experimenting and not in the SPEC testcase itself. Before the included fix, to be added testcase failed with an ICE. I intent to commit the atta

[committed] Fortran: Fix mpfr_tanu use in gfc_simplify_cotand with mpfr 4.2.0+ [PR120225] (was: PING – Re: [Patch] Fortran: Use mpfr_sinu etc. with mpfr 4.2.0+ for degree trigonometric functions [PR12

6-607-gc91c226762b422 and then the fix in r16-608-gaac78fde6aa6ae. Tobias commit aac78fde6aa6ae829679355bc2a65bcadd834e6f Author: Tobias Burnus Date: Wed May 14 09:18:09 2025 +0200 Fortran: Fix mpfr_tanu use in gfc_simplify_cotand with mpfr 4.2.0+ [PR120225] Fix commit r1

PING – Re: [Patch] Fortran: Use mpfr_sinu etc. with mpfr 4.2.0+ for degree trigonometric functions [PR120225]

sinpi etc. functions, cf. https://gcc.gnu.org/PR113152 for Fortran and https://gcc.gnu.org/PR118592 for C23/middle end. Tobias Burnus wrote: C23 added the sinpi, cospi, etc. functions. Therefore, MPFR in 4.2.0 added the mpfr_ counter parts. I assume that those internally use the mpfr_sinu

Re: [PATCH] fortran: map atand(y, x) to atan2d(y, x) [PR113413]

Hi Yuao, Yuao Ma wrote: Following up on your review comments, I have updated the patch. Thanks - LGTM. Two minor comments, but I have already pushed the commit as r16-602-gb239e9cf98ca92 First: * gfortran.dg/dec_math.f90: Add atand(y, x) testcase. Also for the documentation, the

Re: [PATCH] libfortran: Fix up _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} [PR120191]

Jakub Jelinek wrote: There is a bug in _gfortran_s{max,min}loc1_{4,8,16}_s{1,4} which the following testcase shows. The functions return but then crash in the caller. Seems that is because buffer overflows, I believe those functions for if (mask == NULL || *mask) condition being false are sup

Re: [PATCH] libfortran: Fix up _gfortran_s{max,min}loc2_{4,8,16}_s{1,4} [PR120191]

First is slightly confusing as there are three patches for PR120191. In particular, two which look almost identical - one for loc2 (this one) and one for loc1 (the one sent one our later). Jakub pointed out that the remarks after "ok for trunk?" for this patch are obsoleted by the follow up patch

Re: [PATCH] libfortran: Fix up _gfortran_{, m, s}findloc2_s{1, 4} [PR120196]

Hi Jakub, Jakub Jelinek wrote: As mentioned in the PR, _gfortran_{,m,s}findloc2_s{1,4} iterate too many times in the back case if nothing is found. For !back, the loops are for (i = 1; i <= extent; i++) so i is in the body [1, extent] if nothing is found, but for back it is for (i = extent; i >

Re: [PATCH] fortran, v2: Fix up minloc/maxloc lowering [PR120191]

seems they are on the library side, so I'll post it incrementally. 2025-05-12 Jakub Jelinek Daniil Kochergin Tobias Burnus PR fortran/120191 * trans-intrinsic.cc (strip_kind_from_actual): Remove. (gfc_conv_intrinsic_minmaxloc):

[Patch] Fortran: Use mpfr_sinu etc. with mpfr 4.2.0+ for degree trigonometric functions [PR120225]

C23 added the sinpi, cospi, etc. functions. Therefore, MPFR in 4.2.0 added the mpfr_ counter parts. I assume that those internally use the mpfr_sinu, mpfr_cosu, ... functions, which are also user accessible. In any case, MPFR makes the ...u functions available and explicitly documents that for u

Re: [PATCH] fortran: map atand(y, x) to atan2d(y, x)

Hi all, hi Yuao, first, thanks for your patch - you are awesome! I believe it fixes the issue reported by Steven in problem report (PR) 113414, https://gcc.gnu.org/PR113413 Thus: * * * [Linking PR numbers] In order to correlate commits to issued (and get them automatically linked), the commit

Re: [PATCH, fortran] Fix simple typo in libgfortran

Hi Yuao, Yuao Ma wrote: Thanks for the tip! I ran the git_check_commit.py script, and it reported "OK." However, when I regenerated the ChangeLog, the function name wasn't included automatically. Usually 'git diff' shows the function name in the '@@' line, but that does not always work – ei

Re: [PATCH, fortran] Fix simple typo in libgfortran

Hi Yuao, Yuao Ma wrote: I'm writing to express my sincere gratitude for the opportunity to participate in Google Summer of Code with GCC this year. I am very enthusiastic about this program and fully committed to making a valuable contribution and fulfilling my responsibilities. Welcome an

Re: [PATCH] fortran: Fix up minloc/maxloc lowering [PR120191]

Jakub Jelinek wrote: This unfortunately only fixes some of the cases in the new testcase. We indeed should drop the kind argument from what is passed to the library, but need to do it not only when one uses the argument name for it (so kind=4 etc.) but also when one passes all the arguments to t

[committed] OpenMP: Add libgomp.fortran/target-enter-data-8.f90

r16-92-gc9a8f2f9d39a31 Tobias commit c9a8f2f9d39a317ed67fb47157a995ea03c182d4 Author: Tobias Burnus Date: Wed Apr 23 09:03:00 2025 +0200 OpenMP: Add libgomp.fortran/target-enter-data-8.f90 Add another testcase for Fortran deep mapping of allocatable componen

Re: [wwwdocs][Patch] gcc-15/changes: Fortran + offload (C++) update | project/gomp: GCC 15 update

Gerald Pfeifer wrote: On Thu, 17 Apr 2025, Tobias Burnus wrote: * https://gcc.gnu.org/projects/gomp/ This is a no-brainer. Well, it still adds GCC 16 … It does make me wonder whether we really need/want distinct docs for minor releases or shouldn't better keep just one for the branch

[wwwdocs][Patch] gcc-15/changes: Fortran + offload (C++) update | project/gomp: GCC 15 update

Hi all, @Fortraners: Comments to the added 'do concurrent' item? @Thomas: Are you fine with this C++ wording? @Andrew: Likewise for C++ and ROCm bump? Anyone: comments are welcome. Affected pages: * https://gcc.gnu.org/gcc-15/changes.html * https://gcc.gnu.org/projects/gomp/ Cheers, Tobia

[Patch] Fortran: Add code gen for do,concurrent's LOCAL/LOCAL_INIT [PR101602]

This patch is essentially the one of PR101602, comment 6. Thus, it has the same issues as that patch: * LOCAL for derived-type variables with default initalizers do not work (not initialized) * LOCAL/LOCAL_INIT for assumed-shape arrays fails (need some 'malloc'/'free' calls + some more other

[committed] Move gfortran.dg/gomp/declare-variant-mod-1*.f90 to libgomp.fortran/ [PR115271] (was: [Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271])

sue does not manifest for in-tree testing when the system provides what is needed.) Committed as r15-8085-g2d5c1e5149809f. Thanks for the report! Tobias commit 2d5c1e5149809f978ea2c07517de13fdbb925de6 Author: Tobias Burnus Date: Mon Mar 17 10:12:44 2025 +0100 Move gfortran.dg/

Re: [Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271]

Hi Thomas, Thomas Koenig wrote: Attached is a long overdue bug fix, given that OpenMP's declare variant is supported in gfortran sincer12-4409-g724ee5a0093da4 (Oct 2021). (and in C/C++ since r10-3744-g94e7f906ca5c73, Oct 2019). While 'omp declare simd' was already handled in the .mod file, 'de

[Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271]

Attached is a long overdue bug fix, given that OpenMP's declare variant is supported in gfortran sincer12-4409-g724ee5a0093da4 (Oct 2021). (and in C/C++ since r10-3744-g94e7f906ca5c73, Oct 2019). While 'omp declare simd' was already handled in the .mod file, 'declare variant' was not. It is eas

Re: [Patch] Fortran: Store OpenMP's 'declare variant' in module file [PR115271]

I wonder why sometimes my line breaks are preserved and at other times all eaten. Next try ... Tobias Burnus wrote: Hi Thomas, Thomas Koenig wrote: Just one question - as this will change the module file, will we still be compatible with reading gfortran 8 to gfortran 14-written module

Re: [Patch] Fortran: Improve gfc_array_kind for assumed rank; gfc_tree_array_size on 'tree'

Just to be clear: the following touches generic Fortran code and, hence, needs Fortran FE review (still pending): Tobias Burnus wrote: (1) gfc_tree_array_size now can determine the array size not only from the passed Fortran gfc_expr but also using a descriptor, passed as gimple 'tree&#

[Patch] Fortran: Improve gfc_array_kind for assumed rank; gfc_tree_array_size on 'tree'

The attached patch does some ground-laying work for OpenMP deep mapping - touching common gfortran code. It does so by: (1)gfc_tree_array_size now can determine the array size not only from the passed Fortran gfc_expr but also using a descriptor, passed as gimple 'tree'. (2) Adds missingGFC_

[committed] gfortran.dg/gomp/metadirective-3.f90

-g8d922a80396b0c, cf. attachment. Tobias commit 8d922a80396b0cc9f5311d79aa760412dd018848 Author: Tobias Burnus Date: Tue Feb 18 15:48:39 2025 +0100 gfortran.dg/gomp/metadirective-3.f90: xfail on offload_nvptx Currently, 'target' with a nested metadirective creating a 'teams

[Patch] OpenMP/Fortran: extend 'adjust_args' clause, fixes for it and declare variant [PR115271]

Hi all, on the fixes side: If a function only appeared in an INTERFACE block, the declare variant handling wasn't triggered - i.e. all diagnostic handled there wasn't. Additionally, when it was written as such in a module - and the module got used, it wasn't active such that the wrong (the non v

[committed] Fortran/OpenMP: Add location data to 'sorry' [PR118740]

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

[committed] fortran/trans-openmp.cc: Use the correct member in gfc_omp_namelist [PR118745]

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

Re: [PATCH] OpenMP: Improve Fortran metadirective diagnostics [PR107067]

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

Re: [PATCH v6 4/6] OpenMP: Fortran support for metadirectives and dynamic selectors

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

Re: [PATCH v6 4/6] OpenMP: Fortran support for metadirectives and dynamic selectors

-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

[committed] Fortran: In openmp.cc, uncomment unroll/tile lines of gfc_omp_directives

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

Re: DO CONCURRENT with LOCAL / LOCAL_INIT [was: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)]

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

DO CONCURRENT with LOCAL / LOCAL_INIT [was: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)]

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

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

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

[Patch] Fortran/OpenMP: Fix declare_variant's 'adjust_args' mishandling with return by reference [PR118321]

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

[Patch] Fortran: Create fresh ts.u.cl for result in gfc_get_symbol_for_expr [PR118441]

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

Re: [PATCH] Accept commas between clauses in OpenMP declare variant

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

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

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 *

Re: [Patch] Fortran: Fix location_t in gfc_get_extern_function_decl; support 'omp dispatch interop'

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

[Patch] Fortran: Fix location_t in gfc_get_extern_function_decl; support 'omp dispatch interop'

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) |

[Patch] OpenMP: Enable has_device_addr clause for 'dispatch' in Fortran

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

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

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

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

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

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

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:

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

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

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

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

[Patch] OpenMP: 'allocate' directive - fixes for 'alignof' and [[omp::decl]]

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

Re: [PATCH] Fortran: fix crash with bounds check writing array section [PR117791]

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:

[Patch][v2] OpenMP: 'interop' construct - add C parser support, improve Fortran pasing

_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

[Patch] OpenMP: 'interop' construct - add C parser support, improve Fortran pasing

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

[committed] Fortran: Minor follow-up cleanup to error.cc

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

Re: [PATCH] Implement Fortran diagnostic buffering for non-textual formats [PR105916]

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

Re: [Patch, fortran] PR116733: Generic processing of assumed rank objects (f202y)

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).

Fortran: Add range-based diagnostic

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

Re: [Patch] Fortran: Fix translatability of diagnostic strings

*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

[committed] Add libgomp.oacc-fortran/acc_on_device-1-4.f (was: Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device: Harmonize 'libgomp.oacc-fortran/acc_on_device-1-*'

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

Re: [Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device

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

[Patch] Fortran: Fix translatability of diagnostic strings

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

Re: [Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device (was: [Patch]

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

Re: [Patch] Fortran/OpenMP: Warn when mapping polymorphic variables

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

[Patch] Fortran: Unify gfc_get_location handling; fix expr->ts bug

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

[Patch] Fortran: Dead-function removal in error.cc (shrinking by 40%)

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

[Patch] Fortran/OpenMP: Warn when mapping polymorphic variables

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.

[Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device (was: [Patch] (was: [Patch] Fortran/OpenMP: Fix __builtin_omp_is_initial_device))

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

  1   2   3   4   5   6   7   >