This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ and gather-detailed-mem-stats

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]