Re: Compiler options as string?

[Tobias Burnus <burnus at net-b dot de>]

 Basile Starynkevitch wrote:
> On Sat, 25 Sep 2010 14:31:31 +0200 Tobias Burnus<burnus@net-b.de>  wrote:
> > Fortran 2008 offers an intrinsic function called "compiler_options", which returns "a processor-dependent value which describes the options that controlled the translation phase of program execution." (Cf. PR 40569
> I don't know if it is the best way of doing it [...] but the naive way of doing that
> probably could be to store the program arguments in yet another globals, e.g.
>    extern int toplevel_argc;
>    extern char** toplevel_argv;

Well, that's of course the simplest solution - a variant is to make them 
only local to toplev.c but add a function to retrieve them. Another 
possibility is to follow the current printing method (for .asm files) 
and stitch the decoded arguments together - possibly skipping some 
options like -dumpbase or the file name. Here, again, the question is in 
which form one wants to make those available - as single string? As 
array of strings - one per each argument?

> I am not sure to understand the intend of the standard. In particular, even if I transpose to C, I cannot understand the value of having a __builtin (or perhaps a CPP predefined macro) giving the equivalent inside C programs. Why does a standard want such things?


Well, you might have compiled a program with certain options 
"-Dsomething -O3" and with some other options. Later you wonder why one 
program works and the other doesn't.

In that case it is helpful to know with which compiler version and which 
options one has compiled the program. Thus, some programs store this 
information and print the output when run; for instance octopus does so, 
cf. 
http://www.tddft.org/trac/octopus/browser/trunk/src/basic/global.F90#L145

The disadvantage of doing it in the octopus way are twofold: (a) It only 
works with a more complicated build system and pre-processing of the 
source files [here: configure + cpp] and (b) in Fortran, a line is only 
allowed to be 72 (fixed form) or 132 (free form) characters long - the 
FCFLAGS might be longer.

> Do you have an idea of what competitor fortran compilers are doing with
> the compiler_options intrinsic? compiler_options intrinsic?

No, but if you have a monolithic compiler (w/o splitting driver and 
compiler) and with having a global variable (or a function which returns 
the value of the local static variable) that's rather simple.

> > I think most users would prefer to have the options to
> > the driver ("gfortran") rather than the one to the compiler ("f951").
> But then, you need a patch both for gfortran and for f951.

Well, I said that's the ideal output - sometimes the f951 output is also 
better, e.g. when instead of "-march=native" you would like to know the 
real values (--param, -march=... etc.)

The simplest, still conforming but a bit pointless implementation is to 
simply return the string "".

Tobias