This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix BUILTINS_LOCATION with -fpreprocessed (PR preprocessor/41543)
- From: Tom Tromey <tromey at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 12 Oct 2009 11:38:11 -0600
- Subject: Re: [PATCH] Fix BUILTINS_LOCATION with -fpreprocessed (PR preprocessor/41543)
- References: <20091012115141.GI14664@tyan-ft48-01.lab.bos.redhat.com>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "Jakub" == Jakub Jelinek <jakub@redhat.com> writes:
Jakub> As discussed in the PR, BUILTINS_LOCATION is broken with
Jakub> -fpreprocessed, as it doesn't map onto <built-in>:0:0, but to the
Jakub> first character in the preprocessed source (which means e.g. that
Jakub> debuginfo created with -save-temps or ccache references the name
Jakub> of the preprocessed source).
Jakub> Fixed by making BUILTINS_LOCATION also special like UNKNOWN_LOCATION,
Jakub> location 2 is now the first character in the source file (with
Jakub> -fpreprocessed in the preprocessed source file), instead of 1.
These magic locations are a bit funny. Currently, each front end is
responsible for ensuring that they are set properly.
I'm in favor of changing this, and I think this patch is pretty
reasonable as a first step, but I also think it doesn't go far enough.
E.g., code like this in c-opts.c should probably be removed:
cb_file_change (parse_in,
linemap_add (line_table, LC_RENAME, 0,
_("<built-in>"), 0));
Or am I missing something?
Jakub> --- libcpp/line-map.c.jj 2009-05-04 16:46:48.000000000 +0200
Jakub> +++ libcpp/line-map.c 2009-10-12 11:07:59.000000000 +0200
Jakub> @@ -38,8 +38,8 @@ linemap_init (struct line_maps *set)
[...]
Jakub> + set->highest_location = 1;
Jakub> + set->highest_line = 1;
If we are going to make this special in libcpp, then I think the #define
should be in line-map.h. (UNKNOWN_LOCATION should also go there.)
I resisted this idea last time it came up, thinking that
BUILTINS_LOCATION should still be something specific to gcc. But today
I don't really mind either way, it is just a single location value.
Tom