Amongst other changes, r266077 updated value_range_base::dump so
that it additionally prints the type. This broke an assertion within
the jit testsuite, in jit.dg/test-sum-of-squares.c, which was checking
for:
": [-INF, n_"
but was now getting:
": signed int [-INF, n_"
The test is merely inte
On Wed, 2019-07-31 at 10:42 +0200, Martin Liška wrote:
> Hi.
>
> As seen here:
> https://github.com/RPGillespie6/fastcov/pull/18/files/f184dd8b6fc14e0
> 75dfc0ea93de7be5c96298ddb#r308735088
>
> GCOV uses json::number for branch count, line count and similar.
> However, the json library
> uses a d
On Wed, 2019-07-31 at 15:14 -0400, Jason Merrill wrote:
> On 7/24/19 5:24 PM, Paolo Carlini wrote:
> > this takes care of the four locations, two warnings and two errors.
> > I'm
> > also adding the missing complain & tf_warning or tf_error guards,
> > I
> > don't have a SFINAE testcase failing b
On Fri, 2019-08-02 at 14:02 +0200, Paolo Carlini wrote:
> Hi,
>
> On 31/07/19 21:39, David Malcolm wrote:
>
> [snip]
> > I don't care for "cp_expr_loc_or_loc".
> >
> > By "_or_here" do you mean "or input_location"?
> &g
On Fri, 2019-08-02 at 12:22 +0200, Martin Liška wrote:
> On 7/31/19 3:13 PM, David Malcolm wrote:
> > On Wed, 2019-07-31 at 10:42 +0200, Martin Liška wrote:
> > > Hi.
> > >
> > > As seen here:
> > > https://github.com/RPGillespie6
On Wed, 2019-08-14 at 12:02 +0100, Jonathan Wakely wrote:
> On 13/08/19 16:07 -0400, Jason Merrill wrote:
> > On 8/13/19 9:32 AM, Jonathan Wakely wrote:
> > > * g++.dg/lookup/missing-std-include-6.C: Don't check
> > > make_unique in
> > > test that runs for C++11.
> >
> > I'm not comfortab
On Wed, 2019-08-14 at 16:53 +0100, Jonathan Wakely wrote:
> On 14/08/19 10:39 -0400, David Malcolm wrote:
> > On Wed, 2019-08-14 at 12:02 +0100, Jonathan Wakely wrote:
> > > On 13/08/19 16:07 -0400, Jason Merrill wrote:
> > > > On 8/13/19 9:32 AM, Jonathan Wakely
On Wed, 2019-08-14 at 23:36 +0200, Jose E. Marchesi wrote:
> Hi people!
>
[...]
> The second patch adds the new GCC port proper. Machine description,
> implementation of target hooks and macros, command-line options and
> the like.
Looks like [PATCH 2/8] didn't make it to the mailing list for
PR fortran/91426 reports that the following program
program main
10 continue
10 continue
end
yields:
label.f90:2:2:
2 | 10 continue
| 1
3 | 10 continue
| 2
Error: Duplicate statement label 10 at (1) and (2)
where the '1' and '2' annotating lines 2 and 3 in the source are
On Thu, 2018-10-11 at 10:31 -0400, Jason Merrill wrote:
> On Thu, Oct 11, 2018 at 10:28 AM Jason Merrill
> wrote:
> >
> > On Wed, Oct 10, 2018 at 5:01 PM David Malcolm
> > wrote:
> > > On Tue, 2018-10-09 at 18:38 -0400, Jason Merrill wrote:
> > > >
Here's a proposed "User Experience Guidelines" section for our
internals manual
It's a mixture of proposed policy, together with notes on how to
implement the recommendations.
Thoughts?
gcc/ChangeLog:
* Makefile.in (TEXI_GCCINT_FILES): Add ux.texi.
* doc/gccint.texi: Include ux.t
[re this thread "ToT build failure?":
https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00344.html ]
On Thu, 2017-07-06 at 20:58 +0200, Jakub Jelinek wrote:
> On Thu, Jul 06, 2017 at 01:45:42PM -0400, David Malcolm wrote:
> > Given that the previous status quo of the selft
On Fri, 2018-10-12 at 14:45 -0400, David Malcolm wrote:
> [re this thread "ToT build failure?":
> https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00344.html ]
>
> On Thu, 2017-07-06 at 20:58 +0200, Jakub Jelinek wrote:
> > On Thu, Jul 06, 2017 at 01:45:42PM -0400, Davi
On Fri, 2018-10-12 at 14:17 -0400, David Malcolm wrote:
> On Fri, 2018-10-12 at 14:45 -0400, David Malcolm wrote:
> > [re this thread "ToT build failure?":
> > https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00344.html ]
> >
> > On Thu, 2017-07-06 at 20:58 +02
On Tue, 2018-09-18 at 02:33 +0200, Iain Buclaw wrote:
> This patch adds the D front-end implementation, the only part of the
> compiler that interacts with GCC directly, and being the parts that I
> maintain, is something that I can talk about more directly.
>
> For the actual code generation pass
On Sun, 2018-10-14 at 11:01 -0600, Martin Sebor wrote:
> On 10/12/2018 09:43 AM, David Malcolm wrote:
> > Here's a proposed "User Experience Guidelines" section for our
> > internals manual
> >
> > It's a mixture of proposed policy, together with no
"error_at_rich_loc" went away in r254280 (in favor of overloading
"error_at"), but there was a stray reference in a comment.
Remove it.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Committed to trunk as r265177.
gcc/ChangeLog:
* gcc-rich-location.h (gcc_rich_location::a
This patch adds a minimum width to the left margin used for printing
line numbers. I set the default to 6. Hence rather than:
some-filename:9:1: some message
9 | some source text
| ^~~~
some-filename:10:1: another message
10 | more source text
| ^~~~
we now print:
I've been extending -fopt-info to cover inlining, and I added a %S
format code to dump_printf which accepts a symtab_node *.
Unfortunately, -Wformat doesn't like the fact that I'm passing in a
subclass pointer (cgraph_node *), e.g.:
ipa-inline.c: In function ‘unsigned int early_inliner(function*)
On Tue, 2018-10-16 at 14:26 -0600, Jeff Law wrote:
> On 10/13/18 7:12 AM, David Malcolm wrote:
> > On Fri, 2018-10-12 at 14:17 -0400, David Malcolm wrote:
> > > On Fri, 2018-10-12 at 14:45 -0400, David Malcolm wrote:
> > > > [re this thread "ToT build failure?
On Thu, 2018-10-18 at 15:09 +0200, Richard Biener wrote:
> PR63155 made me pick up this old work from Steven, it turns our
> linked-list implementation to a two-mode one with one being a
> splay tree featuring O(log N) complexity for find/remove.
>
> Over Stevens original patch I added a bitmap_tr
In r264887 I broke the build of 502.gcc_r due to an ICE.
The ICE occurs when generating a location for an sprintf warning within
a string literal, where the sprintf call is in a macro.
The root cause is a bug in the original commit of substring locations
(r239175). get_substring_ranges_for_loc ha
On Thu, 2018-10-18 at 07:59 +0200, Eric Botcazou wrote:
> > Thanks; I've committed this to trunk as r265240.
>
> You modified gcc-interface/Make-lang.in without ChangeLog entry.
Oops. I've double-checked my ChangeLog-writing script [1], and it did
generate an entry for ada, but I believe I accid
On Tue, 2018-10-16 at 21:39 -0600, Sandra Loosemore wrote:
> On 10/12/2018 09:43 AM, David Malcolm wrote:
> > Here's a proposed "User Experience Guidelines" section for our
> > internals manual
> >
> > It's a mixture of proposed policy,
On Thu, 2018-10-18 at 22:25 -0600, Sandra Loosemore wrote:
> On 10/18/2018 03:12 PM, David Malcolm wrote:
>
> > Here's an updated version of the patch, addressing your above
> > comments,
> > and those from Martin and Richard (I hope).
>
> Thanks, this
On Mon, 2018-10-22 at 15:56 +0200, Richard Biener wrote:
[...snip...]
> This is what I finally applied for the original patch after fixing
> the above issue.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> 2018-10-22 Richard Biener
>
> * gimple-ssa-e
I want to move material from
https://gcc.gnu.org/wiki/DiagnosticsGuidelines
into the new User Experience Guidelines chapter of our internals
documentation. I've already update the link in that wiki page to point
to the pertinent HTML build of the docs:
https://gcc.gnu.org/onlinedocs/gccint/Gui
On Tue, 2018-10-23 at 18:49 -0600, Martin Sebor wrote:
> On 10/23/2018 02:42 PM, David Malcolm wrote:
> > I want to move material from
> > https://gcc.gnu.org/wiki/DiagnosticsGuidelines
> > into the new User Experience Guidelines chapter of our internals
> > document
On Tue, 2018-10-23 at 19:21 +0200, Iain Buclaw wrote:
> On Tue, 23 Oct 2018 at 15:48, Richard Sandiford
> wrote:
> >
> > Iain Buclaw writes:
> > > I'm just going to post the diff since the original here, just to
> > > show
> > > what's been done since review comments.
> > >
> > > I think I've c
On Wed, 2018-10-24 at 14:05 +0100, Richard Sandiford wrote:
> This patch adds a pass that versions loops with variable index
> strides
> for the case in which the stride is 1. E.g.:
>
> for (int i = 0; i < n; ++i)
> x[i * stride] = ...;
>
> becomes:
>
> if (stepx == 1)
> for
PR c++/87721 reports a crash in get_substring_ranges_for_loc introduced
by r265271, my fix for PR 87562.
The new issue occurs when attempting to get a location with a string
literal inside a macro in which the first token is __FILE__ (formed via
concatenation). Attempting to get the spelling loca
On Sun, 2018-08-05 at 16:59 +, Bernd Edlinger wrote:
> Hi!
>
>
> My other patch with adds assertions to varasm.c regarding correct
> nul termination of sting literals did make these incorrect string
> constants in JIT frontend fail.
>
> The string constants are not nul terminated if their le
On Thu, 2018-11-01 at 11:56 -0400, Mike Gulick wrote:
> 2018-10-31 Mike Gulick
>
> PR preprocessor/83173
> * gcc.dg/plugin/location-overflow-test-pr83173.c: New test.
> * gcc.dg/plugin/location-overflow-test-pr83173.h: Header for
> pr83173.c.
> * gcc.dg/plugin/loca
On Thu, 2018-11-01 at 11:56 -0400, Mike Gulick wrote:
> 2017-10-31 Mike Gulick
>
> PR preprocessor/83173
> * gcc/input.c (dump_location_info): Dump reason and
> included_from fields from line_map_ordinary struct. Fix
> indentation when location > 5 digits.
>
> *
On Thu, 2018-11-01 at 11:56 -0400, Mike Gulick wrote:
> 2018-10-31 Mike Gulick
>
> PR preprocessor/83173
> * libcpp/files.c (_cpp_stack_include): Check if
> line_table->highest_location is past current line before
> decrementing.
> ---
> libcpp/files.c | 32
The C frontend is able (where expression locations are available) to print
problems with binary operators in 3-location form, labelling the types of
the expressions:
arg_0 op arg_1
~ ^~ ~
||
|arg1 type
arg0 type
The C++ frontend currently just shows the com
The C++ frontend gained various location wrapper nodes in r256448 (GCC 8).
That patch:
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00799.html
added wrapper nodes around all nodes with !CAN_HAVE_LOCATION_P for:
* arguments at callsites, and for
* typeid, alignof, sizeof, and offsetof.
This is
On Tue, 2018-11-06 at 13:12 +0100, Richard Biener wrote:
> The following patch pushes a DUMP_VECT_SCOPE down one level because
> it otherwise hides a MSG_OPTIMIZED_LOCATION print.
>
> David - was this an intended effect of the scoping?
No, an accident, sorry. The scope depth thing controlling
MS
and this can be checked for via the dg-optimized test directive
(and appears in the -fsave-optimization-record result, etc).
Dave
David Malcolm (4):
cgraph: add selftest::symbol_table_test
dump_printf: add "%C" for dumping cgraph_node *
support %f in pp_format
ipa-inline.c/tree
This patch adds a selftest fixture for overriding the "symtab" global,
so that selftests involving symtab nodes can be isolated from each
other: each selftest can have its own symbol_table instance.
In particular, this ensures that nodes can have a predictable "order"
and thus predictable dump nam
This patch ports various fprintf calls in the inlining code to using
the dump API, using the %C format code for printing cgraph_node *.
I focused on the dump messages that seemed most significant to
end-users; I didn't port all of the calls.
Doing so makes this information appear in -fopt-info and
This patch implements support for %C in dump_printf for dumping
cgraph_node *.
(I would have preferred to have a code for printing symtab_node *
and both subclasses, but there doesn't seem to be a good way for
-Wformat to handle inheritance, so, failing that, I went with
this approach).
Successful
Numerous formatted messages from the inliner use %f, mostly as %f, but
occasionally with length modifiers.
This patch implements the simplest case of "%f" for pp_format (with no
modifier support) to make it easier to port these messages from fprintf
to dump_printf_loc.
The selftest has an asserti
On Thu, 2018-11-08 at 19:38 +0100, Christophe Lyon wrote:
[...snip...]
> Hi,
>
> This patch breaks my builds:
> /tmp/9837775_6.tmpdir/aci-gcc-fsf/sources/gcc-
> fsf/gccsrc/gcc/doc//invoke.texi:14118:
> @option expected braces.
> /tmp/9837775_6.tmpdir/aci-gcc-fsf/sources/gcc-
> fsf/gccsrc/gcc/doc/
I've committed this obvious fix to trunk as r265968 (a copy&paste error).
gcc/ChangeLog:
* json.cc (selftest::test_writing_literals): Fix comment.
---
gcc/json.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/json.cc b/gcc/json.cc
index a0c43956..46b6ef6 100644
-
On Fri, 2018-11-09 at 12:11 +0100, Jakub Jelinek wrote:
> On Fri, Nov 09, 2018 at 12:04:54PM +0100, Jakub Jelinek wrote:
> > On Fri, Nov 09, 2018 at 11:34:48AM +0100, Dominique d'Humières
> > wrote:
> > > Bootstrapping r265942 on darwin failed with
> > >
> > > In file included from /Applications/X
One of the concerns noted at Cauldron about -fsave-optimization-record
was the size of the output files.
This file implements compression of the -fsave-optimization-record
output, using zlib.
I did some before/after testing of this patch, using SPEC 2017's
502.gcc_r with -O3, looking at the sizes
This patch adds a fix-it hint to various pointer-vs-non-pointer
diagnostics, suggesting the addition of a leading '&' or '*'.
For example, note the ampersand fix-it hint in the following:
demo.c:5:22: error: invalid conversion from 'pthread_key_t' {aka 'unsigned int'}
to 'pthread_key_t*' {aka
PR ipa/87955 reports a problem I introduced in r265920, where I converted
the guard in report_inline_failed_reason from using:
if (dump_file)
to using
if (dump_enabled_p ()).
without updating the calls to cl_target_option_print_diff and
cl_optimization_print_diff, which assume that dump_file is
On Mon, 2018-10-22 at 16:08 +0200, Richard Biener wrote:
> On Mon, 22 Oct 2018, David Malcolm wrote:
>
> > On Mon, 2018-10-22 at 15:56 +0200, Richard Biener wrote:
> > [...snip...]
> >
> > > This is what I finally applied for the original patch after
&
On Sun, 2018-11-11 at 12:10 -0700, Martin Sebor wrote:
> On 11/10/2018 07:57 PM, David Malcolm wrote:
> > On Mon, 2018-10-22 at 16:08 +0200, Richard Biener wrote:
> > > On Mon, 22 Oct 2018, David Malcolm wrote:
> > >
> > > > On Mon, 2018-10-
On Sun, 2018-11-11 at 11:01 -0700, Martin Sebor wrote:
> On 11/10/2018 12:01 AM, Eric Gallager wrote:
> > On 11/9/18, David Malcolm wrote:
> > > This patch adds a fix-it hint to various pointer-vs-non-pointer
> > > diagnostics, suggesting the addition of a leading &
When gcc can't find a header file, it's a hard error that stops the build,
typically requiring the user to mess around with compile flags, Makefiles,
dependencies, and so forth.
Often the exact search paths aren't obvious to the user. Consider the
case where the include paths are injected via a t
This patch is based on grepping the C++ frontend for %P and %qP
i.e. diagnostics that refer to a parameter number. It fixes up
these diagnostics to highlight the pertinent param, where appropriate
(and possible), along with various other tweaks, as described in the
ChangeLog.
OK for trunk if it p
gcc/ChangeLog:
* pretty-print.c (class selftest::test_pretty_printer): New
subclass of pretty_printer.
(selftest::test_prefixes_and_wrapping): New test.
(selftest::pretty_print_c_tests): Call it.
---
gcc/pretty-print.c | 96 ++
We often emit more than one diagnostic at the same source location.
For example, the C++ frontend can emit many diagnostics at
the same source location when suggesting overload candidates.
For example:
../../src/gcc/testsuite/g++.dg/diagnostic/bad-binary-ops.C: In function 'int
test_3(s, t)':
..
Consider:
class t1
{
public:
double length () const { return m_length; }
private:
double m_length;
};
missing-parens-fixit.C: In function 'bool test_1(const t1&)':
missing-parens-fixit.C:14:15: error: invalid use of member function
'double t1::length() const' (did you forget t
On Mon, 2018-11-12 at 21:13 +, Mike Gulick wrote:
> On 11/2/18 5:04 PM, David Malcolm wrote:
> > On Thu, 2018-11-01 at 11:56 -0400, Mike Gulick wrote:
> > > 2017-10-31 Mike Gulick
> > >
> > > PR preprocessor/83173
> > > * gcc/
00..7860696
--- /dev/null
+++ b/gcc/diagnostic-format-json.cc
@@ -0,0 +1,265 @@
+/* JSON output for diagnostics
+ Copyright (C) 2018 Free Software Foundation, Inc.
+ Contributed by David Malcolm .
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it und
On Tue, 2018-11-13 at 17:58 +, Kyrill Tkachov wrote:
> Hi David,
>
> On 09/11/18 21:00, Jeff Law wrote:
> > On 11/9/18 10:51 AM, David Malcolm wrote:
> > > One of the concerns noted at Cauldron about -fsave-optimization-
> > > record
> > > was the s
On Tue, 2018-11-13 at 17:58 +, Kyrill Tkachov wrote:
> Hi David,
>
> On 09/11/18 21:00, Jeff Law wrote:
> > On 11/9/18 10:51 AM, David Malcolm wrote:
> > > One of the concerns noted at Cauldron about -fsave-optimization-
> > > record
> > > was the s
On Tue, 2018-11-13 at 14:54 -0500, Mike Gulick wrote:
> 2018-11-13 Mike Gulick
[...]
> * gcc/diagnostic-core.h (num_digits): Add extern definition.
FWIW you moved the decl to diagnostic.h, but didn't update the above
ChangeLog entry.
[...]
> diff --git a/libcpp/location-example.txt b/
On Wed, 2018-11-14 at 09:49 +, Kyrill Tkachov wrote:
> On 13/11/18 18:45, David Malcolm wrote:
> > On Tue, 2018-11-13 at 17:58 +, Kyrill Tkachov wrote:
> > > Hi David,
> > >
> > > On 09/11/18 21:00, Jeff Law wrote:
> > > > On 11/9/18 10:
On Mon, 2018-11-12 at 13:37 -0700, Martin Sebor wrote:
> On 11/11/2018 07:43 PM, David Malcolm wrote:
> > We often emit more than one diagnostic at the same source location.
> > For example, the C++ frontend can emit many diagnostics at
> > the same source location whe
As of r266080, calls to dump_print* that aren't guarded by
if (dump_enabled_p ())
lead to an assertion failure.
This patch fixes a few calls that weren't guarded, avoiding a
call to find_loop_location for the no-dumping case.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Commi
-- /dev/null
+++ b/gcc/diagnostic-format-json.cc
@@ -0,0 +1,264 @@
+/* JSON output for diagnostics
+ Copyright (C) 2018 Free Software Foundation, Inc.
+ Contributed by David Malcolm .
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the te
As of r266186, auto_diagnostic_group is now user-visible
(via -fdiagnostics-format=json), so update the diagnostic
guidelines accordingly.
Committed to trunk as r266187.
gcc/ChangeLog:
* doc/ux.texi (Group logically-related diagnostics): Move
discussion of auto_diagnostic_group in
On Tue, 2018-11-13 at 16:34 -0500, Jason Merrill wrote:
> On Mon, Nov 12, 2018 at 4:32 PM Martin Sebor
> wrote:
> > On 11/11/2018 02:02 PM, David Malcolm wrote:
> > > On Sun, 2018-11-11 at 11:01 -0700, Martin Sebor wrote:
> > > > On 11/10/2018 12:01 AM, Eric Gal
PR tree-optimization/87025 reports an ICE within
-fsave-optimization-record's optrecord_json_writer.
The issue is that dump_context::begin_scope creates an optinfo
of kind OPTINFO_KIND_SCOPE, but fails to call
dump_context::end_any_optinfo, so the optinfo for the scope remains
pending.
The JSON w
As work towards fixing PR tree-optimization/87025, this patch
eliminates global state from optinfo-emit-json.cc in favor
of adding an optional m_json_writer field to dump_context,
replacing the m_forcibly_enable_optinfo flag.
This allows for writing selftests for the interaction of the
JSON-buildi
Thanks
Dave
On Mon, 2018-11-05 at 15:31 -0500, David Malcolm wrote:
> The C++ frontend gained various location wrapper nodes in r256448
> (GCC 8).
> That patch:
> https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00799.html
> added wrapper nodes around all nodes with !CAN_HAVE
On Fri, 2018-11-16 at 13:13 -0500, Jason Merrill wrote:
> On Thu, Nov 15, 2018 at 4:48 PM David Malcolm
> wrote:
> > On Tue, 2018-11-13 at 16:34 -0500, Jason Merrill wrote:
> > > On Mon, Nov 12, 2018 at 4:32 PM Martin Sebor
> > > wrote:
> > > > O
The dump_* API attempts to capture emission location metadata for the
various dump messages, but looking in -fsave-optimization-record shows
that many dump messages are lacking useful impl_location values, instead
having this location within dumpfile.c:
"impl_location": {
On Tue, 2018-11-20 at 21:57 +0100, Jakub Jelinek wrote:
> Hi!
>
> This PR is complaining about range covering the first token from
> an id-expression:
> pr87386.C:4:15: error: static assertion failed: foo
> 4 | static_assert(foo::test::value, "foo");
> | ^~~
> The following patch a
On Tue, 2018-11-20 at 02:46 +, Joseph Myers wrote:
> On Mon, 19 Nov 2018, David Malcolm wrote:
>
> > +/* C implementation of same_type_p.
> > + Returns true iff TYPE1 and TYPE2 are the same type, in the
> > usual
> > + sense of `same'. */
> >
On Tue, 2018-11-20 at 11:08 +0100, Martin Liška wrote:
> Hi.
>
> It's the script that I used to identify potentially resolvable bugs.
> That's done
> by parsing of comments and seeking for trunk/branch commits. Sample
> output looks
> as follows:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id
Consider this test case:
namespace json
{
enum { JSON_OBJECT };
}
void test ()
{
JSON_OBJECT;
}
which erroneously accesses an enum value in another namespace without
qualifying the access.
GCC 6 through 8 issue a suggestion that doesn't mention the namespace:
: In function 'void test()':
:
On Wed, 2018-11-21 at 16:59 +0100, Jakub Jelinek wrote:
> Hi!
>
> David's r251026 change added a weird trailing ->location.
> It doesn't seem to be useful for anything, matching_braces has its
> own code
> to track locations, so no need to do anything in the caller (and no
> other
> spot does some
On Mon, 2018-11-26 at 10:20 +0100, Matthias Klose wrote:
> test-long-names.c fails to build when -Wformat-security is turned
> on. Fixed by
> the below patch. Alternatives would be to use a plain strcpy, or to
> turn off the
> option in a dg header. Ok to commit, including active branches?
>
> Ma
On Mon, 2018-11-26 at 22:17 +, Mike Gulick wrote:
> On 11/13/18 3:12 PM, David Malcolm wrote:
> > On Tue, 2018-11-13 at 14:54 -0500, Mike Gulick wrote:
> > > 2018-11-13 Mike Gulick
> >
> > [...]
> >
> > > * gcc/diagnostic-core.h (num_digi
On Tue, 2018-11-27 at 14:10 +, Mike Gulick wrote:
> On 11/26/18 8:29 PM, David Malcolm wrote:
> > On Mon, 2018-11-26 at 22:17 +, Mike Gulick wrote:
> > > On 11/13/18 3:12 PM, David Malcolm wrote:
> > > > On Tue, 2018-11-13 at 14:54 -0500, Mike Gulick wro
On Tue, 2018-11-27 at 14:37 +, Mike Gulick wrote:
> On 11/27/18 9:27 AM, David Malcolm wrote:
>
> [...]
>
> >
> > I can commit them for you if you like. Please can you repost the
> > latest version of the patches as one kit, for clarity, so I can
> > co
On Tue, 2018-11-27 at 09:53 -0500, Mike Gulick wrote:
> 2018-11-27 Mike Gulick
>
> PR preprocessor/83173
> * libcpp/files.c (_cpp_stack_include): Check if
> line_table->highest_location is past current line before
> decrementing.
I've committed these patches to trunk as
On Wed, 2018-11-21 at 13:41 -0500, Jason Merrill wrote:
> On 11/21/18 8:35 AM, David Malcolm wrote:
> > Consider this test case:
> >
> > namespace json
> > {
> >enum { JSON_OBJECT };
> > }
> >
> > void test ()
> > {
> >JSON_OB
On Tue, 2018-11-20 at 17:39 -0700, Martin Sebor wrote:
> > +void test_2 (void)
> > +{
> > + takes_int_ptr(ivar); /* { dg-warning "" "" { target c } } */
> > + /* { dg-error "" "" { target c++ } .-1 } */
> > + /* { dg-message "possible fix: take the address with '&'" "" {
> > target *-*-* } .-2 }
PR preprocessor/88257 reports an ICE on gcc.dg/format/pr78304.c
when compiled using g++:
void test (const char *msg)
{
printf ("size: %" PRIu32 "\n", msg);
}
due to mismatching files (and line maps) between
linemap_resolve_location and expand_location_to_spelling_point
when PRIu32 is defined in
On Tue, 2018-11-20 at 22:23 +, Joseph Myers wrote:
> On Tue, 20 Nov 2018, David Malcolm wrote:
>
> > Should I do:
>
> You should do whatever is appropriate for the warning in
> question. But if
> what's appropriate for the warning in question includes types tha
On Mon, 2019-06-24 at 15:30 +, Andrea Corallo wrote:
> Hi all,
> second version for this patch.
> Given the suggestion for the bit-field one I've tried to improve also
> here the error message.
Thanks.
> I've added a simple testcase as requested, here I'm trying to do
> *void=int+int.
> This
On Mon, 2019-06-24 at 16:37 +, Andrea Corallo wrote:
> David Malcolm writes:
>
> > On Mon, 2019-06-24 at 15:30 +, Andrea Corallo wrote:
> > > Hi all,
> > > second version for this patch.
> > > Given the suggestion for the bit-field one I've trie
On Mon, 2019-06-24 at 15:26 +, Andrea Corallo wrote:
> Hi all,
> second version here of the gcc_jit_context_new_bitfield patch
> addressing
> review comments.
>
> Checked with make check-jit runs clean.
>
> Bests
>
> Andrea
>
> 2019-06-20 Andrea Corallo andrea.cora...@arm.com
>
> * docs/t
On Tue, 2019-06-25 at 10:16 +0200, Martin Liška wrote:
> Hi.
>
> That's a thinko that's pre-approved by Richi.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression
> tests.
>
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-06-24 Martin Liska
>
> PR tree-optimization/909
On Wed, 2019-06-26 at 11:07 +, Andrea Corallo wrote:
> Hi David,
> thanks for the suggestions.
> Updated version for the bitfield libgccjit support patch here
> addressing comments.
>
> test-error-gcc_jit_context_new_bitfield-invalid-width.c is reworked
> and now assume that the long of the co
On Tue, 2019-06-25 at 08:11 +, Andrea Corallo wrote:
> Hi,
> third version for this patch with the simplified test.
>
> make check-jit pass clean
>
> Bests
> Andrea
>
> 2019-06-09 Andrea Corallo andrea.cora...@arm.com
>
> * libgccjit.c (gcc_jit_context_new_binary_op): Check result_type
On Mon, 2019-07-01 at 12:50 +0300, Vladislav Ivanishin wrote:
> Hi!
>
> GDB's Python API provides strip_typedefs method that can be
> instrumental
> for writing DRY code. Using it at least partially obviates the need
> for
> the add_printer_for_types method we have in gdbhooks.py (it takes a
> li
On Mon, 2019-07-01 at 13:07 +0300, Vladislav Ivanishin wrote:
> This change is threefold:
> - enable pretty printing of vec<>, not just vec<>*
> - generalize 'vec<(\S+), (\S+), (\S+)>' regex, which is limiting
> - extend to work for vl_ptr layout (only vl_embed was supported)
>
> The motivating ex
On Tue, 2019-07-02 at 14:29 +0300, Vladislav Ivanishin wrote:
> David Malcolm writes:
>
> > On Mon, 2019-07-01 at 12:50 +0300, Vladislav Ivanishin wrote:
> > > Hi!
> > >
> > > GDB's Python API provides strip_typedefs method that can be
> > >
On Wed, 2019-06-26 at 15:05 +, Andrea Corallo wrote:
> David Malcolm writes:
>
> > On Tue, 2019-06-25 at 08:11 +, Andrea Corallo wrote:
> > > Hi,
> > > third version for this patch with the simplified test.
> > >
> > > make check-
On Thu, 2019-07-18 at 14:20 +, Andrea Corallo wrote:
> Hi all,
> I've just realized that what we has been done recently for
> gcc_jit_context_new_binary_op should be done also for the unary
> version.
> This patch checks at record time for the result type of
> gcc_jit_context_new_unary_op to be
On Thu, 2019-07-18 at 14:20 +, Andrea Corallo wrote:
> Hi all,
> I've just realized that what we has been done recently for
> gcc_jit_context_new_binary_op should be done also for the unary
> version.
> This patch checks at record time for the result type of
> gcc_jit_context_new_unary_op to be
On Mon, 2019-02-18 at 14:07 -1000, Jason Merrill wrote:
> On 2/18/19 12:50 PM, Jakub Jelinek wrote:
> > Hi!
> >
> > On the following testcase we ICE because name is BIT_NOT_EXPR and
> > suggest_alternative_in_scoped_enum assumes it is called on
> > IDENTIFIER_NODE
> > only.
> >
> > Fixed thusly,
2401 - 2500 of 5457 matches
Mail list logo