public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bernd Schmidt <bschmidt@redhat.com>
To: David Malcolm <dmalcolm@redhat.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: Fix 69650, bogus line numbers from libcpp
Date: Tue, 22 Mar 2016 01:35:00 -0000	[thread overview]
Message-ID: <56F07CA0.5040607@redhat.com> (raw)
In-Reply-To: <1458591323.9902.81.camel@redhat.com>

On 03/21/2016 09:15 PM, David Malcolm wrote:
> On Mon, 2016-03-14 at 14:20 +0100, Bernd Schmidt wrote:
>> On 03/11/2016 11:09 PM, David Malcolm wrote:
>>>> +	  cpp_error (pfile, CPP_DL_ERROR,
>>>> +		     "file \"%s\" left but not entered",
>>>> new_file);
>>>                                                            ^^^^^^^^
>>> Although it looks like you're preserving the existing behavior from
>>> when this was in linemap_add, shouldn't this be
>>>     ORDINARY_MAP_FILE_NAME (from)
>>> rather than new_file?  (i.e. shouldn't it report the name of the
>>> file
>>> being *left*, rather than the one being entered?)
>
> I realize now that I was wrong here: "new_file" refers to the filename
> given in the linemarker directive, which, depending on the (optional)
> flag could be a directive to enter or leave a linemap.
>
> Sorry about that; you may want to disregard my earlier worries.

No, I think you were mostly on point: new_file is the one in the #line 
directive, which AFAICT is the file being reentered. so the wording is 
in fact misleading. Including a file called "t.h" from "v.c" produces 
this pattern:

# 1 "t.h" 1
int t;
# 2 "v.c" 2

> I was thinking of something like the attached, which makes things more
> explicit; I felt the first dg-error in your patch was a little too
> concise.

No problem, but I do think we want to change the wording of the message 
to something like "file %s unexpectedly reentered".

> I'm very familiar with the code for tracking ranges and issuing
> diagnostics, but less familiar with other parts of libcpp, so I'm not
> sure I'm fully qualified to approve the patch.  That said, the patch
> looks sane, mostly...  The remaining thing I have a concern about
> relates to the other question I had, which I don't think you addressed:
> is it possible to construct a testcase that triggers the logic in the
> non-MAIN_FILE_P clause?

Are you thinking of anything more complex than the following?

# 1 "v.c"
# 1 "t.h" 1
# 1 "t2.h" 1
int t;
# 2 "t.h" 2
# 2 "v.c" 2

Change any of the filenames of the "^#.*2$" lines and you'll see error 
messages. For example, changing "t.h" to "x.h" in the second to last line:

In file included from t.h:1:0,
                  from v.c:1:
t2.h:2:13: error: file "x.h" left but not entered
t2.h:3:12: error: file "v.c" left but not entered

Of course any such error is likely to have a large number of follow-on 
errors. Not sure how to avoid this given that the input file most likely 
has a completely messed up structure.

> (How much existing test coverage do we have for line-markers?  I found
> about 15 existing testcases that use them in a crude search with grep,
> but these are all apparently only incidentally as part of testing other
> functionality; is it worth me adding some more general test coverage
> for this?)

It might be worthwhile but I'm not planning to for this issue.


Bernd

  reply	other threads:[~2016-03-21 22:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <56E12FFF.6050800@t-online.de>
2016-03-10  8:40 ` Bernd Schmidt
2016-03-11 22:09   ` David Malcolm
2016-03-14 13:20     ` Bernd Schmidt
2016-03-21 14:58       ` Bernd Schmidt
2016-03-21 20:17       ` David Malcolm
2016-03-22  1:35         ` Bernd Schmidt [this message]
2016-03-23 12:58           ` Richard Biener
2016-03-23 13:21             ` Bernd Schmidt
2016-03-23 14:39               ` Richard Biener
2016-03-24 16:21                 ` Bernd Schmidt
2016-03-24 21:42                   ` Jeff Law
2016-03-25 18:25                     ` Jeff Law

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=56F07CA0.5040607@redhat.com \
    --to=bschmidt@redhat.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    /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).