This patch fixes a regression introduced by g:708ee71808ea61758e73.
x86_64 allows addresses of the form:
(zero_extend:DI (subreg:SI (symbol_ref:DI "foo") 0))
Before the previous patch, a lax SUBREG check meant that we would
treat the subreg as a base and reload it into a base register.
But that
From: Pan Li
This patch would like to support the scalar signed ssadd pattern
for the RISC-V backend. Aka
Form 1:
#define DEF_SAT_S_ADD_FMT_1(T, UT, MIN, MAX) \
T __attribute__((noinline)) \
sat_s_add_##T##_fmt_1 (T x, T y) \
{
> -Original Message-
> From: Gerald Pfeifer
> Sent: Thursday, August 29, 2024 3:20 AM
>
> On Wed, 28 Aug 2024, Haochen Jiang wrote:
> > Sorry for the disturb since I mis-typoed gcc-patches to gcc-patchs,
> > resend the patch.
>
> No worries.
>
> > This patch will add documentation for r
Victor Do Nascimento 于2024年8月28日周三 23:15写道：
>
> Hello,
>
> Gentle reminder for this simple renaming patch :)
>
Approved, but, it will be better if we can add a test case for it.
> Thanks,
> Victor
>
>
> On 8/15/24 09:44, Victor Do Nascimento wrote:
> > Following the migration of the dot_prod opt
After adding popcount{qi,hi}2 to the aarch64 backend, I noticed that
the expansion for popcount==1 was no longer trying to do the trick
of handling popcount==1 as `(arg ^ (arg - 1)) > arg - 1`. The problem
is the expansion was using OPTAB_DIRECT, when using OPTAB_WIDEN
will allow modes which are sm
On Wed, Aug 28, 2024 at 4:05 AM Alex Coplan wrote:
>
> On 28/08/2024 11:53, Richard Sandiford wrote:
> > Alex Coplan writes:
> > > Hi,
> > >
> > > This is a v2 of:
> > > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659966.html
> > > which is rebased on top of Richard S's patch to reduce
Jason Merrill writes:
> On 8/28/24 3:59 PM, Arsen Arsenović wrote:
>> This patch fixes a gcc-15 regression (PR116502) and an inelegance in my
>> earlier patch related to converting CO_AWAIT_EXPRs to void.
>> This wasn't noticed anywhere AFAICT, but it was a bit unfortunate.
>> The other two patch
Thanks Jeff. Yes, sounds good to me.
Mark
On 27/08/2024 16:23, Jeff Law wrote:
On 8/26/24 4:48 PM, Mark Harmstone wrote:
Run all CodeView names through a new function get_name, which chains
together a DIE's DW_AT_name with that of its parent to create a
C++-style name.
gcc/
* dwarf2code
On 8/28/24 3:59 PM, Arsen Arsenović wrote:
This patch fixes a gcc-15 regression (PR116502) and an inelegance in my
earlier patch related to converting CO_AWAIT_EXPRs to void.
This wasn't noticed anywhere AFAICT, but it was a bit unfortunate.
The other two patches fix an actual regression as wel
On 8/28/24 3:18 PM, Arsen Arsenović wrote:
Regtested on x86_64-pc-linux-gnu. OK for trunk?
OK.
-- >8 --
In some scenarios, it is possible for the CFG cleanup to cause one of
the labels mentioned in CO_YIELD, which coro-early-expand-ifns intends
to remove, to become part of so
On 8/28/24 4:51 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
OK.
-- >8 --
Here maybe_init_list_as_array gets elttype=field, init={NON_LVALUE_EXPR <2>}
and it tries to convert the init's element type (int) to field
using implicit_conversion, which wo
On Wed, Aug 28, 2024 at 12:26 AM Richard Biener
wrote:
>
> On Wed, Aug 28, 2024 at 6:34 AM Andrew Pinski
> wrote:
> >
> > While working on PR 114224, I found it would be useful to dump the
> > different costs of the expansion to make easier to understand why one
> > was chosen over the other.
>
Hi,
Arsen Arsenović writes:
>> The && should not be left of the =; if the initializer needs to span multiple
>> lines, it's usually best to wrap it in ().
>
> Okay - done.
[...]
>>> + foo::operator delete (new (123, true) foo, 123, true);
>>> + foo::operator delete[] (new (123, true) foo[123
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
Here maybe_init_list_as_array gets elttype=field, init={NON_LVALUE_EXPR <2>}
and it tries to convert the init's element type (int) to field
using implicit_conversion, which works, so overall maybe_init_list_as_array
is succes
Tested x86_64-linux. Pushed to trunk.
-- >8 --
I misused the AC_CHECK_DECL macro, assuming that it behaved like
AC_CHECK_DECLS and always defined a HAVE_xxx macro if the decl was
found. Instead, the [action-if-found] shell commands are needed to
defined HAVE_O_NONBLOCK explicitly.
libstdc++-v3/C
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/experimental/io_context: Remove name of unused
parameter.
* include/experimental/socket: Add [[maybe_unused]] attribute.
---
libstdc++-v3/include/experimental/io_context | 2 +-
libstdc++-v3
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/format (format_parse_context::check_dynamic_spec):
Add [[maybe_unused]] attribute and comment.
---
libstdc++-v3/include/std/format | 5 +
1 file changed, 5 insertions(+)
diff --git a/libstd
Tested x86_64-linux. Pushed to trunk.
-- >8 --
This local typedef should have been removed in r14-6199-g45630fbcf7875b.
libstdc++-v3/ChangeLog:
* include/std/ranges (to): Remove unused typedef.
---
libstdc++-v3/include/std/ranges | 1 -
1 file changed, 1 deletion(-)
diff --git a/libst
Add Dhruv Matani to the contributors page, for libstdc++ contributions
back in 2004.
-- >8 --
gcc/ChangeLog:
* doc/contrib.texi (Contributors): Add Dhruv Matani.
---
gcc/doc/contrib.texi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/doc/contrib.texi b/gcc/doc/contrib.texi
i
On Sun, 25 Aug 2024 at 19:20, Kim Gräsman wrote:
>
> A few of these files self-identified as ext/random.tcc, update to use
> the actual basename.
Tested and pushed to trunk, thanks.
>
> libstdc++-v3/ChangeLog:
>
> * config/cpu/aarch64/opt/ext/opt_random.h: Improve doxygen file
> d
On Sun, 25 Aug 2024 at 19:19, Kim Gräsman wrote:
>
> There is no file ext/type_traits, point it to ext/type_traits.h instead.
Tested and pushed to trunk, thanks.
(Both your patches are simple enough to not require a copyright
assignment or DCO sign-off).
>
> libstdc++-v3/ChangeLog:
>
>
Hm, maybe-unused-1.C should be moved into the previous patch. Could do
before pushing.
-- >8 --
If such a diagnostic is necessary, it has already been emitted,
otherwise, it is not correct and emitting it here is inactionable by the
user, and bogus.
PR c++/116502
gcc/cp/C
Currently, GCC misses a diagnostic when discarding a CO_AWAIT_EXPR
resulting in a reference type, because such an expression is wrapped in
an INDIRECT_REF in finish_co_await_expr. Similar handling is necessary
for CALL_EXPRs, so extend it to also handle CO_AWAIT_EXPR.
gcc/cp/ChangeLog:
*
This patch fixes a gcc-15 regression (PR116502) and an inelegance in my
earlier patch related to converting CO_AWAIT_EXPRs to void.
This wasn't noticed anywhere AFAICT, but it was a bit unfortunate.
The other two patches fix an actual regression as well as provide
handling for converting INDIRECT
Regtested on x86_64-pc-linux-gnu. OK for trunk?
-- >8 --
In some scenarios, it is possible for the CFG cleanup to cause one of
the labels mentioned in CO_YIELD, which coro-early-expand-ifns intends
to remove, to become part of some statement. As a result, when that
label is remove
On Wed, 28 Aug 2024, Haochen Jiang wrote:
> Sorry for the disturb since I mis-typoed gcc-patches to gcc-patchs,
> resend the patch.
No worries.
> This patch will add documentation for recent update in x86-64 backend.
Thank you!
> + Xeon Phi CPUs support (a.k.a. Knight Landing and Knight Mill)
On Wed, 28 Aug 2024, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu. Any objections? Should I change all the other
> instances of
>
> if (CPP_PEDANTIC...
> cpp_error (...CPP_DL_PEDWARN
>
> the same way?
Yes, I think that's a good change.
A followup question might be whether cases such a
generic_vector_cost is not currently used by any SVE target
by default; it has to be specifically selected by -mtune=generic.
Its SVE costing has historically been somewhat idealised, since
it predated any actual SVE cores. This seems like a useful
tradition to continue, at least for testing purpo
The SVE gather and scatter costs are classified based on whether
they do 4 loads per 128 bits (x32) or 2 loads per 128 bits (x64).
The number after the "x" refers to the number of bits in each
"container".
However, the test for which to use was based on the element size
rather than the container s
On 8/28/24 11:21 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK for trunk/13/14.
-- >8 --
Here we crash on a cp_gimplify_expr/TARGET_EXPR assert:
gcc_checking_assert (!TARGET_EXPR_ELIDING_P (*expr_p)
|| !TREE_ADDRES
g:8d6c6fbc5271dde433998c09407b30e2cf195420 improved the code
generated for functions like:
void test_s8 (int8x8x2_t *ptr) { *ptr = (int8x8x2_t) {}; }
Previously we would load zero from the constant pool, whereas
now we just use "stp xzr, xzr". This patch adds a test for
this improvement.
Test
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we crash on a cp_gimplify_expr/TARGET_EXPR assert:
gcc_checking_assert (!TARGET_EXPR_ELIDING_P (*expr_p)
|| !TREE_ADDRESSABLE (TREE_TYPE (*expr_p)));
We cannot elide the TARGET_EXPR becaus
Hello,
Gentle reminder for this simple renaming patch :)
Thanks,
Victor
On 8/15/24 09:44, Victor Do Nascimento wrote:
Following the migration of the dot_prod optab from a direct to a
conversion-type optab, ensure all back-end patterns incorporate the
second machine mode into pattern names.
gc
Tested x86_64-pc-linux-gnu. Any objections? Should I change all the other
instances of
if (CPP_PEDANTIC...
cpp_error (...CPP_DL_PEDWARN
the same way?
-- 8< --
Using CPP_W_PEDANTIC lets users suppress these diagnostics with
#pragma GCC diagnostic ignored "-Wpedantic".
libcpp/ChangeLog:
Hello,
Gentle reminder for this simple renaming patch :)
Thanks,
Victor
On 8/15/24 09:44, Victor Do Nascimento wrote:
Following the migration of the dot_prod optab from a direct to a
conversion-type optab, ensure all back-end patterns incorporate the
second machine mode into pattern names.
g
Hello,
Gentle reminder for this simple renaming patch :)
Thanks,
Victor
On 8/15/24 09:44, Victor Do Nascimento wrote:
Following the migration of the dot_prod optab from a direct to a
conversion-type optab, ensure all back-end patterns incorporate the
second machine mode into pattern names.
gc
Following on from the earlier tree rename, this patch renames
gimple_asm_input_p to gimple_asm_basic_p, and similarly for
related names.
Tested on aarch64-linux-gnu. OK to install?
Richard
gcc/
* doc/gimple.texi (gimple_asm_basic_p): Document.
(gimple_asm_set_basic): Likewise.
ASM_INPUT_P is so named because it causes the eventual rtl insn
pattern to be a top-level ASM_INPUT rather than an ASM_OPERANDS.
However, this name has caused confusion, partly due to earlier
documentation. The name also sounds related to ASM_INPUTS but
is for a different piece of state.
This pat
Richard Biener writes:
> On Tue, Aug 27, 2024 at 7:17 PM Richard Sandiford
> wrote:
>>
>> The documentation of ASM_INPUT_P implied that the flag has no
>> effect on ASM_EXPRs that have operands (and which therefore must be
>> extended asms). In fact we require ASM_INPUT_P to be false for all
>>
> On Wed, Aug 28, 2024 at 3:21 PM Robin Dapp wrote:
> >
> > > Hmm - but how can you call this ambiguous? VLEN and LMUL is a runtime
> > > property(?), so unknown to the compiler(?) - as you do below the only
> > > way to code generate would be a agnostic way such as with a slide-down.
> > > But c
smallest_int_mode_for_size now returns an optional mode rather
than aborting on failure. This patch adjusts a couple of callers
so that they fail gracefully when no mode exists.
There should be no behavioural change, since anything that triggers
the new return paths would previously have aborted.
Pushed to wwwdocs.
---
htdocs/gcc-15/changes.html | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index d0d6d147..91c020dd 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -8
Hi Sandra,
thanks for your comments.
Sandra Loosemore wrote:
Stepping back to consider this from a higher-level perspective,
shouldn't the interface documented in the GCC manual reflect what GCC
implements, rather than what the spec says that is explicitly *not*
what is implemented? Or is th
On Wed, Aug 28, 2024 at 3:21 PM Robin Dapp wrote:
>
> > Hmm - but how can you call this ambiguous? VLEN and LMUL is a runtime
> > property(?), so unknown to the compiler(?) - as you do below the only
> > way to code generate would be a agnostic way such as with a slide-down.
> > But can't you alw
> I agree. I don't have a preference for which is better, but being consistent
> with other documentation might be a winning argument.
Pushed as attached.
FX
0001-Libquadmath-update-doc-for-some-constants.patch
Description: Binary data
The following emulates classical interleaving for SLP load permutes
that we are unlikely handling natively. This is to handle cases
where interleaving (or load/store-lanes) is the optimal choice for
vectorizing even when we are doing that within SLP. An example
would be
void foo (int * __restric
The following is a prototype for how to represent load/store-lanes
within SLP. I've for now settled with having a single load node
with multiple permute nodes acting as selection, one for each loaded lane
and a single store node fed from all stored lanes. For
for (int i = 0; i < 1024; ++i)
When evaluating the difference of two aligned pointers in CCP we
fail to handle the EXACT_DIV_EXPR by the element size that occurs.
The testcase then also exercises modulo to test alignment but
modulo by a power-of-two isn't handled either.
Re-bootstrap and regtest running on x86_64-unknown-linux-
On Tue, 27 Aug 2024, Filip Kastl wrote:
> Hi,
>
> this is the second version of this patch. See the mail with the first version
> here:
>
> https://inbox.sourceware.org/gcc-patches/ZsnRLdYErnIWQlCe@localhost.localdomain/
>
> In this version I've made these adjustments:
> - Added calls direct_i
> Hmm - but how can you call this ambiguous? VLEN and LMUL is a runtime
> property(?), so unknown to the compiler(?) - as you do below the only
> way to code generate would be a agnostic way such as with a slide-down.
> But can't you always to this, for all subregs of this sort (even with offset)?
> On 28 Aug 2024, at 10:27, Tamar Christina wrote:
>
> External email: Use caution opening links or attachments
>
>
>> -Original Message-
>> From: Kyrylo Tkachov
>> Sent: Wednesday, August 28, 2024 8:55 AM
>> To: Tamar Christina
>> Cc: Richard Sandiford ; Jennifer Schmitz
>> ; gcc-p
On Wed, 28 Aug 2024 at 10:45, Jonathan Wakely wrote:
>
> On Wed, 28 Aug 2024 at 10:38, Jason Merrill wrote:
> >
> > Tested x86_64-pc-linux-gnu. OK for trunk, or were these supposed to be
> > used?
>
> I think the _RefT typedef was used in an earlier version of the code
> (possibly a much earlie
Alex Coplan writes:
> On 28/08/2024 11:53, Richard Sandiford wrote:
>> Alex Coplan writes:
>> > Hi,
>> >
>> > This is a v2 of:
>> > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659966.html
>> > which is rebased on top of Richard S's patch to reduce the cut-and-paste in
>> > scanltranstre
On 28/08/2024 11:53, Richard Sandiford wrote:
> Alex Coplan writes:
> > Hi,
> >
> > This is a v2 of:
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659966.html
> > which is rebased on top of Richard S's patch to reduce the cut-and-paste in
> > scanltranstree.exp (thanks again for doing
On Wed, Aug 28, 2024 at 12:49 PM Alex Coplan wrote:
>
> This is a v2 of:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659969.html
> this version just streams the flag as requested.
>
> Bootstrapped/tested as a series on aarch64-linux-gnu (both with and
> without LTO), OK for trunk?
OK
On Wed, Aug 28, 2024 at 11:10 AM Marc wrote:
>
> Hello,
>
> Gentle reminder for this simple autoconf patch :)
OK.
Note that completely wiping LIBS might remove requirements detected earlier,
like some systems require explicit -lc for example. I would instead not clear
LIBS here and instead allo
Alex Coplan writes:
> Hi,
>
> This is a v2 of:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659966.html
> which is rebased on top of Richard S's patch to reduce the cut-and-paste in
> scanltranstree.exp (thanks again for doing that).
>
> Tested on aarch64-linux-gnu, OK for trunk?
>
> Th
Hi,
This is a v2 of:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659966.html
which is rebased on top of Richard S's patch to reduce the cut-and-paste in
scanltranstree.exp (thanks again for doing that).
Tested on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
-- >8 --
This extends the
This is a v2 of:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659969.html
this version just streams the flag as requested.
Bootstrapped/tested as a series on aarch64-linux-gnu (both with and
without LTO), OK for trunk?
Thanks,
Alex
-- >8 --
When #pragma GCC unroll is processed in
tree-
On Wed, 28 Aug 2024 at 10:55, Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu, OK for trunk?
OK, thanks.
>
> -- 8< --
>
> -Wsign-compare complained about these comparisons between (unsigned) size_t
> and (signed) streamsize, or between (unsigned) native_handle_type
> and (signed) -1. Fixed b
I found it helpful to be able to print a whole SLP instance from gdb.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-slp.cc (debug): Add overload for slp_instance.
---
gcc/tree-vect-slp.cc | 9 +
1 file changed, 9 insertions(+)
diff --git a/gcc/tree-vec
The following fixes a leak of the discovered single-lane store
SLP nodes from which we only use their children. This uncovers
a latent reference counting issue in the interleaving build where
we fail to increment their reference count.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
This splits out SLP store interleaving into a separate function.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-slp.cc (vect_build_slp_store_interleaving): Split
out from ...
(vect_build_slp_instance): Here.
---
gcc/tree-vect-slp.cc | 356 +++
On 8/28/24 6:09 AM, Jonathan Wakely wrote:
On Wed, 28 Aug 2024 at 10:58, Jason Merrill wrote:
On 8/28/24 5:55 AM, Jonathan Wakely wrote:
On Wed, 28 Aug 2024 at 10:54, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
Redefining that macro to invalidate PCH is a bit of a hack,
On Wed, 28 Aug 2024 at 06:47, Dhruv Chawla wrote:
>
> version.syn#2 requires to define
> __cpp_lib_allocator_traits_is_always_equal.
>
> The attached patch therefore defines the
> __glibcxx_want_allocator_traits_is_always_equal macro to get the
> definition of the feature-test macro from .
>
> Th
On Wed, 28 Aug 2024 at 10:58, Jason Merrill wrote:
>
> On 8/28/24 5:55 AM, Jonathan Wakely wrote:
> > On Wed, 28 Aug 2024 at 10:54, Jason Merrill wrote:
> >>
> >> Tested x86_64-pc-linux-gnu, OK for trunk?
> >
> > Redefining that macro to invalidate PCH is a bit of a hack, but it's
> > what we have
On 8/28/24 5:55 AM, Jonathan Wakely wrote:
On Wed, 28 Aug 2024 at 10:54, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
Redefining that macro to invalidate PCH is a bit of a hack, but it's
what we have for now, so OK for trunk, thanks.
If it's just to invalidate PCH, do we w
On Wed, 28 Aug 2024 at 10:54, Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu, OK for trunk?
Redefining that macro to invalidate PCH is a bit of a hack, but it's
what we have for now, so OK for trunk, thanks.
>
> -- 8< --
>
> testsuite/lib/dg-options.exp defines __GLIBCXX__ to 999; avoid
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
-Wsign-compare complained about these comparisons between (unsigned) size_t
and (signed) streamsize, or between (unsigned) native_handle_type
and (signed) -1. Fixed by adding casts to unify the types.
libstdc++-v3/ChangeLog:
* include/
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
testsuite/lib/dg-options.exp defines __GLIBCXX__ to 999; avoid a macro
redefinition warning in that case.
libstdc++-v3/ChangeLog:
* include/bits/c++config: Avoid redefining __GLIBCXX__.
---
libstdc++-v3/include/bits/c++config | 2 +
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The pedwarns for each of these features should be silenced by
the appropriate -Wno-c++??-extensions.
The handle_pragma_diagnostic_impl change is necessary so that we handle
-Wc++23-extensions early so it's available to interpret_float while
On Wed, 28 Aug 2024 at 10:38, Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu. OK for trunk, or were these supposed to be used?
I think the _RefT typedef was used in an earlier version of the code
(possibly a much earlier version that was never even pushed). It can
be removed.
I think the _
Tested x86_64-pc-linux-gnu, applying to trunk as obvious.
-- 8< --
libstdc++-v3/ChangeLog:
* include/std/coroutine (coroutine_handle): Use nullptr instead of
0 as initializer for _M_fr_ptr.
---
libstdc++-v3/include/std/coroutine | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Tested x86_64-pc-linux-gnu, applying to trunk as obvious.
-- 8< --
The unescaped * broke the match.
libstdc++-v3/ChangeLog:
* testsuite/20_util/default_delete/void_neg.cc: Fix regexp quoting.
---
libstdc++-v3/testsuite/20_util/default_delete/void_neg.cc | 2 +-
1 file changed, 1 insert
Tested x86_64-pc-linux-gnu, applying to trunk as obvious.
-- 8< --
The return seems to have been lost in the r15-1858 RAII overhaul.
libstdc++-v3/ChangeLog:
* include/bits/stl_uninitialized.h (__uninitialized_move_copy): Add
missing return.
---
libstdc++-v3/include/bits/stl_uni
> On 28 Aug 2024, at 11:22, saurabh@arm.com wrote:
>
> External email: Use caution opening links or attachments
>
>
> The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
> mandatory from Armv9.5-a. It introduces instructions for computing the
> floating point absolute maxim
Tested x86_64-pc-linux-gnu, applying to trunk as obvious.
-- 8< --
The semicolons after each macro invocation here end up following the closing
brace of a function, leading to -Wextra-semi pedwarns.
libstdc++-v3/ChangeLog:
* include/decimal/decimal.h (_DEFINE_DECIMAL_BINARY_OP_WITH_INT)
Tested x86_64-pc-linux-gnu. OK for trunk, or were these supposed to be used?
-- 8< --
The __ok variable and _RefT typedef aren't used in the rest of their blocks.
Should they be?
libstdc++-v3/ChangeLog:
* include/std/format (check_dynamic_spec): Add [[maybe_unused]].
* include/
The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
mandatory from Armv9.5-a. It introduces instructions for computing the
floating point absolute maximum and minimum of the two vectors element-wise.
This patch introduces AdvSIMD faminmax intrinsics. The intrinsics of
this extensio
The AArch64 FEAT_FAMINMAX extension is optional from Armv9.2-a and
mandatory from Armv9.5-a. It introduces instructions for computing the
floating point absolute maximum and minimum of the two vectors
element-wise.
This patch adds code generation support for famax and famin in terms of
existing R
From: Saurabh Jha
This patch series is a respin of the previous patch here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660917.html
The new version addresses review comments on the previous patch series.
It also introduced a new way of defining AArch4 AdvSIMD intrinsics. All
of the new
Hello,
Gentle reminder for this simple autoconf patch :)
Thanks,
Marc
> On 28 Aug 2024, at 11:04, Richard Sandiford wrote:
>
> External email: Use caution opening links or attachments
>
>
> Tamar Christina writes:
>>> The patch was bootstrapped and regtested on aarch64-linux-gnu:
>>> No problems bootstrapping, but several test files (in aarch64-sve.exp
Tamar Christina writes:
>> The patch was bootstrapped and regtested on aarch64-linux-gnu:
>> No problems bootstrapping, but several test files (in aarch64-sve.exp:
>> gather_load_extend_X.c
>> where X is 1 to 4, strided_load_2.c, strided_store_2.c) fail because of
>> smal
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Wednesday, August 28, 2024 8:55 AM
> To: Tamar Christina
> Cc: Richard Sandiford ; Jennifer Schmitz
> ; gcc-patches@gcc.gnu.org; Kyrylo Tkachov
>
> Subject: Re: [RFC][PATCH] AArch64: Remove
> AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS
>
>
Thank you for your comments. I also think that the description of cost
may need further improvement. For example, I noticed that when the
destination address of SET is a register, riscv_rtx_costs will always
return true, but we haven't covered all scenarios.
On Tue, Aug 27, 2024 at 05:42:36PM +08
On Sun, Aug 25, 2024 at 9:41 PM Jeff Law wrote:
>
>
> On 7/26/24 12:06 PM, Mariam Arutunian wrote:
> >If the target is ZBC or ZBKC, it uses clmul instruction for the CRC
> > calculation.
> > Otherwise, if the target is ZBKB, generates table-based CRC, but for
> > reversing inputs and the outp
Hi all,
Thanks to Jennifer for proposing a patch and Tamar and Richard for digging into
it.
> On 27 Aug 2024, at 13:16, Tamar Christina wrote:
>
> External email: Use caution opening links or attachments
>
>
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Tuesday, August 2
Noted with thanks, will commit with that change if no surprise from test.
Pan
-Original Message-
From: Richard Biener
Sent: Wednesday, August 28, 2024 3:24 PM
To: Li, Pan2
Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com;
jeffreya...@gmail.com; rdapp@gmail.c
> On 28 Aug 2024, at 06:33, Andrew Pinski wrote:
>
> External email: Use caution opening links or attachments
>
>
> While looking into some popcount related I noticed that the popcount
> cost is not modeled at all. This adds both the vector and scalar (for CSSC)
> costs. For CSSC, we default
On Wed, Aug 28, 2024 at 6:34 AM Andrew Pinski wrote:
>
> While working on PR 114224, I found it would be useful to dump the
> different costs of the expansion to make easier to understand why one
> was chosen over the other.
>
> Bootstrapped and tested on x86_64-linux-gnu.
> Build and tested for a
On Wed, Aug 28, 2024 at 6:29 AM wrote:
>
> From: Pan Li
>
> The .SAT_ADD has 2 operand, when one of the operand may be INTEGER_CST.
> For example _1 = .SAT_ADD (_2, 9) comes from below sample code.
>
> Form 3:
> #define DEF_VEC_SAT_U_ADD_IMM_FMT_3(T, IMM) \
> T __attr
On Wed, Aug 28, 2024 at 3:18 AM Li, Pan2 wrote:
>
> Kindly ping.
Please do not include stdint-gcc.h but stdint.h.
otherwise OK.
Richard.
> Pan
>
> -Original Message-
> From: Li, Pan2
> Sent: Monday, August 19, 2024 10:05 AM
> To: gcc-patches@gcc.gnu.org
> Cc: juzhe.zh...@rivai.ai; kit
On Wed, Aug 28, 2024 at 2:05 AM Weslley da Silva Pereira
wrote:
>
> Hi all,
>
> Thanks for reading my email.
>
> I submitted a patch for libstdc++/complex, but I have no idea if that was
> merged. I also have no idea on how to check that. Could someone help me?
>
> Patch name: "[PATCH] libstdc++/
On Wed, Aug 28, 2024 at 12:43 AM Edwin Lu wrote:
>
> On 8/22/2024 5:35 AM, Richard Biener wrote:
> > On Thu, Aug 22, 2024 at 1:03 AM Edwin Lu wrote:
> >>
> >> Hi,
> >>
> >> Just wanted to ping this for more guidance.
> >
> > It's difficult for me as long as I cannot investigate this with a testca
On Tue, Aug 27, 2024 at 4:03 PM Robin Dapp wrote:
>
> Hi,
>
> this is a hopefully better way to solve the "subreg problem" by first,
> in the generic case, have the RA go via memory and second, providing a
> vector-vector extract that deals with it in an optimized way.
>
> When the source mode is
On Tue, Aug 27, 2024 at 7:53 PM Georg-Johann Lay wrote:
>
> Am 27.08.24 um 17:28 schrieb Jeff Law:
> >
> > On 8/26/24 1:15 PM, Georg-Johann Lay wrote:
> >
> >> What the avr-ifelse pass does is try to replace 2 cbranch insns with
> >> one compare insn and two branches. It runs after reload and jus
97 matches
Mail list logo
