Re: [PATCH, OpenMP 5.1, Fortran] Strictly-structured block support for OpenMP directives

Hi Chung-Lin, On 07.10.21 15:59, Chung-Lin Tang wrote: this patch add support for "strictly-structured blocks" introduced in OpenMP 5.1, basically allowing BLOCK constructs to serve as the body for directives: !$omp target block ... end block [!$omp end target]  !! end directive is optional

Re: [PATCH, Fortran] Add diagnostic for F2018:C839 (TS29113:C535c)

Hi Sandra, On 06.10.21 23:37, Sandra Loosemore wrote: This patch is for PR fortran/54753, to add a diagnostic for violations of this constraint in the 2018 standard: C839 If an assumed-size or nonallocatable nonpointer assumed-rank array is an actual argument that corresponds to a dummy

PING - (Re: [Patch] Fortran: Various CLASS + assumed-rank fixed [PR102541])

Early ping for this patch. (I still plan to review Harald's pending patch soon, unless someone beats me: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580810.html ) On 01.10.21 02:43, Tobias Burnus wrote: Hi all, this patch fixes a bunch of issues with CLASS. * * * Side remark: I

Re: [Patch] Fortran: Fix deprecate warning with parameter

Hi Harald, On 05.10.21 21:10, Harald Anlauf wrote: Am 05.10.21 um 20:03 schrieb Tobias Burnus: Played around with the warning in the 'omp_lib' module (needs tweaking as for the current version, no warning is done). Turned out that already use omp_lib outputs a warning even when not used

[committed] gfortran.dg/gomp/pr43711.f90: Change dg-* for XFAIL->PASS

b76d Author: Tobias Burnus Date: Tue Oct 5 14:28:10 2021 +0200 gfortran.dg/gomp/pr43711.f90: Change dg-* for XFAIL->PASS gcc/testsuite/ * gfortran.dg/gomp/pr43711.f90: Add dg-error + dg-prune-output, remove dg-excess-errors to change XFAIL to PASS. diff --gi

Re: [Patch] Fortran: Avoid var initialization in interfaces [PR54753]

Hi Harald, unfortunately, your email did not arrive at fortran@gcc.gnu.org – nor at my private address. I copied it from https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580794.html You wrote: >/I do not see this error. Can you double check that you indeed use the />/posted patch:

Re: [Patch] Fortran: Avoid var initialization in interfaces [PR54753]

On 02.10.21 20:01, Sandra Loosemore wrote: On 9/29/21 2:53 AM, Tobias Burnus wrote: There are three issues, this patch solves the first: * reject-valid issue due to adding the initializer also to a dummy    argument which is in an INTERFACE block. Having initializers in    INTERFACE blocks

[Patch] Add/update libgomp.fortran/alloc-*.f90 [Re: [committed] openmp: Add alloc_align attribute to omp_aligned_*alloc and testcase for omp_realloc]

... and attached the Fortran version of the C/C++ testcase. OK? Tobias On 01.10.21 10:59, Jakub Jelinek wrote: 2021-10-01 Jakub Jelinek * omp.h.in (omp_aligned_alloc, omp_aligned_calloc): Add __alloc_align__ (1) attribute. * testsuite/libgomp.c-c++-common/alloc-9.c: New

[Patch] Fortran: Various CLASS + assumed-rank fixed [PR102541]

Hi all, this patch fixes a bunch of issues with CLASS. * * * Side remark: I disliked the way CLASS is represented when it was introduced; when writing the testcase for this PR and kept fixing the testcase fallout, I started to hate it! I am sure that there are more issues – but I tried hard

Re: [PATCH, part 2] PR 102458 - issues with simplification of SIZE intrinsic applied to automatic arrays

Dear Harald, dear all, On 29.09.21 21:20, Harald Anlauf via Fortran wrote: I think I have solved the remaining issue in PR 102458 that prevented the simplification of an expression involving a static initialization and the evaluation of the SIZE of an automatic array which has provable constant

Re: [Patch] openmp: Add omp_aligned_{, c}alloc and omp_{c, re}alloc for Fortran (was: [committed] openmp: Add omp_aligned_{,c}alloc and omp_{c,re}alloc)

4 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 ef37ddf477ac4b21ec4d1be9260cfd3b431fd4a9 Author: Tobias Burnus Date: Thu Sep 30 14:44:06 2021 +0200 libgomp.fortran/alloc-

[Patch] openmp: Add omp_aligned_{,c}alloc and omp_{c,re}alloc for Fortran (was: [committed] openmp: Add omp_aligned_{,c}alloc and omp_{c,re}alloc)

On 30.09.21 09:45, Jakub Jelinek wrote: This patch adds new OpenMP 5.1 allocator entrypoints ... ... and this patch adds the Fortran support for it, using the C→Fortran converted testcases. Additionally, it fixes and updated the list of API routine names. We now can also tick off one item in

Re: [Patch] Fortran: Fix same_type_as

as(class_star, class_star)" is .false. Code wise, this implies the extra check for class_star._vtab == NULL while class_t._vtab is always set and, thus, class._vtab->hash is always available. (Unchanged in this patch, but probably not obvious without reading the standard.) On 28

[Patch] Fortran: Fix same_type_as

Found when looking at Sandra's c535b-1.f90 and playing around. When fixing same_type_as, I spotted by code reading another issue, related to not catering for derived types. (Untested whether it failed indeed.) I added now a bunch of testcases. OK for mainline? Tobias - Siemens

[committed] gfortran.dg/include_15.f90: Add dg-prune-output [PR102500]

Gesellschaft: München; Registergericht München, HRB 106955 commit ce450af5087b95001b003184b8ecc2c9bbf65378 Author: Tobias Burnus Date: Tue Sep 28 09:49:12 2021 +0200 gfortran.dg/include_15.f90: Add dg-prune-output [PR102500] gcc/testsuite/ PR fortran/102500

Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]

Hi Harald, hi all, On 27.09.21 21:34, Harald Anlauf via Gcc-patches wrote: [...] here is what I played with: program p implicit none integer, pointer :: x(:,:) allocate (x(-3:3,4:0)) print *, "lbound =", lbound (x) call sub (x) contains subroutine sub (y) integer, pointer

[committed] libgomp.oacc-fortran/privatized-ref-2.f90: Fix dg-note (was: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070])

On 27.09.21 14:07, Tobias Burnus wrote: now committed r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0 I accidentally changed dg-note to dg-message when updating the expected output, as the dump has changed. (Copying seemingly the sorry line instead of the dg-note lines as template

Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]

mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 commit 00f6de9c69119594f7dad3bd525937c94c8200d0 Author: Tobias Burnus Date: Mon Sep 27 14:04:54 2021 +0200 Fortran: Fix assumed-size to assumed-ran

Re: [PATCH, Fortran] Add missing diagnostic for F2018 C711 (TS29113 C407c)

On 24.09.21 01:19, Sandra Loosemore wrote: Here's another missing-diagnostic patch for the Fortran front end, this time for PR Fortran/101333. OK to commit? That's "C711 An assumed-type actual argument that corresponds to an assumed-rank dummy argument shall be assumed-shape or assumed-rank."

Re: Fortran: Improve file-reading error diagnostic [PR55534] (was: Re: [Patch] Fortran: Improve -Wmissing-include-dirs warnings [PR55534])

On 23.09.21 23:01, Harald Anlauf via Fortran wrote: compiled with -cpp gives: pr55534-play.f90:4:2: 4 |   type t |  1~~ Fatal Error: no/such/file.inc: No such file or directory compilation terminated. If you have an easy solution for that one, David has an easy but hackish

[Patch] Fortran: Fix associated intrinsic with assumed rank [PR101334] [was: [PATCH, Fortran] Fixes for F2018 C838 (PR fortran/101334)]

On 20.09.21 09:58, Tobias Burnus wrote: On 20.09.21 06:01, Sandra Loosemore wrote: This patch fixes some bugs in handling of assumed-rank arguments revealed by the TS29113 testsuite, ... giving a bogus error when passing one as the first argument to the ASSOCIATED intrinsic. ... ... if I

Re: [PATCH, Fortran] Diagnose default-initialized pointer/allocatable dummies

On 23.09.21 18:30, Sandra Loosemore wrote: On 9/23/21 10:10 AM, Tobias Burnus wrote: On 23.09.21 17:50, Sandra Loosemore wrote: This patch is for PR101320, another issue related to missing bind(c) diagnostics. OK to commit? LGTM - I am only ... + gfc_error ("Default-initializ

Re: [Patch] Fortran: Handle allocated() with coindexed scalars [PR93834] (was: [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469)

München, HRB 106955 commit 1b07d9dce6c51c98d011236c3d4cd84a2ed59ba2 Author: Tobias Burnus Date: Thu Sep 23 18:47:45 2021 +0200 Fortran: Handle allocated() with coindexed scalars [PR93834] While for an allocatable 'array', 'array(:)' and 'array(:)[1]' are not allocatable

Re: [PATCH, Fortran] Diagnose default-initialized pointer/allocatable dummies

On 23.09.21 17:50, Sandra Loosemore wrote: This patch is for PR101320, another issue related to missing bind(c) diagnostics. OK to commit? LGTM - I am only ... commit d3507154fd34e65e2887262218fec09d5fb082a2 Author: Sandra Loosemore Date: Thu Sep 23 08:03:52 2021 -0700 Fortran:

Fortran: Improve file-reading error diagnostic [PR55534] (was: Re: [Patch] Fortran: Improve -Wmissing-include-dirs warnings [PR55534])

Hi Harald, On 22.09.21 20:29, Harald Anlauf via Gcc-patches wrote: What I find a bit confusing - from the viewpoint of a user - is the case of using the preprocessor (-cpp), as one gets e.g. : Warning: ./no/such/dir: No such file or directory [-Wmissing-include-dirs] while without -cpp:

Re: PING**2 – Re: [Patch] Fortran: Handle allocated() with coindexed scalars [PR93834] (was: [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.

iguous attribute handling, len=* with assumed-size/explicit-size arrays, ...) On 16.09.21 14:26, Tobias Burnus wrote: Patch PING – see comment in the follow-up email of the patch email - and in the email(s) before in that thread. Tobias On 07.09.21 16:33, Tobias Burnus wrote: Now I actually

Re: [PATCH, Fortran] diagnostic for argument w/type parameters for assumed-type dummy

On 22.09.21 16:58, Sandra Loosemore wrote: This patch is adds the missing diagnostic noted in PR fortran/101319. OK to commit? LGTM. Thanks! For reference, the F2018 wording is: "If the actual argument is of a derived type that has type parameters, type-bound procedures, or final

[Patch] Fortran: Improve -Wmissing-include-dirs warnings [PR55534]

While the previous patch fixed -Wno-missing-include-dirs and sorted out some inconsistencies with libcpp warnings, it had two issues: * Some superfluous warnings were printed, e.g. for gfortran nonexisting/file.f90 there was a warning about include path "nonexisting" not existing and

[Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]

bound, lbound); - se->expr = fold_build2_loc (input_location, PLUS_EXPR, - gfc_array_index_type, - se->expr, gfc_index_one_node); - se->expr = fold_build2_loc (input_location, MAX_EXPR, - gfc_array_index_type, se->expr, - gfc_index_zero_node); -} - +size

Re: [Patch] Fortran: Fix -Wno-missing-include-dirs handling [PR55534]

And v3 – I realized that testcases would be useful. Thus, now with added testcases. :-) Tobias On 17.09.21 20:45, Tobias Burnus wrote: I seemingly messed up a bit in previous patch – corrected version attached. OK? Tobias PS: Due to now enabling the missing-include-dir warning also for cpp

[Patch]GCC11 - Fortran: combined directives - order(concurrent) not on distribute (was: Re: [Patch] Fortran/OpenMP: unconstrained/reproducible ordered modifier)

On 20.09.21 11:55, Jakub Jelinek via Fortran wrote: So the FE was splitting the order clause to distribute already before, perhaps we should undo that for gcc 11 which doesn't claim any OpenMP 5.1 support. The difference is e.g. the distribute parallel do order(concurrent) copyin(thr) case which

Re: [PATCH, Fortran] Fixes for F2018 C838 (PR fortran/101334)

On 20.09.21 06:01, Sandra Loosemore wrote: This patch fixes some bugs in handling of assumed-rank arguments revealed by the TS29113 testsuite, allowing xfails to be removed from those testcases. It was previously failing to diagnose an error when passing an assumed-rank argument to a procedure

[Patch] Fortran/OpenMP: unconstrained/reproducible ordered modifier

This patch adds Fortran support for the new OpenMP 5.1 unconstrained and reproducible modifiers to ordered(concurrent). This patch requires Jakub's patch to handle the middle-end (and C/C++) part, which still has to be committed. The testcases are based on the C/C++ ones. OK? Tobias

Re: [Patch] Fortran: Fix -Wno-missing-include-dirs handling [PR55534]

in a normal way not with -B etc.). Thus, I think it should be fine. Alternatively, we could think of reducing the noisiness. Thoughts? PPS: Besides this, the following still applies: On 17.09.21 15:02, Tobias Burnus wrote: Short version: * -Wno-missing-include-dirs had no effect as the warning

[committed] Fortran: Prefer GCC internal macros to float.h in ISO_Fortran_binding.h (was: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h)

t mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 commit 654187d05376f08667c8ba88309073e0345431c2 Author: Tobias Burnus Date: Fri Sep 17 15:43:30 2021 +0200 Fortran: Prefer GCC

[Patch] Fortran: Fix -Wno-missing-include-dirs handling [PR55534]

Short version: * -Wno-missing-include-dirs had no effect as the warning was always on * For CPP-only options like -idirafter, no warning was shown. This patch tries to address both, i.e. cpp's include-dir diagnostics are shown as well – and silencing the diagnostic works as well. OK for

Re: [PATCH, Fortran] Use _Float128 rather than __float128 for c_float128 kind

On 17.09.21 06:02, Sandra Loosemore wrote: On 9/5/21 11:20 PM, Sandra Loosemore wrote: Unless the aarch64 maintainers think it is a bug that __float128 is not supported, I think the right solution here is [...] to tie the C_FLOAT128 kind to _Float128 rather than __float128, [...] Here's a new

[Patch] Fortran: Add gfc_simple_for_loop aux function

This patch adds a useful auxiliary function to generate a loop. I intent to use it for: (A) An updated/cleaned-up version of "[Patch] Fortran: Fix Bind(C) Array-Descriptor Conversion (Move to Front-End Code)" https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578904.html → new

PING – Re: [Patch] Fortran: Handle allocated() with coindexed scalars [PR93834] (was: [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469)

Patch PING – see comment in the follow-up email of the patch email - and in the email(s) before in that thread. Tobias On 07.09.21 16:33, Tobias Burnus wrote: Now I actually tested the patch – and fixed some issues. OK? – It does add support for 'allocated(a[i])' by treating it as 'allocated

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

This looks like it matches existing Linux case already in place? On 14.09.21 16:50, Gerald Pfeifer wrote: On Mon, 13 Sep 2021, Tobias Burnus wrote: Can you run 'echo | cpp -E -g3|grep DBL' to (or in the build dir: echo | ./gcc/cc1 -E -g3 -dD|grep DBL) to check what's the output? Thank you, Tobias

[committed] Fortran: Add missing ST_OMP_END_SCOPE handling [PR102313]

33fdbbe4ce6055eb858096d01720ccf94aa854ec Author: Tobias Burnus Date: Tue Sep 14 14:17:35 2021 +0200 Fortran: Add missing ST_OMP_END_SCOPE handling [PR102313] PR fortran/102313 gcc/fortran/ChangeLog: * parse.c (gfc_ascii_statement): Add missing ST_OMP_END_SCOPE

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

On 14.09.21 05:39, Sandra Loosemore wrote: Here's a patch. Gerald, can you check that this fixes your bootstrap problem on i586-unknown-freebsd11? LGTM – thanks! Tobias Fortran: Prefer GCC internal macros to float.h in ISO_Fortran_binding.h. 2021-09-13 Sandra Loosemore

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

On 13.09.21 18:59, Sandra Loosemore wrote: On 9/13/21 10:51 AM, Jakub Jelinek wrote: On Mon, Sep 13, 2021 at 06:32:56PM +0200, Tobias Burnus wrote: On 13.09.21 17:56, Gerald Pfeifer wrote: This broke bootstrap on i586-unknown-freebsd11: % egrep -r '#define.*LDBL_(MANT_DIG|MIN_EXP|MAX_EXP

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

Hi Gerald, On 13.09.21 17:56, Gerald Pfeifer wrote: This broke bootstrap on i586-unknown-freebsd11: In file included from .../GCC-HEAD/libgfortran/runtime/ISO_Fortran_binding.c:30: .../GCC-HEAD/libgfortran/ISO_Fortran_binding.h:255:2: error: #error "Can't determine kind of long

Re: [PATCH] PR fortran/82314 - ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972

On 07.09.21 23:44, Harald Anlauf via Fortran wrote: When adding the initializer for an array, we need to make sure that array bounds are properly simplified if that array is a PARAMETER. Otherwise the generated initializer could be wrong and screw up subsequent simplifications, see PR. The

Re: [PATCH] PR fortran/85130 - Handling of substring range

Dear Harald, hi all, On 12.09.21 20:40, Harald Anlauf via Fortran wrote: in find_substring_ref we erroneously handled given substring start and end indices as unsigned integers. However, gives indices could be negative, which is legal as long as end < start, leading to a string of length zero.

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

On 10.09.21 17:39, Andreas Schwab wrote: This misses the m68k extended real format. * ISO_Fortran_binding.h (CFI_type_long_double) (CFI_type_long_double_Complex) [LDBL_MANT_DIG == 64 && LDBL_MIN_EXP == -16382 && LDBL_MAX_EXP == 16384]: Define. LGTM – thanks! Tobias ---

PING – [Patch] Fortran: Fix Bind(C) Array-Descriptor Conversion (Move to Front-End Code)

Early PING for that patch. On 06.09.21 12:52, Tobias Burnus wrote: Hi all, gfortran's internal array descriptor (xgfc descriptor) and the descriptor used with BIND(C) (CFI descriptor, ISO_Fortran_binding.h of TS29113 / Fortran 2018) are different. Thus, when calling a BIND(C) procedure the gfc

Re: [Patch] libgfortran: Makefile fix for ISO_Fortran_binding.h

Now committed as r12-3384-gfc4f0631de806c89a383fd02428a16e91068b9f6 Sorry for the breakage – and thanks for the report on IRC, Richard! Tobias On 07.09.21 16:13, Tobias Burnus wrote: Since the last libgfortran/Makefile.am commit, https://gcc.gnu.org/g

[Patch] Fortran: Handle allocated() with coindexed scalars [PR93834] (was: [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469)

swer to my question to the J3-list as linked below. Tobias * Ignoring issues related to failed images. It could also be handled by fetching 'a' from the remote image, but I am not sure that's better in terms of handling failed images. PS: On 07.09.21 10:02, Tobias Burnus wrote: Hi Harald, I spend

[Patch] libgfortran: Makefile fix for ISO_Fortran_binding.h

Since the last libgfortran/Makefile.am commit, https://gcc.gnu.org/g:13beaf9e8d2d8264c0ad8f6504793fdcf26f3f73 the ISO_Fortran_binding.h file is no longer copied to $(build)/.../libgfortran/include/ – which breaks in-build-tree testing. The Makefile does contain the rule:

Re: [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

omas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 Fortran: Handle allocated() with coindexed scalars [PR93834] 2021-09-07 Harald Anlauf Tobias Burnus While for an allocatable 'array', 'array(:)' and 'array(:)[1]' are not allocat

Re: [PATCH] PR fortran/101327 - ICE in find_array_element, at fortran/expr.c:1355

On 30.08.21 23:40, Harald Anlauf via Fortran wrote: There was an issue when trying to use an element from an array constructor which was a broken in a way probably only Gerhard could conceive. We hit an assert that can be replaced by more robust code. Patch is basically Steve's. Regtested on

Re: [PATCH, Fortran] Revert to non-multilib-specific ISO_Fortran_binding.h

On 19.08.21 04:57, Sandra Loosemore wrote: This is a follow-up to commit fef67987cf502fe322e92ddce22eea7ac46b4d75: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fef67987cf502fe322e92ddce22eea7ac46b4d75 I realized last week that having multilib-specific versions of ISO_Fortran_binding.h

Re: [PATCH, Fortran] Skip gfortran.dg/PR100914.f90 on targets that don't provide quadmath.h

Hi Sandra, hi all, On 06.09.21 07:20, Sandra Loosemore wrote: On 9/5/21 7:29 PM, H.J. Lu wrote: On Sun, Sep 5, 2021 at 11:02 AM Sandra Loosemore wrote: On 9/5/21 7:31 AM, H.J. Lu wrote: On Sat, Sep 4, 2021 at 7:31 PM Sandra Loosemore wrote: The testcase gfortran.dg/PR100914.f90 that I

Re: [PATCH v3, Fortran] TS 29113 testsuite

Hi, On 03.09.21 09:46, Christophe Lyon wrote: I'm not quite sure I understand the expected status of this patch: are all the "expected" failures tagged as XFAIL? I think that's the idea. If yes, then there's a problem because I see lots of unresolved on aarch64/arm XFAIL:

Re: [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

Hi Harald, On 24.08.21 22:36, Harald Anlauf via Fortran wrote: here's a pretty obvious one: we didn't properly check the arguments for intrinsics when these had to be ALLOCATABLE and in the case that argument was a coarray object. Simple solution: just reuse a check that was used for pointer

Re: Fwd: FortranCon 2021

Hi all, I want to note that the FortranCon 2021 is in the same week as the GNU Tools @ Linux Plumbers Conference, https://gcc.gnu.org/wiki/linuxplumbers2021 – Mon 20 to Fri 24 September, 07:00–11:00 a.m. PDT / 16:00–20:00 CEST with submission deadline next Tuesday. While the FortranCon is

Re: [RFH] ME optimizes variable assignment away / Fortran bind(C) descriptor conversion

Hi all, hi Richard, On 27.08.21 21:48, Richard Biener wrote: It looks really nice with "-O1 -fno-inline" :-) The callee 'rank_p()' is mostly optimized and in the caller only those struct elements are set, which are used: integer(kind=4) rank_p (struct CFI_cdesc_t & _this) { _1 =

*PING**2 – Re: [Patch] Fortran: Fix Bind(C) char-len check, add ptr-contiguous check

PING**2 On 25.08.21 20:58, Tobias Burnus wrote: Early *PING*. (I also should still review several Fortan patches... There are lots of patches waiting for review :-/) On 20.08.21 19:24, Tobias Burnus wrote: The following is about interoperability (BIND(C)) only. * The patch adds a missing

Re: [RFH] ME optimizes variable assignment away / Fortran bind(C) descriptor conversion

On 27.08.21 17:47, Tobias Burnus wrote at https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578271.html : PS: Current GCC (mainline w/o patch) generates the following. [-> with patch, see a-test.f90.*.original.] I accidentally attached the original dump created by mainline

*PING* – Re: [Patch] Fortran: Fix Bind(C) char-len check, add ptr-contiguous check

Early *PING*. (I also should still review several Fortan patches... There are lots of patches waiting for review :-/) On 20.08.21 19:24, Tobias Burnus wrote: The following is about interoperability (BIND(C)) only. * The patch adds a missing check for pointer + contiguous. (Rejected to avoid

Re: [patch, libgfortran] Further fixes for GFC/CFI descriptor conversions

Hi Sandra, On 19.08.21 05:57, Sandra Loosemore wrote: This patch addresses several bugs in converting from GFC to CFI descriptors and vice versa. [...] The root of all the problems addressed here is that GFC descriptors contain incomplete information; in particular, they only encode the size

Re: Failing tests after applying patches?

Hi Arjen, On 23.08.21 20:59, Arjen Markus via Fortran wrote: as promised, here is an overview of the unexpectedly failing tests. I got these after applying the patches by Steve Kargl for bug ID 101951 and 101967. The platform I used to build it is Cygwin on WIndows 10. FAIL:

Re: [Patch] Fortran/OpenMP: strict modifier on grainsize/num_tasks + duplicate errors (was: [committed] openmp: Add support for strict modifier on grainsize/num_tasks clauses)

On 23.08.21 14:53, Jakub Jelinek wrote: On Mon, Aug 23, 2021 at 02:14:46PM +0200, Tobias Burnus wrote: + unsigned capture:1, grainsize_strict, num_tasks_strict; Missing :1 twice. Fixed. Well spotted! Otherwise LGTM, though maybe it would be better to commit separately the change to handle

[Patch] Fortran/OpenMP: strict modifier on grainsize/num_tasks + duplicate errors (was: [committed] openmp: Add support for strict modifier on grainsize/num_tasks clauses)

Hi Jakub, hi all, On 23.08.21 10:25, Jakub Jelinek wrote: The following patch implements it for C and C++. The attached patch now adds Fortran support for it, which is a small change - the two testcases (in 4 files) are the converted C ones. Additionally, the previous diagnostic for

[Patch] Fortran: Fix Bind(C) char-len check, add ptr-contiguous check

The following is about interoperability (BIND(C)) only. * The patch adds a missing check for pointer + contiguous. (Rejected to avoid copy-in issues? Or checking issues?) * And it corrects an issue regarding len > 1 characters. While subroutine foo(x) character(len=2) :: x(*) is valid

Re: [Patch] c-format.c/Fortran: Support %wd / host-wide integer in gfc_error (Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514)

On 20.08.21 13:56, Jakub Jelinek wrote: On Fri, Aug 20, 2021 at 01:50:00PM +0200, Tobias Burnus wrote: Comments? OK? LGTM (except that the last hunk won't apply anymore). Now applied as r12-3044; I have now changed it to %wd ... ... but as discussed in another email in the thread, I think

Re: Aw: Re: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

On 20.08.21 12:53, Harald Anlauf wrote: I have verified it fixes i686-linux bootstrap. But the new testcase doesn't trigger any of those new errors, is something else in the testsuite covering those or do you have some short snippet that could verify the errors work properly? The testcase was

[Patch] c-format.c/Fortran: Support %wd / host-wide integer in gfc_error (Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514)

On 20.08.21 11:16, Jakub Jelinek wrote: Now, the non-Fortran FE diagnostic code actually has %wd for this (w modifier like l modifier), which takes HOST_WIDE_INT/unsigned HOST_WIDE_INT argument and prints it. So, either you get through the hops to support that, unfortunately it isn't just

[Patch] Fortran: Add OpenMP's error directive (was: [committed] openmp: Implement the error directive)

Hi Jakub, hi all, On 20.08.21 11:45, Jakub Jelinek wrote: This patch implements the error directive. Depending on clauses it is either a compile time diagnostics (in that case diagnosed right away) or runtime diagnostics (libgomp API call that diagnoses at runtime), The attached patch does

Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

On 20.08.21 02:21, H.J. Lu wrote: This may have broken bootstrap on 32-bit hosts: https://gcc.gnu.org/pipermail/gcc-regression/2021-August/075209.html The latter has: ../../src-master/gcc/fortran/simplify.c:4557:22: error: unknown conversion type character ‘l’ in format [-Werror=format=]

Re: [PATCH] libgfortran : Use the libtool macro to determine libm availability.

On 20.08.21 09:34, Richard Biener via Fortran wrote: On Thu, Aug 19, 2021 at 10:10 PM Iain Sandoe wrote: libm is not needed on Darwin, and should not be added unconditionally even if that is (mostly) harmless since it is a symlink to libc. tested on x86_64, i686-darwin, x86_64-linux, OK for

Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

Hi Harald, On 18.08.21 23:01, Harald Anlauf wrote: Von: "Tobias Burnus" Note, however, that gfc_simplify_len still won't handle neither deferred strings nor their substrings. Obviously, nonsubstrings cannot be simplified but I do not see why len(str(1:2)) cannot or should not be

Re: (Re: [committed] openmp: Add nothing directive support)

Registergericht München, HRB 106955 commit f0fca213bc52644ba896da622b35842a6157bd98 Author: Tobias Burnus Date: Wed Aug 18 21:47:04 2021 +0200 Fortran: Add OpenMP's nothing directive support (con't) Fix directory to enable -fopenmp processing. gcc/testsuite/ PR

(Re: [committed] openmp: Add nothing directive support)

On 18.08.21 11:18, Jakub Jelinek wrote: As has been clarified, it is intentional that nothing directive is accepted in substatements of selection and looping statements and after labels and is handled as if the directive just isn't there ... And here is the Fortran version; as ST_NONE is

Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

Hi Harald, sorry for the belated review. On 03.08.21 23:17, Harald Anlauf wrote: allocate(x%str2, source="abd") if (len (x%str)) /= 1) ... if (len (x%str2(1:2) /= 2) ... etc. Namely: Search the last_ref = expr->ref->next->next ...? and then check that lastref? The mentioned search is now

[Patch] Fortran/OpenMP: Add memory routines existing for C/C++

The added routines existed before for C/C++ (being part of OpenMP 5.0) but not for Fortran (new there since OpenMP 5.1) – as those are all bind(C), it only affects 'omp_lib' and uses the C interface otherwise. Note 1: OpenMP 5.1 added additional (target) memory routines for C/C++ and Fortran;

Fortran: Implement OpenMP 5.1 scope construct (was: Re: openmp: Implement OpenMP 5.1 scope construct)

On 17.08.21 09:47, Jakub Jelinek wrote: This patch implements the OpenMP 5.1 scope construct, which is similar to worksharing constructs in many regards, but isn't one of them. And the attached patch does the same for Fortran. I took the opportunity to convert some additional C/C++ testcases

Re: [Patch] Fortran/OpenMP: Add support for OpenMP 5.1 masked construct (was: Re: [committed] openmp: Add support for OpenMP 5.1 masked construct)

On 13.08.21 16:37, Tobias Burnus wrote: When converting the C/C++ runtime testcase to Fortran, I did run into a bug: https://gcc.gnu.org/PR101899 (see PR or testcase; related to 'omp taskloop'.) I am any more sure whether it is a bug or not or what is the bug (see PR) – however, for this patch

[Patch] Fortran/OpenMP: Add support for OpenMP 5.1 masked construct (was: Re: [committed] openmp: Add support for OpenMP 5.1 masked construct)

Hi all, hi Jakub, On 12.08.21 22:48, Jakub Jelinek via Gcc-patches wrote: This construct has been introduced as a replacement for master construct, but unlike that construct is slightly more general, has an optional clause which allows to choose which thread will be the one running the region,

Re: [Patch] OpenMP 5.1: Add proc-bind 'primary' support

I will commit the attached patch in a while – unless last-minute comments or other issues show up. On 12.08.21 13:31, Jakub Jelinek wrote: LGTM, some nits below. Maybe in tree-core.h do: - OMP_CLAUSE_PROC_BIND_MASTER = 2, + OMP_CLAUSE_PROC_BIND_PRIMARY = 2, + OMP_CLAUSE_PROC_BIND_MASTER =

Re: gfortran.dg/PR82376.f90: Avoid matching a file-path.

On 12.08.21 14:13, Hans-Peter Nilsson via Fortran wrote: I'd call it obvious, so i dare to approve it. OK. thanks! Thanks, but not coming from a testsuite or fortran maintainer I'm not sure I can actually rely on that. OTOH, damn the torpedoes. Committed. If it helps: A post-commit LGTM

[Patch] OpenMP 5.1: Add proc-bind 'primary' support

The attached patch adds another (very) low-hanging fruit of OpenMP 5.1 to GCC, given that we already have one OpenMP 5.1 feature and another one also related to 'master'/'masked' construct might be added soon. OK? Tobias - Siemens Electronic Design Automation GmbH; Anschrift:

Re: [Patch v3 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

On 11.08.21 00:46, Sandra Loosemore wrote: On 8/10/21 2:29 AM, Tobias Burnus wrote: [snip] To conclude: I like the code changes (LGTM); the '__float128' -> 'TFmode' comment change also matches the code. However, I think both longer comments need to be updated. OK. I used your word

[Patch] gfortran: Fix in-build-tree testing [PR101305, PR101660]

This is a follow up to https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576970.html /https://gcc.gnu.org/r12-2808-g527a1cf32c27a3fbeaf6be7596241570d864cc4c It turned out that -I $specpath/libgfortran caused gfortran

Re: [Patch v2 Fortran] Fix c_float128 and c_float128_complex on targets with 128-bit long double.

Hi Sandra, hi all, Let's start reverse – by trying to answer: On 09.08.21 23:42, Sandra Loosemore wrote: ... if (mode_precision != LONG_DOUBLE_TYPE_SIZE && mode_precision == 128) { + /* FIXME: why are we assuming that this type has IEEE + representation? That's implied by

Re: [PATCH 3/3] [PR libfortran/101305] Fix ISO_Fortran_binding.h paths in gfortran testsuite

Hi Andreas, On 04.08.21 11:00, Andreas Schwab wrote: On Jul 13 2021, Sandra Loosemore wrote: -#include "../../../libgfortran/ISO_Fortran_binding.h" +#include "ISO_Fortran_binding.h" Shouldn't that use since that is an installed header, not one that is supposed to be picked up from the

committed – Re: [Patch] testsuite/lib/gfortran.exp: Add -I for ISO*.h [PR101305, PR101660] (was: Re: [Patch] gfortran.dg/dg.exp: Add libgfortran as -I flag for ISO*.h [PR101305] (was: [PATCH 3/3] [PR

ltilib run. Thus, in that case the previous settings are used. – For the discussion in this thread, this means the wrong ISO_Fortran_binding.h is read. Or in previous wording: On 29.07.21 11:51, Tobias Burnus wrote: On 29.07.21 09:09, Jakub Jelinek wrote: On Thu, Jul 29, 2021 at 12:56:32AM +0200, Jakub

Re: Fwd: Curious Behavior with Fortran gfortran-10.2-catalina.dmg on macOS Big Sur Version 11.4

On 29.07.21 13:26, Iain Sandoe wrote: … perhaps someone here can see what the issue might be? Lawrence Doctors wrote: (1) I see that you now check consistency of the argument types and rank, in CALL statements. Thus, if an argument would normally be an array, but is unused in some CALL

[Patch] testsuite/lib/gfortran.exp: Add -I for ISO*.h [PR101305, PR101660] (was: Re: [Patch] gfortran.dg/dg.exp: Add libgfortran as -I flag for ISO*.h [PR101305] (was: [PATCH 3/3] [PR libfortran/10130

On 29.07.21 09:09, Jakub Jelinek wrote: On Thu, Jul 29, 2021 at 12:56:32AM +0200, Jakub Jelinek wrote: On Wed, Jul 28, 2021 at 01:22:53PM +0200, Tobias Burnus wrote: gfortran.dg/dg.exp: Add libgfortran as -I flag for ISO*.h [PR101305] Wouldn't it be better to do that in gcc/testsuite/lib

[Patch] gfortran.dg/dg.exp: Add libgfortran as -I flag for ISO*.h [PR101305] (was: [PATCH 3/3] [PR libfortran/101305] Fix ISO_Fortran_binding.h paths in gfortran testsuite)

Hi Sandra, hi all, On 28.07.21 06:36, Sandra Loosemore wrote: On 7/26/21 2:13 PM, Sandra Loosemore wrote: On 7/26/21 3:45 AM, Tobias Burnus wrote: PS: Still, it would be nice if the proper multi-lib ISO*.h could be found; (Example for x86-64-gnu-linux with 32bit and 64bit support) Namely

Re: [PATCH] PR fortrsn/101564 - ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

Hi Harald, On 27.07.21 23:42, Harald Anlauf wrote: This almost worked, needing only a restriction to %KIND and %LEN. Note that %RE and %IM are usually definable. Well spotted :-) Regtested on x86_64-pc-linux-gnu. OK? LGTM - except [...] feel free add them and commit without further review.

Re: [PATCH, Fortran] [PR libfortran/101310] Bind(c): Fix bugs in CFI_section

On 18.07.21 06:36, Sandra Loosemore wrote: This patch fixes bugs I observed in tests for the CFI_section function -- it turns out both the function and test cases had bugs. :-( The bugs in CFI_section itself had to do with incorrect computation of the base address for the result descriptor,

Re: [PATCH v2, Fortran] TS 29113 testsuite

Hi Sandra, hi Thomas, hi all, @Thomas K: Comments about the following - and of course to the testsuite itself - are highly welcome. In my opinion, the testsuite LGTM and can be committed. @Sandra: - Thoughts on the directory name? (cf. below) - Give others/Thomas a chance to comment on this,

Re: [r12-2511 Regression] FAIL: gfortran.dg/PR93963.f90 -Os execution test on Linux/x86_64

The automatic regression test of Sunil wrote: On 26.07.21 19:27, sunil.k.pandey wrote: commit 0cbf03689e3e7d9d6002b8e5d159ef3716d0404c PR fortran/93308/93963/94327/94331/97046 problems raised by descriptor handling caused FAIL: gfortran.dg/PR93963.f90 -O2 execution test ... (That's

Re: [PATCH] PR fortrsn/101564 - ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

Hi Harald, On 26.07.21 23:55, Harald Anlauf wrote: I've updated this for ALLOCATE/DEALLOCATE and STAT/ERRMSG, see attached patch. This required updating the error messages of two existing files in the testsuite. Thanks. Also affected: Some I/O items, a bunch of other stat=%v and errmsg=%v.

Committed: Re: [Patch, fortran V2] PR fortran/93308/93963/94327/94331/97046 problems raised by descriptor handling

:-) Thanks, Tobias PS: I wrote: On 22.06.21 09:11, Tobias Burnus wrote: On 21.06.21 22:29, Tobias Burnus wrote: However, that's independent from the patch you had submitted and which is fine except for the two tiny nits. As I just did run into a test, which does trigger the error, I think it would

Re: [PATCH 3/3] [PR libfortran/101305] Fix ISO_Fortran_binding.h paths in gfortran testsuite

Hi Sandra, On 23.07.21 22:43, Sandra Loosemore wrote: On 7/23/21 8:15 AM, Tobias Burnus wrote: On 21.07.21 12:17, Tobias Burnus wrote: On 13.07.21 23:28, Sandra Loosemore wrote: ISO_Fortran_binding.h is now generated in the libgfortran build directory where it is on the default include path

Re: Add f2008 to description

Hi Vivek, On 24.07.21 16:19, Vivek Rao via Fortran wrote: The gfortran page https://gcc.gnu.org/wiki/GFortran says, "Gfortran is the name of the GNU Fortran project, developing a free Fortran 95/2003/2008 compiler for GCC, the GNU Compiler Collection."  Since Fortran 2018 features are being

<    1   2   3   4   5   6   >