New DEBUG fflags break back-compatibility with GCC 8.3.0

[beddalumia]

Hi, I noticed that one of the new gfortran compiler options, introduced in commit 9e1dba4c5c365b927da035905108cc629010656f, is not recognized by GCC 8.3.0 (which is crucially the latest available version of gfortran on Ulysses and all of SISSA's CentOS workstations).

Here's what we see with a toy command (but the same happens trying to compile Scifortran with the usual cmake procedure, at the "make/ninja" step).

$ gfortran -O0 -p -g  -fbacktrace -fwhole-file -fcheck=all -fbounds-check -fsanitize=address -fdebug-aux-vars -Wall -Waliasing -Wsurprising -Wampersand -Warray-bounds -Wc-binding-type -Wcharacter-truncation -Wconversion -Wdo-subscript -Wfunction-elimination -Wimplicit-interface -Wimplicit-procedure -Wintrinsic-shadow -Wintrinsics-std -Wno-align-commons -Wno-overwrite-recursive -Wno-tabs -Wreal-q-constant -Wunderflow -Wunused-parameter -Wrealloc-lhs -Wrealloc-lhs-all -Wfrontend-loop-interchange -Wtarget-lifetime

gfortran: error: unrecognized command line option ‘-fdebug-aux-vars’
gfortran: fatal error: no input files   # OF COURSE WITH THE TOY COMMAND, the problem is above
compilation terminated.

$ gfortran --version
GNU Fortran (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Should we dump it?

[aamaricci]

As for DMFT_Tools.

Dump it and possibly keep it commented in the macro.

Great work. A

[beddalumia]

There are still problems I believe. After compiling everything (Scifor + Tools + EDIpack2) in debug mode and then a driver, i have loads of link errors, which to a quick look feel all related to some debug machinery that apparently is referenced in both Scifor and DMFT-tools (not in EDIpack2), which are the two libraries featuring the new flags. I have no quick way of guessing which option is offending, except for trying removing them one by one, which is annoying. I may do it later.

Full log of the link errors attached as: LOG.make.txt

Relevant also for https://github.com/aamaricci/DMFTtools/issues/3

[aamaricci]

Perhaps the DEBUG directives are too aggressive on some platform.

Let's do this: for GNU compilers we can use two debug degree: SET(CMAKE_Fortran_FLAGS_DEBUG "-O0 -p -g -Wsurprising -Waliasing -fwhole-file -fcheck=all -fbacktrace -fbounds-check -ffree-line-length-none -fPIC -w -fallow-argument-mismatch") SET(CMAKE_Fortran_FLAGS_DAGGRESSIVE "-O0 -p -g -fbacktrace -fwhole-file -fcheck=all -fbounds-check -fsanitize=address -fdebug-aux-vars -Wall -Waliasing -Wsurprising -Wampersand -Warray-bounds -Wc-binding-type -Wcharacter-truncation -Wconversion -Wdo-subscript -Wfunction-elimination -Wimplicit-interface -Wimplicit-procedure -Wintrinsic-shadow -Wintrinsics-std -Wno-align-commons -Wno-overwrite-recursive -Wno-tabs -Wreal-q-constant -Wunderflow -Wunused-parameter -Wrealloc-lhs -Wrealloc-lhs-all -Wfrontend-loop-interchange -Wtarget-lifetime")

Knowing that the second can break compilation (and in any case should be used mostly for debugging external programs which may need such aggressive directives, note that to use those directives you need the entire hierarchy of dynamic libraries to be compiled with the same level of debug).

Hopefully the mild debug options are enough for most use.

On Tue, Jul 2, 2024 at 11:40 AM Gabriele Bellomia @.***> wrote:

There are still problems I believe. After compiling everything (Scifor + Tools + EDIpack2) in debug mode and then a driver, i have loads of link errors, which to a quick look feel all related to some debug machinery that apparently is referenced in both Scifor and DMFT-tools (not in EDIpack2), which are the two libraries featuring the new flags. I have no quick way of guessing which option is offending, except for trying removing them one by one, which is annoying. I may do it later.

Full log of the link errors attached as: LOG.make.txt https://github.com/user-attachments/files/16065958/LOG.make.txt

Relevant also for aamaricci/DMFTtools#3 https://github.com/aamaricci/DMFTtools/issues/3

— Reply to this email directly, view it on GitHub https://github.com/aamaricci/SciFortran/issues/23#issuecomment-2202572223, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARRDWEYKTNNNNYPOCUTSU3ZKJYRJAVCNFSM6AAAAABKHAH3TWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBSGU3TEMRSGM . You are receiving this because you commented.Message ID: @.***>

[beddalumia]

Okie dokie, I'll do it later today / tomorrow. But one question: once we define an "aggressive" profile, should we include also stuff like -ffpe-trap=zero,overflow,underflow? Or maybe even in the "mild debug" profile, as weird IEEE stuff happens sometimes especially when using ARPACK (an I never got to investigate it thoroughly).

[aamaricci]

That's a good question. I introduced such an aggressive profile to debug some memory leak in any ED code coming from a wrong use of pointers (my bad interpretation of freeing pointer in Fortran) causing huge accumulation of the memory and eventually some crashes. Other than that I have been well served by regular options all time. Admittedly, having better debug options would be useful but I am afraid that pushing too much in one direction will inevitably lead to some compilation/linking error on some platforms.

On Wed, Jul 3, 2024 at 4:48 PM Gabriele Bellomia @.***> wrote:

Okie dokie, I'll do it later today / tomorrow. But one question: once we define an "aggressive" profile, should we include also stuff like -ffpe-trap=zero,overflow,underflow? Or maybe even in the "mild debug" profile, as weird IEEE stuff happens sometimes especially when using ARPACK (an I never got to investigate it thoroughly).

— Reply to this email directly, view it on GitHub https://github.com/aamaricci/SciFortran/issues/23#issuecomment-2206381632, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARRDWH4JSTCQHMPWP74QITZKQFMPAVCNFSM6AAAAABKHAH3TWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBWGM4DCNRTGI . You are receiving this because you commented.Message ID: @.***>