Re: [PATCH] gcc: middle-end opt for trigonometric pi-based functions builtins

On Fri, Jun 27, 2025 at 08:17:46AM +0200, Tobias Burnus wrote: > Hi Yuao, > > > Yuao Ma wrote: > > >//but the testcases don't seem to be conditionalized on this. Would the > > >//new tests fail if gcc is built against an insufficiently recent version > > >//of mpfr, > … > > The test case is indee

[Patch] Fortran/OpenACC: Permit PARAMETER as 'var' in clauses (+ ignore)

Background: In real-world code, one can find: !$ACC DECLARE COPYIN(c1es, c2es, ...) as here for the ICON weather model. This clearly implies that other compilers accept and, potentially, require those. For better compatibility with real-world use, the just released OpenACC 3.4 now permits PARAME

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/27/25 1:08 PM, Toon Moene wrote: On 6/27/25 17:41, Toon Moene wrote: Note: as the timeline at the top of the source implies, I have worked on this until early 2021. This means it compiled with gfortran 10 and 11. So the problem is probably introduced after these versions. [ Of course,

Re: [PATCH, part2] Fortran: follow-up fix to checking of renamed-on-use interface name [PR120784]

On 6/27/25 1:48 PM, Harald Anlauf wrote: Dear all, my original patch caused a regression on previously working code where an imported interface was *not* renamed-on-use, as the related new logic did not expect a local_name to be an empty string. Funnily, there was no previously existing test in

Re: [PATCH, part2] Fortran: follow-up fix to checking of renamed-on-use interface name [PR120784]

Am 27.06.25 um 22:57 schrieb Jerry D: On 6/27/25 1:48 PM, Harald Anlauf wrote: Dear all, my original patch caused a regression on previously working code where an imported interface was *not* renamed-on-use, as the related new logic did not expect a local_name to be an empty string. Funnily, t

[PATCH, part2] Fortran: follow-up fix to checking of renamed-on-use interface name [PR120784]

Dear all, my original patch caused a regression on previously working code where an imported interface was *not* renamed-on-use, as the related new logic did not expect a local_name to be an empty string. Funnily, there was no previously existing test in the testsuite... The attached fixes this

Re: [Fortran, Patch, PR120843, v1] Fix reject valid, because of inconformable coranks

I take this patch back. It seems to be incomplete. - Andre On Fri, 27 Jun 2025 14:45:36 +0200 Andre Vehreschild wrote: > Hi all, > > this patch fixes a reject valid when the coranks of two operands do not match > and no coindex is given. I.e. when only an implicit this_image co-ref is used. >

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/27/25 1:08 PM, Toon Moene wrote: On 6/27/25 17:41, Toon Moene wrote: Note: as the timeline at the top of the source implies, I have worked on this until early 2021. This means it compiled with gfortran 10 and 11. So the problem is probably introduced after these versions. [ Of course,

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/27/25 17:41, Toon Moene wrote: Note: as the timeline at the top of the source implies, I have worked on this until early 2021. This means it compiled with gfortran 10 and 11. So the problem is probably introduced after these versions. [ Of course, while I perused the Fortran 2018 standa

[Fortran, Patch, PR120843, v1] Fix reject valid, because of inconformable coranks

Hi all, this patch fixes a reject valid when the coranks of two operands do not match and no coindex is given. I.e. when only an implicit this_image co-ref is used. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot d

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Hi Jerry, I can not compile the example from Toon. I get two issues: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120843 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120847 Can you reproduce? - Andre On Thu, 26 Jun 2025 16:49:59 -0700 Jerry Delisle wrote: > Toon, thank you! I will give

[PATCH] gcc: middle-end opt for trigonometric pi-based functions builtins

Hi Jakub, > I think the __builtin_constant_p(acospi(0.5)) approach is usable, but would > be much better done on the lib/target-supports.exp side. > So, have foldable_pi_based_trigonometry effective target, which would test > if __builtin_constant_p(acospi(0.5)) is 1. Thanks again for your helpfu

Re: [PATCH] gcc: middle-end opt for trigonometric pi-based functions builtins

On Fri, Jun 27, 2025 at 03:04:35PM +, Yuao Ma wrote: > > I think the __builtin_constant_p(acospi(0.5)) approach is usable, but would > > be much better done on the lib/target-supports.exp side. > > So, have foldable_pi_based_trigonometry effective target, which would test > > if __builtin_const

[PATCH] gcc: middle-end opt for trigonometric pi-based functions builtins

Hi Jakub, > Please don't include math.h here. Done. > And instead of this line use __builtin_acospi (0.5). > and, in dejagnu for runtime tests we prefer __builtin_abort on failure, so Done. Yuao 0001-gcc-middle-end-opt-for-trigonometric-pi-based-functi.patch Description: 0001-gcc-middle-en

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

I am out of office at the moment. I do not get the ICE, but I did get errors about rank mismatching in four places. Jerry On Fri, Jun 27, 2025, 2:22 AM Andre Vehreschild wrote: > Hi Jerry, > > I can not compile the example from Toon. I get two issues: > > https://gcc.gnu.org/bugzilla/show_bug.c

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/27/25 17:33, Jerry Delisle wrote: I am out of office at the moment. I do not get the ICE, but I did get errors about rank mismatching in four places. Jerry On Fri, Jun 27, 2025, 2:22 AM Andre Vehreschild > wrote: Hi Jerry, I can not compile the example fro

Re: [PATCH] gcc: middle-end opt for trigonometric pi-based functions builtins

On Fri, Jun 27, 2025 at 03:38:32PM +, Yuao Ma wrote: > Hi Jakub, > > > Please don't include math.h here. > > Done. > > > And instead of this line use __builtin_acospi (0.5). > > and, in dejagnu for runtime tests we prefer __builtin_abort on failure, so > > Done. Oh, one more thing. signbit

[PATCH] gcc: middle-end opt for trigonometric pi-based functions builtins

Hi Jakub, > signbit is documented to be a macro, so please don't declare > int signbit (double); > function in the testcase and instead of signbit use __builtin_signbit. This is indeed my negligence. Done. If everything looks good, could you please help me merge this patch? Thank you! Yuao 0