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

[Patch] (was: [Patch] Fortran/OpenMP: Fix __builtin_omp_is_initial_device)

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

[Patch] Fortran/OpenMP: Fix __builtin_omp_is_initial_device

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

[committed] Move gfortran.dg/gomp/allocate-static.f90 to libgomp.fortran/ (was: [r15-4104 Regression] FAIL: gfortran.dg/gomp/allocate-static.f90 -Os (test for excess errors) on Linux/x86_64)

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

Re: [Patch] OpenMP: Allocate directive for static vars, clean up

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

Re: [Patch] OpenMP: Allocate directive for static vars, clean up

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

[Patch] OpenMP: Allocate directive for static vars, clean up

'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

Re: [Patch] OpenMP: Update OMP_REQUIRES_TARGET_USED for declare_target + interop

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

[Patch] OpenMP: Update OMP_REQUIRES_TARGET_USED for declare_target + interop

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

Re: [Patch] OpenMP: Add support for 'self_maps' to the 'require' directive

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

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

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

Re: OpenMP: Fix omp_get_device_from_uid, minor cleanup

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

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

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

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

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

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

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

[Patch] OpenMP: Add support for 'self_maps' to the 'require' directive

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

OpenMP: Fix omp_get_device_from_uid, minor cleanup (was: Re: [Patch][v2] OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines)

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

[wwwdocs][Patch] gcc-15: Fortran - mention -funsigned + PowerPC Darwin IEEE module support

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

Re: [Patch][v2] OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines

/ (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,

[Patch][v2] OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines

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

Re: [Patch] OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines

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

[Patch] OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines

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

[Patch] Fortran: Fixes to OpenMP 'interop' directive parsing support

This patch fixes a couple of issues, like a missing white-space gobbling after matching an expression. It also reorganizes some code to handle 'identifier_"string"' vs. 'identifier' better as there were some diagnostic issues. (OpenMP requires for 'fr' that the argument is either an identifie

[committed] fortran/openmp.cc: Fix var init and locus use to avoid uninit values [PR fortran/116661]

bcb7630ba330e Author: Tobias Burnus Date: Wed Sep 11 09:25:47 2024 +0200 fortran/openmp.cc: Fix var init and locus use to avoid uninit values [PR fortran/116661] gcc/fortran/ChangeLog: PR fortran/116661 * openmp.cc (gfc_match_omp_prefer_type):

[patch][v2] Fortran: Add OpenMP 'interop' directive parsing support

Now also supports the following (note the variable name): 'init(targetsync, target)' – and I fixed an ICE when the variable parsing failed. Comments before I commit it? Tobias Tobias Burnus wrote: This patch adds Fortran parsing support for OpenMP's 'interop' dire

[patch] Fortran: Add OpenMP 'interop' directive parsing support

This patch adds Fortran parsing support for OpenMP's 'interop' directive (which stops with a 'sorry' in trans-openmp.cc as the middle end support is still missing). Tested on x86-64-gnu-linux. Comments, suggestions, remarks? * * * Background: 'interop' makes it easier to call, e.g., a CUDA-

Re: [patch][v3] libgomp: Add interop types and routines to OpenMP's headers and module

v3: Changes: (A) The 'ret_code' arguments of omp_get_interop_{int,ptr,str} are actually 'optional'. That's something that got lost in at some point between OpenMP 5.2 and TR13 (I filed OpenMP spec Issue #4165 for it). When adding it, I noticed that two '…_async' function lacked the '= NULL'

[patch][v2a] libgomp: Add interop types and routines to OpenMP's headers and module

function. Tobias Am 21.08.24 um 20:27 schrieb Tobias Burnus: Nearly identical to v1, except that I realized that OpenMP permits to call those functions also from target regions. Hence, those also got those functions, including a use of omp_irc_other to make clear why it will fail … In ad

[patch] libgomp: Add interop types and routines to OpenMP's headers and module

This patch adds 'interop' to C/C++'s omp.h and Fortran's omp_lib.h and omp_lib module. The implementation should match OpenMP 5.1 (which added interop) and also TR13; the Fortran routine support is new in TR13. It also adds 'hsa' as foreign object enum/paramter, which is currently being added

Re: [PATCH, v3] OpenMP: Constructors and destructors for "declare target" static aggregates

tic-aggr-constructor-destructor-3.C for a reason why running constructors on the target is preferable to e.g. constructing on the host and then copying the resulting object to the target.) 2024-08-07 Julian Brown Tobias Burnus gcc/ChangeLog: * builtins.def (DEF_GOMP_BUILTIN_COMPILER): Define

[PATCH, v3] OpenMP: Constructors and destructors for "declare target" static aggregates

low-up patch. On Aug 1, 2024, Jakub Jelinek wrote: On Tue, Jul 30, 2024 at 10:51:56PM +0200, Tobias Burnus wrote: - char id[sizeof (SSDF_IDENTIFIER) + 1 /* '\0' */ + 32]; + tree name; ... I'd just use a single buffer here, char id[MAX (sizeof (SSDF_IDENTIFIER), sizeof (OMP_

  1   2   3   4   5   6   7   >