Re: Compiler options as string?

[Basile Starynkevitch <basile at starynkevitch dot net>]

On Sat, 25 Sep 2010 14:31:31 +0200
Tobias Burnus <burnus@net-b.de> wrote:

>   I wonder what is the best way to obtain the compiler options as string 
> in a front end.
> 
> Background: 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 forgot to mention that I don't know much Fortran (the last time I
hacked a Fortran program, it was Fortran77 code more than 20 years
ago), and more importantly 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?

There are of course cases where an application is interested in
recording how it was configured & built (GCC itself is a valid
example), but that is the configuration's job (i.e. autoconf, make, ...
variables).

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

> 
> PS: Some options such as FE specific options end up in gfc_handle_option 
> (alias lang_hooks.handle_option) but those to not contain options such 
> as "-march=native", "-O3" or "-m32" which users presumably would like to 
> see recorded. -- 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. So
toplevel.c is not enough to patch, you probably want to patch gcc.c (or
its fortran equivalent) itself.

If you make it into a patch, I would be delighted if it was not Fortran
specific. At least, some plugins can be interested in knowing every
option passed to gcc (in particular, for C or C++, optimization options
and also preprocessor options like -D or -I). I would imagine cases
where a GCC MELT extension would benefit from knowing all these options
(a silly example would be a plugin which wants to optimize some call;
for example, a good plugin which does the fprintf(stdout, ...) => printf
(...) optimization should know that the fprintf is coming from
<stdio.h> and was not redefined by the user).


But I am a bit surprized that the Fortran standardization committee
designed such a compiler_options intrinsics. Maybe there are
non-official documentation or draft motivating that addition to the
standard.

Cheers.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***