Re: [PATCH v5 11/11] openmp, fortran: Add support for non-constant iterator bounds in Fortran deep-mapping iterator support

Kwok Cheung Yeung wrote on July 9, 2025: This patch adds support for non-constant iterator bounds to the Fortran deep-mapping iterator support. To do this, we need to keep track of the new iterator entries generated during by the deep mapping. Code is generated by lower_omp_target to allocate

Re: [PATCH v5 8/11] openmp: Fix struct handling for OpenMP iterators

Kwok Cheung Yeung wrote: This patch fixes some issues with the struct handling introduced in the patch for Fortran support. The problem is that build_omp_struct_comp_nodes and omp_accumulate_sibling_list can add extra clauses with iterators onto the target construct, but this occurs after the

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

Hi Yuao, Yuao Ma wrote: I've made two key updates in this version: 1. In gfc_conv_expr_reference, the previous logic handled BT_CHARACTER first. This caused a failure when we had a cond-arg with a character type, as the cond-expr logic wasn't being handled correctly. I've simply reordered the ch

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

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

[committed] OpenMP: Unshare expr in context-selector condition [PR121922]

testcase and debugging Sandra! Tobias commit 97c1d2fa97afc59b02d2894b88069136145603e2 Author: Tobias Burnus Date: Thu Sep 18 11:07:50 2025 +0200 OpenMP: Unshare expr in context-selector condition [PR121922] As the testcase shows, a missing unshare_expr caused that the condition

Re: [Patch][RFC?] libgomp: Init hash table for 'indirect'-clause of 'declare target' on the host [PR114445, PR119857]

likely only the third one will track this. Tobias Tobias Burnus wrote: Minor update (as attached): Fixed two bugs in plugin-gcn.c. The patch has now also been tested with AMD GPUs (MI300) offloading and on a PowerPC (powerpc64le) system with offloading to a Volta GPU. Tobias Burnus wrote: The

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

[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 v5 9/11] openmp: Add support for using custom mappers with iterators (C, C++)

Kwok Cheung Yeung wrote: This patch adds support for custom mappers with iterators (C and C++ only, as the Fortran custom mapper support has not been committed yet, nor has support for nested mappers). It works by propagating clause iterators onto new clauses generated by mappers. As this oc

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 v5 6/11] openmp: Add support for non-constant iterator parameters in map, to and from clauses

Hi Kwok, Kwok Cheung Yeung wrote: Subject: [PATCH 06/11] openmp: Add support for non-constant iterator parameters in map, to and from clauses This patch enables support for using non-constant expressions when specifying iterators in the map clause of target constructs and to/from clauses of t

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 v5 5/11] openmp, fortran: Add support for iterators in OpenMP 'target update' constructs (Fortran)

Kwok Cheung Yeung wrote on July 9, 2025: Subject: [PATCH 05/11] openmp, fortran: Add support for iterators in OpenMP 'target update' constructs (Fortran) This adds Fortran support for iterators in 'to' and 'from' clauses in the 'target update' OpenMP directive. ... @@ -1418,16 +1419,67 @@ gf

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

Hi all, attached is a patch to update the Fortran section of the GCC 16 release notes. I am sure that I missed some fine print and the most important changes are also some bug fixes, which are difficult to list. → https://gcc.gnu.org/gcc-16/changes.html Comments? Tobias PS: I am aware of addit

Re: [PATCH v5 7/11] openmp: Add macros for iterator element access

Kwok Cheung Yeung wrote on July 9, 2025: This patch adds macros to refer to the fields of OpenMP iterators by name rather than by index, as the number of items has increased to 10 and referring to them by index has become error-prone. Subject: [PATCH 07/11] openmp: Add macros for iterator ele

Re: [PATCH v5 4/11] openmp, fortran: Add support for map iterators in OpenMP target construct (Fortran)

Hi Kwok, sorry for the belated review. [Some minor but trivial changes are required due to bitrotting - both in gimplify.cc and in libgomp/target.c] Kwok Cheung Yeung wrote: Subject: [PATCH 04/11] openmp, fortran: Add support for map iterators in OpenMP target construct (Fortran) This add

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, 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 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 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][RFC?] libgomp: Init hash table for 'indirect'-clause of 'declare target' on the host [PR114445, PR119857]

Minor update (as attached): Fixed two bugs in plugin-gcn.c. The patch has now also been tested with AMD GPUs (MI300) offloading and on a PowerPC (powerpc64le) system with offloading to a Volta GPU. Tobias Burnus wrote: The main motivation for this patch is that on MI300, libgomp.c-c++-common

[Patch][RFC?] libgomp: Init hash table for 'indirect'-clause of 'declare target' on the host [PR114445, PR119857]

The main motivation for this patch is that on MI300, libgomp.c-c++-common/declare-target-indirect-2.c always fails because of the known fragile/racy code - as noticed before (PR114445 and PR119857), albeit triggering the fail has become more reliably. 'indirect' means that such-tagged functions a

[committed] invoke.texi: AMD GCN - remove '(experimental)' from some gfx*-generic [was: [patch] install.texi: For amdgcn, clarify which llvm-* binaries are required]

, but libgomp needs to be fixed in either case.) Tobias commit 5a7e3d44bab04017f82fb8b883e564bf7198c35c Author: Tobias Burnus Date: Fri Aug 29 09:51:06 2025 +0200 invoke.texi: AMD GCN - remove '(experimental)' from some gfx*-generic GCC added generic support in r15-7406-gb5a29a93ee29a8 (Feb 2025) with a

[patch] install.texi: For amdgcn, clarify which llvm-* binaries are required

This kind of came up because now objdump is required during the GCC build (for ./configure) to set the required HAVE_..., solving PR119367. While LLVM's assembler and linker are required to handle AMD GPUs, all others just need to be found and can be the LLVM or Binutils' variant alike. Addition

[patch][v2] install.texi: For amdgcn, update Newlib version recommendation

IMD issues. Tobias Burnus wrote: Changes in GCC 16 enables more vectorization, triggering bugs in the GCN's Newlib vector implementation. This patch adds a second Newlib commit to the documentation; and a third – the two new ones both related to 'fmod' and lane handling, see commit lo

[patch] install.texi: For amdgcn, update Newlib version recommendation

Changes in GCC 16 enables more vectorization, triggering bugs in the GCN's Newlib vector implementation. This patch adds a second Newlib commit to the documentation; for GCN user - esp. for mainline - it is recommended to update Newlib to at least that commit or to cherry pick the two commits on

[patch][v2][gcn] gcc/configure.ac + install.texi - changes to detect HAVE_AS_LEB128 [PR119367]

Ok, admittedly, the following patch [v2] is cleaner and the assumption that the llvm-mc assembler is used is also inside the backend assembler spec. OK for mainline? * * * Note: I tried to see whether this patch plus the comment 14 patch makes a difference. While the testcase itself (and in our

[patch][gcn] gcc/configure.ac + install.texi - changes to detect HAVE_AS_LEB128 [PR119367]

PR119367 is about an overflow related to debug views, if those are not supported directly by the assembler. The problem is that dw2_asm_output_delta yields a 2-byte variable, which isn't sufficient. However, as the draft patch of comment 14 shows, dw2_asm_output_delta_uleb128 can be used to avoid

Re: [PATCH 2/3] OpenMP: Fix handling of "simd" selector on "declare variant" [PR121630]

Jakub Jelinek wrote: It of course makes a lot of sense. declare simd is used mostly on the host in the wild, outside of target regions. On "normal" Linux for instance in /usr/include/bits/math-vector.h, albeit most of the time -fopenmp is not active such that the "simd" attribute is used inste

Re: [PATCH 2/3] OpenMP: Fix handling of "simd" selector on "declare variant" [PR121630]

Hi Sandra, Sandra Loosemore wrote: On 8/26/25 05:26, Jakub Jelinek wrote: I wouldn't emit sorry for targets where we already implement it "correctly", i.e. at least all targets which have NULL targetm.simd_clone.compute_vecsize_and_simdlen There the argument transformation is identity. That

Re: [PATCH 2/3] OpenMP: Fix handling of "simd" selector on "declare variant" [PR121630]

Dear Jakub, dear Sandra, hello world, Jakub Jelinek wrote: Starting with OpenMP 5.2, the spec explicitly says differently for C++: "The function variant is determined by base language standard name lookup rules ([basic.lookup]) of variant-name using the argument types at the call site..." I th

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 v2 1/3] OpenMP: Improve front-end error-checking for "declare variant"

Sandra Loosemore wrote: This patch fixes a number of problems with parser error checking of "declare variant", especially in the C front end. ... gcc/c/ChangeLog * c-parser.cc (c_finish_omp_declare_variant): Rework diagnostic code. Do not record variant if there are errors. Ma

Re: [PATCH 2/3] OpenMP: Fix handling of "simd" selector on "declare variant" [PR121630]

Am 25.08.25 um 08:13 schrieb Jakub Jelinek: On Sun, Aug 24, 2025 at 08:16:32PM -0600, Sandra Loosemore wrote: As noted in PR middle-end/121630, GCC seems to think that the "simd" construct selector on "declare variant" implies that the variant function accepts vectorized arguments, although this

Re: [PATCH 3/3] OpenMP: give error when variant is the same as the base function [PR118839]

Sandra Loosemore wrote: As noted in the issue, the C++ front end has deeper problems: […] Some real solution ought to be included as part of fixing PR118791. okay. gcc/c/ […] gcc/cp/ […] gcc/fortran/ PR middle-end/118839 * trans-openmp.cc (gfc_trans_omp_declare_variant): Error i

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] OpenMP: Improve front-end error-checking for "declare variant"

Sandra Loosemore wrote: This patch fixes a number of problems with parser error checking of "declare variant", especially in the C front end. The new C testcase unprototyped-variant.c added by this patch used to ICE when gimplifying the call site, at least in part because the variant was being r

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] contrib/download_prerequisites: Update GMP, MPFR, MPC [PR120237]

Committed as r16-3063-gb399a0084bc962 fix the file name in download_prerequisites fixed. And ... Richard Biener wrote: On Wed, 6 Aug 2025, Tobias Burnus wrote: OK for mainline? (Requires a prior update of 'infrastructure'). -gmp='gmp-6.2.1.tar.bz2' … +gmp='gm

[Patch] contrib/download_prerequisites: Update GMP, MPFR, MPC [PR120237]

This patch updates contrib/download_prerequisites to download newer versions (the latest) of GMP, MPFR and MPC. Main reason is a newer MPFR that provides C23 functions, additionally, the usual bug fixes or the new "away from zero" rounding in MPC might turn out to be useful. GMP also claims bette

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: [PATCH] openmp: Allocate memory for private/firstprivate clauses as, directed by allocate clauses in target constructs [PR113436]

Hello Kwok, hi all, Kwok Cheung Yeung wrote: Currently, GCC accepts an allocate clause (to use a specific memory allocator and alignment) on the OpenMP target construct, but it has no effect - memory is always allocated with the defaults. This patch causes memory for privatized variables (i.e

Re: [PATCH v5 2/11] openmp: Add support for iterators in map clauses (C/C++)

Hi Kwok, Kwok Cheung Yeung wrote: I find the following warning odd:    #pragma omp target map(iterator(i3=0:10, j3=0:20, k3=0:30), to: x[i3+j3], y[j3+k3], z[k3+i3]) ;    /* { dg-warning "iterator variable .i3. not used in clause expression" "" { target *-*-* } .-2 } */    /* { dg-warnin

Re: [wwwdocs, patch] gcc-16/changes.html: Update OpenACC support

Now reworded and committed - see attached + https://gcc.gnu.org/gcc-16/changes.html Thanks for the comments! Tobias commit b420d69be557f55635d869b770e80789977ffcf4 Author: Tobias Burnus Date: Wed Jul 30 09:41:30 2025 +0200 gcc-16/changes.html: Update OpenACC support diff --git a

Re: [wwwdocs, patch] gcc-16/changes.html: Update OpenACC support

Hi Gerald, Gerald Pfeifer wrote: + OpenACC 3.4: In Fortran, named constants (PARAMETER) used as + var in clauses are now accepted (and ignored as not being + required). The support for named constants has been added to the + specification and GCC for better compatibility with exi

Re: [wwwdocs, patch] gcc-16/changes.html: Update OpenACC support

Thanks for proof reading and noting the missing patch … Gerald Pfeifer: On Tue, 29 Jul 2025, Tobias Burnus wrote: Update https://gcc.gnu.org/gcc-16/changes.html for some OpenACC features that went in; while small and some of them rather new (OpenACC 3.4 was only released in June 2025), they

[wwwdocs, patch] gcc-16/changes.html: Update OpenACC support

Update https://gcc.gnu.org/gcc-16/changes.html for some OpenACC features that went in; while small and some of them rather new (OpenACC 3.4 was only released in June 2025), they all show up in real-world code and, hence, are important to users. Any comments before (or after) I pushed the changes?

[Patch] gcn: Fix CDNA3 atomics' buffer invalidation

When initially adding MI300 support, the buffer invalidation before atomics was messed up - it should have been buffer_wbl2 (wbl2 = write back L2). With this patch in place, most test cases work on MI300A :-) Without this change, there were several multi-teams issues. MI300A testing shows: large

Re: [Patch] gcn: Add more s_nop for MI300

Hi Andrew, thanks for all the suggestions and the review! Andrew Stubbs wrote: ... +  /* CDNA3: VALU writes VGPR/VCC: v_readlane, v_readfirstlane, v_cmp, +         v_add_*i/u, v_sub_*i/u, v_div_*scale - followed by: +         - VALU reads SGPR as constant requires 1 waite state +         -

Re: [Patch] gcn: Add more s_nop for MI300

Hi Andrew, Andrew Stubbs wrote: +static bool +gcn_v_cmp_insn_p (attr_type type) +{ +  return type == TYPE_VOPC || type == TYPE_VOP3A;  } There are many vop3a encoded instructions. I don't understand how this uniquely identifies v_cmp instructions? It doesn't - how about an attribute variant?

[Patch] gcn: Add 'nops' insn, extend comments

Tiny cleanup patch - as fallout of trying to understand MI300 and its fails better (A) Replace 's_nop 0x0; s_nop 0x0; s_nop 0x0' by 's_nop 0x2'. Advantage: fewer instructions - this helps on the hardware side by permitting more follow-up instructions in the instruction cache and it reduces the f

[Patch] gcn: Add more s_nop for MI300

There are still issues with MI300, some which get resolved by adding s_nop. One case where it is exactly known where the s_nop fixes a fail is for libgomp.c-c++-common/task-detach-10.c, where libgomp/single.c's GOMP_single_start() never returns 1, such that 'omp single' is never executed. Adding

Re: [Patch] gcn: Add "s_nop"s for MI300

Andrew Stubbs wrote: On 24/07/2025 16:49, Tobias Burnus wrote: Andrew Stubbs wrote: On 24/07/2025 14:25, Tobias Burnus wrote: +/* Device requires CDNA1-style manually inserted wait states for AVGPRs.  */ +#define TARGET_AVGPR_CDNA3_NOPS TARGET_CDNA3 This is not for CDNA1, and not for AVGPRS

Re: [Patch] gcn: Add "s_nop"s for MI300

Andrew Stubbs wrote: On 24/07/2025 14:25, Tobias Burnus wrote: +/* Device requires CDNA1-style manually inserted wait states for AVGPRs.  */ +#define TARGET_AVGPR_CDNA3_NOPS TARGET_CDNA3 This is not for CDNA1, and not for AVGPRS. I have deleted it and use now TARGET_CDNA3 directly

[Patch] gcn: Add "s_nop"s for MI300

Hello Andrew, hello world, some instructions take a bit longer but permit that the next instruction is processed while finishing the work. That works well - and speeds up the calculation - unless the next instruction relies on those being available. Which combinations instructions are affected ar

Re: [PATCH v5 3/11] openmp: Add support for iterators in 'target update' clauses (C/C++)

Kwok Cheung Yeung wrote: Subject: [PATCH 03/11] openmp: Add support for iterators in 'target update' clauses (C/C++) This adds support for iterators in 'to' and 'from' clauses in the 'target update' OpenMP directive. * * * + c_parser_error (parser, "% or % clause with modifier " +

Re: [PATCH v5 2/11] openmp: Add support for iterators in map clauses (C/C++)

Hi Kwok, thanks for the patch; looks quite good, but I have a couple of remarks: Kwok Cheung Yeung wrote: Date: Sat, 3 May 2025 20:24:26 + Subject: [PATCH 02/11] openmp: Add support for iterators in map clauses (C/C++) This adds preliminary support for iterators in map clauses within Op

Re: PING⁴ – PING³ – Re: PING³ — Re: PING (and v2) – [Patch] nvptx/nvptx.opt: Update -march-map= for newer sm_xxx

PING⁴ June 25, 2025, Tobias Burnus wrote: PING³ June 2, 2025 Tobias Burnus wrote: Tobias Burnus wrote: PING² On May 12, 2025, Tobias Burnus wrote: PING. There is actually a minor update as meanwhile CUDA 12.8 was released that added the 'f' suffix and sm_103 and sm_121. Still, t

Re: [PATCH v5 1/11] openmp: Refactor handling of iterators

Kwok Cheung Yeung wrote: Date: Wed, 27 Nov 2024 21:49:12 + Subject: [PATCH 01/11] openmp: Refactor handling of iterators Move code to calculate the iteration size and to generate the iterator expansion loop into separate functions. Use OMP_ITERATOR_DECL_P to check for iterators in clause de

Re: [PATCH] openmp, fortran: Fix ICE when the procedure name cannot be found in declare variant directives [PR104428]

Kwok Cheung Yeung wrote: This patch fixes an ICE due to a null-pointer dereference when finding the symbol for the procedure name in a declare variant directive, which occurs because the result of gfc_find_sym_tree is being dereferenced unconditionally. The result is now checked, and the symbo

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

PING³ – Re: PING³ — Re: PING (and v2) – [Patch] nvptx/nvptx.opt: Update -march-map= for newer sm_xxx

PING³ June 2, 2025 Tobias Burnus wrote: Tobias Burnus wrote: PING² On May 12, 2025, Tobias Burnus wrote: PING. There is actually a minor update as meanwhile CUDA 12.8 was released that added the 'f' suffix and sm_103 and sm_121. Still, the pattern remains the same; hence, a normal

Re: [Patch] gcn: Fix glc vs. sc0 handling for scalar memory access

, but that's probably overkill until we need it. I think it would good to properly use the right sc0/sc1/nt for memory access, but I concur that's something for a bit later. Tobias commit 750bc2899844d662aee93476f2da63fce68535d9 Author: Tobias Burnus Date: Tue Jun 24 23:55:27

[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

[Patch] gcn: Fix glc vs. sc0 handling for scalar memory access

This is more based on documentation reading that on testing as still only limited MI300 testing has been done and seemingly this code does not usually get touched. MI300's "9.1.10 Memory Scope and Temporal Control" distinguishes between scalar memory (9.1.10.1) for which a single control bit exis

[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'.

[Patch] libgomp.texi: Document omp(x)::allocator::*, restructure memory allocator doc (was: [PATCH] Docs: Document omp::allocator::* and ompx::allocator::* allocators.)

ently look as follows: https://gcc.gnu.org/onlinedocs/libgomp/Memory-allocation.html and https://gcc.gnu.org/onlinedocs/libgomp/OMP_005fALLOCATOR.html Tobias Burnus wrote: Alex wrote: Here is a follow up patch for documentation of the omp.h allocators, […] I want the table in there somewhere bu

Re: [Patch] OpenMP: Fix implicit 'declare target' for

he attached patch, which assumes a sufficiently new nvptx-tools (and has no xfails). → r16-1536-gea43b99537591b Tobias commit ea43b99537591b1103da3961c61f1cbfae968859 Author: Tobias Burnus Date: Tue Jun 17 11:33:09 2025 +0200 OpenMP: Fix implicit 'declare target'

[Patch] OpenMP: Fix implicit 'declare target' for

This fixes an issue with implicit declare target. '' has: template … endl() { ... } ... extern template ostream& endl(ostream&); which leads to a decl that is 'extern' but still has the full function body available. Result: On the offload side, 'endl' is present but the functions it calls

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

[Patch] [+wwwdocs] gcn: Add experimental MI300 (gfx942) support

This add experimental support for AMD Instinct MI300. It has been tested to support hello world, but not yet much beyond (to come). OK for mainline? Tobias gcn: Add experimental MI300 (gfx942) support As gfx942 and gfx950 belong to gfx9-4-generic, the latter two are also added. Note that there

[wwwdocs, committed] gcc-16/changes.html + projects/gomp/: OpenMP/OpenACC update

libgomp.texi [and hence onlinedocs/libgomp]. But that's for another day.) Tobias commit 152a09eae9d5852e2f628c3e8b3156bf744e63cf Author: Tobias Burnus Date: Tue Jun 10 06:21:12 2025 +0200 gcc-16/changes.html + projects/gomp/: OpenMP/OpenACC update * gcc-16/changes.html: Add O

[Patch] omp-builtins.def: Leaf attribute fixes to omp_{is_initial_device,get_{mapped_ptr,interop_int}}

Most builtins in omp-builtins.def is marked as LEAF. At a glance, that's surprising but looking at the functions, it turns out that most of them just call 'gomp_thread ()' which is a simple inline function such that no function call remains. However, that's not true for all - and omp_get_mapped_p

([commited] →) Re: [Patch][RFC?] OpenMP: Add omp_get_initial_device/omp_get_num_devices builtins

I have now pushed those patches as: r16-1262-g387209938d2c47 OpenMP: Add omp_get_initial_device/omp_get_num_devices builtins r16-1261-g214b5d66c54613 builtins.def: Enable OpenMP/OpenACC builtins also with -fno-nonansi-builtins Tobias

[Patch] builtins.def: Enable OpenMP/OpenACC builtins also with -fno-nonansi-builtins

Currently, using the ISO version of C and C++ will disable the OpenMP and OpenACC intrinsics, which is rather surprising. The reason is that those imply -fno-nonansi-builtins and the OpenMP/OpenACC are marked as non-ansi builtins. While the latter is true, -fopenmp/-fopenacc seems to be rather or

[Patch] gcn: Update --with-arch= for newer archs

As a user reported, --with=arch= did not support the newer devices, as we forgot to update the list. While we still have lists to update, this one can be replaced by checking directly against the .def file. There was another list that we didn't update - in install.texi: https://gcc.gnu.org/insta

Re: [PATCH] OpenMP: Fix regressions in metadirective-target-device-2.c [PR120518]

Sandra Loosemore wrote: gcc/ChangeLog PR c++/120518 * omp-general.cc (omp_device_num_check): Look inside a CLEANUP_POINT_EXPR when trying to optimize special cases. LGTM. Thanks, Tobias […] + tree t = *device_num; + if (TREE_CODE (t) == CLEANUP_POINT_EXPR) +t =

[Patch][RFC?] OpenMP: Add omp_get_initial_device/omp_get_num_devices builtins

This came up when looking at some context selectors that use 'target_device', but is largely unrelated to it. (target_device has its own special casing). Namely, it makes omp_get_initial_device and omp_get_num_devices PURE, which attributes don't permit for Fortran - based on the state that the n

Re: [Patch] libgomp.texi (omp_interop_*): Add note about 5.2-to-6.0 incompatibility

Hi Sandra, hello world, Sandra Loosemore wrote: On 6/2/25 12:15, Tobias Burnus wrote: The problem is that 'int'/'int*' became 'omp_interop_rc_t ret_code' and 'omp_interop_rc_t *ret_code'. ... I think the patch just confuses readers, as-is.  Plus it h

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] libgomp.texi (omp_interop_*): Add note about 5.2-to-6.0 incompatibility

Not really new - but as the topic came up elsewhere (OpenMP issue 4455), I had a second thought about this and I think it make sense to add a note. GCC uses the OpenMP 6.0 version. The problem is that 'int'/'int*' became 'omp_interop_rc_t ret_code' and 'omp_interop_rc_t *ret_code'. For C++, pas

Re: PING³ — Re: PING (and v2) – [Patch] nvptx/nvptx.opt: Update -march-map= for newer sm_xxx

Tobias Burnus wrote: PING² On May 12, 2025, Tobias Burnus wrote: PING. There is actually a minor update as meanwhile CUDA 12.8 was released that added the 'f' suffix and sm_103 and sm_121. Still, the pattern remains the same; hence, a normal PING. On April 25, 2025, Tobias Bu

[Patch] libgomp: Add OpenMP's omp_target_memset/omp_target_memset_async [PR120444]

Attached patch adds omp_target_memset and omp_target_memset_async permitting to set (potentially large) data on the device to a certain value - in particular to '\0'. It uses 'memset' on the host (and for shared memory, e.g. via requires unified_shared_memory/self_maps). For nvptx, cuMemsetD8 is

[committed] OpenMP: Support OpenMP 5.0 "declare mapper" directives for C

I have now committed the second declare mapper patch, submitted by Julian at https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629367.html again it is based in the associated OG15 commit (kudos to all doing the rediffs): 69fd51954fc OpenMP: Support OpenMP 5.0 "declare mapper" directives

Re: [PATCH 3/3] OpenMP: Handle more cases in user/condition selector

Sandra Loosemore wrote: Like the attached V2 patch? LGTM. However, I think in metadirective-condition-template.C the "scan-tree-dump" should now be changed to "scan-tree-dump-times", given that there are several tests. Thanks, Tobias

Re: [PATCH 3/3] OpenMP: Handle more cases in user/condition selector

@Jason – The idea is make semantics.cc's maybe_convert_cond callable from parser.cc + pt.cc, i.e. to make it a non-static function. Any reasons not do so? Sandra Loosemore wrote: […] By using the existing front-end hooks for the implicit conversion to bool in conditional expressions, we also ge

[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

  1   2   3   4   5   6   7   8   9   10   >