Am 15.08.2012 18:26, schrieb Gabriel Dos Reis:
On Wed, Aug 15, 2012 at 11:21 AM, Tobias Burnus <bur...@net-b.de> wrote:
Gabriel Dos Reis wrote:
A few points to consider:
* relation of __builtin_function_location to C99 (and C++11) __func__
* Do we want to update libcpp to systematically expand __FILE__ to
__builtin_file_location, etc?
If you do so, please make sure that you don't break Fortran, which also uses
libcpp.
I hope Fortran also shares the gimplifier? How does it handler the
CPP macro assert which expands to a builtin?
Do you talk about the compiler itself, i.e. gcc/{,*/,*/*/}*.[ch]? Then,
of course the Fortran compiler is written in C (well, C++) and handles
the the CPP assert macro.
Otherwise, if you talk about using the libcpp internally for
pre-processing Fortran code via scan_translation_unit_trad,
scan_translation_unit etc.: Well, in that case, no built in is currently
handled. Given that Fortran code is translated into a Fortran AST and
only later into a gimple tree, that's probably not surprising.
If now libcpp in that process generates __builtin_file_location (...)
instead of a string, compilation will fail.
I admit that using the C pre-processor for Fortran is not well defined,
but as the Fortran's conditional compilation (coco) wasn't successful
and as all Fortran compiler support CPP (at least in the traditional
mode), we have to live with that. __FILE__ and __LINE__ belong to the
commonly used CPP expressions in Fortran code.
I don't mind that one adds __builtin* support to gfortran's parser. But
in any case, one should be aware of the problem before one modifies libcpp.
Tobias
