[Patch] OpenMP/Fortran: Fix handling of 'declare target' with 'link' clause [PR11555]

Hi all, it turned out that 'declare target' with 'link' clause was broken in multiple ways. The main fix is the attached patch, i.e. namely pushing the variables already to the offload-vars list already in the FE. When implementing it, I noticed: * C has a similar issue when using nested

Re: [Patch, PR Fortran/90072] Polymorphic Dispatch to Polymophic Return Type Memory Leak

Andre Vehreschild wrote: PS That's good news about the funding. Maybe we will get to see "built in" coarrays soon? You hopefully will see Nikolas work on the shared memory coarray support, if that is what you mean by "built in" coarrays. I will be working on the distributed memory coarray

Re: [committed] nvptx, libgfortran: Switch out of "minimal" mode

Sandra Loosemore wrote: On 6/6/24 06:06, Tobias Burnus wrote: +@item I/O within OpenMP target regions and OpenACC compute regions is supported +  using the C library @code{printf} functions. +  Additionally, the Fortran @code{print}/@code{write} statements are +  supported within

Re: [committed] nvptx, libgfortran: Switch out of "minimal" mode

Hi Thomas, regarding the commit r15-1070-g3a4775d4403f2e / https://gcc.gnu.org/r15-1070 First, thanks for adding I/O support to nvptx offloading. I have a wording nit, to be confirmed by a native speaker: --- a/libgomp/libgomp.texi +++ b/libgomp/libgomp.texi ... +@item I/O within OpenMP

[wwwdocs][patch] gcc-15/changes.html: Fortran - mention F2023 logical-kind additions

Let's make https://gcc.gnu.org/gcc-15/changes.html a bit more useful … While there were several useful Fortran commits already, only one seems to be about a new feature. Thus, document selected_logical_kind and the ISO_FORTRAN_ENV additions. Comments or suggestions before I commit it? Tobias

Re: [Patch] Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single

Hi Bernhard, rep.dot@gmail.com wrote: library such as @url{http://opencoarrays.org} needs to be linked. Maybe use https? Works, but as the certificate is not valid, it requires to ignore the errors in a browser, which is a worse user experience. The error is, e.g., "curl: (60) SSL

[Patch] Fortran: Fix SHAPE for zero-size arrays

That is for https://gcc.gnu.org/PR115150 – a GCC 12/13/14/15 regression, caused when switching from a libgomp call to inline code and missing the corner case of zero-size arrays ... OK for mainline + all affected branches? Tobias Fortran: Fix SHAPE for zero-size arrays PR fortran/115150

[Patch] Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single

I noticed that gfortran's coarray support did not link to the http://www.opencoarrays.org/ As that library is needed to support parallelization, it makes sense to have the link. Motivated by someone claiming at ISC-HPC that GCC only supports a single image. And also motivated by Damian's

Re: Mattermost discussion on PR98426

Hi Bernhard, hello all, Bernhard Reutner-Fischer wrote: PS: unfortunately the git branch ( https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool ) mentioned in mail (I) lived in the old git, before we switched to git, and i fear that branch maybe got lost. Try

Generated files in libgfortran for Fortran intrinsic procedures (was: Updated Sourceware infrastructure plans)

Hi Janne, Janne Blomqvist wrote: back when I was active I did think about this issue. IMHO the best of my ideas was to convert these into C++ templates. I think this will work – but we have to be super careful: With C++, there is the problem that we definitely do not want to add dependency

[Patch] Fortran: List-directed read - accept again tab as alternative to space as separator [PR114304] (was: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not a

Jerry D wrote: See attached updated patch. It turned rather quickly out that this patch – committed as r14-9822-g93adf88cc6744a – caused regressions. Namely, real-world code use tab(s) as separator instead of spaces. [For instance, PR114304 which contains a named-list input file from SPEC

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

Hi Jerry, hello world, Jerry D wrote: On 4/5/24 10:47 AM, Jerry D wrote: On 4/4/24 2:41 PM, Tobias Burnus wrote: I think for the current testcases, I like the patch – the question is only what's about:    ',3' as input for 'comma'   (or '.3' as input for 'point') [...] But for 'comma

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

Hi Jerry, I think for the current testcases, I like the patch – the question is only what's about:   ',3' as input for 'comma'   (or '.3' as input for 'point') For 'point' – 0.3 is read and ios = 0 (as expected) But for 'comma': * GCC 12 reads nothing and has ios = 0. * GCC 13/mainline has

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

Hi Jerry, Jerry D wrote: The attached log entry and patch (git show) fixes this issue by adding logic to handle spaces in eat_separators. One or more spaces by themselves are a valid separator. So in this case we look at the character following the spaces to see if it is a comma or semicolon.

Re: OpenACC 2.7: front-end support for readonly modifier: Add basic OpenACC 'declare' testing

Hi all, hi Thomas & Chung-Lin, Thomas Schwinge wrote: But I realized another thing: don't we have to handle the 'readonly' modifier also in Fortran module files, that is, next to the OpenACC 'declare' 'copyin' handling in 'gcc/fortran/module.cc': 'AB_OACC_DECLARE_COPYIN' etc.? I bet so; it is

Re: OpenACC 2.7: front-end support for readonly modifier: Add basic OpenACC 'declare' testing

Hi all, hi Thomas & Chung-Lin, Thomas Schwinge wrote: But I realized another thing: don't we have to handle the 'readonly' modifier also in Fortran module files, that is, next to the OpenACC 'declare' 'copyin' handling in 'gcc/fortran/module.cc': 'AB_OACC_DECLARE_COPYIN' etc.? I bet so; it is

Re: [PATCH, OpenACC 2.7] struct/array reductions for Fortran

Hi Chung-Lin, hi Thomas, hello world, some thoughts glancing at the patch. Chung-Lin Tang wrote: There is still some shortcomings in the current state, mainly that only explicit-shaped arrays can be used (like its C counterpart). Anything else is currently a bit more complicated in the

Re: [Patch] OpenMP/Fortran: Fix defaultmap(none) issue with dummy procedures [PR114283]

Jakub Jelinek wrote: So firstprivate clause handling remaps them then if declare target indirect is used? If so, the patch looks reasonable to me. [I have now updated the patch to turn the testcase to ensure that is also keeps works at runtime.] OpenMP leaves it a bit open when the remapping

[Patch] OpenMP/Fortran: Fix defaultmap(none) issue with dummy procedures [PR114283]

Using dummy procedures in a target region with 'defaultmap(none)' leads to: Error: 'g' not specified in enclosing 'target' and this cannot be fixed by using 'firstprivate' as non-pointer dummy routines are rejected as "Error: Object 'g' is not a variable". Fixed by doing the same for mapping

[Patch] Fortran/Openmp: Use OPT_Wopenmp for gfc_match_omp_depobj warning

When checking something else, I noticed that there was one warning in openmp.cc that did not use OPT_Wopenmp. I intent to commit the attached patch later today as obvious. Tobias Fortran/Openmp: Use OPT_Wopenmp for gfc_match_omp_depobj warning gcc/fortran/ChangeLog: * openmp.cc

Re: [PATCH v2] openmp, fortran: Add Fortran support for indirect clause on the declare target directive

} +! { dg-xfail-run-if "Requires libgomp bug fix pending review" { offload_device } } Thanks, Tobias On 06/02/2024 9:03 am, Tobias Burnus wrote: LGTM. I just wonder whether there should be a value test and not just a does-not-crash-when-called test for the latter testcase, i.e. +++

Re: [PATCH v2] openmp, fortran: Add Fortran support for indirect clause on the declare target directive

Kwok Cheung Yeung wrote: As previously discussed, this version of the patch adds code to emit a warning when a directive like this: !$omp declare target indirect(.true.) is encountered (i.e. a target directive containing at least one clause, but no to/enter clause, which appears to violate

Re: [PATCH] openmp, fortran: Add Fortran support for indirect clause on the declare target directive

Kwok Cheung Yeung wrote: This patch adds support for the indirect clause on the OpenMP 'declare target' directive in Fortran. As with the C and C++ front-ends, this applies the 'omp declare target indirect' attribute on affected function declarations. The C test cases have also been translated

Re: Open MP offloading

Hi, Rheinhardt Matthias wrote: at the moment, offloading Open MP workshare section is not supported, nor can implicit do-loops from expressions with array syntax be delt with in another way for offloading. Are there any plannings to lift this restriction, which is rather severe for - in

Re: [PATCH 2/8] OpenMP: lvalue parsing for map/to/from clauses (C)

Julian Brown wrote: This patch adds support for parsing general lvalues ("locator list item types") for OpenMP "map", "to" and "from" clauses to the C front-end, similar to the previously-posted patch for C++. Such syntax is permitted for OpenMP 5.0 and above. It was previously posted for

Re: [PATCH 1/8] OpenMP: lvalue parsing for map/to/from clauses (C++)

Am 05.01.24 um 13:23 schrieb Julian Brown: On Wed, 20 Dec 2023 15:31:15 +0100 Tobias Burnus wrote: Here's a rebased/retested version which fixes those bits (I haven't adjusted the libgomp.texi bit you noted yet, though). How does this look now? --- a/gcc/gimplify.cc +++ b/gcc/gimplify.cc

Re: [PATCH] libgfortran: Bugfix if not define HAVE_ATOMIC_FETCH_ADD

On 22.12.23 03:36, Lipeng Zhu wrote: This patch try to fix the bug when HAVE_ATOMIC_FETCH_ADD is not defined in dec_waiting_unlocked function. libgfortran/ChangeLog: * io/io.h (dec_waiting_unlocked): Use __gthread_rwlock_wrlock/__gthread_rwlock_unlock or

Re: [PATCH v7 5/5] OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc

Hi Julian, On 20.12.23 22:29, Julian Brown wrote: Thanks for review! Here's a new version of the patch which hopefully addresses this round of comments. Thanks for the patch. LGTM now. Tobias On Tue, 19 Dec 2023 16:41:54 +0100 Tobias Burnus wrote: On 16.12.23 14:25, Julian Brown wrote

Re: [PATCH 1/8] OpenMP: lvalue parsing for map/to/from clauses (C++)

On 05.09.23 21:28, Julian Brown wrote: This patch supports "lvalue" parsing (or "locator list item type" parsing) for several OpenMP clause types for C++, as required for OpenMP 5.0 and above. It is based on the version committed to the og13 branch, posted here:

Re: [PATCH 1/5] OpenMP, NVPTX: memcpy[23]D bias correction

Hi Julian & Thomas, the patch LGTM - and seemingly also Thomas is somewhat fine with it - and it includes the stand-alone testcase. * * * I guess, you don't know the answer to Thomas question, i.e. whether that's a bug in CUDA or in our use of the CUDA API? CUDA's spec itself,

Re: [PATCH v7 5/5] OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc

Hi Julian, On 16.12.23 14:25, Julian Brown wrote: OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc This patch has been separated out from the C++ "declare mapper" support patch. It contains just the gimplify.cc rearrangement work, mostly moving

Re: [PATCH v7 4/5] OpenMP/OpenACC: Unordered/non-constant component offset runtime diagnostic

On 19.08.23 00:47, Julian Brown wrote: This patch adds support for non-constant component offsets in "map" clauses for OpenMP (and the equivalants for OpenACC), which are not able to be sorted into order at compile time. Normally struct accesses in such clauses are gathered together and sorted

RE: [PATCH v7] libgfortran: Replace mutex with rwlock

Hi, Thomas Schwinge wrote:   On 2023-12-14T02:28:22+, "Zhu, Lipeng" wrote: On 2023/12/14 4:52, Thomas Schwinge wrote: >> I've just filed >

[Patch] OpenMP: Minor '!$omp allocators' cleanup - and still: Re: [patch] OpenMP/Fortran: Implement omp allocators/allocate for ptr/allocatables

Hi Thomas & Jakub, I included a minor cleanup patch - but the rest is really a bunch of RFC. I intent to commit that patch as obvious, unless there are further comments. On 09.12.23 16:14, Jakub Jelinek wrote: There were 3 reasons to add GOMP_alloc (and 1 for GOMP_free): 1) when it was

Re: [PATCH v7 3/5] OpenMP: Pointers and member mappings

Hi Julian, On 07.12.23 18:24, Julian Brown wrote: On Wed, 6 Dec 2023 12:36:34 +0100 Tobias Burnus wrote: LGTM, except for: * The 'target exit data' handling - comments below - looks a bit fishy/inconsistent. ... Thus, I wonder whether that shouldn't be instead OMP_CLAUSE_MAP_KIND

Re: [PATCH v7 3/5] OpenMP: Pointers and member mappings

Hi Julian, LGTM, except for: * The 'target exit data' handling - comments below - looks a bit fishy/inconsistent. I intent to have a closer look with more code context, but maybe you should have a look at it as well. BTW: Fortran deep-mapping is not yet on mainline. Are you aware of changes

Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors

Hi all, the patch submission looks confusing as the context is a bit unclear (aarch64 having two integer types?) and the slightly unmotivated 'long' change (as explained in later emails: used as trick to find all locations that should be changed and not being part of actually proposed patch).

Re: [PATCH v7 2/5] OpenMP/OpenACC: Rework clause expansion and nested struct handling

Hi Julian, On 29.11.23 12:43, Julian Brown wrote: Here is a patch incorporating your initial review comments (hopefully!). Thanks. The patch LGTM - with the two remarks below addressed. (i.e. fixing one testcase and filing two PRs (or common PR) about the features missing and exposed by the

Re: [PATCH v2] Fortran: fix reallocation on assignment of polymorphic variables [PR110415]

s the best way to fix this (the Fortran front-end is new territory for me) but I've verified that the testcase passes with this change, fails without it, and that the change does not introduce any FAILs when running the gfortran testcases on x86_64-pc-linux-gnu. After the previous submission, Tobia

[Patch] OpenMP: Support acquires/release in 'omp require atomic_default_mem_order'

I stumbled over this omission when looking at Sandra's patch. It turned out that this is a new OpenMP 5.2 feature - probably added to simplify/unify the syntax. I guess the reason that release/acquire wasn't added before is that it cannot be universally be used - read/write do only accept one

Re: [patch] OpenMP: Add -Wopenmp and use it

Hi, On 27.11.23 11:20, Christophe Lyon wrote: I think the lack of final '.' in: Indeed - but you are lagging a bit behind: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638128.html [committed] c-family/c.opt (-Wopenmp): Add missing tailing '.' Fri Nov 24 18:56:21 GMT 2023

[patch] OpenMP: Add -Wopenmp and use it

Following the general trend to add a "[-W...]" to the warning messages for both better grouping of the warnings and - more importantly - for providing a means to silence such a warning (or to -Werror= them explicitly), this patch replaces several '0' by OPT_Wopenmp. Comments or remarks before I

[Patch,v3] OpenMP: Accept argument to depobj's destroy clause

As discussed on IRC, we now go for a warning and useOEP_LEXICOGRAPHIC - at least until the spec issue has been solve. [The OpenMP spec Issue 3739 tracks the open questions/issues mentioned in this thread.] Updated patch attached. Tobias - Siemens Electronic Design Automation

Re: [Patch] OpenMP: Accept argument to depobj's destroy clause

Hi Jakub, On 23.11.23 16:32, Jakub Jelinek wrote: On Thu, Nov 23, 2023 at 04:21:50PM +0100, Tobias Burnus wrote: @@ -21663,7 +21666,25 @@ c_parser_omp_depobj (c_parser *parser) + else if (depobj != error_mark_node + && !operand_equal_p (destobj

Re: [Patch] OpenMP: Accept argument to depobj's destroy clause

Hi Jakub, On 23.11.23 15:32, Jakub Jelinek wrote: On Thu, Nov 23, 2023 at 03:21:41PM +0100, Tobias Burnus wrote: I stumbled over this trivial omission which blocks some testcases. I am not sure whether I have solved the is-same-expr most elegantly, Answer: I didn't - as expected

[Patch] OpenMP: Accept argument to depobj's destroy clause

I stumbled over this trivial omission which blocks some testcases. I am not sure whether I have solved the is-same-expr most elegantly, but I did loosely follow the duplicated-entry check for 'map'. As that's a restriction to the user, we don't have to catch all and I hope the code catches the

Re: [PATCH] Fortran: fix reallocation on assignment of polymorphic variables [PR110415]

Hi Andrew, On 20.11.23 14:56, Andrew Jenner wrote: This patch adds the testcase from PR110415 and fixes the bug. Thanks. I can confirm experimentally that it fixes the original PR. However, if I extend the original testcase (-2), it fails with run with valgrind or when run with

[patch] OpenMP: Add uses_allocators support

: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 OpenMP: Add uses_allocators support 2023-11-19 Tobias Burnus Chung-Lin Tang gcc/ChangeLog: * builtin-types.def (BT_FN_VOID_PTRMODE): (BT_FN_PTRMODE_PTRMODE_INT_PTR): Add. * gimplify.cc

Re: [PATCH v7 2/5] OpenMP/OpenACC: Rework clause expansion and nested struct handling

Hi Julian, first round of comments - I think I need a second pass as the patch is long and complex. The depth of review also was decreasing, hence, I assume I will spot things in later parts of the compiler. In any case, I think the patch is a huge leap forward and very useful! Contrary to

[patch] OpenMP/Fortran: Implement omp allocators/allocate for ptr/allocatables

Hi all, Comment to reviewers: * Fortran: Except for ensuring that the version field in array descriptors is always set to the default (zero), the generated code should only be affected when -fopenmp-allocators is set, even though several files are touched. * Middle-end:

[committed] libgfortran: Fix calloc call by swapping arg order [PR112364]

; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 commit 17df6ddcf11aef6d200305d35641a7deb2f430e1 Author: Tobias Burnus Date: Mon Nov 6 11:34:31 2023 +0100 libgfortran: Fix calloc call by swapping arg order [PR112364] The prototype of calloc is void *calloc(si

Re: [PATCH] Fortran: Fix generate_error library function fnspec

On 03.11.23 13:54, Martin Jambor wrote: when developing an otherwise unrelated patch I've discovered that the fnspec for the Fortran library function generate_error is wrong. It is currently ". R . R " where the first R describes the first parameter and means that it "is only read and does not

Re: [PATCH] Fortran: Fix incompatible types between INTEGER(8) and TYPE(c_ptr)

Hi Paul-Antoine, On 26.10.23 13:24, Paul-Antoine Arras wrote: Please see the updated patch attached incorporating your input and details below. ... Is this latest revision ready to commit? LGTM. Thanks, Tobias - Siemens Electronic Design Automation GmbH; Anschrift:

Re: [PATCH] Fortran: Fix incompatible types between INTEGER(8) and TYPE(c_ptr)

, depending on the parsing order. This patch prevents such situation from turning into a compile error. 2023-10-20 Paul-Antoine Arras Tobias Burnus gcc/fortran/ChangeLog: * interface.cc (gfc_compare_types): Return true in this situation. That's a bad description. It makes sense when

[Patch] OpenMP/Fortran: Handle unlisted items in 'omp allocators' + exec. 'omp allocate'

This patch assumes that EXEC_OMP_ALLOCATE/EXEC_OMP_ALLOCATORS is/will be later handled as currently done in OG13, https://github.com/gcc-mirror/gcc/blob/devel/omp/gcc-13/gcc/fortran/trans-openmp.cc Depending how we want to handle it in mainline, the patch still could make sense - or parts

Re: OpenMP/Fortran: Group handling of 'if' clause without and with modifier

CC: fortran@ for completeness. On 24.10.23 10:55, Thomas Schwinge wrote: OK to push (after testing) the attached "OpenMP/Fortran: Group handling of 'if' clause without and with modifier"? That makes an upcoming change a bit lighter. LGTM. (The patch just moves some code up (in the same

[Patch] omp_lib.f90.in: Deprecate omp_lock_hint_* for OpenMP 5.0

I noticed that we only tagged half of the 5.0 deprecations in the omp_lib module; this added the other half. (omp_lock_hint_* was renamed to omp_sync_hint_*.) Currently, this patch has has no visible effect - but once we bump the OpenMP version from 4.5 to 5.0, there will warnings of the

[Patch] OpenMP: Avoid ICE with LTO and 'omp allocate (was: [Patch] Fortran: Support OpenMP's 'allocate' directive for stack vars)

On 18.10.23 11:36, Jakub Jelinek wrote: On Wed, Oct 18, 2023 at 11:12:44AM +0200, Thomas Schwinge wrote: +FAIL: gfortran.dg/gomp/allocate-13.f90 -O (internal compiler error: tree code 'statement_list' is not supported in LTO streams) Any references to GENERIC code in clauses etc.

Re: [patch] fortran/intrinsic.texi: Improve SIGNAL intrinsic entry

: Tobias Burnus Date: Tue, 17 Oct 2023 19:35:18 +0200 Subject: [PATCH] fortran/intrinsic.texi: Add 'intrinsic' to SIGNAL example gcc/fortran/ChangeLog: * intrinsic.texi (signal): Add 'intrinsic :: signal, sleep' to the example to make it safer. --- gcc/fortran/intrinsic.texi | 1 + 1 file

[patch] fortran/intrinsic.texi: Improve SIGNAL intrinsic entry (was: [patch] fortran/intrinsic.texi: Add 'passed by value' to signal handler)

Hi Harald, On 16.10.23 20:31, Harald Anlauf wrote: Hi Tobias, Am 16.10.23 um 19:11 schrieb Tobias Burnus: OK for mainline? I think the patch qualifies as obvious. While at it, you might consider removing the comment a few lines below the place you are changing, @c TODO: What should

[patch] fortran/intrinsic.texi: Add 'passed by value' to signal handler

Yesterday, someone was confused because the signal handler did not work. It turned out that the created Fortran procedure used as handler used pass by reference - and 'signal' passed the it by value. This patch adds the 'passed by value' to the wording: "@var{HANDLER} to be executed with a

Re: [Patch] Fortran: Support OpenMP's 'allocate' directive for stack vars

On 13.10.23 13:01, Jakub Jelinek wrote: On Tue, Oct 10, 2023 at 06:46:35PM +0200, Tobias Burnus wrote: +++ b/gcc/gimplify.cc @@ -1400,23 +1400,53 @@ gimplify_bind_expr (tree *expr_p, gimple_seq *pre_p) + else if (errorcount + || (align == NULL_TREE

Re: PR fortran/39627 [meta-bug] Fortran 2008 support

On 13.10.23 08:31, Richard Biener wrote: On Thu, Oct 12, 2023 at 6:54 PM Paul Richard Thomas wrote: I have posted the version 4 of Ian Chivers and Jane Sleightholme's F2008 compliance table as an attachment to PR39627. ... I am halfway through the F2018 table and will post it on PR85836

[Patch] Fortran: Support OpenMP's 'allocate' directive for stack vars

The attached patch adds 'omp allocate' support for stack/automatic variables variables for Fortran. I had originally a pure FE version for Fortran, which failed with 'defaultmap'/'default'; I then thought I could simply piggyback on the existing C/C++ support. But it turns out that Fortran is

[Patch] Fortran/OpenMP: Fix handling of strictly structured blocks

Strictly structured blocks are '!$omp ' directly followed by 'BLOCK ... END BLOCK', i.e. a Fortran block construct. I did run into this issue because 'integer :: n; n = 5; !$omp ...; block; integer :: A(n)' was not accepted. Well, it turned out that was because the BLOCK handling was not quite

Re: Test with an lto-build of libgfortran.

(replace gcc@ by gcc-patches@; see https://gcc.gnu.org/pipermail/gcc/2023-September/242591.html and other emails in that thread) On 28.09.23 11:51, Jakub Jelinek wrote: On Thu, Sep 28, 2023 at 09:29:02AM +0200, Tobias Burnus wrote: On 28.09.23 08:25, Richard Biener via Fortran wrote

Re: Test with an lto-build of libgfortran.

Hi all, the following works for me. I have only tried a normal build (where it does silence the same warning) and not an LTO build and I just believed the comment - see attached patch. Comments? On 28.09.23 08:25, Richard Biener via Fortran wrote: This particular place in libgfortran has

Re: [PATCH] fortran: Rename TRUE/FALSE to true/false in *.cc files

On 25.08.23 10:26, Uros Bizjak via Gcc-patches wrote: gcc/fortran/ChangeLog: * match.cc (gfc_match_equivalence): Rename TRUE/FALSE to true/false. * module.cc (check_access): Ditto. * primary.cc (match_real_constant): Ditto. * trans-array.cc

Re: Help with fortran pointer ans OpenACC

Hi, On 23.08.23 12:19, Patrick Begou via Fortran wrote: For several days I have some trouble with OpenACC offloading and fortran pointers. I'm testing with a very small peace of code to investigate but I do not progress for several days and I need your help. Could someone give me advices or a

[committed] OpenMP/Fortran: Extend reject code between target + teams [PR71065, PR110725] (was: Re: [patch] OpenMP/Fortran: Reject declarations between target + teams (was: [Patch] OpenMP/Fortran: Rej

: München; Registergericht München, HRB 106955 commit 081e25d3cfd86c4094999ded0bbe99b91762013c Author: Tobias Burnus Date: Thu Jul 27 18:14:11 2023 +0200 OpenMP/Fortran: Extend reject code between target + teams [PR71065, PR110725] The previous version failed to diagnose when the 'teams

[patch] OpenMP/Fortran: Reject declarations between target + teams (was: [Patch] OpenMP/Fortran: Reject not strictly nested target -> teams [PR110725, PR71065])

On 24.07.23 21:49, Jakub Jelinek via Fortran wrote: On Mon, Jul 24, 2023 at 09:43:10PM +0200, Tobias Burnus wrote: This patch adds diagnostic for additional code alongside a nested teams in a target region. Thanks for working on this. The fuzzy thing on the Fortran side is if e.g. multiple

Re: [Patch] OpenMP/Fortran: Reject not strictly nested target -> teams [PR110725, PR71065]

Now committed as r14-2754-g2e31fe431b08b0 with a minor addition: On 24.07.23 22:05, Tobias Burnus wrote: The current patch rejects nested blocks, be it 'omp target; block; block; omp teams;' which was before in the testcase. But now also or be it 'omp target; block; block;end block; omp teams

Re: [Patch] OpenMP/Fortran: Reject not strictly nested target -> teams [PR110725, PR71065]

On 24.07.23 21:49, Jakub Jelinek via Fortran wrote: Thanks for working on this. The fuzzy thing on the Fortran side is if e.g. multiple nested BLOCK statements can appear sandwiched in between target and teams (of course without declarations in them), or if e.g. The current patch rejects

[Patch] OpenMP/Fortran: Reject not strictly nested target -> teams [PR110725, PR71065]

This patch adds diagnostic for additional code alongside a nested teams in a target region. The diagnostic is happening soon after parsing such that expressions in clauses are not yet expanded - those would end up before TEAMS and can be very complicated (e.g. assume an allocatable-returning

[committed] - Re: [patch] OpenMP/Fortran: Non-rectangular loops with constant steps other than 1 or -1 [PR107424]

, the following still applies: On 18.07.23 14:11, Tobias Burnus wrote: Comments regarding the validity of the Fortran assumptions are welcome! This patch now uses a 'simple' loop for OpenMP loops with a constant loop-step size. Before, it only did so for step = ±1. (Otherwise, a count variable is used

[patch] OpenMP/Fortran: Non-rectangular loops with constant steps other than 1 or -1 [PR107424]

Comments regarding the validity of the Fortran assumptions are welcome! This patch now uses a 'simple' loop for OpenMP loops with a constant loop-step size. Before, it only did so for step = ±1. (Otherwise, a count variable is used from which the original loop index variable is calculated from.)

[committed] OpenMP/Fortran: Parsing support for 'uses_allocators'

106955 commit 89d0f082b3c95f68d116d4480126e3ab7fb7f36b Author: Tobias Burnus Date: Mon Jul 17 15:13:44 2023 +0200 OpenMP/Fortran: Parsing support for 'uses_allocators' The 'uses_allocators' clause to the 'target' construct accepts predefined allocators and can also be used

Re: [Patch, fortran] PR108961 - Segfault when associating to pointer from C_F_POINTER

On 20.06.23 18:19, Paul Richard Thomas via Fortran wrote: Is there a better way to detect a type(c_ptr) formal argument? u.derived->intmod_sym_id == ISOCBINDING_PTR ? Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft

[committed] Fortran: Fix parse-dump-tree for OpenMP ALLOCATE clause

634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 commit 99e3214f582b08b69b11b53eb3fc73b0919ef4f1 Author: Tobias Burnus Date: Tue Jun 20 13:46:11 2023 +0200 Fortran: Fix pa

[Patch] Fortran's gfc_match_char: %S to match symbol with host_assoc

When just matching a symbol, one can use 'gfc_match_symbol (, host_assoc)' and has the option to match with and without host association. However, when matching something more complex via 'gfc_match' like "something ( %s ) , " the match uses host_assoc = false. While it can be combined

[committed] Doc update: -foffload-options= examples + OpenMP in Fortran intrinsic modules

er Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 commit e9c1679c350be09cec5354a3d98915c3afe02c87 Author: Tobias Burnus Date: Mon Jun 19 10:24:08 2023 +0200 Doc update: -foffload-options= examples + OpenMP in Fortran

Re: [ping] Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'

On 13.06.23 12:42, Thomas Schwinge wrote: On 2023-06-05T14:18:48+0200, I wrote: OK to push the attached "Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'"? Subject: [PATCH] Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90' gcc/testsuite/ *

Fwd: GNU Tools Cauldron 2023

FYI — in case you want to come to Cambridge in September. (I intent to be there.) - Tobias Forwarded Message Subject:GNU Tools Cauldron 2023 Date: Mon, 5 Jun 2023 14:59:05 +0100 From: Richard Earnshaw To: GCC Development We are pleased to invite you all to

[Patch] OpenMP/Fortran: Permit pure directives inside PURE

I intent to commit the attached patch soon. However, I want to give anyone the chance to comment on any aspect before committing. Comments after the commit are welcome as well :-) OpenMP 5.2 now uses properties to clauses and "pure" is among those properties. Note that pure-2.f90 contains also

[committed][Patch] Fortran/OpenMP: Add parsing support for allocators/allocate directives

th allocators, https://gcc.gnu.org/PR109998 PPPS: I remarked before: On 21.12.22 16:51, Tobias Burnus wrote: On 14.12.22 11:47, Tobias Burnus wrote: This patch adds parsing/argument-checking support for '!$omp allocators allocate([align(int),allocator(a) :] list)' This follow-up patch additionally

[committed] Re: [Patch,v4] Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings

23.03.23 10:28, Tobias Burnus wrote: [...] Another update - fixing an independent issue which makes sense to be part of this patch. Allocatable/pointer scalars are currently mapped as: #pragma omp target enter data map(to:*var.1_1 [len: 4]) map(alloc:var [pointer assign, bias: 0]) #pragma omp targe

Re: [PATCH] OpenACC: Further attach/detach clause fixes for Fortran [PR109622]

On 03.05.23 14:59, Julian Brown wrote: How does this version look? Retested with offloading to nvptx. LGTM (for mainline + GCC 13 backporting) but I have two tiny comments: diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc index 86e4515..322856a 100644 --- a/gcc/fortran/openmp.cc

Re: [PATCH] OpenACC: Further attach/detach clause fixes for Fortran [PR109622]

On 29.04.23 12:57, Julian Brown wrote: This patch moves several tests introduced by the following patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616939.html I believe you intent this as git log entry. Can you add ... commit r14-325-gcacf65d74463600815773255e8b82b4043432bd7

Re: [PATCH] OpenACC: Stand-alone attach/detach clause fixes for Fortran [PR109622]

On 27.04.23 20:36, Julian Brown wrote: This patch fixes several cases where multiple attach or detach mapping nodes were being created for stand-alone attach or detach clauses in Fortran. After the introduction of stricter checking later during compilation, these extra nodes could cause ICEs,

[committed] Fortran: Fix (mostly) comment typos

; Registergericht München, HRB 106955 commit 7ebd4a1d61993c0a75e9ff3098aded21ef04a4da Author: Tobias Burnus Date: Fri Apr 28 09:23:18 2023 +0200 Fortran: Fix (mostly) comment typos Only other changes are fixing the variable name a(b)breviated_modproc_decl and a few typos

[committed] gfortran.dg/gomp/affinity-clause-1.f90: Fix scan-tree-dump (was: [r13-7120 Regression] FAIL: gfortran.dg/gomp/affinity-clause-1.f90 -O scan-tree-dump-times original "#pragma omp task affin

ation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 commit b8e32978e3d9e3b88cd4f441edfdebfa395a5c26 Author: Tobias Burnus Date: Tue Apr 11 13:

[OG12][committed] Fortran/OpenMP: Fix 'alloc' and 'from' mapping for allocatable components

955 commit a63735b8034db65a33c359633462accd9d71d3b5 Author: Tobias Burnus Date: Thu Mar 23 18:04:17 2023 +0100 Fortran/OpenMP: Fix 'alloc' and 'from' mapping for allocatable components Even with 'alloc' and map-entering 'from' mapping, the following should hold. For explicit mapping, that's already the case, th

[OG12][committed] Fortran: Add attr.class_ok check for generate_callback_wrapper

der Gesellschaft: München; Registergericht München, HRB 106955 commit 9c18db65914a751e4a1d9330ccc1659fe5ef270d Author: Tobias Burnus Date: Thu Mar 23 14:29:00 2023 +0100 Fortran: Add attr.class_ok check for generate_callback_wrapper Proper variables/components of type BT_CLASS have

[Patch,v4] Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings

://gcc.gnu.org/g:8ea805840200f7dfd2c11b37abf5fbfe479c2fe2 Comments/thoughts/remarks to this patch? Tobias PS: For the rest of the patch, see a short description below - or with some longer remarks previous in this thread. On 27.02.23 13:15, Tobias Burnus wrote: And another re-diff for GCC 13

Re: [PATCHv4, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

Hi, LGTM, except for: On 21.03.23 07:29, HAO CHEN GUI wrote: @@ -4708,7 +4710,12 @@ do_simplify (gfc_intrinsic_sym *specific, gfc_expr *e) finish: if (result == _bad_expr) -return false; +{ + if (errorcount == old_errorcount + && (!gfc_buffered_p () &&

Re: [PATCH] Fortran: reject MODULE PROCEDURE outside generic module interface [PR99036]

On 20.03.23 21:57, Harald Anlauf via Gcc-patches wrote: --- a/gcc/fortran/decl.cc +++ b/gcc/fortran/decl.cc @@ -9998,6 +9998,7 @@ gfc_match_modproc (void) if ((gfc_state_stack->state != COMP_INTERFACE && gfc_state_stack->state != COMP_CONTAINS) || gfc_state_stack->previous

Re: [PATCHv3, gfortran] Escalate failure when Hollerith constant to real conversion fails [PR103628]

a "Cannot simplify expression" error on a bad result if error count doesn't change and no other errors buffered. gcc/testsuite/ PR target/103628 * gfortran.dg/pr103628.f90: New. Co-Authored-By: Tobias Burnus ... --- a/gcc/fortran/intrinsic.cc +++ b/gcc/fortran/in

Re: [PATCH] Fortran: rank checking with explicit-/assumed-size arrays and CLASS [PR58331]

Hi Harald, On 14.03.23 20:38, Harald Anlauf wrote: The testcase covers only non-coarray cases, as playing with coarray variants hit pre-exisiting issues in gfortran that are very likely unrelated to the interface checks. I concur (but would not rule out additional interface issues). I

Re: [Patch, fortran] PR37336 finalization

On 08.03.23 16:12, Steve Kargl via Fortran wrote: For one of my codes, I see % foreach i (*.o) foreach? nm $i | grep final foreach? end 0280 T __beamsm_MOD___final_beamsm_Table_t 0580 T __bsam_MOD___final_bsam_Bsa_info_t 01e0 T __bsam_MOD___final_bsam_Bsa_t

Re: Request for participation in GSoC

Hello, welcome to the GCC/gfortran community. On 08.03.23 14:02, Martin Jambor wrote: On Sat, Mar 04 2023, Priyabrata Mondal via Gcc wrote: I want to participate in Google Summer of Code 2023 by contributing to the *Fortran – DO CONCURRENT* project, an implementation of loop that executes

  1   2   3   4   5   6   >