Andrew Pinski wrote:
> Does anyone know of the status of --enable-mapped-location? I tried to
> do a bootstrap and test and I got a lot of failures due to getting the
> wrong line number and file for the error message when dealing with
macros.
I took a look. The status doesn't seem to have changed much
- for good or ill.
There is a new set of failures from builtin-stringop-chk-1.c,
which is a new testcase. These are the kind you mention.
I believe the issue is that --enable-mapped-location gives
us more precise error locations based on an individual token
rather than at the statement level. If the token associated
with the error comes from a macro expansion text, then we
will see the location in the macro definition.
I don't think the implemented behavor is *wrong*, but it
probably isn't the most *useful*.
Ideally it would be nice to show the "macro nesting" just
like we do for "include nesting". I.e. add "In macro expanded at"
lines. That shouldn't be very difficult with the line-map
framework, though it would require more line_map entries in
the line_table. For that reason, and perhaps because it might be
"too much information" perhaps it shouldn't be the default.
The default should probably be that positions from macro expansion
text should be replaced by the position of the macro call. I don't
know how easily that is available, or if we need a new data structure.
Of course tokens that come from the application site (i.e. macro
parameters) should get the location of the application site, as I
believe the code currently does. Finally, we have to handle macros
that call macros.
Other errors are pch-related, due to the pch machinery not saving and
restoring the line-table, as discussed in this thread:
http://gcc.gnu.org/ml/gcc/2005-03/msg01318.html
I get a bunch of failures in the libstdc++ tests, for example:
FAIL: 23_containers/map/operators/1_neg.cc (test for errors, line 209)
The problem is the line number of the "candidates" is garbage.
This is nasty because it appears to be optimization-related: I tried
recompiling without optimization and the problem went away.
Trying to debug an optimized cc1plus I found that diagnostic.location
is trashed when print_z_candidates calls gettext here:
2444 str = _("candidates are:");
Perhaps there is an aliasing bug somewhere?
I really would welcome someone else looking at one or more
of these, as I'm really behind on other (paying) projects.
--
--Per Bothner
[EMAIL PROTECTED] http://per.bothner.com/
