Re: Installing gfortran-14
Dear Jerry, Thomas and Damian, Not knowing what to do with libc6-i386 libc6-dev-i386 I tried instead to do without multilib by disabling it: $ ../Gcc/gcc-14.2.0/configure --prefix=$HOME --disable-multilib --enable-languages=c,c++,fortran $ make -j4 $ make -j4 install That ran for over an 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't intend ever to run gfortran-9 to gfortran-12 again.) John On Fri, 30 Aug 2024, Jerry D wrote: Date: Fri, 30 Aug 2024 03:19:37 + From: Jerry D To: John Harper , Thomas Koenig Cc: Damian Rouson , "fortran@gcc.gnu.org" Subject: Re: Installing gfortran-14 Resent-Date: Fri, 30 Aug 2024 15:19:51 +1200 (NZST) Resent-From: [You don't often get email from jvdelis...@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] 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 libc6-dev $ ../Gcc/gcc-14.2.0/configure --prefix=$HOME --enable-multilib --enable-languages=c,c++,fortran $ make -j4 but I still got the same error message from make. John I am reminded. When using --enable-multilib you need both the 32-bit and the 64-bit libraries. Possibly libc6-i386 libc6-dev-i386. Jerry -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
Re: [PATCH] Fortran: downgrade use associated namelist group name to, legacy extension
On 8/30/24 21:36, Steve Kargl wrote: Harald, I'm fine with the patch. You may want to wait to see if anyone has a rasonable objection. Since you and Thomas agreed, pushed as r15-3332-g79b5b50402454d . Thanks, Harald
Re: [PATCH] Fortran: downgrade use associated namelist group name to, legacy extension
Hi Harald, the attached patch downgrades this feature from a GNU extension (silent per default) to a legacy extension (warning by default). The feature is tested in at least 4 gfortran testcases. I adjusted the pattern of one of these tests to check for the downgrade. Regtested on x86_64-pc-linux-gnu. OK for mainline? Seconding Steve, this is OK. We should never accept a constraint violation by default. Best regards Thomas
Re: [PATCH] Fortran: default-initialization of derived-type function results [PR98454]
Hi Harald, The invalid testcase is posted as PR116543. I plan to hit PDTs in the second half of September, when daytime work will lighten up a bit. Cheers Paul On Fri, 30 Aug 2024 at 17:28, Harald Anlauf wrote: > Hi Paul, > > Am 30.08.24 um 18:09 schrieb Paul Richard Thomas: > > Hi Harald, > > > > The patch is good for mainline. > > > > The PDT testcase is invalid because the component has a fixed length > > initializer, while its length is a len parameter. One of the fixes that I > > will have to do in the PDT revamp. Ignore it for now. > > duh, another invalid testcase in the testsuite! > Thanks for checking and pointing this out. > > And indeed, after renaming .f03 -> .f90, I see that Intel and NAG > agree with you. > > > Thanks for the patch. > > Pushed as r15-3323-gb222122d4e93de . > > Thanks for the review! > > Harald > > > > > Paul > > > > > > > > > > On Thu, 29 Aug 2024 at 21:30, Harald Anlauf wrote: > > > >> Dear all, > >> > >> the attached, rather simple patch adds the missing > default-initialization > >> of non-pointer, non-allocatable derived-type function results. > >> > >> Regtested ok on x86_64-pc-linux-gnu, but needed two adjustments in the > >> testsuite. One of them is easily explained by the fix, but the other > >> one to gfortran.dg/pdt_26.f03 makes me scratch my head. > >> > >> The patch adds default-initialization and thus changes the count of > >> __builtin_malloc in the tree dump, but not the __builtin_free count. > >> > >> Running the testcase under valgrind shows that no memleak occurs at > >> -O1 and higher, but I get a minor leak at -O0 and -Og. > >> > >> The dump tree is the same at -O0 and -O1, which is nice. > >> > >> Any suggestions how to proceed? > >> > >> And is the patch OK for mainline? The PDT implementation may have > >> latent issues, but that is just a guess. > >> > >> Thanks, > >> Harald > >> > >> > > > >
