C++ and gather-detailed-mem-stats

Tobias Burnus burnus@net-b.de
Wed Aug 15 16:42:00 GMT 2012

Am 15.08.2012 18:26, schrieb Gabriel Dos Reis:
> On Wed, Aug 15, 2012 at 11:21 AM, Tobias Burnus <burnus@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.


More information about the Gcc mailing list