On Wed, 15 Aug 2012, Tobias Burnus wrote:
> 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.
I don't think making libcpp emit builtin calls is good. Consider -E.
Richard.
