With nagfor W2 uses -g instead of -g90

[sschmidt]

If you configure with nagfor and without explicit compiler flags

./configure FC=nagfor

the -g compiler flag is set. For nagfor the flag should be -g90 instead.

The -g option in NAG Fortran is specifically for debugging with the upsf90 debugger, which we no longer support.
Please use the -g90 option for debugging with dbx90 or gdb. (The reasons for this are historical.)

[sschmidt]

Just another remark on nagfor and -g90
Using -g90 breaks make distcheck:

Fatal Error: ../../../src/hepmc/HepMCWrap_dummy.f90: Cannot create file ../../../src/hepmc/HepMCWrap_dummy.g90

because nagfor tries to generate .g90 files in the dirs of the .f90 files.

[kilian]

This is a fault of the NAG compiler developers. We may document it somewhere, but eventually they will support -g again. It just happens that -g -O2 is configure default for FCFLAGS.

I change this to a documentation ticket.

[Juergen Reuter]

The documentation part is done. Now I have to reproduce the god-damn breaking of 'make distcheck'.

[Juergen Reuter]

It seems that Sebastian is not using HepMC, so I try to reproduce this.

[Juergen Reuter]

JRR reproduces the case above. Seems that the compiler wants to write some files into the src directory during the make distcheck procedure in the whizard-2.0.0/_build directory.

[Juergen Reuter]

Right now I have a slow internet connection, someone with a better access should take over. Or we are just happy by knowing which flags to set for development. :-s

[Juergen Reuter]

I updated the INSTALL files, put a comment on the WIKI and CS changed the default configure/libtool flags from "-O2 -g" to " ". So the user never gets a debug flag, except he sets it. THIS MEANS THAT DEVELOPERS WHO WANT TO COMPILE WITH DEBUGGING FLAGS HAVE TO SET THEM EXPLICITLY BY THEMSELVES FROM NOW ON. The -g90 problem with the source and build dirs is a known problem for developpers that will NOT be fixed. Closing.

[ohl]

Replying to jr_reuter:

THIS MEANS THAT DEVELOPERS WHO WANT TO COMPILE WITH DEBUGGING FLAGS HAVE TO SET THEM EXPLICITLY BY THEMSELVES FROM NOW ON.

I spoke w/WK and we agreed that this change is unacceptable: please revert it. While it is a common misconception that debugging flags are only for developers, it is a misconception. From the GNU coding standards:

• By default, the Make rules should compile and link with `-g', so that executable programs have debugging symbols. Users who don't mind being helpless can strip the executables later if they wish.

Seriously: we want bug reports with meaningful backtraces.

The only two reasonable options are:

• Put a note in INSTALL informing nagfor users of their compiler's non-standard behaviour and ask them to ./configure FCFLAGS="-O2"
• Put a test for nagfor into configure and sed -e 's/ -g ' -e 's/^{-g ' -e 's/ -g$'}

[Juergen Reuter]

Well, we did this with good reasons after discussions especially with the HERWIG people. They do the same. It's also that libraries are becoming unreasonably big. Performance is not an issue. I don't want to revert it again and again. We are loosing too much time on Nebenkriegsschauplaetze.

[Juergen Reuter]

Otherwise, if you want to use your free time to change INSTALL file, web page (compilers.html) plus configure.ac etc. plus WIKI entry please feel free to do so. I do not have time to do it.

[Juergen Reuter]

CS and JRR discuss tomorrow.

[Christian Speckner]

I'm indifferent on the question of whether to keep or not to keep debugging information (although I doubt that this increases the number of usable bug reports), but I think that just documenting this issue is not acceptable as it breaks NAG in the default configuration, and I also dislike the idea of automatically modifying FCFLAGS - the user should have full control over them.

Therefore, I have changed the quirk in r2327 to only override the default flags for nagfor with "-g90"; please check if this is fine with you and close the ticket (or complain and keep it open ;) ).

[ohl]

My suggestion is in r2336. Unlike r2327, it replaces only -g by -g90 and only if we are dealing with a NAG compiler.

Re: CS's dislike [of] the idea of automatically modifying FCFLAGS, we could add a AC_MESSAGE() to inform the user.

[ohl]

It's never boring ...

libtool: compile:  /opt/NAG/5.2/686/bin/nagfor -I../misc -I../vamp -O2 -g90 -gline -f2003 -C=all -pg -c expressions.f90  -pic -o .libs/expressions.o
NAG Fortran Compiler Release 5.2(686)
Warning: expressions.f90, line 1455: Unused dummy variable EN1
         detected at IGNORE_FIRST_LL@<end-of-statement>
Warning: expressions.f90, line 4816: Local variable PN_CLAUSE is default initialised but never used
         detected at EVAL_NODE_COMPILE_SPRINT@<end-of-statement>
Segmentation violation
Internal error - please report this bug

I have to see whether it's -g90, -O2 or the combination of the two.

[Christian Speckner]

Now I _strongly_ disagree. What I did was just changing the autoconf default (if CFLAGS is unset, mind you) for the _specific_ case of using nagfor; what TO is doing is _automatically_ changing CFLAGS which the user may be having good reasons for setting the way it is.

[Christian Speckner]

Talking about FCFLAGS, not CFLAGS, of course :)

[ohl]

Replying to cnspeckn:

Now I _strongly_ disagree. What I did was just changing the autoconf default (if CFLAGS is unset, mind you) for the _specific_ case of using nagfor; what TO is doing is _automatically_ changing CFLAGS which the user may be having good reasons for setting the way it is.

OK, I can live with checking whether FCFLAGS was given by the user and leaving this untouched. What I didn't like was that all flags in autoconf default were changed (which after all might not have been such a bad idea, in the light of nagfor's reaction to -O2 -g90 ...)

[ohl]

Replying to ohl:

I have to see whether it's -g90, -O2 or the combination of the two.

It's the -O2 ...

[Christian Speckner]

OK, then I would be in favor for reverting r2336 and keeping with r2327 which is precisely the conditional overwriting of the default FCFLAGS for nagfor... ;)

[ohl]

Replying to cnspeckn:

OK, then I would be in favor for reverting r2336 and keeping with r2327 which is precisely the conditional overwriting of the default FCFLAGS for nagfor... ;)

What about r2237?. It has the followin advantages over r2327:

• it doesn't forget O'Mega,
• it checks FC_VENDOR and not FC and
• it leaves all options othe than -g alone.

[Christian Speckner]

Huh? r2237 is a manual patch, I guess you are talking about r2337 :) As far as r2327 is concerned:

• My bad, sorry.
• Fair enough, but libtool actually checks for ${FC}, so if this is wrong, we will fail horribly anyways.
• ??? It should let all options alone, provided the user set them. If he didn't, we need a default, and "-g90" seems fine for me, but this can be changed to whatever one likes. Coincidentally, this is just what r2327 did.

Apart from that, I am fine with r2337, seeing that it does exactly the same as my previous patch in a slightly more complicated way (excluding the fact that I forgot to add the line to O'Mega)...

[ohl]

It does the same, but only as long as the autotools defaults are only -g for non-GNU compilers.

Anyway --- this has gone on far too long for such a trivial matter. Since we agree, I'm closing the ticket now.