Re: Test with an lto-build of libgfortran.
Hi Toon, During the GNU Tools Cauldron we discussed (at the BoF: IPA & LTO) the possibility (and hazards) of building the run time libraries for various compilers with -flto, enabling an -flto -static linking of programs with the run time library available during link time optimizations. This would be a big win for libgfortran, especially the array functions, knowing that stride==1 can be a _big_ win for optimization. This is why LTO is such an excellent idea for Fortran in general, and for the library in particular. There is a PR on this with quite some discussion already, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77278 . I've put you in CC of that bug, maybe we can discuss there more in detail. One point about the array functions: In the library, we use sort of a ripple carry algorithm to step through the arrays. This saves space an is general, but the performance (esp for the most common one-and two-dimensional arrays) can suffer. [...] The full question of "lto-ing" run time libraries is more complicated than just "whether it works" as those who attended the BoF will recall. I didn't attend the Cauldron (but that discussion would have been very interesting). I think for libgfortran, a first step would be additional work to get declarations on both sides to agree (which is worth doing anyway). Best regards Thomas
Re: Test with an lto-build of libgfortran.
On 9/27/23 12:21, Toon Moene wrote: The lto-ing of libgfortran did succeed, because I did get a new warning: gfortran -O3 -flto -flto-partition=none -static -o xlintstrfz zchkrfp.o zdrvrfp.o zdrvrf1.o zdrvrf2.o zdrvrf3.o zdrvrf4.o zerrrfp.o zlatb4.o zlaipd.o zlarhs.o zsbmv.o zget04.o zpot01.o zpot03.o zpot02.o chkxer.o xerbla.o alaerh.o aladhd.o alahd.o alasvm.o ../../libtmglib.a ../../liblapack.a ../../librefblas.a In function 'xtoa_big', inlined from 'write_z' at /home/toon/compilers/gcc/libgfortran/io/write.c:1296:11, inlined from 'formatted_transfer_scalar_write' at /home/toon/compilers/gcc/libgfortran/io/transfer.c:2136:4: /home/toon/compilers/gcc/libgfortran/io/write.c:1222:6: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 1222 | *q = '\0'; | ^ /home/toon/compilers/gcc/libgfortran/io/write.c: In function 'formatted_transfer_scalar_write': /home/toon/compilers/gcc/libgfortran/io/write.c:1291:8: note: at offset [34, 4294967294] into destination object 'itoa_buf' of size 33 1291 | char itoa_buf[GFC_XTOA_BUF_SIZE]; | ^ which was (of course) not given with a non-lto libgfortran. Yea. This certainly can happen with LTO. These warnings would definitely be something worth investigating. Essentially the inlining enabled by LTO can expose a different set of diagnostics. Jeff
Test with an lto-build of libgfortran.
Hi all, During the GNU Tools Cauldron we discussed (at the BoF: IPA & LTO) the possibility (and hazards) of building the run time libraries for various compilers with -flto, enabling an -flto -static linking of programs with the run time library available during link time optimizations. Today I tried that on my (AMD Ryzen 7 5800U) laptop with gcc version 14.0.0 20230926 (experimental) [master r14-4282-g53daf67fd55] (GCC) with the following "quick hack": diff --git a/libgfortran/configure b/libgfortran/configure index cd176b04a14..69a2b4a8881 100755 --- a/libgfortran/configure +++ b/libgfortran/configure @@ -5959,11 +5959,11 @@ fi # Add -Wall -fno-repack-arrays -fno-underscoring if we are using GCC. have_real_17=no if test "x$GCC" = "xyes"; then - AM_FCFLAGS="-I . -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring" + AM_FCFLAGS="-I . -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring -flto" ## We like to use C11 and C99 routines when available. This makes ## sure that ## __STDC_VERSION__ is set such that libc includes make them available. - AM_CFLAGS="-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla" + AM_CFLAGS="-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla -flto" ## Compile the following tests with the same system header contents ## that we'll encounter when compiling our own source files. CFLAGS="-std=gnu11 $CFLAGS" The build of this compiler (languages=fortran) completed without problems (no test results - not enough time). I then proceeded to build LAPACK with the following build options: CFLAGS = -O3 -flto -flto-partition=none -static and FFLAGS = -O3 -flto -flto-partition=none -static This gave the same test results of the LAPACK test suite as the build with the same compiler, but without an lto'd libgfortran. The lto-ing of libgfortran did succeed, because I did get a new warning: gfortran -O3 -flto -flto-partition=none -static -o xlintstrfz zchkrfp.o zdrvrfp.o zdrvrf1.o zdrvrf2.o zdrvrf3.o zdrvrf4.o zerrrfp.o zlatb4.o zlaipd.o zlarhs.o zsbmv.o zget04.o zpot01.o zpot03.o zpot02.o chkxer.o xerbla.o alaerh.o aladhd.o alahd.o alasvm.o ../../libtmglib.a ../../liblapack.a ../../librefblas.a In function 'xtoa_big', inlined from 'write_z' at /home/toon/compilers/gcc/libgfortran/io/write.c:1296:11, inlined from 'formatted_transfer_scalar_write' at /home/toon/compilers/gcc/libgfortran/io/transfer.c:2136:4: /home/toon/compilers/gcc/libgfortran/io/write.c:1222:6: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 1222 | *q = '\0'; | ^ /home/toon/compilers/gcc/libgfortran/io/write.c: In function 'formatted_transfer_scalar_write': /home/toon/compilers/gcc/libgfortran/io/write.c:1291:8: note: at offset [34, 4294967294] into destination object 'itoa_buf' of size 33 1291 | char itoa_buf[GFC_XTOA_BUF_SIZE]; |^ which was (of course) not given with a non-lto libgfortran. The full question of "lto-ing" run time libraries is more complicated than just "whether it works" as those who attended the BoF will recall. Hope this helps, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: gfortran: error: unrecognized argument in option '-mcmodel=medium'
> On 27 Sep 2023, at 08:33, Iain Sandoe wrote: > > > >> On 27 Sep 2023, at 08:25, Andrew Pinski via Fortran >> wrote: >> >> On Tue, Sep 26, 2023 at 11:39 PM Richard Biener via Fortran >> wrote: >>> >>> On Tue, Sep 26, 2023 at 4:44 PM Lingadahally, Vishakha (2023) >>> wrote: Dear GCC Team, I'm running Ubuntu 22 on my Mac virtually and my gfortran version is 11.4.0. When I try to install a certain software package, I encounter the following error: gfortran: error: unrecognized argument in option '-mcmodel=medium' gfortran: note: valid arguments to '-mcmodel=' are: large small tiny Is this due to attempting to run gfortran on arm64 architecture? Could you please let me know how I could resolve the issue? >>> >>> You have to turn to Ubuntu here, -mcmodel=medium is certainly >>> supported in GCC 11, maybe Ubuntu patches out >>> the support? >> >> Well -mcmodel=medium is the x86_64 specific option while they are >> trying to run on aarch64 which has a different set options. > > > The current Arm64 port (aarch64 on macOS) only supports the “small” mcmodel > “tiny” is not supported by macOS and we have not yet implemented “large”. > > Despite it’s name “small” should suffice as an approximate equivalent for the > x86_64 “medium” (at least on macOS). > > So, either you need to change the flag depending on the architecture, or omit > it > (on macOS currently GCC only supports the default mcmodel). > > We plan to support the “large” model at some stage on Arm64 (but unlikely for > GCC 14) Ah, and now I see you are not running native so the comments above are not relevant. Iain
Re: gfortran: error: unrecognized argument in option '-mcmodel=medium'
> On 27 Sep 2023, at 08:25, Andrew Pinski via Fortran > wrote: > > On Tue, Sep 26, 2023 at 11:39 PM Richard Biener via Fortran > wrote: >> >> On Tue, Sep 26, 2023 at 4:44 PM Lingadahally, Vishakha (2023) >> wrote: >>> >>> Dear GCC Team, >>> >>> I'm running Ubuntu 22 on my Mac virtually and my gfortran version is >>> 11.4.0. When I try to install a certain software package, I encounter the >>> following error: >>> >>> gfortran: error: unrecognized argument in option '-mcmodel=medium' >>> gfortran: note: valid arguments to '-mcmodel=' are: large small tiny >>> >>> Is this due to attempting to run gfortran on arm64 architecture? Could you >>> please let me know how I could resolve the issue? >> >> You have to turn to Ubuntu here, -mcmodel=medium is certainly >> supported in GCC 11, maybe Ubuntu patches out >> the support? > > Well -mcmodel=medium is the x86_64 specific option while they are > trying to run on aarch64 which has a different set options. The current Arm64 port (aarch64 on macOS) only supports the “small” mcmodel “tiny” is not supported by macOS and we have not yet implemented “large”. Despite it’s name “small” should suffice as an approximate equivalent for the x86_64 “medium” (at least on macOS). So, either you need to change the flag depending on the architecture, or omit it (on macOS currently GCC only supports the default mcmodel). We plan to support the “large” model at some stage on Arm64 (but unlikely for GCC 14) HTH, Iain
Re: gfortran: error: unrecognized argument in option '-mcmodel=medium'
On Tue, Sep 26, 2023 at 11:39 PM Richard Biener via Fortran wrote: > > On Tue, Sep 26, 2023 at 4:44 PM Lingadahally, Vishakha (2023) > wrote: > > > > Dear GCC Team, > > > > I'm running Ubuntu 22 on my Mac virtually and my gfortran version is > > 11.4.0. When I try to install a certain software package, I encounter the > > following error: > > > > gfortran: error: unrecognized argument in option '-mcmodel=medium' > > gfortran: note: valid arguments to '-mcmodel=' are: large small tiny > > > > Is this due to attempting to run gfortran on arm64 architecture? Could you > > please let me know how I could resolve the issue? > > You have to turn to Ubuntu here, -mcmodel=medium is certainly > supported in GCC 11, maybe Ubuntu patches out > the support? Well -mcmodel=medium is the x86_64 specific option while they are trying to run on aarch64 which has a different set options. > > > > > Thank you > > > > Warm regards, > > Vishakha > > > > This email, its contents and any attachments are intended solely for the > > addressee and may contain confidential information. In certain > > circumstances, it may also be subject to legal privilege. Any unauthorised > > use, disclosure, or copying is not permitted. If you have received this > > email in error, please notify us and immediately and permanently delete it. > > Any views or opinions expressed in personal emails are solely those of the > > author and do not necessarily represent those of Royal Holloway, University > > of London. It is your responsibility to ensure that this email and any > > attachments are virus free.
Re: gfortran: error: unrecognized argument in option '-mcmodel=medium'
On Tue, Sep 26, 2023 at 4:44 PM Lingadahally, Vishakha (2023) wrote: > > Dear GCC Team, > > I'm running Ubuntu 22 on my Mac virtually and my gfortran version is 11.4.0. > When I try to install a certain software package, I encounter the following > error: > > gfortran: error: unrecognized argument in option '-mcmodel=medium' > gfortran: note: valid arguments to '-mcmodel=' are: large small tiny > > Is this due to attempting to run gfortran on arm64 architecture? Could you > please let me know how I could resolve the issue? You have to turn to Ubuntu here, -mcmodel=medium is certainly supported in GCC 11, maybe Ubuntu patches out the support? > > Thank you > > Warm regards, > Vishakha > > This email, its contents and any attachments are intended solely for the > addressee and may contain confidential information. In certain circumstances, > it may also be subject to legal privilege. Any unauthorised use, disclosure, > or copying is not permitted. If you have received this email in error, please > notify us and immediately and permanently delete it. Any views or opinions > expressed in personal emails are solely those of the author and do not > necessarily represent those of Royal Holloway, University of London. It is > your responsibility to ensure that this email and any attachments are virus > free.
