> 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
> 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 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 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
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 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,
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
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,
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
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
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
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
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
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
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.
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
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-
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
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
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
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
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/
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
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 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_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
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
(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
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
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"
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/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
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-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
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/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
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
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
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
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,
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.
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 Wed, 24 Jul 2024 at 20:58, Jonathan Wakely wrote:
>
> On Wed, 24 Jul 2024 at 20:55, Ville Voutilainen
> wrote:
> >
> > On Wed, 24 Jul 2024 at 22:51, Jonathan Wakely wrote:
> > >
> > > Tested x86_64-linux.
> > >
> > > Any reason not to do this? I don't think the assertions are useful to
> > >
On Wed, 24 Jul 2024 at 20:55, Ville Voutilainen
wrote:
>
> On Wed, 24 Jul 2024 at 22:51, Jonathan Wakely wrote:
> >
> > Tested x86_64-linux.
> >
> > Any reason not to do this? I don't think the assertions are useful to
> > catch implementation bugs where we access the contained value without
> >
On Wed, 24 Jul 2024 at 22:51, Jonathan Wakely wrote:
>
> Tested x86_64-linux.
>
> Any reason not to do this? I don't think the assertions are useful to
> catch implementation bugs where we access the contained value without
> checking it - we should use tests for that.
Looks good to me.
> The cu
Tested x86_64-linux.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/expected (bad_expected_access): Add noexcept
to special member functions, as per LWG 4031.
* testsuite/20_util/expected/bad.cc: Check for nothrow copy and
move members.
---
libstdc++-v3/include/s
Tested x86_64-linux.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/expected (expected): Constrain constructors to
prevent problematic bool conversions, as per LWG 3836.
* testsuite/20_util/expected/lwg3836.cc: New test.
---
libstdc++-v3/include/std/expected
Tested x86_64-linux.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/optional (optional): Constrain constructors to
prevent problematic bool conversions, as per LWG 3836.
* testsuite/20_util/optional/cons/lwg3836.cc: New test.
---
libstdc++-v3/include/std/optional
Tested x86_64-linux.
-- >8 --
In C++20 mode we can simplify some of the std::optional base class
hierarchy using concepts. We can overload the destructor and copy
constructor and move constructor with a trivial defaulted version and a
constrained non-trivial version. This allows us to remove some
Tested x86_64-linux.
-- >8 --
Now that _base::_M_get() doesn't check the precondition, we can use
_M_get() instead of operator*() for the internal uses where we've
already checked the precondition holds.
Add a using-declaration so that we don't need to lookup _M_get in the
dependent base class,
Tested x86_64-linux.
Any reason not to do this? I don't think the assertions are useful to
catch implementation bugs where we access the contained value without
checking it - we should use tests for that.
-- >8 --
Currently we implement the precondition for accessing the contained
value of a std
While working on a patch to the Ada compiler, I found a spot in
dwarf2out.cc that calls add_name_attribute where a call to
add_name_and_src_coords_attributes would be better, because the latter
respects DECL_NAMELESS.
gcc
* dwarf2out.cc (modified_type_die): Call
add_name_and_src_c
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_resume was discarded.
CO_AWAIT_EXPR trees do conveniently contain t
On 7/23/24 7:41 PM, Arsen Arsenović wrote:
It is possible to use parameters of a parent function of a lambda in
unevaluated contexts without capturing them. By not capturing them, we
work around the usual mechanism we use to prevent rewriting captured
parameters. Prevent this by simply skipping
On 7/24/2024 3:03 AM, Robin Dapp wrote:
Thanks for the explanation! I have a few clarification questions about this.
If I understand correctly, B would represent the number of elements the
vector can have (for 128b vector operating on 32b elements, B == 4, but if
operating on 64b elements B ==
On 7/24/2024 3:03 AM, Robin Dapp wrote:
Thanks for the explanation! I have a few clarification questions about this.
If I understand correctly, B would represent the number of elements the
vector can have (for 128b vector operating on 32b elements, B == 4, but if
operating on 64b elements B ==
On 7/24/2024 3:52 AM, Richard Biener wrote:
On Wed, Jul 24, 2024 at 1:31 AM Edwin Lu wrote:
On 7/23/2024 11:20 AM, Richard Sandiford wrote:
Edwin Lu writes:
On 7/23/2024 4:56 AM, Richard Biener wrote:
On Tue, Jul 23, 2024 at 1:03 AM Edwin Lu wrote:
Hi Richard,
On 5/31/2024 1:48 AM, Ri
Hi!
On Wed, Jul 24, 2024 at 11:38:11AM -0700, Carl Love wrote:
> On 7/24/24 10:03 AM, Segher Boessenkool wrote:
> >So much manual stuff needed, sigh.
> >
> >On Fri, Jul 19, 2024 at 01:04:12PM -0700, Carl Love wrote:
> >>gcc/ChangeLog:
> >> * config/rs6000/altivec.md (vsdb_): Change
> >> de
Segher:
Thanks for the review, a few questions...
On 7/24/24 10:03 AM, Segher Boessenkool wrote:
Hi!
So much manual stuff needed, sigh.
On Fri, Jul 19, 2024 at 01:04:12PM -0700, Carl Love wrote:
gcc/ChangeLog:
* config/rs6000/altivec.md (vsdb_): Change
define_insn iterator to VEC_I
On Wed, Jul 24, 2024 at 12:16:33PM -0500, Peter Bergner wrote:
>
> On 7/24/24 12:03 PM, Segher Boessenkool wrote:
> >> +/* { dg-options "-mdejagnu-cpu=power10 -save-temps" } */
> >
> > Why the -save-temps? Always document it if you want that for something,
> > but never put it in the testcase if
On Wed, Jul 24, 2024 at 12:12:05PM -0500, Peter Bergner wrote:
> On 7/24/24 12:06 PM, Segher Boessenkool wrote:
> I thought we always wanted the predicate to match the constraint being used?
Predicates and constraints have different purposes, and are used at
different times (typically). Everythin
This implements stack-clash protection for riscv, with
riscv_allocate_and_probe_stack_space being based of
aarch64_allocate_and_probe_stack_space from aarch64's implementation.
We enforce the probing interval and the guard size to always be equal, their
default value is 4Kb which is riscv page size
Add the TARGET_STACK_CLASH_PROTECTION_ALLOCA_PROBE_RANGE to riscv in
order to enable stack clash protection when using alloca.
The code and tests are the same used by aarch64.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_compute_frame_info): Update
outgoing args size.
Adds basic support to vector stack-clash protection using a loop to do
the probing and stack adjustments.
gcc/ChangeLog:
* config/riscv/riscv.cc
(riscv_allocate_and_probe_stack_loop): New function.
(riscv_v_adjust_scalable_frame): Add stack-clash protection
support.
Move riscv_v_adjust_scalable_frame () in preparation for the stack clash
protection support.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_v_adjust_scalable_frame): Move
closer to riscv_expand_prologue.
---
gcc/config/riscv/riscv.cc | 62 +++
Enable the register used by riscv_emit_stack_tie () to be passed as
an argument so we can tie the stack with other registers besides
hard_frame_pointer_rtx.
Also don't allow operand 1 of stack_tie to be optimized to sp
in preparation for the stack clash protection support.
gcc/ChangeLog:
*
Hi All,
This patch series implements stack-clash protection for RISC-V using 4K
probes as default. The non-vector implementation is based on AArch64’s
as the generated stack frame is similar.
The tests are also adapted from AArch64.
Thanks,
Raphael
Raphael Moreira Zinsly (5):
RISC-V: Small st
On 7/24/24 1:33 PM, Jakub Jelinek wrote:
Hi!
When playing with P2963R3, while reading and/or modifying code I've fixed
various comment or code formatting issues (and in 3 spots also comment
wording), but including that in the WIP P2963R3 patch made that patch
totally unreadable because these cha
Hi!
When playing with P2963R3, while reading and/or modifying code I've fixed
various comment or code formatting issues (and in 3 spots also comment
wording), but including that in the WIP P2963R3 patch made that patch
totally unreadable because these changes were 4 times the size of the
actual co
So this has been in the hopper since the first bugs were reported
against ext-dce. It'd been holding off committing as I was finding
other issues in terms of correctness of live computations. There's
still problems in that space, but I think it's time to push this chunk
forward. I'm marking
On 7/24/24 12:03 PM, Segher Boessenkool wrote:
>> +/* { dg-options "-mdejagnu-cpu=power10 -save-temps" } */
>
> Why the -save-temps? Always document it if you want that for something,
> but never put it in the testcase if not. A leftover from development?
I can answer this one. :-). Since th
On 7/24/24 12:06 PM, Segher Boessenkool wrote:
> On Tue, Jul 23, 2024 at 04:26:43PM -0500, Peter Bergner wrote:
>> On 7/19/24 3:04 PM, Carl Love wrote:
>>> (define_insn "vsdb_"
>>> - [(set (match_operand:VI2 0 "register_operand" "=v")
>>> - (unspec:VI2 [(match_operand:VI2 1 "register_operand" "v"
On Tue, Jul 23, 2024 at 04:26:43PM -0500, Peter Bergner wrote:
> On 7/19/24 3:04 PM, Carl Love wrote:
> > diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
> > index 5af9bf920a2..2a18ee44526 100644
> > --- a/gcc/config/rs6000/altivec.md
> > +++ b/gcc/config/rs6000/altivec.md
On 7/22/24 8:13 AM, Jerry D wrote:
Hi all,
The attached patch fixes this by avoiding looking for and avoiding the
EOF condition in the parent READ after returning from the child IO process.
I could not think of a simple test case yet since the problem occurred
only when redirecting the input
Hi!
So much manual stuff needed, sigh.
On Fri, Jul 19, 2024 at 01:04:12PM -0700, Carl Love wrote:
> gcc/ChangeLog:
> * config/rs6000/altivec.md (vsdb_): Change
> define_insn iterator to VEC_IC.
>From VI2 (a nothing-saying name) to VEC_IC (also a nonsensical name).
Maybe VEC_IC should ha
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 gimple_folder::redirect_call from
> gimple * to gcall *. The motivation for this is that so far, most callers of
> the function had be
On 7/23/24 19:48, Kito Cheng wrote:
I incline do not add skip_zacas stuffs (although skip_zabha is already
there but that's fine), because that's different situation compare to
the zaamo/zalrsc, zaamo/zalrsc should automatically append if a
extension is available, which is new behavior and new ex
Hi!
Didn't notice the memmove is into an int variable, so the test
was still failing on big endian.
Committed to trunk as obvious.
2024-07-24 Jakub Jelinek
PR tree-optimization/116034
PR testsuite/116061
* gcc.dg/pr116034.c (g): Change type from int to unsigned short.
Tested x86_64-linux.
Pushed to trunk. Backports to follow after the 14.2 release.
-- >8 --
This questionable combination of flags causes a number of errors. This
one in std::vector needs to be fixed in the gcc-13 branch so I'm
committing it separately to simplify backporting.
libstdc++-v3/Chang
Tested x86_64-linux.
Pushed to trunk. Backports to follow after the 14.2 release.
-- >8 --
This questionable combination of flags causes a number of errors. The
ones in the rvalue stream overloads need to be fixed in the gcc-14
branch so I'm committing it separately to simplify backporting.
lib
Replace the existing uint64_t typedef with a bbitmap<2> typedef. Most
of the preparatory work was carried out in previous commits, so this
patch itself is fairly small.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(aarch64_set_asm_isa_flags): Store a second uint64_t v
gcc/ChangeLog:
* config/aarch64/aarch64.cc
(aarch64_valid_sysreg_name_p): Add bool cast.
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index
66ce04d77e17a65d320578de389462756d33d110..7c2af1316b6740ccb7a383b3ac73f7c8ec36889c
100644
--- a/gcc/config/a
This class provides a constant-size bitmap that can be used as almost a
drop-in replacement for bitmaps stored in integer types. The
implementation is entirely within the header file and uses recursive
templated operations to support effective optimisation and usage in
constexpr expressions.
This
gcc/ChangeLog:
* config/aarch64/aarch64-feature-deps.h
(get_flags_off): Construct aarch64_feature_flags (0) explicitly.
diff --git a/gcc/config/aarch64/aarch64-feature-deps.h
b/gcc/config/aarch64/aarch64-feature-deps.h
index
79126db88254b89f74a8583d50a77bc27865e265..a14ae22b729
The awk scripts that process the .opt files are relatively fragile and
only handle a limited set of data types correctly. The unrecognised
aarch64_feature_flags type is handled as a uint64_t, which happens to be
correct for now. However, that assumption will change when we extend
the mask to 128
Use a new AARCH64_HAVE_ISA macro in TARGET_* definitions, and eliminate
all the AARCH64_ISA_* feature macros.
gcc/ChangeLog:
* config/aarch64/aarch64-c.cc
(aarch64_define_unconditional_macros): Use TARGET_V8R macro.
(aarch64_update_cpp_builtins): Use TARGET_* macros.
Building an aarch64_feature_flags value from data within a gcc_options
or cl_target_option struct will get more complicated in a later commit.
Use a macro to avoid doing this manually in more than one location.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(aarch64_hand
The name would become misleading in a later commit anyway, and I think
this is marginally more readable.
gcc/ChangeLog:
* config/aarch64/aarch64.cc
(aarch64_override_options): Remove temporary variable.
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
i
Currently there are many places where an aarch64_feature_flags variable
is used, but only the bottom three isa mode bits are set and read.
Using a separate data type for these value makes it more clear that
they're not expected or required to have any of their upper feature bits
set. It will also
AARCH64_NUM_ISA_MODES will be used within aarch64-opts.h in a later
commit.
gcc/ChangeLog:
* config/aarch64/aarch64.h (DEF_AARCH64_ISA_MODE): Move to...
* config/aarch64/aarch64-opts.h (DEF_AARCH64_ISA_MODE): ...here.
diff --git a/gcc/config/aarch64/aarch64-opts.h
b/gcc/config/
The end goal of the series is to change the definition of aarch64_feature_flags
from a uint64_t typedef to a class with 128 bits of storage. This class is a
new template bitmap type that uses operator overloading to mimic the existing
integer interface as much as possible.
The changes are mostly
gcc/ChangeLog:
* config/aarch64/aarch64.cc
(aarch64_tune_flags): Remove unused global variable.
(aarch64_override_options_internal): Remove dead assignment.
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index
9e51236ce9fa059ccc6e4fe24335b5fb3
On Tue, Jul 23, 2024 at 09:38:15PM -0400, Jason Merrill wrote:
Thanks.
> > but please see
> > https://github.com/llvm/llvm-project/pull/97274#issuecomment-2230929277
> > comment and whether we really want the preprocessor to preprocess it for
> > C++ as (or as-if)
> > static_cast(127),static_cast
> That phrasing makes sense to me. It's consistent with the -mbig-endian
> sorry message:
>
> https://godbolt.org/z/oWMeorEeM
I seem to remember that explicitly mentioning GCC in an error message like
that was discouraged but I might be confusing things.
So probably
"GCC's current 'V' implementa
Peter:
On 7/23/24 2:26 PM, Peter Bergner wrote:
On 7/19/24 3:04 PM, Carl Love wrote:
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 5af9bf920a2..2a18ee44526 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -878,9 +878,9 @@ (define_i
On 7/24/24 08:37, Robin Dapp wrote:
It's really GCC's implementation of the V extension that requires M, not
the actul ISA V extension. So I think the wording could be a little
confusing for users here, but no big deal either way on my end so
Reviewed-by: Palmer Dabbelt
Hmm, fair. How abou
> It's really GCC's implementation of the V extension that requires M, not
> the actul ISA V extension. So I think the wording could be a little
> confusing for users here, but no big deal either way on my end so
>
> Reviewed-by: Palmer Dabbelt
Hmm, fair. How about just "the 'V' implementatio
On Wed, 24 Jul 2024 08:25:30 PDT (-0700), Robin Dapp wrote:
Hi,
now with proper diff...
For calculating the value of a poly_int at runtime we use a
multiplication instruction that requires the M extension.
Instead of just asserting and ICEing this patch emits an early
error at option-parsing ti
1 - 100 of 144 matches
Mail list logo
