[Bug fortran/100724] -fwhole-program breaks module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724 --- Comment #6 from Jan Hubicka --- > Could the manual entry for -fwhole-program just be amended to clarify that > it's > a fallback for when a linker plugin isn't available for -flto. That may be > what it was intended to say, but it's not clear to me. I used -fwhole-program > because it seemed to fit my case exactly. It can be also used in non-lto if your program has only one source file and FE is not producing duplicated decls... Honza
[Bug fortran/100724] -fwhole-program breaks module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724 --- Comment #5 from Dave Love --- Thanks for the explanation. Could the manual entry for -fwhole-program just be amended to clarify that it's a fallback for when a linker plugin isn't available for -flto. That may be what it was intended to say, but it's not clear to me. I used -fwhole-program because it seemed to fit my case exactly.
[Bug fortran/100724] -fwhole-program breaks module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #4 from Richard Biener --- -fwhole-program means the program is entirely confined within a single TU, using modules might break this in subtle ways. -fwhole-program is really sth "legacy" meant to help with LTO and the case where no linker plugin is available. When a linker plugin is available just -flto is as powerful and using -fwhole-program will only result in subtly to debug issues if you "lied" to GCC. I can reproduce the -fwhole-program issue with GCC 10 as well and this likely means the Fortran FE creates invalid GENERIC and thus two distinct 'twice' function declarations. With -flto the WPA stage will unify those, "fixing" the issue (basically treating the single TU as two distinct TUs which they appearantly are). When I -fdump-ipa-cgraph-details I indeed see: twice_/10 (twice) @0x769cdca8 Type: function Visibility: external public References: Referring: Function flags: Called by: MAIN__/1 Calls: twice_/0 (twice) @0x769cd000 Type: function definition analyzed Visibility: public Aux: @0x769cd2d0 References: Referring: Function flags: body Called by: Calls: so there's an external 'twice' called by main and a distinct, unused, definition 'twice'. With -fwhole-program you tell GCC that there are no external users and thus the definition gets promoted 'static' and is eliminated as unused (GCC doesn't consider it resolving the call to the external 'twice' which we might consider a bug - but we expect the frontends to resolve those internal bindings).
[Bug fortran/100724] -fwhole-program breaks module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||10.3.1, 11.1.0, 12.0, ||8.5.0, 9.3.1 Known to work||9.2.0 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Dave Love from comment #2) > The manual says not to use -flto with -fwhole-program. Is that misleading? I guess the manual entry has a reason, but I do not know why the optimimzations implied by these options should not be combined. > I checked self-built gfortran 10.2.0 again, and it definitely works for me > without -flto on Debian 10, but it fails with Red Hat devtoolset's 10.2.1 on > RHEL7. Odd... I checked against gfortran 9.2.0, which works fine, whereas the current development version 9.3.1 fails too. The change likely happened in a newer developer version and was backported to the release branches.
[Bug fortran/100724] -fwhole-program breaks module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724 --- Comment #2 from Dave Love --- The manual says not to use -flto with -fwhole-program. Is that misleading? I checked self-built gfortran 10.2.0 again, and it definitely works for me without -flto on Debian 10, but it fails with Red Hat devtoolset's 10.2.1 on RHEL7. Odd...
[Bug fortran/100724] -fwhole-program breaks module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||7.5.0 Ever confirmed|0 |1 Keywords||link-failure, wrong-code Last reconfirmed||2021-05-23 CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Interesting bug. With optimization enabled (e.g. -O) I find a linking failure with 8.5.0 and newer, except when I add -ftlo. With -fwhole-program -O -flto the program seems to work up to 11.1, but fails with 12.0 (hangs). With -fwhole-program -O0 it also hangs with 12.0, but not with 11.1. So there are possibly two issues, a 12-regression and an 8+-regression.
