public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/97932] [8/9/10/11 Regression] Preprocessor, generated error dumps most of the source file, not just one line by r6-5941 Date: Thu, 04 Feb 2021 20:23:47 +0000 [thread overview] Message-ID: <bug-97932-4-Necr6h3tR0@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-97932-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97932 --- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by David Malcolm <dmalcolm@gcc.gnu.org>: https://gcc.gnu.org/g:65c1cb358999e9d1618834af341b31837ede839e commit r11-7105-g65c1cb358999e9d1618834af341b31837ede839e Author: David Malcolm <dmalcolm@redhat.com> Date: Thu Feb 4 15:20:59 2021 -0500 diagnostics: fix excessive range-printing involving macros [PR97932] PR c/97932 describes a bug in which diagnostic_show_locus prints most of a source file. The issue is that it prints a range in which the start and end locations are part of the same macro map, but the start location is for a token in the definition of the macro, whereas the end location is for a token in an argument of the macro. This patch extends compatible_locations_p to require that range-printing of macro maps requires the location to either be both for the definition of the macro, or both for the arguments of the macro (not one of each), fixing the issue. gcc/ChangeLog: PR c/97932 * diagnostic-show-locus.c (compatible_locations_p): Require locations in the same macro map to be either both from the macro definition, or both from the macro arguments. gcc/testsuite/ChangeLog: PR c/97932 * gcc.dg/pr97932.c: New test.
next prev parent reply other threads:[~2021-02-04 20:23 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-21 8:27 [Bug c/97932] New: Preprocessor, generated error dumps most of the source file, not just one line lance.delahaye at gmail dot com 2020-11-21 9:21 ` [Bug c/97932] " pinskia at gcc dot gnu.org 2020-11-21 10:19 ` lance.delahaye at gmail dot com 2020-11-21 10:26 ` lance.delahaye at gmail dot com 2020-11-21 14:34 ` [Bug c/97932] [8/9/10/11 Regression] Preprocessor, generated error dumps most of the source file, not just one line by r6-5941 hjl.tools at gmail dot com 2020-11-23 7:31 ` rguenth at gcc dot gnu.org 2021-02-03 13:07 ` jakub at gcc dot gnu.org 2021-02-03 14:21 ` dmalcolm at gcc dot gnu.org 2021-02-04 20:23 ` cvs-commit at gcc dot gnu.org [this message] 2021-02-04 20:30 ` [Bug c/97932] [8/9/10 " dmalcolm at gcc dot gnu.org 2021-05-14 9:54 ` [Bug c/97932] [9/10 " jakub at gcc dot gnu.org 2021-06-01 8:18 ` rguenth at gcc dot gnu.org 2022-05-27 9:43 ` [Bug c/97932] [10 " rguenth at gcc dot gnu.org 2022-06-28 10:42 ` jakub at gcc dot gnu.org 2023-07-07 9:13 ` rguenth at gcc dot gnu.org
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=bug-97932-4-Necr6h3tR0@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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: linkBe 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).