gfortran-dev branch, how to re-establish

Hi all, Quite a few years ago I created a gfortran-dev branch that I could keep up to date with trunk by merging periodically. It is still listed in the gcc website documentation. I tried to follow the instructions in there to create a new branch. The purpose is so we can expand on

Re: [RFC] Add multi-attributes syntax to future `target_clones` in GFortran

ity who is very interested in > C language and GCC development. I am currently adding multi-versioning > support to GFortran. Specifically, I am adding `target` and `target_clones` > support at the function and subroutine level for the Fortran language. > > Since Fortran does not support as ma

[PATCH 07/17] gfortran: Avoid freeing uninitialized value

Hi, When compiling fortran/match.cc, clang emits a warning fortran/match.cc:5301:7: warning: variable 'p' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] which looks accurate, so this patch adds an initialization of p to avoid the use. Bootstrapped and teste

Re: [PATCH 07/17] gfortran: Avoid freeing uninitialized value

On Wed, Jun 25, 2025 at 04:09:26PM +0200, Martin Jambor wrote: > Hi, > > When compiling fortran/match.cc, clang emits a warning > > fortran/match.cc:5301:7: warning: variable 'p' is used uninitialized > whenever 'if' condition is true [-Wsometimes-uninitialized] > > which looks accurate, so t

Re: Execution time for gfortran regression testing

On 6/13/25 11:20 PM, Paul Richard Thomas wrote: Hi Jerry, I have an octave script that does that. I last used it when I was working on ASSOCIATE. I'll dig it out and send it to you. Regards Paul Thanks Paul, I will have a look. I was thinking to use Python since many other scripts in con

Re: Execution time for gfortran regression testing

um 20:37 > >> Von: "Jerry D" > >> An: "Mikael Morin" , "Harald Anlauf" < > anl...@gmx.de>, fortran@gcc.gnu.org > >> Betreff: Re: Execution time for gfortran regression testing > >> > >> On 6/3/25 3:02 AM, Mikael Morin

Re: Execution time for gfortran regression testing

On 6/10/25 1:55 PM, Harald Anlauf wrote: Gesendet: Mittwoch, 4. Juni 2025 um 20:37 Von: "Jerry D" An: "Mikael Morin" , "Harald Anlauf" , fortran@gcc.gnu.org Betreff: Re: Execution time for gfortran regression testing On 6/3/25 3:02 AM, Mikael Morin wrote: The b

Re: Execution time for gfortran regression testing

> Gesendet: Mittwoch, 4. Juni 2025 um 20:37 > Von: "Jerry D" > An: "Mikael Morin" , "Harald Anlauf" , > fortran@gcc.gnu.org > Betreff: Re: Execution time for gfortran regression testing > > On 6/3/25 3:02 AM, Mikael Morin wrote: > > The

Re: Execution time for gfortran regression testing

On 6/3/25 3:02 AM, Mikael Morin wrote: Le 30/05/2025 à 22:28, Harald Anlauf a écrit : When I'm working on a particular area of gfortran, I tend to use RUNTESTFLAGS to limit what is tested.  For example, I just fixed SPREAD() for scalar source and ncopies < 1. I do % cd obj % gmake

Re: Execution time for gfortran regression testing

Le 30/05/2025 à 22:28, Harald Anlauf a écrit : When I'm working on a particular area of gfortran, I tend to use RUNTESTFLAGS to limit what is tested.  For example, I just fixed SPREAD() for scalar source and ncopies < 1. I do % cd obj % gmake % cd gcc % gmake check-fortran RUNTESTFLAGS

Re: Execution time for gfortran regression testing

You could possibly modify the dg.exp file. These are basically scripts. It's a bit of a pain. On Fri, May 30, 2025, 1:29 PM Harald Anlauf wrote: > > When I'm working on a particular area of gfortran, I tend > > to use RUNTESTFLAGS to limit what is tested. For example, &

Re: Execution time for gfortran regression testing

When I'm working on a particular area of gfortran, I tend to use RUNTESTFLAGS to limit what is tested.  For example, I just fixed SPREAD() for scalar source and ncopies < 1. I do % cd obj % gmake % cd gcc % gmake check-fortran RUNTESTFLAGS="dg.exp=spread\*.f90" This only

Re: Execution time for gfortran regression testing

On Fri, May 30, 2025 at 09:03:27PM +0200, Harald Anlauf wrote: > > the time needed for running the gfortran testsuite has increased so > much that I am looking for options to get this down to something > that is more bearable when working on a Fortran-only patch. > > I am alr

Execution time for gfortran regression testing

Dear all, the time needed for running the gfortran testsuite has increased so much that I am looking for options to get this down to something that is more bearable when working on a Fortran-only patch. I am already building with --disable-bootstrap, as I cannot afford a full bootstrap. It is

Re: possible gfortran bug

On 5/21/25 6:46 PM, George Rinker wrote: When I run gfortran (13.1.0 installed 2023/08/20.17:50) from cmd.exe on a source.f that generates a compiler error, I get a message listing the first error line and column in normal text, then subsequent messages in a different color, and then it hangs

possible gfortran bug

When I run gfortran (13.1.0 installed 2023/08/20.17:50) from cmd.exe on a source.f that generates a compiler error, I get a message listing the first error line and column in normal text, then subsequent messages in a different color, and then it hangs and doesn't respond to any keyboard

Re: aarch64-w64-mingw32-gfortran: just checking

On Mon, May 12, 2025 at 6:49 PM Iain Sandoe wrote: > > > On 12 May 2025, at 17:20, Allin Cottrell wrote: > > > > If gcc 15.1.0 is built as a cross compiler from Linux x86_64 to > > aarch64-w64-mingw32, is it expected that gfortran will work? I doubt > > it, since

Re: aarch64-w64-mingw32-gfortran: just checking

> On 12 May 2025, at 17:20, Allin Cottrell wrote: > > If gcc 15.1.0 is built as a cross compiler from Linux x86_64 to > aarch64-w64-mingw32, is it expected that gfortran will work? I doubt > it, since fortran support is not mentioned in the context of the > AArch64 Min

aarch64-w64-mingw32-gfortran: just checking

If gcc 15.1.0 is built as a cross compiler from Linux x86_64 to aarch64-w64-mingw32, is it expected that gfortran will work? I doubt it, since fortran support is not mentioned in the context of the AArch64 MinGW target at https://gcc.gnu.org/gcc-15/changes.html (only C and C++) but I just wanted

Re: F2008 and F2018 statuses on gfortran wiki

On 4/13/25 12:48 AM, Paul Richard Thomas wrote: Hi All, Recently a lot of work has been done on the "partial" or "no"s in the F2008 and F2018 implementation statuses. Please send me updates and I will do the editing in time for the gcc-15 release. Thanks Paul Andre has a good chunk of th

F2008 and F2018 statuses on gfortran wiki

Hi All, Recently a lot of work has been done on the "partial" or "no"s in the F2008 and F2018 implementation statuses. Please send me updates and I will do the editing in time for the gcc-15 release. Thanks Paul

Re: Is ASSOCIATE implemented correctly in gfortran?

Hi Mikael, thanks for your input. Meanwhile I checked the compiler explorer https://godbolt.org/z/Ehbjefzab and got an in-decided picture of what could be the way to go. First of all, most of the compilers in compiler explorer are gfortran for different architectures. So I ignored them. I used

Re: Is ASSOCIATE implemented correctly in gfortran?

Hi Andre and Mikael, The associate block is added *after* the associate statement is matched and the associate_names added to the parent namespace; see parse.cc(parse_associate). nagfor and flang-new both behave in the same way as gfortran. So ifort and ifx are the odd ones out. In F2018 and

Re: Is ASSOCIATE implemented correctly in gfortran?

Hello, Le 08/04/2025 à 15:29, Andre Vehreschild a écrit : Hi all, while working at teams stuff I encountered some issue with the ASSOCIATE statement: 1. First of all: It does not open its namespace as it is expected to. I.e. the associate-name (referring to the term as used in F2018 11.1.3.1 R

Is ASSOCIATE implemented correctly in gfortran?

Hi all, while working at teams stuff I encountered some issue with the ASSOCIATE statement: 1. First of all: It does not open its namespace as it is expected to. I.e. the associate-name (referring to the term as used in F2018 11.1.3.1 R1104) is put into the parent namespace/scope and not into its

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

On 3/10/25 1:08 AM, Andre Vehreschild wrote: Hi Steve and Jerry, thanks for the review and the proposed changes. I have based on them, but needed to adapt some places, because the meaning was changed. Can you please take another look? Jerry, where do I find this check-script? In bin/ nothing ju

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

On 3/10/25 9:57 AM, Jerry D wrote: On 3/10/25 1:08 AM, Andre Vehreschild wrote: Hi Steve and Jerry, thanks for the review and the proposed changes. I have based on them, but needed to adapt some places, because the meaning was changed. Can you please take another look? Jerry, where do I find

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

Hi Jerry, thanks for the review. Committed as 87c7db8b1b2c1484d6de3331098669735d33f95e. I also had it checked using the W3C validator w/o any errors. Therefore committed. Thanks again, Andre On Mon, 10 Mar 2025 10:01:46 -0700 Jerry D wrote: > On 3/10/25 9:57 AM, Jerry D wrote: > > On

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

Hi Steve and Jerry, thanks for the review and the proposed changes. I have based on them, but needed to adapt some places, because the meaning was changed. Can you please take another look? Jerry, where do I find this check-script? In bin/ nothing jumps out at me to be a check-script. Thanks,

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

On 3/6/25 10:02 AM, Steve Kargl wrote: Andre, Here's a bit of wordsmith. I removed the abbreviation "Esp." I'm not sure if there is additional markup needed; especially, with the "-fcoarray=single" I inserted. Coarray support has been reworked to allow access to components in derived typ

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

Andre, Here's a bit of wordsmith. I removed the abbreviation "Esp." I'm not sure if there is additional markup needed; especially, with the "-fcoarray=single" I inserted. Coarray support has been reworked to allow access to components in derived types that have not been compiled with coarray

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

PING! On Thu, 20 Feb 2025 10:54:30 +0100 Andre Vehreschild wrote: > Hi all, > > attached patch makes an attempt to announce the ABI-changes in the coarrays > library. Me being German always has difficulties to find a proper wording. So > please propose improvements. > > Stupid question: How to I

Re: DLL with gfortran open statement crashes Excel

On 2/25/25 11:41 AM, Jürgen Bausa wrote: In the meantime I found out what is causing the problem. There seems to be a bug in the connection from gfortran to UCRT (Microsofts universal C runtime, that ships with Windows 10 and 11). If I switch to a compiler that uses MSVCRT (Microsoft Visual C

Re: DLL with gfortran open statement crashes Excel

In the meantime I found out what is causing the problem. There seems to be a bug in the connection from gfortran to UCRT (Microsofts universal C runtime, that ships with Windows 10 and 11). If I switch to a compiler that uses MSVCRT (Microsoft Visual C runtime, an older library, but still

[Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

Hi all, attached patch makes an attempt to announce the ABI-changes in the coarrays library. Me being German always has difficulties to find a proper wording. So please propose improvements. Stupid question: How to I test this? The change looks good in my browser. Is there a style checker, I don'

DLL with gfortran open statement crashes Excel

- gcc -march=native -fno-diagnostics-color -Wall -c -o dlltest2.o dlltest2.c gfortran -march=native -fno-diagnostics-color -Wall -c f77open.f gcc -march=native -fno-diagnostics-color -shared -Wl,--add-stdcall-alias dlltest2.o f77open.o -o dlltest2.dll -lgfortran Regards, Juergen

Re: [patch, fortran] PR117430 gfortran allows type(C_ptr) in I/O list

itself is trivial so I will wait a day or so for any other comments. Thanks for feedback. Jerry Committed after adjusting the test cases. commit r15-7569-g12771b Author: Jerry DeLisle Date: Thu Feb 13 20:19:56 2025 -0800 Fortran: gfortran allows type(C_ptr) in I/O list Before

Re: [patch, fortran] PR117430 gfortran allows type(C_ptr) in I/O list

09e4..834570cb74d 100644 --- a/gcc/testsuite/gfortran.dg/c_ptr_tests_10.f03 +++ b/gcc/testsuite/gfortran.dg/c_ptr_tests_10.f03 @@ -1,5 +1,4 @@  ! { dg-do run } -! { dg-options "-std=gnu" }  ! This test case exists because gfortran had an error in converting the  ! expressions for the

Re: [patch, fortran] PR117430 gfortran allows type(C_ptr) in I/O list

sts_10.f03 +++ b/gcc/testsuite/gfortran.dg/c_ptr_tests_10.f03 @@ -1,5 +1,4 @@ ! { dg-do run } -! { dg-options "-std=gnu" } ! This test case exists because gfortran had an error in converting the ! expressions for the derived types from iso_c_binding in some cases. module c_ptr_tests_

[patch, fortran] PR117430 gfortran allows type(C_ptr) in I/O list

The attached patch is fairly obvious. The use of notify_std is changed to a gfc_error. Several test cases had to be adjusted. Regression tested on x86_64. OK for trunk? Regards, Jerry Author: Jerry DeLisle Date: Tue Feb 11 20:57:50 2025 -0800 Fortran: gfortran allows type(C_ptr

Re: gfortran not following deferred initialization rules for get_command_argument

ied a bug in gfortran? > Should I file at the GCC Bugzilla? > gfortan is an open-source project. It does not spontaneously manifest new features when a new standard comes into existence. This tracked under https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117798 Patches welcomed. -- Steve

gfortran not following deferred initialization rules for get_command_argument

This last week, as an exercise in learning FORTRAN, I attempted to complete a programming puzzle ( https://adventofcode.com/2024/day/4 ) with gfortran. I made a specific decision to target the 2023 standard and *not* the GNU standard. I believe I have found a nonconformance with gfortran 14.2.0

Interview Request: Insights on Your Work with GFortran

Dear GFortan Team, My name is Paulina Kowalska and I am currently conducting research at the University of Oldenburg in the field of open-source software. My study focuses on the impact of the Sovereign Tech Fund (STF) on the work within open-source projects. In this context, I have already bee

Re: [Patch, fortran] PR117897 - [13/14 Regression] Bug in gfortran compiled windows run time with the latest release (14.2.0)

Thanks Paul. Regards, Jerry On Tue, Dec 17, 2024, 12:34 AM Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi All, > > This bug was so obviously in defiance of the standard that I pushed it to > mainline as r15-6260. I meant to post this message immediately but was > distracted bef

[Patch, fortran] PR117897 - [13/14 Regression] Bug in gfortran compiled windows run time with the latest release (14.2.0)

Hi All, This bug was so obviously in defiance of the standard that I pushed it to mainline as r15-6260. I meant to post this message immediately but was distracted before I could press send. I will be backporting today. Paul Change.Logs Description: Binary data diff --git a/gcc/fortran/trans-ex

Re: [Patch, fortran] PR117434 - [F08] gfortran rejects actual argument corresponding to procedure pointer dummy argument

Hi Harald, Yes indeed about proc_ptr_56.f90 :-( That was a slip that occurred in the preparation of the patch for the list. I will indeed make proc_ptr_54.f90 compile-only for the time being. The latter was not elided from my platform for any level of optimization for the simple reason that system

Re: [Patch, fortran] PR117434 - [F08] gfortran rejects actual argument corresponding to procedure pointer dummy argument

Hi Folks. > On 5 Nov 2024, at 19:23, Harald Anlauf wrote: > > Hi Paul, > > Am 05.11.24 um 16:24 schrieb Paul Richard Thomas: >> Hi All, >> >> There is not much to say about the attached patch other than it is minimal >> :-) The testcases are probably a bit more than is strictly needed since th

Re: [Patch, fortran] PR117434 - [F08] gfortran rejects actual argument corresponding to procedure pointer dummy argument

Hi Paul, Am 05.11.24 um 16:24 schrieb Paul Richard Thomas: Hi All, There is not much to say about the attached patch other than it is minimal :-) The testcases are probably a bit more than is strictly needed since the interface tests (proc_ptr_55.f90) are already tested elsewhere. However, it i

[Patch, fortran] PR117434 - [F08] gfortran rejects actual argument corresponding to procedure pointer dummy argument

Hi All, There is not much to say about the attached patch other than it is minimal :-) The testcases are probably a bit more than is strictly needed since the interface tests (proc_ptr_55.f90) are already tested elsewhere. However, it is as well to check in this context. OK for mainline and 14-br

PR 117434 - [F08] gfortran rejects actual argument corresponding to procedure pointer dummy

. Gfortran rejects this feature, which is used ubiquitously throughout the test suite for the recently released Julienne unit testing framework (https://go.lbl.gov/julienne) and thus is also used ubiquitously in any software that uses Julienne for unit testing. % cat gfortran-reproducer.f90 module

Re: possible bug in Windows version from Gfortran 11.3.0 when using omp_set_num_threads

On Sun, Oct 06, 2024 at 07:16:18PM +1100, John Campbell wrote: > > I can confirm that the bug is not evident in equation.com's Gfortran 11.1.0 This is your problem. > and earlier, but is present from Gfortran 11.3.0. Pr

Re: possible bug in Windows version from Gfortran 11.3.0 when using omp_set_num_threads

Hi John, I would like to report a problem I have identified with using “call omp_set_num_threads (n)”, which has appeared when on Windows 10 using Gfortran version 11.3.0, (12.3.0 and 14.1.0). Prior versions ( 9.2.0, 10.2.0 and 11.1.0 run to completion. The reproducer program below does not

possible bug in Windows version from Gfortran 11.3.0 when using omp_set_num_threads

I would like to report a problem I have identified with using "call omp_set_num_threads (n)", which has appeared when on Windows 10 using Gfortran version 11.3.0, (12.3.0 and 14.1.0). Prior versions ( 9.2.0, 10.2.0 and 11.1.0 run to completion. The reproducer program below does not

Re: [PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

On 25 September 2024 22:08:15 CEST, rep.dot@gmail.com wrote: > >>Your interpretation of my typo is correct. Along with Andre I like auto >>cleanup. On new test cases we try to have them self delete whether they pass >>or fail. >> > >so why don't we issue the cleanup then, regardless?

Re: [PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

>Your interpretation of my typo is correct. Along with Andre I like auto >cleanup. On new test cases we try to have them self delete whether they pass >or fail. > so why don't we issue the cleanup then, regardless? >So your changes are ok with me. > >> No. >> >>>

Re: [PATCH v2] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

>>> +proc fortran-delete-unit-files { src } { >>> + # verbose -log "Found \"$openmatches\"" there's a numeric level. I'd probably put it in 4 (or drop it; IIRC modules cleanup may print'em at 4 or somesuch. Or maybe I also left them commented out, don't know offhand) just as a sidenote, as

Re: [PATCH v2] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

inline. But you may >want to wait for one other ok from some one who has more experience in >the gfortran testsuite (yes, still wondering who that might be :-( ). LGTM Ok for trunk. thanks, > >Thanks for the patch, > Andre > >On Wed, 25 Sep 2024 04:06:14 +0200

Re: [PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

On 9/24/24 5:46 PM, Hans-Peter Nilsson wrote: Thanks for the review! Date: Tue, 24 Sep 2024 17:10:27 -0700 Cc: Jerry D From: Jerry D On 9/23/24 11:21 PM, Hans-Peter Nilsson wrote: I hope the inclusion of gfortran-dg.exp in fortran-torture.exp is not controversial, but there's no fo

Re: [PATCH v2] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

nguage-specific tricks. > So I may be wrong in arguing that your changes look reasonable. I like the > "automatic" clean-up process very much. So by me, ok for mainline. But you may > want to wait for one other ok from some one who has more experience in > the gfortran tes

Re: [PATCH v2] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

nce in the gfortran testsuite (yes, still wondering who that might be :-( ). Thanks for the patch, Andre On Wed, 25 Sep 2024 04:06:14 +0200 Hans-Peter Nilsson wrote: > Changes since v1: > - Rename gfortran-dg-rmunits to fortran-delete-unit-files. > - Move it to lib/fortran-modules.ex

[PATCH v2] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

Changes since v1: - Rename gfortran-dg-rmunits to fortran-delete-unit-files. - Move it to lib/fortran-modules.exp. - Tweak commit message accordingly and mention cause of placement of the proc. - Tweak proc comment to mention why keeping removals unique despite comment. Here's a ge

Re: [PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

Thanks for the review! > Date: Tue, 24 Sep 2024 17:10:27 -0700 > Cc: Jerry D > From: Jerry D > On 9/23/24 11:21 PM, Hans-Peter Nilsson wrote: > > I hope the inclusion of gfortran-dg.exp in > > fortran-torture.exp is not controversial, but there's no > > fortra

Re: [PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

scan the source for open-statements than relying on manual annotations and people remembering to add them for new test-cases. I hope the inclusion of gfortran-dg.exp in fortran-torture.exp is not controversial, but there's no fortran-specific testsuite file common to dg and classic-torture and

[PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

lying on manual annotations and people remembering to add them for new test-cases. I hope the inclusion of gfortran-dg.exp in fortran-torture.exp is not controversial, but there's no fortran-specific testsuite file common to dg and classic-torture and also this placement is still in the "Uti

Re: Installing gfortran-14

hour, without obvious error messages though occasional warnings flashed up for milliseconds on the screen while configure and make were running. I now have a gfortran-14 compiler - thank you all! Now to discover how to remove all the out-of-date gfortran stuff cluttering up my computer. (I don&#

Re: Installing gfortran-14

On 8/29/24 7:53 PM, John Harper wrote: Hi Thomas & Damian Thank you. I'm running Ubuntu 24.04 in an x86_64 system. I do have dpkg and it said (lf) john:~/Gcc-build$ dpkg -S libc-header-start.h libc6-dev:amd64: /usr/include/x86_64-linux-gnu/bits/libc-header-start.h So I tried $ sudo apt install

Re: Installing gfortran-14

"fortran@gcc.gnu.org" Subject: Re: Installing gfortran-14 Resent-Date: Thu, 29 Aug 2024 18:25:38 +1200 (NZST) Resent-From: [You don't often get email from tkoe...@netcologne.de. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hi John, /usr/include/st

Re: Installing gfortran-14

Hi John, /usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such file or directory    27 | #include I'm not sure what system you are running. On my Ubuntu system, which is Debian-based, you can search for the package that provides a file with $ dpkg -S libc-header-start.

Re: Installing gfortran-14

On 8/28/24 8:33 PM, John Harper wrote: Hi Thomas Thank you! I got part of the way there after discovering that download-prerequisites had to be download_prerequisites, but make -j12 had a fatal error. What I did was $ cd % mkdir Gcc % cd ~/Gcc $ tar xvjf  ../Downloads/gmp-6.2.1.tar.bz2 $ tar

Re: Installing gfortran-14

as Koenig wrote: Date: Thu, 22 Aug 2024 05:19:16 + From: Thomas Koenig To: John Harper , Damian Rouson Cc: "fortran@gcc.gnu.org" Subject: Re: Installing gfortran-14 Resent-Date: Thu, 22 Aug 2024 17:19:33 +1200 (NZST) Resent-From: [You don't often get email from tkoe

Re: Installing gfortran-14

Hi John, Thank you Damian. Tried the first suggestion. It said I already had gfortran; it turned out to be version 13. Tried the second suggestion. My system has not heard of git. Managed to find gcc-14.2.0.tar so I am now struggling to do something with that. Assuming you have the top

Re: Installing gfortran-14

Thank you Damian. Tried the first suggestion. It said I already had gfortran; it turned out to be version 13. Tried the second suggestion. My system has not heard of git. Managed to find gcc-14.2.0.tar so I am now struggling to do something with that. On Tue, 20 Aug 2024, Damian Rouson wrote

Re: Installing gfortran-14

n just use > > sudo apt install gcc > > and that will install gcc, g++, and gfortran.  My Linux knowledge is limited.  > I never figured out how to install a specific version of GCC on Ubuntu so I > think you just get what you get.  However, what I liked about Ubuntu was

Re: Installing gfortran-14

It has been a few years since I used Ubuntu. If I recall correctly, I think you can just use sudo apt install gcc and that will install gcc, g++, and gfortran. My Linux knowledge is limited. I never figured out how to install a specific version of GCC on Ubuntu so I think you just get what you

Installing gfortran-14

I did this in my Ubuntu 22.04 system with no trouble: (lf) john:~$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test but the next step failed: (lf) john:~$ sudo apt install gfortran-14 Reading package lists... Done Building dependency tree... Done Reading state information... Done Package

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Thank you very much! Sergey On Aug 19, 2024 at 00:55 +0800, FX Coudert , wrote: > Thanks Sergey, > > I have pushed the patch at > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1cfe4a4d0d4447b364815d5e5c889deb2e533669 > > FX

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Thanks Sergey, I have pushed the patch at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1cfe4a4d0d4447b364815d5e5c889deb2e533669 FX

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Hi, If we are good at this point, could someone help with merging it? (I don’t have commit access, of course.) Sergey On Aug 14, 2024 at 21:30 +0800, Sergey Fedorov , wrote: > Thank you, Iain. > I have adjusted a longer line and added an intro sentence before changelog > record. > > > > > On We

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Thank you, Iain. I have adjusted a longer line and added an intro sentence before changelog record. On Wed, Aug 14, 2024 at 8:24 PM Iain Sandoe wrote: > > > > On 14 Aug 2024, at 13:17, Sergey Fedorov wrote: > > > > > > > > On Wed, Aug 14, 2024 at 8:03 PM FX Coudert wrote: > > > Thank you for

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

> On 14 Aug 2024, at 13:17, Sergey Fedorov wrote: > > > > On Wed, Aug 14, 2024 at 8:03 PM FX Coudert wrote: > > Thank you for responding. > > I have added a changelog (is this a correct way?). > > Content seems ok, lines are maybe too long. Check with > contrib/gcc-changelog/git_check_com

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

On Wed, Aug 14, 2024 at 8:03 PM FX Coudert wrote: > > Thank you for responding. > > I have added a changelog (is this a correct way?). > > Content seems ok, lines are maybe too long. Check with > contrib/gcc-changelog/git_check_commit.py before pushing. > Once that is fine, OK to push. > Looks l

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

> Thank you for responding. > I have added a changelog (is this a correct way?). Content seems ok, lines are maybe too long. Check with contrib/gcc-changelog/git_check_commit.py before pushing. Once that is fine, OK to push. FX

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Thank you for responding. I have added a changelog (is this a correct way?). Sergey On Wed, Aug 14, 2024 at 12:58 AM FX Coudert wrote: > Hi, > > > I dropped a change to the test file, since you have fixed it > appropriately, and switched to Apple libm convention for flags, as you have > suggest

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Hi, > I dropped a change to the test file, since you have fixed it appropriately, > and switched to Apple libm convention for flags, as you have suggested. > Please let me know if I should do anything further to improve it and make it > acceptable for a merge. The patch itself is OK. Please add

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

On Mon, Aug 5, 2024 at 6:25 PM Sergey Fedorov wrote: > > On Thu, Jul 25, 2024 at 4:47 PM FX Coudert wrote: > >> Can you post an updated version of the patch, following the first round >> of review? >> >> FX > > If you got some time, please review this. I will likely be away from my PowerPC har

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

On Thu, Jul 25, 2024 at 4:47 PM FX Coudert wrote: > Can you post an updated version of the patch, following the first round of > review? > > FX Sorry for a delay, done. I dropped a change to the test file, since you have fixed it appropriately, and switched to Apple libm convention for flags,

gfortran module version

Would you consider adding the following table to the gfortran documentation: GCC versionmodule file version --- up to 4.3.2unversioned 4.40 4.5.1 4 4.6.3 6 4.7.0pre 8 4.7.1 9 4.8.[1-3

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Can you post an updated version of the patch, following the first round of review? FX

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Bumping the topic. Since this patch exclusively affects powerpc-darwin, and I think we agree that it does not add regressions with tests (no tests which passed without it fail with it), perhaps it can be merged? It would be great to have it in gcc 15 when it is released, otherwise we will need to

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

On Sat, Jul 6, 2024 at 6:07 AM FX Coudert wrote: > > This part of the patch is quite old, but from the remaining log it looks > I got an error here: > > Now on a second thought, this did not require a fix perhaps. We can drop > it. > > I have addressed this: > https://gcc.gnu.org/pipermail/gcc-pa

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

>From f19315cd425d0a23c02ba1be9c24c2a1f82cb47c Mon Sep 17 00:00:00 2001 From: Sergey Fedorov Date: Sat, 29 Apr 2023 14:55:44 +0800 Subject: [PATCH] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic Signed-off-by: Sergey Fedorov --- libgfortran/config/fpu-macppc.h | 414

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

> This part of the patch is quite old, but from the remaining log it looks I > got an error here: > Now on a second thought, this did not require a fix perhaps. We can drop it. I have addressed this: https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656484.html The test should now be run on al

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

n every attempt (and aside from one version, extra failures, if present, were in single digit numbers), and whenever the output contained numerical values, those also matched, AFAICT. I think I cannot attach a log here, even compressed, but I have put it here: http://macos-powerpc.org/gcc/gfortra

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Hi, The core of the powerpc-FPU manipulation is okay for me. Some comments below. > --- a/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c > +++ b/gcc/testsuite/gfortran.dg/ieee/signaling_2_c.c > @@ -1,3 +1,11 @@ > +#ifdef __POWERPC__ // No support for issignaling in math.h on Darwin PPC Two thin

Re: [PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

Below is the diff of tests for gfortran on powerpc-apple-darwin10.8.0 without (unmodified gcc upstream) vs with the gfortran patch being added. === gfortran Summary === -# of expected passes69273 -# of unexpected failures36 +# of expected passes69646 +# of unexpected

[PATCH, gfortran] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic

>From 50fc05566ba7479844949d727233c04a5e8151e8 Mon Sep 17 00:00:00 2001 From: Sergey Fedorov Date: Sat, 29 Apr 2023 14:55:44 +0800 Subject: [PATCH] libgfortran: implement fpu-macppc for Darwin, support IEEE arithmetic Signed-off-by: Sergey Fedorov --- .../gfortran.dg/ieee/signaling_2_c.c

Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)

Accumulate instructions. This is on by default for -march=armv8.1-a. I.e., -mno-rdma (I hope that's correct - I'll will try that when the Sun rises again and I have some power to run the AArch64 machine ...). Well, I did two independent runs with gfortran-13.2 and the following opt

Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)

default for -march=armv8.1-a. I.e., -mno-rdma (I hope that's correct - I'll will try that when the Sun rises again and I have some power to run the AArch64 machine ...). Well, I did two independent runs with gfortran-13.2 and the following options: -O3 -march=armv8.1-a+rdma and

Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)

e instructions. This is on by > > default for -march=armv8.1-a. > > > > I.e., -mno-rdma > > > > (I hope that's correct - I'll will try that when the Sun rises again and > > I have some power to run the AArch64 machine ...). > > Well, I did two indep

Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)

l try that when the Sun rises again and I have some power to run the AArch64 machine ...). Well, I did two independent runs with gfortran-13.2 and the following options: -O3 -march=armv8.1-a+rdma and -O3 -march=armv8.1-a+nordma No difference in the number of error runs exceeding the

  1   2   3   4   >