Alexandre Oliva <aol...@redhat.com> writes:
> On Jul 16, 2011, Dodji Seketeli <do...@redhat.com> wrote:
>
>> This patch adds -fdebug-cpp option. When used with -E this dumps the
>> relevant macro map before every single token. This clutters the output
>> a lot but has proved to be invaluable in tracking some bugs during the
>> development of the virtual location support.
>
> Any way to read that back in while compiling a preprocessed file, so
> that ccache et al can use this flag to get the same location information
> that would have been gotten without separate preprocessing?
Jakub Jelinek <ja...@redhat.com> writes:
>
> For ccache and friends I think it would be better to have a preprocessing
> mode that would output all lines as is (i.e. no macro replacement), except
> for processing #include/#include_next directives.
Would that be enough for, say, when people submit bug reports to GCC? I
think it would but maybe I am missing some corner cases.
Tom Tromey <tro...@redhat.com> writes:
>>>>>> "Jakub" == Jakub Jelinek <ja...@redhat.com> writes:
>
> Jakub> For ccache and friends I think it would be better to have a
> Jakub> preprocessing mode that would output all lines as is (i.e. no
> Jakub> macro replacement), except for processing #include/#include_next
> Jakub> directives.
>
> That exists -- -fdirectives-only.
>
> Tom
Jakub Jelinek <ja...@redhat.com> writes:
> On Mon, Aug 22, 2011 at 08:16:45AM -0600, Tom Tromey wrote:
>> >>>>> "Jakub" == Jakub Jelinek <ja...@redhat.com> writes:
>>
>> Jakub> For ccache and friends I think it would be better to have a
>> Jakub> preprocessing mode that would output all lines as is (i.e. no
>> Jakub> macro replacement), except for processing #include/#include_next
>> Jakub> directives.
>>
>> That exists -- -fdirectives-only.
>
> It isn't exactly what would be needed, as e.g. \\\n are removed from
> from #defines and thus they get different location of the tokens.
Would it be acceptable to just change the output of -fdirective to fit?
Or are we bound to not breaking existing consumers?
>
> BTW, I guess we should do something about parsing such an output,
> we emit e.g.
> # 1 "<stdin>"
> # 1 "<built-in>"
> #define __STDC__ 1
> #define __STDC_HOSTED__ 1
> #define __GNUC__ 4
> #define __GNUC_MINOR__ 6
> #define __GNUC_PATCHLEVEL__ 0
> ...
>
> For <built-in> we really should assume line 0 for all the defines
> in that "file".
Right now BUILTIN_LOCATION is defined to 1 at least the C/C++ FEs. Are
you saying defines should have UNKNOWN_LOCATION (which is 0) instead?
OTOH, c_builtin_function already sets the location of c builtins to
UNKNOWN_LOCATION. Which makes me wonder what BUILTIN_LOCATION is
actually good for then. :-)
--
Dodji
