Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

On Sun, 9 Feb 2025, 09:08 Thomas Koenig via Gcc, wrote: > Hello world, > > looking at a few Fortran bug reports, I found some cases where > it was not clear if the program in question was standard-conforming > or not. I would propose to add a keyword for that, tentatively > called "interp". > >

2/7 [Fortran, Patch, Coarray, PR107635] Prepare for more caf-rework.

[PATCH 2/7] Fortran: Prepare for more caf-rework. [PR107635] Factor out generation of code to get remote function index and to create the additional data structure. Rename caf_get_by_ct to caf_get_from_remote. gcc/fortran/ChangeLog: PR fortran/107635 * gfortran.texi: Rename caf

0/7 [Fortran, Patch, Coarray, PR107635] Implement call to remote side routine for caf

Hi all, this small series of patches adds/changes the way coarray access to data on remote images is done. Previously for more elaborate access pattern (e.g. an allocatable array in a derived type component stored in an array) the access was done by emulating Fortran's addressing in C. When using

6/7 [Fortran, Patch, Coarray, PR107635] Add transfer_between_remotes

[PATCH 6/7] Fortran: Add transfer_between_remotes [PR107635] Add the last missing coarray data manipulation routine using remote accessors. gcc/fortran/ChangeLog: PR fortran/107635 * gfortran.texi: Add documentation for transfer_between_remotes. * intrinsic.cc (add_subro

1/7 [Fortran, Patch, Coarray, PR107635] Move caf_get-rewrite to rewrite.cc

[PATCH 1/7] Fortran: Move caf_get-rewrite to rewrite.cc [PR107635] Add a rewriter to keep all expression tree manipulation that is not optimization together. At the moment this is just a move from resolve.cc, but will be extended to handle more cases where rewriting the expression tree may be eas

4/7 [Fortran, Patch, Coarray, PR107635] Add caf_is_present_on_remote.

[PATCH 4/7] Fortran: Add caf_is_present_on_remote. [PR107635] Replace caf_is_present by caf_is_present_on_remote which is using a dedicated callback for each object to test on the remote image. gcc/fortran/ChangeLog: PR fortran/107635 * gfortran.h (enum gfc_isym_id): Add caf_is_

3/7 [Fortran, Patch, Coarray, PR107635] Allow to use non-pure/non-elemental functions in coarray indexes

[PATCH 3/7] Fortran: Allow to use non-pure/non-elemental functions in coarray indexes [PR107635] Extract calls to non-pure or non-elemental functions from index expressions on a coarray. gcc/fortran/ChangeLog: PR fortran/107635 * rewrite.cc (get_arrayspec_from_expr): Treat arra

5/7 [Fortran, Patch, Coarray, PR107635] Add send_to_remote

[PATCH 5/7] Fortran: Add send_to_remote [PR107635] Refactor to use send_to_remote instead of the slow send_by_ref. gcc/fortran/ChangeLog: PR fortran/107635 * gfortran.h (enum gfc_isym_id): Add SENDGET-isym. * gfortran.texi: Add documentation for send_to_remote. *

[PATCH] Fortran: checking of pointer targets for structure constructors [PR56423]

Dear all, the attached patch enhances the checking of pointer targets in structure constructors to catch the following invalid cases (before we ICE :) - different rank - vector subscript of target Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald From 118a6c3247bb30ef932341cec

Re: [PATCH] Fortran: checking of pointer targets for structure constructors [PR56423]

Hello Harld, the attached patch enhances the checking of pointer targets in structure constructors to catch the following invalid cases (before we ICE :) - different rank - vector subscript of target Regtested on x86_64-pc-linux-gnu.  OK for mainline? OK (and bordering on obvious). Thanks fo

Re: [PATCH] Fortran: checking of pointer targets for structure constructors [PR56423]

Hi Thomas, Am 10.02.25 um 20:26 schrieb Thomas Koenig: Hello Harld, the attached patch enhances the checking of pointer targets in structure constructors to catch the following invalid cases (before we ICE :) - different rank - vector subscript of target Regtested on x86_64-pc-linux-gnu.  OK

Re: [Patch, Fortran] Fix PR 24878, checking actual arguments against global symbols

Am 09.02.25 um 20:24 schrieb Jerry D: "Type mismatch at %L when passing global function %qs "  "declared at %L (%s/%s)" Committed as r15-7460-gd2ff1b78d70731db1b7adc1cbac7e44688828370 . Thanks for the help with the wording! Best regards Thomas

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

On Mon, 2025-02-10 at 09:29 +, Jonathan Wakely via Gcc wrote: > On Sun, 9 Feb 2025, 09:08 Thomas Koenig via Gcc, > wrote: > > > Hello world, > > > > looking at a few Fortran bug reports, I found some cases where > > it was not clear if the program in question was standard-conforming > > or n

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Am 10.02.25 um 21:05 schrieb David Malcolm: FWIW my first thought for "interp" was that we gaining an interpreter (there are some in the libgccjit test suite). It was motivated by Fortran interps, which are interpretation requrests. But I think that Richard's suggestion, neeeds-stdcheck, makes

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Am 10.02.25 um 08:43 schrieb Richard Biener: We have need-bisection and other need-, so iff then maybe a need-stdchk for cases compliance is unclear? That sounds very good to me; if there are no objections, I will create this in a day or so. The fact that a testcase is (non-)compliant is also

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

Hi! On 2025-02-10T20:59:43+0100, Thomas Koenig wrote: > Am 10.02.25 um 08:43 schrieb Richard Biener: >> We have need-bisection and other need-, so iff then maybe a need-stdchk for >> cases compliance is unclear? > > That sounds very good to me; if there are no objections, I will create > this in