Hi Jason,
Thanks for the review.
Jason Merrill writes:
> On 7/23/24 7:41 PM, Arsen Arsenović wrote:
>> co_await expressions are nearly calls to Awaitable::await_resume, and,
>> as such, should inherit its nodiscard. A discarded co_await expression
>> should, hence, act as if its call to await_
On 7/24/24 5:57 AM, Richard Sandiford wrote:
PR116044 is a regression in the testsuite on AMD GCN caused (again)
by the split_clobber_group code. The first patch in this area
(g:71b31690a7c52413496e91bcc5ee4c68af2f366f) fixed a bug caused
by carrying the old group over as one the split ones.
On 7/24/24 4:20 PM, Arsen Arsenović wrote:
Hi Jason,
Thanks for the review.
Jason Merrill writes:
On 7/23/24 7:41 PM, Arsen Arsenović wrote:
co_await expressions are nearly calls to Awaitable::await_resume, and,
as such, should inherit its nodiscard. A discarded co_await expression
should,
Jason Merrill writes:
> Ah, of course, I was overlooking the assignment. The patch is OK.
Thanks. Here's a range diff with a few changes to the commits, chiefly
in the commit messages. If you agree, I can push with these changes
applied:
1: 32f810cca55 ! 1: d2e74525965 cp/coroutines: do no
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
cp_parser_simple_type_specifier tries a variety of different things that
might qualify as a user-defined type: an actual type-name, a constrained
auto, a CTAD placeholder. In a context where a type-specifier is optional,
this is all tentati
The following patch kit overhauls various aspects of JSON/SARIF output:
* patch 1: adds a simpler json::value::dump () method to make it easier
to debug JSON-handling code
* patches 2-9 are cleanups/refactorings of the json-handling code and
the JSON/SARIF output formats with no functional ch
No functional change intended.
gcc/analyzer/ChangeLog:
* supergraph.cc (supernode::to_json): Avoid naked "new" by using
json::array::append_string.
(supernode::to_json): Likewise.
gcc/ChangeLog:
* diagnostic-format-sarif.cc (sarif_artifact::populate_roles):
This has saved me a lot of typing in the debugger.
gcc/ChangeLog:
* json.cc (value::dump): New overload, taking no params.
* json.h (value::dump): New decl.
Signed-off-by: David Malcolm
---
gcc/json.cc | 10 ++
gcc/json.h | 1 +
2 files changed, 11 insertions(+)
diff
This patch uses templates to add overloads of json::array::append and
json::object::set taking std::unique_ptr where T is a subclass of
json::value.
Doing so makes it much easier to track memory ownership and enforce
schema validity when constructing non-trivial JSON; using the wrong
kind of JSON
No functional change intended.
gcc/ChangeLog:
* diagnostic-format-sarif.cc: Introduce subclasses of sarif_object
for all aspects of the spec that we're using. Replace almost all
usage of json::object with uses of these subclasses, the only
remaining use of json::ob
No functional change intended.
gcc/analyzer/ChangeLog:
* call-string.cc (call_string::to_json): Avoid naked "new".
* constraint-manager.cc (bounded_range::set_json_attr): Likewise.
(equiv_class::to_json): Likewise.
(constraint::to_json): Likewise.
(bounded_r
No functional change intended.
gcc/ChangeLog:
* diagnostic-format-json.cc (json_from_expanded_location): Make
"static". Pass param "context" by reference, as it cannot be null.
(json_from_location_range): Likewise for param "context".
(json_from_fixit_hint): Likewis
No functional change intended.
gcc/ChangeLog:
* gcov.cc (output_intermediate_json_line): Use
json::object::set_integer to avoid naked "new".
Signed-off-by: David Malcolm
---
gcc/gcov.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/gcov.cc b/gcc/gco
The existing DejaGnu-based tests for our SARIF output used regexes
to verify the JSON at the string level, which lets us test for
the presence of properties, but doesn't check the overall structure.
This patch uses the selftest framework to verify the structure of
the tree of JSON values for a log
No functional change intended.
gcc/analyzer/ChangeLog:
* checker-event.cc (maybe_add_sarif_properties): Update setting
of "original_fndecl" to use typesafe unique_ptr variant of
json::object::set.
gcc/ChangeLog:
* diagnostic-format-sarif.cc: Include "make-unique.h"
No functional change intended.
gcc/ChangeLog:
* diagnostic-format-json.cc: Include "make-unique.h".
(json_output_format::m_toplevel_array): Convert to
std::unique_ptr.
(json_output_format::json_output_format): Update accordingly.
(json_output_format::~json_o
gcc/ChangeLog:
* diagnostic-format-sarif.cc
(make_date_time_string_for_current_time): New.
(sarif_invocation::sarif_invocation): Set "startTimeUtc"
property (§3.20.7).
(sarif_invocation::prepare_to_flush): Set "endTimeUtc"
property (§3.20.8).
gcc/tes
gcc/ChangeLog:
* diagnostic-format-sarif.cc
(sarif_builder::make_artifact_location_object): Make public.
(sarif_invocation::sarif_invocation): Add param "builder".
Use it to potentially populate the "workingDirectory" property
with the result of pwd (§3.20.19
gcc/ChangeLog:
* diagnostic-format-sarif.cc (sarif_invocation::sarif_invocation):
Add "original_argv" param and use it to populate "arguments"
property (§3.20.2).
(sarif_builder::sarif_builder): Pass argv to m_invocation_obj's
ctor.
* diagnostic.cc (d
This patch extends our SARIF output so that if a diagnostic has any
labelled source ranges, the "location" object gains an "annotations"
property capturing them (§3.28.6).
For example, given this textual output:
../../src/gcc/testsuite/gcc.dg/bad-binary-ops.c: In function ‘test_2’:
../../src/gcc/
gcc/ChangeLog:
* diagnostic-format-sarif.cc (sarif_builder::make_locations_arr):
Don't add entirely empty location objects, such as for
UNKNOWN_LOCATION.
(test_sarif_diagnostic_context::test_sarif_diagnostic_context):
Add param "main_input_filename".
This patch adds support to our SARIF output for cases where
rich_loc.escape_on_output_p () is true, such as for -Wbidi-chars.
In such cases, the pertinent SARIF "location" object gains a property
bag with property "gcc/escapeNonAscii": true, and the "artifactContent"
within the location's physical
On Linux/x86_64,
679086172b84be18c55fdbb9cda7e97806e7c083 is the first bad commit
commit 679086172b84be18c55fdbb9cda7e97806e7c083
Author: Jeff Law
Date: Wed Jul 24 11:16:26 2024 -0600
[rtl-optimization/116037] Explicitly track if a destination was skipped in
ext-dce
caused
FAIL: gcc.dg/
Binutils 2.42 and before don't recognize the B extension in the march
strings even though it supports zba_zbb_zbs. Add a configure check to
ignore the B in the march string if found.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_subset_list::to_string):
Skip b in mar
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 (after
14.2 is released)?
-- >8 --
The type of an implicit object parameter is always the current class.
For an explicit object parameter however, its deduced type can be a
class derived from the current class. So when combining multi
Bumping the topic.
Since this patch exclusively affects powerpc-darwin, and I think we agree
that it does not add regressions with tests (no tests which passed without
it fail with it), perhaps it can be merged?
It would be great to have it in gcc 15 when it is released, otherwise we
will need to
On Wed, Jul 24, 2024 at 3:11 PM Kong, Lingling wrote:
>
> Tested spec2017 performance in Sierra Forest, Icelake, CascadeLake, at least
> there is no obvious regression.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
>
> OK for trunk?
Ok.
>
> gcc/ChangeLog:
>
> * config/i386
On Mon, Jul 22, 2024 at 9:35 AM Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> -- >8 --
>
> This removes the TODO in libstdc++_init, so that we don't copy all *.tst
> and *.txt files from testsuite/data into every test's working directory.
> Instead, only the necessary files declared with dg-
The problem here is that v3_additional_files will have a space
at the begining of the string as dg-additional-files will append
`" " $files` to it. Then when split is called on that string,
there will be an empty file and copying a dir will just fail for
remote/sim testing (I didn't look at why it
This renames the patterns orn3 to iorn3 so it
matches the new optab that was added with r15-1890-gf379596e0ba99d.
Likewise for bic3 to andn3.
Note the operand 1 and operand 2 are swapped from the original
patterns to match the optab now.
Built and tested for aarch64-linux-gnu with no regression.
Now there is an optab for bic, andn since r15-1890-gf379596e0ba99d.
This moves aarch64_bic for sve over to use it instead.
Note unlike the simd bic patterns, the operands were already
in the order that was expected for the optab so no swapping
was needed.
Built and tested on aarch64-linux-gnu wit
To better create rtl directly from gimple, we can use
these already internal functions from the gimple.
That is simplify `a & ~b` into BIT_ANDN.
Likewise `a | ~b` into BIT_IORN.
We only want to do this late after vectorization as some
targets (e.g. aarch64 SVE) has BIT_IORN on scalars but not on
s
Since r15-1890-gf379596e0ba99d, these are the new optabs.
So let's use these names for them. These will be used to
generate during expand from gimple in the next few patches.
Built and tested for aarch64-linux-gnu with no regressions.
gcc/ChangeLog:
* config/aarch64/aarch64.md (*_one_cmp
With constants we can match `~(a | CST)` into `CST & ~a`.
Likewise `~(a & CST)` into `CST | ~a`.
Built and tested for aarch64-linux-gnu with no regressions.
PR target/116013
PR target/115086
gcc/ChangeLog:
* match.pd (`~(a & CST)`, `~(a | CST)`): New pattern.
gcc/testsu
On Tue, Jul 23, 2024 at 11:56 PM Richard Biener
wrote:
>
> On Tue, Jul 23, 2024 at 10:27 AM Kugan Vivekanandarajah
> wrote:
> >
> > On Tue, Jul 23, 2024 at 10:35 AM Andrew Pinski wrote:
> > >
> > > On Mon, Jul 22, 2024 at 5:26 PM Kugan Vivekanandarajah
> > > wrote:
> > > >
> > > > Revised based
Hi,
There are a few PRs (meta-bug PR101926) about accessing aggregate
parameters/returns which are passed through registers.
A major reason of those issues is when access the aggregate, the
temporary stack slots are used without leverage the information about
the incoming/outgoing registers.
We
Hi,
This patch add const_vector into any_operand predicate. From my
understanding, any_operand should include all kinds of operands.
The const_vector should be included. As emit_move_insn doesn't check
the predicate, the const_vector is actually supported by vector mode
move expand. So it should
Hi,
This patch optimizes vector construction with two vector doubleword
loads. It generates an optimal insn sequence as "xxlor" has lower
latency than "mtvsrdd" on Power10.
Compared with previous version, the main change is to add new
patterns for LE platform. Also lxsd[x] instructions are gua
> On 25 Jul 2024, at 04:14, Andrew Pinski wrote:
>
> External email: Use caution opening links or attachments
>
>
> This renames the patterns orn3 to iorn3 so it
> matches the new optab that was added with r15-1890-gf379596e0ba99d.
> Likewise for bic3 to andn3.
>
> Note the operand 1 and ope
Hi Andrew,
> On 25 Jul 2024, at 04:14, Andrew Pinski wrote:
>
> External email: Use caution opening links or attachments
>
>
> Since r15-1890-gf379596e0ba99d, these are the new optabs.
> So let's use these names for them. These will be used to
> generate during expand from gimple in the next f
On Wed, Jul 24, 2024 at 11:22 PM Kyrylo Tkachov wrote:
>
>
>
> > On 25 Jul 2024, at 04:14, Andrew Pinski wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > This renames the patterns orn3 to iorn3 so it
> > matches the new optab that was added with r15-1890-gf37959
On Thu, 25 Jul 2024, 02:58 Andrew Pinski, wrote:
> The problem here is that v3_additional_files will have a space
> at the begining of the string as dg-additional-files will append
> `" " $files` to it. Then when split is called on that string,
> there will be an empty file and copying a dir wil
> On 24 Jul 2024, at 18:50, Richard Sandiford wrote:
>
> External email: Use caution opening links or attachments
>
>
> Jennifer Schmitz writes:
>> As suggested in the review of
>> https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657474.html,
>> this patch changes the return type of gimpl
> On 25 Jul 2024, at 04:14, Andrew Pinski wrote:
>
> External email: Use caution opening links or attachments
>
>
> Now there is an optab for bic, andn since r15-1890-gf379596e0ba99d.
> This moves aarch64_bic for sve over to use it instead.
>
> Note unlike the simd bic patterns, the operands
101 - 144 of 144 matches
Mail list logo
