Re: [Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device

On 14 October 2024 10:23:56 CEST, Thomas Schwinge wrote: >Hi Tobias! > >On 2024-10-13T10:21:01+0200, Tobias Burnus wrote: >> Now pushed as r15-4298-g3269a722b7a036. > >> Tobias Burnus wrote: >>> Anyone feeling like reviewing this patch? > >Yes. But please allow for more than 1 1/2 work days. >

Re: Fortran test typebound_operator_7.f03 broken by non-Fortran commit. Confirm anyone?

On 14 October 2024 14:05:36 CEST, Andre Vehreschild wrote: >Hi all, > >please note, that I don't know this bisecting very well, so this may very well >be a wrong blame. During latest regression testing of the Fortran suite I got >typebound_operator_7.f03 failing with: > > >03623fa91ff36ecb9faa3b5

Re: Fortran test typebound_operator_7.f03 broken by non-Fortran commit. Confirm anyone?

Sam James writes: > Andre Vehreschild writes: > >> Hi all, >> >> please note, that I don't know this bisecting very well, so this may very >> well >> be a wrong blame. During latest regression testing of the Fortran suite I got >> typebound_operator_7.f03 failing with: >> >> typebound_operator_

Re: Fortran test typebound_operator_7.f03 broken by non-Fortran commit. Confirm anyone?

Andre Vehreschild writes: > Hi all, > > please note, that I don't know this bisecting very well, so this may very well > be a wrong blame. During latest regression testing of the Fortran suite I got > typebound_operator_7.f03 failing with: > > typebound_operator_7.f03:94:25: > >94 | u = (u*

OpenACC 'nohost' clause: harmonize 'libgomp.oacc-{c-c++-common,fortran}/routine-nohost-1.*'

Hi! On 2021-07-22T00:20:13+0200, I wrote: > [...], I've now pushed "OpenACC 'nohost' clause" to > master branch in commit a61f6afbee370785cf091fe46e2e022748528307, [...] Via Tobias' recent commit 3269a722b7a03613e9c4e2862bc5088c4a17cc11 "Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP'

[PATCH 7/7] fortran: Evaluate once BACK argument of MINLOC/MAXLOC with DIM [PR90608]

From: Mikael Morin Bootstrapped and regression-tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- Evaluate the BACK argument of MINLOC/MAXLOC once before the scalarization loops in the case where the DIM argument is present. This is a follow-up to r15-1994-ga55d24b3cf7f4d07492bb8e6fcee5571

[PATCH 5/7] fortran: Inline non-character MINLOC/MAXLOC with DIM [PR90608]

From: Mikael Morin Bootstrapped and regression-tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- Enable generation of inline MINLOC/MAXLOC code in the cases where DIM is a constant, and either ARRAY is of REAL type or MASK is an array. Those cases are the remaining bits to fully support i

[PATCH 3/7] fortran: Inline MINLOC/MAXLOC with DIM and scalar MASK [PR90608]

From: Mikael Morin Bootstrapped and regression-tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- Enable the generation of inline code for MINLOC/MAXLOC when argument ARRAY is of integral type and has rank > 1, DIM is a constant, and MASK is scalar (only absent MASK or rank 1 ARRAY were inl

[PATCH 4/7] fortran: Check MASK directly instead of its scalarization chain

From: Mikael Morin Bootstrapped and regression-tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- Update the conditions used by the inline MINLOC/MAXLOC code generation function to check directly the properties of MASK instead of the variable holding its scalarization chain. The inline imp

[PATCH 6/7] fortran: Check for empty MINLOC/MAXLOC ARRAY along DIM only

From: Mikael Morin Bootstrapped and regression-tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- In the function generating inline code to implement MINLOC and MAXLOC, only check for ARRAY size along DIM if DIM is present. The check for ARRAY emptyness had been checking the size of the fu

[PATCH 1/7] fortran: Add tests covering inline MINLOC/MAXLOC with DIM [PR90608]

From: Mikael Morin Checked on x86_64-pc-linux-gnu. OK for master? -- >8 -- Add the tests covering the cases for which the following patches will implement inline expansion of MINLOC and MAXLOC. Those are cases where the DIM argument is a constant value, and the ARRAY argument has rank greater

[PATCH 2/7] fortran: Inline unmasked integral MINLOC/MAXLOC with DIM [PR90608]

From: Mikael Morin Bootstrapped and regression-tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- Enable generation of inline code for the MINLOC and MAXLOC intrinsics, if the ARRAY argument is of integral type and of rank > 1 (only the rank 1 case was previously inlined), the DIM argument

[PATCH 0/7] fortran: Inline MINLOC/MAXLOC with DIM [PR90608]

From: Mikael Morin Hello, this is the second (and last) series of patches to inline MINLOC and MAXLOC. The previous series added support for inlining without DIM. This one focuses on the cases where the DIM argument is present (and is a constant), using the existing support for reduction funct

Re: [Ping*4, Patch, Fortran, 77871, v1] Allow for class typed coarray parameter as dummy [PR77871]

Hi Paul, thank you for the review. Committed as: gcc-15-4329-gfd1a2f63bca No problem. I will persist :-) - Regards, Andre On Mon, 14 Oct 2024 11:27:58 +0100 Paul Richard Thomas wrote: > Hi Andre, > > This looks fine to me. OK for mainline. > > Thanks for the patch and sorry for the wa

Fortran test typebound_operator_7.f03 broken by non-Fortran commit. Confirm anyone?

Hi all, please note, that I don't know this bisecting very well, so this may very well be a wrong blame. During latest regression testing of the Fortran suite I got typebound_operator_7.f03 failing with: typebound_operator_7.f03:94:25: 94 | u = (u*2.0*4.0) + u*4.0 |

Re: [Ping*4, Patch, Fortran, 77871, v1] Allow for class typed coarray parameter as dummy [PR77871]

Hi Andre, This looks fine to me. OK for mainline. Thanks for the patch and sorry for the wait for review. Paul On Mon, 14 Oct 2024 at 08:50, Andre Vehreschild wrote: > Ping ^ 4. > > Really no one to review this 160 something patch? > > Regtests ok on x86_64-pc-linux-gnu /Fedora 39? Ok for ma

Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device: Revert 'gimple_fold_builtin_acc_on_device' change

Hi! On 2024-10-14T10:23:56+0200, I wrote: > On 2024-10-13T10:21:01+0200, Tobias Burnus wrote: >> Now pushed as r15-4298-g3269a722b7a036. > * (new) For OpenACC, use a builtin for acc_on_device + actually do > compile-time optimization when offloading is not configured. > > No. 2. This r

Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device: Harmonize 'libgomp.oacc-fortran/acc_on_device-1-*'

Hi! On 2024-10-14T10:23:56+0200, I wrote: > On 2024-10-13T10:21:01+0200, Tobias Burnus wrote: >> Now pushed as r15-4298-g3269a722b7a036. >> --- a/libgomp/testsuite/libgomp.oacc-fortran/acc_on_device-1-1.f90 >> +++ b/libgomp/testsuite/libgomp.oacc-fortran/acc_on_device-1-1.f90 >> -! TODO: Have t

Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device: Fix effective-target keyword in 'libgomp.oacc-fortran/acc_on_device-2.f90'

Hi! On 2024-10-14T10:23:56+0200, I wrote: > On 2024-10-13T10:21:01+0200, Tobias Burnus wrote: >> Now pushed as r15-4298-g3269a722b7a036. > Tested on x86-64 without and with offloading configured, running > with nvptx offloading. I see an UNRESOLVED: +PASS: libgomp.oacc-fortran/acc

Re: [Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device

Hi Tobias! On 2024-10-13T10:21:01+0200, Tobias Burnus wrote: > Now pushed as r15-4298-g3269a722b7a036. > Tobias Burnus wrote: >> Anyone feeling like reviewing this patch? Yes. But please allow for more than 1 1/2 work days. >> Tobias Burnus write: >>> Tobias Burnus wrote: Sometimes waiti

Re: [Ping*4, Patch, Fortran, 77871, v1] Allow for class typed coarray parameter as dummy [PR77871]

Ping ^ 4. Really no one to review this 160 something patch? Regtests ok on x86_64-pc-linux-gnu /Fedora 39? Ok for mainline? - Andre On Mon, 7 Oct 2024 12:52:29 +0200 Andre Vehreschild wrote: > Hi all, > > this patch somehow slipped my attention. Anyone for a review? Third time ping! > > Rebas