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

2025-06-23 Thread Richard Biener
On Sat, Jun 7, 2025 at 3:56 PM Yuao Ma wrote: > > Hi all, > > This patch has been updated to conditionally fold the specified math functions > only when using MPFR version 4.2.0 or newer. > > To accompany this change, the test case now utilizes `__builtin_constant_p` to > determine whether to exec

Re: Help my confusion with march/mtune and AMD/Intel

2025-06-23 Thread Richard Biener
On Sun, Jun 22, 2025 at 10:24 PM Thompson, Matt (GSFC-610.1)[SCIENCE SYSTEMS AND APPLICATIONS INC] wrote: > All, > > > > I'm currently a bit confused and I'm hoping the gfortran gurus can help. > > > > To wit, I have a code on a system with both AMD EPYC (Milan) and Intel > Cascade Lake nodes. Th

Re: GNU Fortran Compiler

2025-06-23 Thread Paul Richard Thomas
Hello Rich, This list is devoted to the development and maintenance of gfortran. Please refer to the gfortran wiki https://gcc.gnu.org/wiki/GFortran for the information that you require. Please note that most Linux distributions offer up to date gfortran; eg. Fedora 42 has the latest release versi

Re: [PATCH] fortran: Mention user variable in SELECT TYPE temporary variable names

2025-06-23 Thread Harald Anlauf
Hi Mikael! Am 23.06.25 um 19:51 schrieb Mikael Morin: Le 22/06/2025 à 21:09, Harald Anlauf a écrit : Hi Mikael! Am 20.06.25 um 12:08 schrieb Mikael Morin: From: Mikael Morin   Regression-tested on x86_64-pc-linux-gnu.   Ok for master? -- >8 -- The temporary variables that are generated to

[PATCH] Fortran: fix checking of renamed-on-use interface name [PR120784]

2025-06-23 Thread Harald Anlauf
Dear all, here's an obvious fix for a rejects-valid when an interface was renamed on use and is extended in the importing module. One check incorrectly referred to the original interface name, not the renamed one. Regtested on x86_64-pc-linux-gnu. OK for mainline / backports? Thanks, Harald

GNU Fortran Compiler

2025-06-23 Thread Rich Cao
Dear GNU Family: Could you please provide a link to download GNU Fortran Compiler for Fortran 90/95 on Windows platform and Linux platform? Sincerely, Rich Cao

[Patch, fortran] PR106135 - Implement F2018 IMPORT statements

2025-06-23 Thread Paul Richard Thomas
Hello All, I was mulling over the F2018 status of gfortran, when I came across the additions to the IMPORT statement. This seemed like such a useful addition to fortran that I set about an implementation; thinking that this would be low hanging fruit. Parsing and checking the constraints C897-8100

Re: [Patch, fortran] PR106135 - Implement F2018 IMPORT statements

2025-06-23 Thread Jerry D
On 6/23/25 9:43 AM, Paul Richard Thomas wrote: Hello All, I was mulling over the F2018 status of gfortran, when I came across the additions to the IMPORT statement. This seemed like such a useful addition to fortran that I set about an implementation; thinking that this would be low hanging f

Re: [PATCH] fortran: Mention user variable in SELECT TYPE temporary variable names

2025-06-23 Thread Mikael Morin
Le 22/06/2025 à 21:09, Harald Anlauf a écrit : Hi Mikael! Am 20.06.25 um 12:08 schrieb Mikael Morin: From: Mikael Morin   Regression-tested on x86_64-pc-linux-gnu.   Ok for master? -- >8 -- The temporary variables that are generated to implement SELECT TYPE and TYPE IS statements have (befo

[committed] OpenACC: Add 'if' clause to 'acc wait' directive

2025-06-23 Thread Tobias Burnus
This simple patch adds the 'if' clause to 'acc wait'. while OpenACC 3.0 also added it to the init, shutdown and set directive this patch only handles 'acc wait' as that's used in the ICON code. Committed as Rev. r16-1634-g2b077252cafa50 Tobias commit 2b077252cafa5045498a0e0c480ee6d48c136232 Auth

[Patch] Fortran/OpenACC: Add Fortran support for acc_attach/acc_detach

2025-06-23 Thread Tobias Burnus
This patch adds the OpenACC routines acc_attach and acc_detach. However, in order to avoid the generation of a temporary, which breaks this feature, a special case had to be added to gfc_trans_call. Otherwise, I think it completes the Fortran additions of existing C/C++ functions, by adding this

Re: [PATCH] Fortran: fix checking of renamed-on-use interface name [PR120784]

2025-06-23 Thread Jerry D
On 6/23/25 12:39 PM, Harald Anlauf wrote: Dear all, here's an obvious fix for a rejects-valid when an interface was renamed on use and is extended in the importing module.  One check incorrectly referred to the original interface name, not the renamed one. Regtested on x86_64-pc-linux-gnu.  OK

Re: [PATCH] Fortran: fix checking of renamed-on-use interface name [PR120784]

2025-06-23 Thread Harald Anlauf
Am 23.06.25 um 22:33 schrieb Jerry D: On 6/23/25 12:39 PM, Harald Anlauf wrote: Dear all, here's an obvious fix for a rejects-valid when an interface was renamed on use and is extended in the importing module.  One check incorrectly referred to the original interface name, not the renamed one.

[PATCH] gcc: remove atan from edom_only_function

2025-06-23 Thread Yuao Ma
Hi all, This patch addresses previous review feedback by splitting the atan handling into a separate patch. This patch is part of https://gcc.gnu.org/pipermail/fortran/attachments/20250607/4a4a9cb6/attachment.obj Please take a look when you are available. Thanks! Best regards, Yuao 0001-gcc-