Re: [Fortran, Patch, PR86468, v1] Follow up: Remove obsolete VIEW_CONVERT

Hi Steve, thanks for the ok. Committed as gcc-15-3099-g0636de8c520 Thanks again, Andre On Wed, 21 Aug 2024 09:31:55 -0700 Steve Kargl wrote: > On Wed, Aug 21, 2024 at 12:17:46PM +0200, Andre Vehreschild wrote: > > > > attached small patch removes a VIEW_CONVERT that I erroneously inser

[pushed] fortran: Minor fix to -ffrontend-optimize description (was: typo on homepage)

On Mon, 8 Apr 2024, Johannes Nendwich via Gcc wrote: > on https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html > there is at the end the part > >-ffrontend-optimize > >This option performs front-end optimization, based on manipulating > parts the Fortran parse tree. > > Migh

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

Hi Tobias, I just had a short look at your PR. Besides that it did not git-am for me (see below), I have only one question (see also below). Please note, that I have only user-level experience in OpenMP and can say nothing about completeness or soundness of your PR. I hope that a first check on ov

[PATCH v3 00/10] fortran: Inline MINLOC/MAXLOC without DIM argument [PR90608]

From: Mikael Morin Hello, this is the third version of the inline MINLOC/MAXLOC without DIM patchset whose second version was posted before at: https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660599.html Compared to the previous version, it contains a change of wording of the documentatio

[PATCH v3 02/10] fortran: Disable frontend passes for inlinable MINLOC/MAXLOC [PR90608]

From: Mikael Morin Disable rewriting of MINLOC/MAXLOC expressions for which inline code generation is supported. Update the gfc_inline_intrinsic_function_p predicate (already existing) for that, with the current state of MINLOC/MAXLOC inlining support, that is only the cases of a scalar result a

[PATCH v3 04/10] fortran: Remove MINLOC/MAXLOC frontend optimization

From: Mikael Morin Remove the frontend pass rewriting calls of MINLOC/MAXLOC without DIM to calls with one-valued DIM enclosed in an array constructor. This transformation was circumventing the limitation of inline MINLOC/MAXLOC code generation to scalar cases only, allowing inline code to be ge

[PATCH v3 08/10] fortran: Inline non-character MINLOC/MAXLOC with no DIM [PR90608]

From: Mikael Morin Enable generation of inline MINLOC/MAXLOC code in the case where DIM is not present, and either ARRAY is of floating point type or MASK is an array. Those cases are the remaining bits to fully support inlining of non-CHARACTER MINLOC/MAXLOC without DIM. They are treated toget

[PATCH v3 03/10] fortran: Inline MINLOC/MAXLOC with no DIM and ARRAY of rank 1 [PR90608]

From: Mikael Morin Enable inline code generation for the MINLOC and MAXLOC intrinsic, if the DIM argument is not present and ARRAY has rank 1. This case is similar to the case where the result is scalar (DIM present and rank 1 ARRAY), which already supports inline expansion of the intrinsic. Bo

[PATCH v3 06/10] fortran: Inline integral MINLOC/MAXLOC with no DIM and no MASK [PR90608]

From: Mikael Morin Enable generation of inline code for the MINLOC and MAXLOC intrinsic, if the ARRAY argument is of integral type and of any rank (only the rank 1 case was previously inlined), and neither DIM nor MASK arguments are present. This needs a few adjustments in gfc_conv_intrinsic_min

[PATCH v3 07/10] fortran: Inline integral MINLOC/MAXLOC with no DIM and scalar MASK [PR90608]

From: Mikael Morin Enable the generation of inline code for MINLOC/MAXLOC when argument ARRAY is of integral type, DIM is not present, and MASK is present and is scalar (only absent MASK or rank 1 ARRAY were inlined before). Scalar masks are implemented with a wrapping condition around the code

[PATCH v3 01/10] fortran: Add tests covering inline MINLOC/MAXLOC without DIM [PR90608]

From: Mikael Morin Add the tests covering the various cases for which we are about to implement inline expansion of MINLOC and MAXLOC. Those are cases where the DIM argument is not present. PR fortran/90608 gcc/testsuite/ChangeLog: * gfortran.dg/ieee/maxloc_nan_1.f90: New test

[PATCH v3 05/10] fortran: Outline array bound check generation code

From: Mikael Morin The next patch will need reindenting of the array bound check generation code. This outlines it to its own function beforehand, reducing the churn in the next patch. -- >8 -- gcc/fortran/ChangeLog: * trans-array.cc (gfc_conv_ss_startstride): Move array bound check

[PATCH v3 09/10] fortran: Continue MINLOC/MAXLOC second loop where the first stopped [PR90608]

From: Mikael Morin Continue the second set of loops where the first one stopped in the generated inline MINLOC/MAXLOC code in the cases where the generated code contains two sets of loops. This fixes a regression that was introduced when enabling the generation of inline MINLOC/MAXLOC code with

[PATCH v3 10/10] fortran: Add -finline-intrinsics flag for MINLOC/MAXLOC [PR90608]

From: Mikael Morin The documentation in this patch was partly reworded, compared to the previous version posted at: https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660607.html The rest of the patch is unchanged, just rebased to a more recent master. Joseph is in CC as I need a ack for the

[Fortran, Patch, PR85002, v1] Fix deep-copy of alloc. comps. in coarrays ICEing and crashing w/ lib.

Hi all, attached patch fixes an ICE during trans-phase when allocatable components in derived typed coarrays were nested. I am nearly convinced, that the ICE is mostly fixed by pr86468, because I get a slightly different ICE. Nevertheless was the executable crashing with -fcoarray=lib because the

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

Oh, and I get compile errors: /mnt/work_store/gcc/gcc.test/libgomp/target.c: In function 'omp_get_interop_type_desc': /mnt/work_store/gcc/gcc.test/libgomp/target.c:5179:30: error: excess elements in scalar initializer [-Werror] 5179 | "const char*", /* fr_name *

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

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

Fwd: [Bug fortran/116261] [15 regression] gfortran.dg/sizeof_6.f90 -O1 timeout since r15-2739-g4cb07a38233

Hi All, Since the patch for PR102689 was committed, sporadic time outs at -O1 have been recorded and so I have reverted the patch. This is a bit awkward because I have yet to see the problem. However, I will endeavour to understand what went wrong. Paul -- Forwarded message - Fr