public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: gcc-patches@gcc.gnu.org,	Andreas Schwab <schwab@suse.de>
Cc: David Malcolm <dmalcolm@redhat.com>
Subject: [PATCH] C: fix logic within c_expr::get_location
Date: Wed, 23 Aug 2017 19:35:00 -0000	[thread overview]
Message-ID: <1503511727-32388-1-git-send-email-dmalcolm@redhat.com> (raw)
In-Reply-To: <mvm378jn9xc.fsf@suse.de>

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.  It could be argued that this could be papering over
    other "missing location" bugs, but if there are any, 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 bugs that may
    be lurking in the codebase.

Successfully bootstrapped&regrtested on x86_64-pc-linux-gnu;
I've verified the fix with --target=m68k-elf.

OK for trunk?

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.
---
 gcc/c-family/c-lex.c | 2 +-
 gcc/c/c-tree.h       | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/c-family/c-lex.c b/gcc/c-family/c-lex.c
index 3765a80..a614b26 100644
--- a/gcc/c-family/c-lex.c
+++ b/gcc/c-family/c-lex.c
@@ -988,7 +988,7 @@ interpret_float (const cpp_token *token, unsigned int flags,
     }
 
   if (type != const_type)
-    value = build1 (EXCESS_PRECISION_EXPR, type, value);
+    value = build1_loc (token->src_loc, EXCESS_PRECISION_EXPR, type, value);
 
   return value;
 }
diff --git a/gcc/c/c-tree.h b/gcc/c/c-tree.h
index 5182cc5..96c7ae7 100644
--- a/gcc/c/c-tree.h
+++ b/gcc/c/c-tree.h
@@ -149,7 +149,7 @@ struct c_expr
 
   location_t get_location () const
   {
-    if (CAN_HAVE_LOCATION_P (value))
+    if (EXPR_HAS_LOCATION (value))
       return EXPR_LOCATION (value);
     else
       return make_location (get_start (), get_start (), get_finish ());
-- 
1.8.5.3

  parent reply	other threads:[~2017-08-23 17:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-19 20:23 [PATCH 1/2] c-family/c/c++: pass optional vec<location_t> to c-format.c David Malcolm
2017-08-19 18:22 ` [PATCH 2/2] C: use full locations within c_parser_expr_list's vec<location_t> David Malcolm
2017-08-21 15:32   ` Joseph Myers
2017-08-22 11:40   ` Andreas Schwab
2017-08-23 16:01     ` David Malcolm
2017-08-23 19:35     ` David Malcolm [this message]
2017-08-24 11:23       ` [PATCH] C: fix logic within c_expr::get_location Marek Polacek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1503511727-32388-1-git-send-email-dmalcolm@redhat.com \
    --to=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=schwab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).