On Fri, 2015-08-28 at 17:56 +0100, Andre Vieira wrote:
[..snip..]
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/forwprop-33.c
> b/gcc/testsuite/gcc.dg/tree-ssa/forwprop-33.c
> new file mode 100644
> index
> ..984d8b37a01defe0e6852070a7dfa7ace5027c51
> --- /d
"pinter" -> "printer"
Committed to trunk as r227562, under the "obvious" rule.
gcc/ChangeLog:
* pretty-print.h (printer_fn): Fix typo in comment.
---
gcc/pretty-print.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/pretty-print.h b/gcc/pretty-print.h
index 6e8a3
On Thu, 2015-09-03 at 11:48 +0200, Richard Biener wrote:
> On Thu, Sep 3, 2015 at 7:26 AM, wrote:
> > From: Trevor Saunders
> >
> > Hi,
> >
> > Personally I think hiding that variables are pointers is confusing, and I
> > believe consensus is we should move away from this style. So this series
This is a followup to the ideas posted at:
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00837.html
I've been experimenting with capturing and printing richer
information for our diagnostics, underlining pertinent source ranges
when printing them, and potentially providing "fix-it" hints.
Attac
The function "diagnostic_show_locus" gains new functionality in the
next patch, so this preliminary patch breaks it out into a new source
file, diagnostic-show-locus.c, along with a couple of related functions.
gcc/ChangeLog:
* Makefile.in (OBJS-libcommon): Add diagnostic-show-locus.o.
location_get_source_line takes an expanded_location, but the column
is irrelevant; it just needs a filename and line number.
This change is used by, but independent of, the new implementation of
diagnostic_show_locus later in the kit, so am breaking this out early.
gcc/ChangeLog:
* input.
gcc/ChangeLog:
* gcc-rich-location.c (get_range_for_expr): New function.
(gcc_rich_location::add_expr): New method.
(gcc_rich_location::maybe_add_expr): New method.
(gcc_rich_location::add_expr_with_caption_va): New method.
(gcc_rich_location::add_expr_with_c
I don't yet have an explicit test case for these.
gcc/c/ChangeLog:
* c-parser.c (c_parser_declaration_or_fndef): Use token range
rather than location for a couple of warnings.
---
gcc/c/c-parser.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/c/c-pars
This patch adds an easy way to write tests for expected multiline
output. For example we can test carets and underlines for
a particular diagnostic with:
/* { dg-begin-multiline-output "" }
typedef struct _GMutex GMutex;
^~~
{ dg-end-multiline-output "" } */
It is used ex
This patch adds source *range* information to libcpp's cpp_token, and to
c_token and cp_token in the C and C++ frontends respectively.
To minimize churn, I kept the existing location_t fields, though in
theory these are always just equal to the start of the source range.
cpplib.h's struct cpp_tok
This patch makes use of token ranges in the C frontend to add underlines
to various diagnostics.
Screenshot:
https://dmalcolm.fedorapeople.org/gcc/2015-09-09/diagnostic-token-ranges.html
gcc/c/ChangeLog:
* c-decl.c (undeclared_variable): Convert param "loc" from a
location_t to a
This patch replaces the source_location in c_declspecs with
a source_range, and uses it for various diagnostics to gain
underlines.
Screenshot:
https://dmalcolm.fedorapeople.org/gcc/2015-09-09/bad-c-decls.html
gcc/c/ChangeLog:
* c-decl.c (declspecs_add_addrspace): Convert param 1 from
Screenshot:
https://dmalcolm.fedorapeople.org/gcc/2015-09-09/c++-token-ranges.html
gcc/cp/ChangeLog:
* parser.c (cp_parser_string_literal): Show ranges of both
string literals in the "unsupported concatenation" error.
(cp_parser_primary_expression): Use token range rather
This patch adds the ability to add "fix-it hints" to a rich_location,
which will be displayed when the corresponding diagnostic is printed.
It does not actually add any fix-it hints (that comes in a later
patch), but it adds test coverage of the machinery and printing,
by using the existing diagno
This is a proof-of-concept of
(a) using the string-literal location info to show locations of errors
in format strings, and
(b) underlining the corresponding argument where applicable (no more
having to guess what the compiler means by "argument 2")
In particular, this can handle format strings
Various followup patches convert variables from "location_t" to
"source_range". For the places where we issue diagnostics using
these variables, it's useful to have overloaded variants of
"warning_at" etc that take a source_range, allowing these
diagnostics to display underlines without needing to
This patch rewrites diagnostic_show_locus so that it can display
underlined source ranges in addition to the main caret.
It does this by introducing a new "rich_location" class, containing
a location and (potentially) some source ranges. These are to be
allocated on the stack when generating diag
This patch adds a way to associate source range information with tree
expressions and decls, for later use by diagnostics.
It's a poor implementation which is unacceptable on multiple grounds:
for starters, it adds a source_range (8 bytes) to struct tree_exp and
to struct tree_decl_minimal. (It a
This patch updates the C frontend to capture source_range information
for various kinds of tree expression.
It adds a unit test via a plugin, to verify the source ranges are
correct for many kinds of expression.
Screenshot:
https://dmalcolm.fedorapeople.org/gcc/2015-09-09/tree-range-unit-test.ht
This patch adds a test plugin that recurses down an expression tree,
printing diagnostics showing the ranges of each node in the tree.
Screenshot:
https://dmalcolm.fedorapeople.org/gcc/2015-09-09/show-trees.html
This needs a linker hack, since it's the only user of
gcc_rich_location::add_expr
gcc/ChangeLog:
* gcc-rich-location.c (cpp_string_fragment_location::debug): New.
(cpp_string_location::debug): New.
---
gcc/gcc-rich-location.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/gcc/gcc-rich-location.c b/gcc/gcc-rich-location.c
index 00
This patch uses the string-literal location generated in libcpp in the
previous patch, and stores it in tree_string (adding a new field there).
This hasn't been optimized. Perhaps the case of a single unbroken run
of 1-column per-char is the most common case, so we could only bother to
store the
This has not been optimized yet.
gcc/c-family/ChangeLog:
* c-common.c (fname_as_string): Initialize loc field of "cstr",
and call init_raw on strname.loc.
* c-lex.c (cb_ident): Initialize loc field of "cstr".
libcpp/ChangeLog:
* charset.c (struct _cpp_strbuf): Add
Screenshot:
https://dmalcolm.fedorapeople.org/gcc/2015-09-09/tree-ranges.html
This mostly affects the C frontend, but it touches c-common.h so the
C++ frontend needs a slight adjustment.
gcc/c-family/ChangeLog:
* c-common.c: Include gcc-rich-location.h.
(binary_op_error): Add par
Screenshot:
https://dmalcolm.fedorapeople.org/gcc/2015-09-10/spellcheck.html
There are a couple of FIXMEs here:
* where to call levenshtein_distance_unit_tests
* should we attempt error-recovery in c-typeck.c:build_component_ref
gcc/ChangeLog:
* Makefile.in (OBJS): Add spellcheck.o.
Screenshot:
https://dmalcolm.fedorapeople.org/gcc/2015-09-10/spellcheck-with-fixits.html
gcc/c/ChangeLog:
* c-parser.c (c_parser_declaration_or_fndef): Add fix-it
hint to "did you mean" suggestion.
* c-typeck.c (build_component_ref): Likewise.
gcc/testsuite/ChangeLog:
On Fri, 2015-09-11 at 16:07 +0200, Michael Matz wrote:
> Hi,
>
> On Thu, 10 Sep 2015, David Malcolm wrote:
>
> > +/* A range of source locations.
> > +
> > + Ranges are half-open:
> > + m_start is the first location within the range, whereas
> > +
On Mon, 2015-09-14 at 13:42 -0600, Jeff Law wrote:
> On 09/14/2015 11:43 AM, Bernd Schmidt wrote:
> > It's hard to provide meaningful review under these conditions. My advice
> > would be to resubmit the things that are ready now and can stand on
> > their own so that we can get them out of the way
On Tue, 2015-09-15 at 12:20 +0200, Jakub Jelinek wrote:
> On Tue, Sep 15, 2015 at 12:14:22PM +0200, Richard Biener wrote:
> > > diff --git a/gcc/cp/parser.h b/gcc/cp/parser.h
> > > index 760467c..c7558a0 100644
> > > --- a/gcc/cp/parser.h
> > > +++ b/gcc/cp/parser.h
> > > @@ -61,6 +61,8 @@ struct G
Updated patch attached, which is now independent of the rest of the
patch kit; see below. Various other comments inline.
On Fri, 2015-09-11 at 17:30 +0200, Manuel López-Ibáñez wrote:
On 10/09/15 22:28, David Malcolm wrote:
> > There are a couple of FIXMEs here:
> > * w
On Thu, 2016-11-03 at 17:43 +0100, Bernd Schmidt wrote:
> On 11/03/2016 05:35 PM, Martin Jambor wrote:
> >
> > * print-rtl.c (print_rtx_operand_codes_E_and_V): Print how many
> > times
> > an element is repeated istead of printing each repeated
> > element.
>
> "instead"
>
> > ---
> > g
(ping)
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01785.html
On Fri, 2016-10-21 at 13:45 -0400, David Malcolm wrote:
> On Fri, 2016-10-21 at 12:04 +0200, Bernd Schmidt wrote:
> > On 10/21/2016 02:36 AM, David Malcolm wrote:
> > > + /* Test dumping of hard regs. This is
On Fri, 2016-10-21 at 12:04 +0200, Bernd Schmidt wrote:
> On 10/21/2016 02:36 AM, David Malcolm wrote:
> > + ASSERT_RTL_DUMP_EQ ("(cjump_insn (set (pc)\n"
> > + "(label_ref 0))\n"
> > +
On Fri, 2016-11-04 at 18:51 +0100, Bernd Schmidt wrote:
> Here's something simpler. Only very lightly tested, but isn't
> something
> like this all that's needed? Could decide whether to apply it to
> expr_list etc. as well.
>
> Index: print-rtl.c
>
On Fri, 2016-11-04 at 19:53 +0100, Bernd Schmidt wrote:
> On 11/04/2016 08:14 PM, David Malcolm wrote:
> >
> > With this, compact dumps omit the trailing (nil) for both regular
> > insns
> > and for JUMP_INSNs, and omits the surplus newline seen in my
> > earlie
On Fri, 2016-11-04 at 20:40 +0100, Bernd Schmidt wrote:
> On 11/04/2016 08:25 PM, David Malcolm wrote:
>
> > return m_compact;
>
> Ok with this one plus a comment.
>
Thanks.
Using m_compact required turning the static function into a (private)
member function.
MODE, 0)
Is the attached patch OK as a fix? (assuming testing passes) Or should
these builtins have other attrs? (sorry, am not very familiar with the
sanitizer code).
Dave
From 6db5f9e50dc95f504d33970ee553172bbf400ae7 Mon Sep 17 00:00:00 2001
From: David Malcolm
Date: Mon, 7 Nov 2016
On Tue, 2016-10-25 at 14:47 +0200, Bernd Schmidt wrote:
> On 10/21/2016 10:27 PM, David Malcolm wrote:
> > Thanks. I attemped to use those fields of recog_data, but it
> > doesn't
> > seem to be exactly what's needed here.
>
> Yeah, I may have been confus
Whilst working on the RTL frontend, I ran into various crashes
relating to missing RTL information for params, for DECL_RTL, and
DECL_RTL_INCOMING.
These are normally set up for a PARM_DECL by "expand", but are
currently NULL when reading dumps from print_rtx_function.
Attempting to access DECL_R
On Tue, 2016-11-08 at 13:00 +0100, Martin Liška wrote:
> Hello.
>
> This is fallout fix where I changed:
>
> 1) Fix ICE for lambda functions (added test-case: use-after-scope
> -4.C)
> 2) Fix ICE in gimplify_switch_expr, at gimplify.c:2269 (fixed by not
> adding
> artificial variables)
> 3) PR te
On Wed, 2016-11-09 at 12:59 +0100, Bernd Schmidt wrote:
> On 11/08/2016 07:03 PM, David Malcolm wrote:
> > int __RTL("rtl-combine") f1 (int n)
> > {
> > (function "f1"
> > (param "n"
> > (DECL_RTL
> > (reg/v:SI %
On Wed, 2016-11-09 at 17:46 +0100, Bernd Schmidt wrote:
> On 11/09/2016 05:46 PM, David Malcolm wrote:
>
> > OK for trunk if it passes bootstrap and regrtest?
> >
> > gcc/ChangeLog:
> > * print-rtl-function.c (print_any_param_name): New function.
>
* More test cases. Use "dg-do run" in various places.
* Lots of bugfixing
I've successfully bootstrapped®rtested the kit as whole on
x86_64-pc-linux-gnu.
Stage 1 builds and passes selftesting and check-gcc with
RUNTESTFLAGS="rtl.exp=*" for target aarch64-linux-gnu.
OK for tru
Link to earlier version of the patch:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00278.html
gcc/ChangeLog:
* emit-rtl.c (gen_reg_rtx): Move regno_pointer_align and
regno_reg_rtx resizing logic to...
(emit_status::ensure_regno_capacity): ...this new method.
(ini
(approved by Bernd)
Move this part of "expand"'s initialization of crtl into its own
method so that it can used by the RTL frontend when postprocessing
RTL dumps.
gcc/ChangeLog:
* cfgexpand.c (pass_expand::execute): Move stack initializations
to rtl_data::init_stack_alignment and
Link to earlier discussion:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01690.html
This moves read_rtx and friends into rtx_reader, and splits
rtx_reader into two classes:
class md_reader: has responsibility for reading chars, managing
include files, top-level directives etc. It is the read-
Posted earlier here:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00651.html
Link to earlier discussion:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01801.html
This version:
- eliminates the rtx_reuse_manager singleton
- eliminates print-rtl-reuse.h, moving class rtx_reuse_manager into
prin
Link to discussion of earlier version of patch:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00260.html
On Wed, 2016-10-05 at 18:10 +0200, Bernd Schmidt wrote:
> On 10/05/2016 06:15 PM, David Malcolm wrote:
> > selftest: s-selftest
> > s-selftest: $(GCC_PASSES) cc1$(exeext
An earlier version of this was approved by Bernd as:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00280.html
and the changes since then probably fall under the "obvious" rule.
gcc/ChangeLog:
* read-md.c (rtx_reader::require_char): New method.
(require_char_ws): Convert from func
Changed in this version:
* Rather than running just one pass, run *all* passes, but start at
the given pass; support for "dg-do run" tests that execute the
resulting code.
* Updated test cases to new "compact" dump format; more test cases;
use "dg-do run" in various places.
* Lots of bugfixi
Link to previous discussion:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00648.html
On Mon, 2016-10-10 at 19:53 +0100, Richard Sandiford wrote:
> David Malcolm writes:
> > On Wed, 2016-10-05 at 18:00 +0200, Bernd Schmidt wrote:
> > > On 10/05/2016 06:15 PM, D
Changed in v4:
- error-handling changes split out into a separate patch
- rewritten the loader to use the new "compact" dump format
- support for reuse_rtx in loader
- handling of params, DECL_RTL and DECL_RTL_INCOMING
- moved target-dependent selftests to target-specific code
(aarch64.c and i386.c
This patch implements fix-it hints to -Wmissing-braces, showing where to
add braces.
For example:
$ cat test.c
int arr_2_3_2[2][3][2] =
{ 0, 1, 2, 3, 4, 5,
6, 7, 8, 9, 10, 11};
$ ./xgcc -B. -c test.c -Wall -fdiagnostics-generate-patch
test.c:2:3: warning: missing braces around
On Mon, 2016-11-14 at 15:17 +0100, Bernd Schmidt wrote:
> On 11/11/2016 10:15 PM, David Malcolm wrote:
> > Link to earlier version of the patch:
> > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00278.html
>
> Isn't this the same one?
>
It is; sorry. The rest
On Mon, 2016-11-14 at 16:14 +0100, Richard Biener wrote:
> On Fri, Nov 11, 2016 at 10:15 PM, David Malcolm
> wrote:
> > Changed in this version:
> >
> > * Rather than running just one pass, run *all* passes, but start at
> > the given pass; support for &quo
This patch addresses various bugs in the spellcheck code in which
the goal string somehow makes it into the candidate list.
The goal string will always have an edit distance of 0 to itself, and
thus is the "closest" string to the goal, but offering it as a
suggestion will always be nonsensical e.g.
Whilst investigating PR preprocessor/78324 I noticed that the
substring location code currently doesn't handle raw strings
correctly, by not skipping the 'R', opening quote, delimiter
and opening parenthesis.
For example, an attempt to underline chars 4-7 with caret at 6 of
this raw string yields
gcc.dg/tree-ssa/builtin-sprintf-2.c is showing intermittent failures, which
valgrind shows to be a read past the end of a buffer.
The root cause is that the on-demand substring loc code isn't set up
to cope with -ftrack-macro-expansion != 2 (the default).
In the failing case, it attempts to use t
On Wed, 2016-10-05 at 17:55 +0200, Bernd Schmidt wrote:
> On 10/05/2016 06:15 PM, David Malcolm wrote:
> > - /* Make sure regno_pointer_align, and regno_reg_rtx are large
> > - enough to have an element for this pseudo reg number. */
> > +
On Wed, 2016-11-16 at 14:24 +0100, Richard Biener wrote:
> On Tue, Nov 15, 2016 at 10:07 PM, David Malcolm
> wrote:
> > On Mon, 2016-11-14 at 16:14 +0100, Richard Biener wrote:
> > > On Fri, Nov 11, 2016 at 10:15 PM, David Malcolm <
> > > dmalc...@redhat.com>
On Fri, 2016-11-18 at 09:51 -0700, Martin Sebor wrote:
> > Martin: are the changes to your test cases OK by you, or is there
> > a better way to rewrite them?
>
> Thanks for looking into it!
>
> Since the purpose of the test_sprintf_note function in the test is
> to verify the location of the car
On Fri, 2016-11-18 at 22:13 +, Joseph Myers wrote:
> On Fri, 18 Nov 2016, David Malcolm wrote:
>
> > + /* Consume all tokens, up to the closing brace, handling
> > + matching pairs of braces in the rtl dump. */
> > + int num_open_braces = 1;
> > + while (1
On Fri, 2016-11-18 at 15:47 -0700, Martin Sebor wrote:
> On 11/18/2016 03:57 PM, David Malcolm wrote:
> > On Fri, 2016-11-18 at 09:51 -0700, Martin Sebor wrote:
> > > > Martin: are the changes to your test cases OK by you, or is
> > > > there
>
On Tue, 2016-11-22 at 14:37 +0100, Jakub Jelinek wrote:
> On Tue, Nov 22, 2016 at 02:32:39PM +0100, Bernd Schmidt wrote:
> > On 11/22/2016 02:18 PM, Dominik Vogt wrote:
> >
> > > > @@ -284,7 +292,7 @@ print_rtx_operand_code_i (const_rtx in_rtx,
> > > > int idx)
> > > > if (INSN_HAS_LOCATION
Does this fix the failing tests?
From 642d511fdba3a33fb18ce46c549f7c972ed6b14e Mon Sep 17 00:00:00 2001
From: David Malcolm
Date: Tue, 22 Nov 2016 11:06:41 -0500
Subject: [PATCH] print-rtl.c: conditionalize quotes for filenames
gcc/ChangeLog:
* print-rtl.c (rtx_writer::print_rtx_operand_code_i):
On Wed, 2016-11-23 at 21:15 +0100, Bernd Schmidt wrote:
> On 11/11/2016 10:15 PM, David Malcolm wrote:
>
> > +static void
> > +aarch64_test_loading_full_dump ()
> > +{
> > + rtl_dump_test t (SELFTEST_LOCATION, locate_file ("aarch64/times
> > -two.rtl&
The terminology within rich_location has become muddled, and
with the simplifications of the previous patch, I'd like to
rename things to better reflect what's going on.
A rich_location can contain one more more nested locations, each
of which can have a start, a finish, and optionally a caret.
Th
Previously, source_location/location_t values passed to
rich_location were immediately expanded (to expanded_location
instances stored inside the rich_location).
This patch updates the insides of class rich_location to delay
this expansion until the insides of diagnostic_show_locus.
This simplifi
Changes in v2:
- add two more testcases, based on additional reproducers
reported (one to the PR, another to a dup); now adds 17 PASS
results to gcc.sum.
- update for delayed expansion of locations within rich_location
and the terminology fixes from the other patches in this kit.
A
On Tue, 2015-11-24 at 13:43 +0100, Bernd Schmidt wrote:
> On 11/23/2015 07:26 PM, David Malcolm wrote:
> >
> > In theory we could attempt to try to handle this kind of thing by
> > looking at the macro expansions, and to print something like:
> >
>
When issuing diagnostics for _Static_assert, we currently ignore the
location/range of the asserted expression, and instead use the
location/range of the first token within it, which can be
incorrect for compound expressions:
error: expression in static assertion is not constant
_Static_assert
We can use rich_location and the new diagnostic_show_locus to print
*both* locations when complaining about a bogus string concatenation
in the C++ FE, giving e.g.:
test.C:3:24: error: unsupported non-standard concatenation of string literals
const void *s = u8"a" u"b";
~ ^
On Wed, 2015-12-09 at 18:44 +0100, Bernd Schmidt wrote:
> On 12/09/2015 05:58 PM, David Malcolm wrote:
> > On Wed, 2015-11-04 at 14:56 +0100, Bernd Schmidt wrote:
> >>
> >> This seems like fairly low impact but also low cost, so I'm fine with it
> >> in
In the C frontend,
c_parser_postfix_expression
after parsing a primary expression passes "loc", the location of the
*first token* in that expression to
c_parser_postfix_expression_after_primary,
which thus discards any range information we had for primary
expressions containing more than one to
On Wed, 2015-12-16 at 15:58 +0100, Marek Polacek wrote:
> The following improves the location for "statement with no effect" warning by
> using the location of the expression if available. Can't use EXPR_LOCATION as
> *_DECLs still don't carry a location.
Out of interest, does it emit sane underl
On Wed, 2015-12-16 at 16:09 +0100, Marek Polacek wrote:
> On Wed, Dec 16, 2015 at 10:04:05AM -0500, David Malcolm wrote:
> > On Wed, 2015-12-16 at 15:58 +0100, Marek Polacek wrote:
> > > The following improves the location for "statement with no effect"
> > >
Currently trunk emits range information for most bad binary operations
in the C++ frontend; but not in the C frontend.
The helper function binary_op_error shared by C and C++ takes a
location_t. In the C++ frontend, a location_t containing the range
has already been built, so we get the underline
On Wed, 2015-12-09 at 18:44 +0100, Bernd Schmidt wrote:
> On 12/09/2015 05:58 PM, David Malcolm wrote:
> > On Wed, 2015-11-04 at 14:56 +0100, Bernd Schmidt wrote:
> >>
> >> This seems like fairly low impact but also low cost, so I'm fine with it
> >> in
On Wed, 2015-12-16 at 00:52 +0100, Bernd Schmidt wrote:
> On 12/15/2015 08:30 PM, David Malcolm wrote:
>
> > I got thinking about what we'd have to do to support Perforce-style
> > markers, and began to find my token-matching approach to be a little
> > clunky
In the C FE, c_parser_statement_after_labels passes "xloc" to
c_finish_return, which is the location of the first token
within the returned expression.
Hence we don't get a full underline for the following:
diagnostic-range-bad-return.c:34:10: warning: function returns address of local
variable
cp_parser_parenthesized_expression_list can leave *close_paren_loc
untouched if an error occurs; specifically when following this goto:
7402 if (expr == error_mark_node)
7403goto skip_comma;
which can lead to cp_parser_postfix_expression attempting to
use uninitialize
On Thu, 2015-12-17 at 19:21 +0100, Bernd Schmidt wrote:
> On 12/17/2015 07:32 PM, David Malcolm wrote:
> > + if (close_paren_loc)
>
> close_paren_loc != UNKNOWN_LOCATION - it's very confusing otherwise.
>
>
> Bernd
Here's an updated ve
When debugging PR c++/68819 I noticed an inefficiency during
the handling of locations > LINE_MAP_MAX_LOCATION_WITH_COLS.
When combining ranges for locations with
start == caret == finish (with a NULL data ptr)
get_combined_adhoc_loc was always building an ad-hoc entry
rather than simply returnin
libcpp has a degraded fallback mode for large source files where if a
location_t > LINE_MAP_MAX_LOCATION_WITH_COLS
we fall back to just tracking lines, not columns&ranges
(currently 0x6000), and every location_t expands to having a
column == 0.
Sadly we're more likely to see this case in gcc 6
Looking over the discussion of missing semicolons in
"Quality of Implementation and Attention to Detail"
within
http://clang.llvm.org/diagnostics.html
and comparing with
https://gcc.gnu.org/wiki/ClangDiagnosticsComparison
I noticed that of the cases we do handle [1], there's room for
improvem
The following patch adds a fix-it insertion hint for missing
"template <> " in explicit specializations.
This is more of an enhancement than a bug fix (PR 62314 is more of a
catch-all for adding fix-its), but it's low-risk and a user-visible
improvement, and this specific example is called out as
When we emit a hint about a misspelled member name, it will slightly
aid readability if we use a fixit-hint to show the proposed
name in context within the source code (and in the future this
might support some kind of auto-apply in an IDE).
This patch adds such a hint to the C++ frontend, taking
Similar to the C++ case in the previous patch, but more involved as
the location of the pertinent token isn't readily available; the patch
adds it as a param to build_component_ref. All callers are updated to
provide the info, apart from objc_build_component_ref; fixing the latter
would lead to a
Currently, trunk emits this for a bad unary * in C:
bad-dereference.c:10:10: error: invalid type argument of unary ‘*’ (have ‘int’)
return *some_f.x;
^
The following patch fixes the reported location to highlight the
expression that was attempted to be dereferenced:
bad-dereference.
Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
OK for trunk?
gcc/c-family/ChangeLog:
PR c/69122
* c-indentation.c (get_visual_column): Remove default argument.
(should_warn_for_misleading_indentation): For the multiline case,
update call to get_visual_col
On Tue, 2016-01-05 at 19:23 +0100, Jakub Jelinek wrote:
> Hi!
>
> Now that input_location can be adhoc location (if it represents a location
> range rather than a single loc and it is long enough), we need to avoid
> passing it to cpp_included_before which compares locations as numbers.
> This can
On Tue, 2015-12-22 at 12:33 -0500, Patrick Palka wrote:
> We are emitting a bogus warning for the code
>
> do foo (0); while (flagA);
> ^--- NEXT
> ^ BODY
> ^--- GUARD
>
> In general I don't think we can get any useful indentation warning out
> of a
The attached patch adds information on various things to the
gcc-6/changes.html page:
* source-range-tracking (the patch merges the description of the string
location work into this, and updates the colorization of the example to
reflect gcc-6's behavior)
* fix-it hints
* hints for misspelled memb
On Tue, 2015-12-29 at 12:53 -0800, Mike Stump wrote:
> On Sep 25, 2015, at 1:11 PM, David Malcolm
> wrote:
> > +layout::layout (diagnostic_context * context,
> >> + const diagnostic_info *diagnostic)
> >>
> >> [...]
> >>
> >
PR c++/68795: fix uninitialized close_paren_loc in
cp_parser_postfix_expression (v2):
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01915.html
[PATCH 1/4] PR c++/62314: add fixit hint for missing "template <> " in
explicit specialization:
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01933.ht
On Mon, 2015-12-21 at 14:10 -0700, Jeff Law wrote:
> On 12/18/2015 01:21 PM, David Malcolm wrote:
>
> > I don't think there's a way to fix -Wmisleading-indentation if we're
> > in this state, so the first part of the following patch detects if
> > this
On Mon, 2015-12-21 at 22:20 +0100, Jakub Jelinek wrote:
> On Mon, Dec 21, 2015 at 02:10:17PM -0700, Jeff Law wrote:
> > On 12/18/2015 01:21 PM, David Malcolm wrote:
> >
> > >I don't think there's a way to fix -Wmisleading-indentation if we're
> > >i
On Mon, 2015-12-21 at 14:10 -0700, Jeff Law wrote:
> On 12/18/2015 01:21 PM, David Malcolm wrote:
>
> > I don't think there's a way to fix -Wmisleading-indentation if we're
> > in this state, so the first part of the following patch detects if
> > this
The root cause here is that the logic to reset the list of expected
multiline outputs was being run from:
handle-multiline-outputs, called by
prune.exp's prune_gcc_output
and none of that happens if the test is skipped by a target exclusion
in dg-do.
This patch moves the clearing of the rele
On Mon, 2016-01-11 at 16:51 +0100, Bernd Schmidt wrote:
> On 12/18/2015 08:05 PM, David Malcolm wrote:
> > On Thu, 2015-12-17 at 19:21 +0100, Bernd Schmidt wrote:
> >> On 12/17/2015 07:32 PM, David Malcolm wrote:
> >>> + if (close_paren_
3301 - 3400 of 5457 matches
Mail list logo
