C: fix logic within c_expr::get_location
authorDavid Malcolm <dmalcolm@redhat.com>
Thu, 24 Aug 2017 14:28:16 +0000 (14:28 +0000)
committerDavid Malcolm <dmalcolm@gcc.gnu.org>
Thu, 24 Aug 2017 14:28:16 +0000 (14:28 +0000)
commit14e18d7100de30f3c2991401bbb414d2e3ffb716
tree5542f916a0b042bb557eb0d1ec63a38f76dc078e
parent845c76ce64bf1cbfcf89651ff84ce8abc28533af
C: fix logic within c_expr::get_location

In r251239 I added a c_expr::get_location method for use by
c_parser_expr_list for building the vec<location_t> for
an expression list, rather than using the location of the first token.

When determining whether to use the location within the tree node,
or fall back to the range in the c_expr, I used EXPR_CAN_HAVE_LOCATION,
rather than EXPR_HAS_LOCATION.  This meant that any tree nodes of kinds
that *can* have a location but which erroneously had
   EXPR_LOCATION (value) == UNKNOWN_LOCATION
had that value added to the vec<location_t>, leading to missing
location information when reporting on the issue
(seen with gcc.dg/Wtraditional-conversion-2.c for m68k).

This patch addresses this in two ways:

(a) it fixes the specific issue in this failing test case, by
    setting up the location properly on the EXCESS_PRECISION_EXPR.

(b) updating c_expr::get_location by only using the EXPR_LOCATION
    if it's sane.  Arguably this is papering over bugs, but they are
    pre-existing ones exposed by r251239, and I'd rather have this
    fix in place than play whack-a-mole on any other such "missing
    location" bugs that are lurking in the codebase.

gcc/c/ChangeLog:
* c-tree.h (c_expr::get_location) Use EXPR_HAS_LOCATION rather
than CAN_HAVE_LOCATION_P when determining whether to use the
location_t value within "value".

gcc/c-family/ChangeLog:
* c-lex.c (interpret_float): Use token location
when building an EXCESS_PRECISION_EXPR.

From-SVN: r251335
gcc/c-family/ChangeLog
gcc/c-family/c-lex.c
gcc/c/ChangeLog
gcc/c/c-tree.h