Hi!
On Wed, May 21, 2025 at 06:27:38AM +0200, Richard Biener wrote:
> On Wed, May 21, 2025 at 12:30 AM Segher Boessenkool
> wrote:
> >
> > On Mon, May 12, 2025 at 06:35:15PM -0400, Michael Meissner wrote:
> > > On Mon, May 12, 2025 at 01:24:04PM +0530, Surya Kumari Jangala wrote:
> > > > Hi Mike,
The kernel developers have requested such a constraint to use csrxchg
in inline assembly.
gcc/ChangeLog:
* doc/md.texi: Document the 'q' constraint for LoongArch.
---
Ok for trunk?
gcc/doc/md.texi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
This commit series implements double indirection avoidance for the
function_ref and it is based on my patch for function_ref implementation.
This patch is send as RFC instead of PATCH ready for review, as I have
noticed that performing this implementation is user-observable and not
allowed in the
This patch uses the additional provisions from LWG 4264, to avoid double
indirection when function_ref is constructed from move_only_function or
copyable_function with compatible signature. The details of compatible
signatures follows the move_only_function as described in
r16-617-g708d40ff109c6e49
On Wed, May 21, 2025 at 10:13:27AM +0800, Yang Yujie wrote:
> On Tue, May 20, 2025 at 03:44:09PM GMT, Jakub Jelinek wrote:
> > I'd suggest working on it incrementally rather than with a full patch set.
> > In one or multiple patches handle the promote_mode stuff, the atomic
> > extension and expr.c
This patch uses the additional provisions from LWG 4264, to avoid double
indirection when function_ref is constructed from function_ref with
compatible signature.
The details of compatible signatures follows the move_only_function
as described in r16-617-g708d40ff109c6e49d02b684a368571722a160af8.
在 2025/5/21 下午3:14, Xi Ruoyao 写道:
The kernel developers have requested such a constraint to use csrxchg
in inline assembly.
gcc/ChangeLog:
* doc/md.texi: Document the 'q' constraint for LoongArch.
---
Ok for trunk?
LGTM!
Thanks!
gcc/doc/md.texi | 3 +++
1 file changed, 3 ins
On 5/21/25 08:29, Tomasz Kaminski wrote:
On Tue, May 20, 2025 at 3:16 PM Luc Grosheintz
wrote:
Implements the parts of layout_left that don't depend on any of the
other layouts.
libstdc++-v3/ChangeLog:
* include/std/mdspan (layout_left): New class.
Signed-off-by: Luc Grosheintz
On Wed, 21 May 2025 at 06:57, Xi Ruoyao wrote:
>
> On Tue, 2025-05-20 at 13:06 +0100, Jonathan Wakely wrote:
> > On 13/07/20 16:45 +0800, Xi Ruoyao via Libstdc++ wrote:
> > >
> > > > The second and third patch together resolve PR 81806.
> > >
> > > The attached patch modifies split_finish to use t
VxWorks uses x18 as the TCB, so STATIC_CHAIN_REGNUM has long been set
(in gcc/config/aarch64/aarch64-vxworks.h) to use x9 instead.
This patch marks x18 as fixed on TARGET_VXWORKS, so that it is not
chosen by the register allocator, and adjusts tests that depend on x18
or on the static chain regi
> gcc/
> * config/sparc/sparc.md (zero_extendhisi2, zero_extendhidi2)
> (extendhisi2, extendqihi2, extendqisi2, extendqidi2)
> (extendhidi2): Use operands[0] and operands[1] instead of
> operand0 and operand1.
OK, thanks.
--
Eric Botcazou
On Wed, May 21, 2025 at 10:20 AM Luc Grosheintz
wrote:
>
>
> On 5/21/25 08:29, Tomasz Kaminski wrote:
> > On Tue, May 20, 2025 at 3:16 PM Luc Grosheintz >
> > wrote:
> >
> >> Implements the parts of layout_left that don't depend on any of the
> >> other layouts.
> >>
> >> libstdc++-v3/ChangeLog:
Hi,
IPA-SRA generally works fine in the presence of reverse Scalar_Storage_Order
by propagating the relevant flag onto the newly generated MEM_REFs. However
we have been recently faced with a specific Ada pattern that it doesn't handle
correctly: 'Valid applied to a floating-point component of
On Wed, 21 May 2025 at 10:56, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > Many tests became unsupported on aarch64 when -mcpu=unset was added to
> > several arm_* effective targets, because this flag is only supported
> > on arm.
> >
> > Since these effective targets are used on arm
This patch implements C++26 function_ref as specified in P0792R14,
with correction for constraints for constructor accepting nontype_t
parameter from LWG 4256.
As function_ref may store a pointer to the const object, __Ptrs::_M_obj is
changed to const void*, so again we do not cast away const from
On Wed, May 21, 2025 at 09:21:40AM GMT, Jakub Jelinek wrote:
>
> The existing testsuite never tests whether the padding bits are sign or zero
> extended or contain unknown values.
> In the s390x patch, info->extended is set to true, yet all bitint tests but
> bitint-64.c at -O3 pass.
>
> So, I'm
On Tue, May 20, 2025, 1:47 PM Christophe Lyon
wrote:
> Many tests became unsupported on aarch64 when -mcpu=unset was added to
> several arm_* effective targets, because this flag is only supported
> on arm.
>
> Since these effective targets are used on arm and aarch64, the patch
> adds -mcpu=unse
The new name is _M_exts, which expresses the fact that it models all
extents not just dynamic extents. It also shortens the name to make it
consistent with _ExtentsStorage.
libstdc++-v3/ChangeLog:
* include/std/mdspan(extents): Change name of private member
from _M_dynamic_extents
Follows up on:
https://gcc.gnu.org/pipermail/libstdc++/2025-May/061535.html
To improve naming conventions, this series includes three new commits:
* Two commits to rename _ExtentsStorage::_M_dynamic_extents, and
extents::_M_dynamic_extents.
* One commit to cleanup whitespace errors in ext
The new name is _M_dyn_exts and makes space for a method
_M_dynamic_extens, which returns a view of the requested dynamic
extents.
libstdc++-v3/ChangeLog:
* include/std/mdspan(__mdspan::_ExtentsStorage): Change name
of private member _M_dynamic_extens to _M_dyn_exts.
Signed-off-b
Implements the parts of layout_left that don't depend on any of the
other layouts.
libstdc++-v3/ChangeLog:
* include/std/mdspan (layout_left): New class.
Signed-off-by: Luc Grosheintz
---
libstdc++-v3/include/std/mdspan | 307 +++-
1 file changed, 306 insert
libstdc++-v3/ChangeLog:
* include/std/mdspan: Fix two instances of
whitespace errors: `for(` -> `for (`.
Signed-off-by: Luc Grosheintz
---
libstdc++-v3/include/std/mdspan | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libstdc++-v3/include/std/mdspan b/li
Implements the remaining parts of layout_left and layout_right; and all
of layout_stride.
libstdc++-v3/ChangeLog:
* include/std/mdspan(layout_stride): New class.
Signed-off-by: Luc Grosheintz
---
libstdc++-v3/include/std/mdspan | 216 +++-
1 file changed, 21
Implements the tests for layout_stride and for the features of the other
two layouts that depend on layout_stride.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add
tests for layout_stride.
* testsuite/23_containers/mdspan/layouts/c
Implement the parts of layout_left that depend on layout_right; and the
parts of layout_right that don't depend on layout_stride.
libstdc++-v3/ChangeLog:
* include/std/mdspan (layout_right): New class.
Signed-off-by: Luc Grosheintz
---
libstdc++-v3/include/std/mdspan | 153
Implements a suite of tests for the currently implemented parts of
layout_left. The individual tests are templated over the layout type, to
allow reuse as more layouts are added.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: New test.
* tes
Adds tests for layout_right and for the parts of layout_left that depend
on layout_right.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/mdspan/layouts/class_mandate_neg.cc: Add
tests for layout_stride.
* testsuite/23_containers/mdspan/layouts/ctors.cc: Add tests for
On Wed, May 21, 2025 at 9:44 AM Jakub Jelinek wrote:
>
> Hi!
>
> As mentioned by Linus, we can't optimize comparison of otherwise unused
> result of plus with CONST_INT second operand, compared against zero.
> This can be done using just cmp instruction with negated constant and say
> js/jns/je/jn
On Wed, May 21, 2025 at 05:38:27PM +0800, Yang Yujie wrote:
> The current master branch does not seem to have _BitInt support for s390x,
> is the patch on this list?
>
> Also, I cannot find the relevant psABI definition or discussions at
> https://github.com/IBM/s390x-abi
They were mailed to me p
s
Hi!
On Thu, May 08, 2025 at 07:44:26PM -0400, Michael Meissner wrote:
> In bug PR target/118541 on power9, power10, and power11 systems, for the
> function:
>
> extern double __ieee754_acos (double);
>
> double
> __acospi (double x)
> {
> double ret =
Hi!
As mentioned by Linus, we can't optimize comparison of otherwise unused
result of plus with CONST_INT second operand, compared against zero.
This can be done using just cmp instruction with negated constant and say
js/jns/je/jne etc. conditional jumps (or setcc).
We already have *cmp_minus_1 i
This patch would like to introduce the combine of vec_dup + vand.vv into
vand.vx on the cost value of GR2VR. The late-combine will take place if
the cost of GR2VR is zero, or reject the combine if non-zero like 1, 15
in test. There will be two cases for the combine:
OK, thanks.
--
Regards
Rob
s/cosntructing/constructing/
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
On Wed, May 21, 2025 at 09:21:40AM +0200, Jakub Jelinek wrote:
> On Wed, May 21, 2025 at 10:13:27AM +0800, Yang Yujie wrote:
> > On Tue, May 20, 2025 at 03:44:09PM GMT, Jakub Jelinek wrote:
> > > I'd suggest working on it incrementally rather than with a full patch set.
> > > In one or multiple pat
Alexandre Oliva writes:
> VxWorks uses x18 as the TCB, so STATIC_CHAIN_REGNUM has long been set
> (in gcc/config/aarch64/aarch64-vxworks.h) to use x9 instead.
>
> This patch marks x18 as fixed on TARGET_VXWORKS, so that it is not
> chosen by the register allocator, and adjusts tests that depend on
Christophe Lyon writes:
> Many tests became unsupported on aarch64 when -mcpu=unset was added to
> several arm_* effective targets, because this flag is only supported
> on arm.
>
> Since these effective targets are used on arm and aarch64, the patch
> adds -mcpu=unset on arm only, and restores ""
On Wed, May 21, 2025 at 02:17:58AM +0200, Alejandro Colomar wrote:
> Hi!
>
> Here's another revision of this patch set.
>
> v23 changes:
>
> - More specific change logs.
> - #define assert() instead of #include'ing .
>
> `make check` says all's good. I haven't diffed against master this
> ti
Pengxuan Zheng writes:
> There was a bug in aarch64_evpc_reencode which could leave zero_op0_p and
> zero_op1_p of the struct "newd" uninitialized. r16-701-gd77c3bc1c35e303 fixed
> the issue by zero initializing "newd." This patch provides an alternative fix
> as suggested by Richard Sandiford b
Hi Yuao,
first comments, I still need to look again at some changes, especially
at simplify.cc.
Yuao Ma wrote:
This patch introduces constant input support for trigonometric functions,
including those involving half-revolutions. Both valid and invalid
inputs have
been thoroughly tested, as
On May 20, 2025, Alexandre Oliva wrote:
> * memcpy-6.c: Bump to -msse2.
I'd missed gcc.dg/ in the ChangeLog, and the checker was adamant that I
ought to fix it ;-)
--
Alexandre Oliva, happy hackerhttps://blog.lx.oliva.nom.br/
Free Software Activist FSFLA co-founder GN
On May 20, 2025, Jonathan Wakely wrote:
> On Tue, 20 May 2025, 05:00 Alexandre Oliva, wrote:
> OK
Thanks
> Maybe we should just define it in terms of std::stod, so it always exists
> but might not support the full accuracy of long double.
That sounds desirable to me, FWIW, but from past exper
On May 20, 2025, Alexandre Oliva wrote:
> (This patch, as posted, applies on top of this:
> https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683066.html
> plus the missing bit in the followup I've just posted)
Since the ppc bits are not approved (yet?), I've rebased the x86 bits
approved by Ur
Hi Tobias,
Thanks for the thorough code review! I'm pretty swamped for the next couple of
days, and I'll get the patch updated as you requested this weekend.
> I don't understand this change. First, I don't see any reason why this
> should get modified. And by modifying it, a simple "git blame" w
On May 20, 2025, Richard Sandiford wrote:
> Alexandre Oliva writes:
>> -** bl __clear_cache
>> +** bl .*ache.*
> .* matches newlines, so how about:
> bl [^\n]*[cC]ache[^\n]*
> instead? OK if that works.
Sure, thanks! Here's what I've installed:
[testsuite] [aarch64
On Wed, May 21, 2025 at 11:48:08AM +0200, Jakub Jelinek wrote:
> With the following patch instead the test finally FAILs on s390x with -O1
> and higher, which shows that left shifts really need special casing for
> info->extended.
> I don't have proof of anything else though.
Note, the shifts are
Merge simple_comparison patterns under a single vec_cond_expr for bit_and,
bit_ior, and bit_xor in the simplify pass.
Ensure that when both operands of a bit_and, bit_or, or bit_xor are
simple_comparison
results, they reside within the same vec_cond_expr rather than separate ones.
This prepares t
New in V3:
Added XOR comparison optimization with the appropriate tests.
Any further optimizations involving scalars are left for a
future, separate patch, as these may be considered outside
the scope of Bug 119196, whose focus was on missed folding
of vector comparisons.
-
Hi,
Yuao Ma wrote:
I'm pretty swamped for the next couple of days
Same issue here - hence, I haven't completed the review ...
You're absolutely right that the best way to keep changes minimal is to just
rename the `*resolve*` function.
I missed the
-gfc_resolve_trigd,
+gfc_resolve_trig,
c
Generalize existing scalar gimple_fold rules to apply the same
bitwise comparison simplifications to vector types. Previously, an
expression like
(x < y) && (x > y)
would fold to `false` if x and y are scalars, but equivalent vector
comparisons were left untouched. T
Jeff Law writes:
> Given you know the RTL gen* related thingies better than anyone, I'd say
> go forward and if there's any fallout, we can certainly cope with it.
Thanks. I've now pushed the series and the earlier genemit tweaks,
with the discussed change to mark the operandN arguments as cons
On Wed, May 21, 2025 at 11:48:34AM +0200, Uros Bizjak wrote:
> Please introduce "x86_64_neg_const_int_operand" predicate that will
> allow only const_int operands, and will reject negative endbr (and
> wide DImode) const_ints. You don't need a constraint if the predicate
> allows only const_ints (t
On 21/05/2025 12:26, Christopher Bazley wrote:
Hi Joseph,
Thanks for reviewing my patch.
On 20/05/2025 18:02, Joseph Myers wrote:
On Tue, 20 May 2025, Christopher Bazley wrote:
+ if (!cleared)
+ {
+ if (complete_p.padded_non_union
+ && warn_zero_init_padding_bits >= ZER
On Wed, 21 May 2025, Alejandro Colomar wrote:
> @@ -10572,6 +10583,8 @@ c_parser_unary_expression (c_parser *parser)
> case CPP_KEYWORD:
>switch (c_parser_peek_token (parser)->keyword)
> {
> + case RID_COUNTOF:
> + return c_parser_countof_expression (parser);
> c
Hi,
this patch initializes saved_vxrm_mode to VXRM_MODE_NONE. This is a
warning (but no error) when building the compiler so better fix it.
Regtested on rv64gcv_zvl512b. Going to commit as obvious if the CI
is happy.
Regards
Robin
gcc/ChangeLog:
* config/riscv/riscv.cc (singleton_vx
Hi,
This patch adds a --param=autovec-mode=. When the param is
specified we make autovectorize_vector_modes return exactly this mode if
it is available. This helps when testing different vectorizer settings.
Regtested on rv64gcv_zvl512b.
Regards
Robin
gcc/ChangeLog:
* config/riscv/r
Commit 0547dbb725b reduced the number of cases in which
union padding bits are zeroed when the relevant language
standard does not strictly require it, unless gcc was
invoked with -fzero-init-padding-bits=unions or
-fzero-init-padding-bits=all in order to explicitly
request zeroing of padding bits.
Hi Joseph,
On Wed, May 21, 2025 at 04:26:46PM +, Joseph Myers wrote:
> On Wed, 21 May 2025, Alejandro Colomar wrote:
>
> > @@ -10572,6 +10583,8 @@ c_parser_unary_expression (c_parser *parser)
> > case CPP_KEYWORD:
> >switch (c_parser_peek_token (parser)->keyword)
> > {
> > +
Sending again because my previous reply got a weird 'Got' word as its
header that might be making it looks like a mistake.
On 14/05/2025 18:46, Jonathan Wakely wrote:
On Wed, 14 May 2025 at 17:31, François Dumont wrote:
On 12/05/2025 23:03, Jonathan Wakely wrote:
On 31/03/25 22:20 +0200, Fra
On Wed, 21 May 2025, Jonathan Wakely wrote:
> Because this constructor delegates to vector(a) the object has been
> fully constructed and the destructor will run if an exception happens.
> That means we need to set _M_finish == _M_start so that the destructor
> doesn't try to destroy any elements.
On 5/20/25 11:28 AM, Patrick Palka wrote:
On Mon, 19 May 2025, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/15/14?
Whoops, CI reports I missed a testsuite adjustment expecting an
additional error in other/default13.C, which seems reasonab
Commit 0547dbb725b reduced the number of cases in which
union padding bits are zeroed when the relevant language
standard does not strictly require it, unless gcc was
invoked with -fzero-init-padding-bits=unions or
-fzero-init-padding-bits=all in order to explicitly
request
Commit 0547dbb725b reduced the number of cases in which
union padding bits are zeroed when the relevant language
standard does not strictly require it, unless gcc was
invoked with -fzero-init-padding-bits=unions or
-fzero-init-padding-bits=all in order to explicitly
request zeroing of padding bits.
On Wed, May 21, 2025 at 10:19 PM Robin Dapp wrote:
>
> > I could imagine that is a simpler way to set the march since the march
> > string becomes terribly long - we have an arch string more than 300
> > char...so I support this, although I think this should be discuss with
> > LLVM community, but
So a followup to last week's bugfix. In last week's change we we
stopped using define_insn_and_split to rewrite instructions. That
change was done to avoid dropping a masking instruction out of the RTL.
As a result the pattern(s) were changed into simple define_insns, which
is good. One of
libstdc++-v3/ChangeLog:
* testsuite/std/format/parse_ctx.cc: Fix typo for bfloat16 guard.
---
Ok for mainline?
libstdc++-v3/testsuite/std/format/parse_ctx.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/std/format/parse_ctx.cc
b/libstdc++-v
On Wed, 21 May 2025, Alejandro Colomar wrote:
> Makes sense. I'm unsure where exactly I should put it. Is this okay?
>
> diff --git i/gcc/c/c-parser.cc w/gcc/c/c-parser.cc
> index 87700339394b..08350a216dd8 100644
> --- i/gcc/c/c-parser.cc
> +++ w/gcc/c/c-parser.cc
>
Hi Joseph,
Thanks for reviewing my patch.
On 20/05/2025 18:02, Joseph Myers wrote:
On Tue, 20 May 2025, Christopher Bazley wrote:
+ if (!cleared)
+ {
+ if (complete_p.padded_non_union
+ && warn_zero_init_padding_bits >= ZERO_INIT_PADDING_BITS_ALL)
+
On Wed, May 21, 2025 at 01:42:01PM +0100, Christopher Bazley wrote:
> On 21/05/2025 12:26, Christopher Bazley wrote:
> > Hi Joseph,
> >
> > Thanks for reviewing my patch.
> >
> > On 20/05/2025 18:02, Joseph Myers wrote:
> > > On Tue, 20 May 2025, Christopher Bazley wrote:
> > >
> > > > + if (
It's missing the "registration" of the three new classes in
std.cc.in.
On 5/21/25 11:40, Luc Grosheintz wrote:
Follows up on:
https://gcc.gnu.org/pipermail/libstdc++/2025-May/061535.html
To improve naming conventions, this series includes three new commits:
* Two commits to rename _ExtentsS
On 5/21/25 5:06 AM, Richard Sandiford wrote:
Jeff Law writes:
Given you know the RTL gen* related thingies better than anyone, I'd say
go forward and if there's any fallout, we can certainly cope with it.
Thanks. I've now pushed the series and the earlier genemit tweaks,
with the discusse
Could you make a simple testcase that could vectorize two loops in
different modes (e.g one SI and one SF) and with this param will only
auto vec on loop?
On Wed, May 21, 2025 at 9:47 PM Robin Dapp wrote:
>
> Hi,
>
> This patch adds a --param=autovec-mode=. When the param is
> specified we make
I could imagine that is a simpler way to set the march since the march
string becomes terribly long - we have an arch string more than 300
char...so I support this, although I think this should be discuss with
LLVM community, but I think it's fine to accept as a GCC extension.
So LGTM, go ahead t
On Wed, 21 May 2025, Christopher Bazley wrote:
> Would you agree this is adequate? If anyone wants different source code
> locations to be highlighted then a future commit could change that.
In this case the locations seem reasonable.
--
Joseph S. Myers
josmy...@redhat.com
Dear Richard,
Thank you so much for your reply. I submitted the patch for the third case to
LLVM before I've received your reply, and they said the same thing,
that it would probably be used outside of loops as well and it would inflict
a branch misprediction, so it should be implemented at the le
On Wed, May 21, 2025 at 1:20 PM Jakub Jelinek wrote:
>
> On Wed, May 21, 2025 at 11:48:34AM +0200, Uros Bizjak wrote:
> > Please introduce "x86_64_neg_const_int_operand" predicate that will
> > allow only const_int operands, and will reject negative endbr (and
> > wide DImode) const_ints. You don'
Hi Jakub,
Thanks for your review.
On 21/05/2025 13:51, Jakub Jelinek wrote:
On Wed, May 21, 2025 at 01:42:01PM +0100, Christopher Bazley wrote:
On 21/05/2025 12:26, Christopher Bazley wrote:
Hi Joseph,
Thanks for reviewing my patch.
On 20/05/2025 18:02, Joseph Myers wrote:
On Tue, 20 May 2
Hi,
This patch allows an -march string like
-march=sifive-p670
in order to allow overriding a previous -march in a simple way.
Suppose we have a Makefile that specifies -march=rv64gc by default.
A user-specified -mcpu=sifive-p670 would be after the -march in the
options string and thus only s
Could you make a simple testcase that could vectorize two loops in
different modes (e.g one SI and one SF) and with this param will only
auto vec on loop?
I added a test now in the attached v2 that checks that we vectorize with the
requested mode. Right now the patch only takes away "additiona
Patch is originally from Siarhei Volkau .
RISC-V has a zero register (x0) which we can use to store zero into memory
without loading the constant into a distinct register. Adjust the
constraints
of the 32-bit movdi_32bit pattern to recognize that we can store 0.0 into
memory using x0 as the source
LGTM
On Wed, May 21, 2025 at 9:49 PM Robin Dapp wrote:
>
> Hi,
>
> this patch initializes saved_vxrm_mode to VXRM_MODE_NONE. This is a
> warning (but no error) when building the compiler so better fix it.
>
> Regtested on rv64gcv_zvl512b. Going to commit as obvious if the CI
> is happy.
>
> Reg
I could imagine that is a simpler way to set the march since the march
string becomes terribly long - we have an arch string more than 300
char...so I support this, although I think this should be discuss with
LLVM community, but I think it's fine to accept as a GCC extension.
So LGTM, go ahead to
Commit 0547dbb725b reduced the number of cases in which
union padding bits are zeroed when the relevant language
standard does not strictly require it, unless gcc was
invoked with -fzero-init-padding-bits=unions or
-fzero-init-padding-bits=all in order to explicitly
request
Because this constructor delegates to vector(a) the object has been
fully constructed and the destructor will run if an exception happens.
That means we need to set _M_finish == _M_start so that the destructor
doesn't try to destroy any elements.
libstdc++-v3/ChangeLog:
PR libstdc++/12036
On 5/20/25 8:39 PM, Li, Pan2 wrote:
Thanks Jeff.
So for the tests, why are we forcing matching of the assembly code for
the entire function? That must makes for a fragile test as we may
change various aspects of code generation over time.
If the point of the patch is to detect SAT_ADD in
On 5/20/25 4:05 PM, Edwin Lu wrote:
The instruction scheduler appears to be speculatively hoisting vsetvl
insns outside of their basic block without checking for data
dependencies. This resulted in a situation where the following occurs
vsetvli a5,a1,e32,m1,tu,ma
vle32.v v2,
On 5/20/25 4:05 PM, Edwin Lu wrote:
The instruction scheduler appears to be speculatively hoisting vsetvl
insns outside of their basic block without checking for data
dependencies. This resulted in a situation where the following occurs
vsetvli a5,a1,e32,m1,tu,ma
vle32.v v2,
On 4/14/25 5:34 AM, Yangyu Chen wrote:
On 14 Apr 2025, at 19:06, Alfie Richards wrote:
Hi Yangyu,
This looks great with what we discussed previously.
I have a very similar patch that implements a slightly stronger optimisation
that I was about to send. It makes use of information if th
I have posted a new version of the patch at:
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684473.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
On 20/05/25 16:35, Richard Sandiford wrote:
External email: Use caution opening links or attachments
Dhruv Chawla writes:
On 06/05/25 21:57, Richard Sandiford wrote:
External email: Use caution opening links or attachments
Dhruv Chawla writes:
This patch modifies the intrinsic expanders
From: Dhruv Chawla
This patch modifies the shift expander to immediately lower constant
shifts without unspec. It also modifies the ADR, SRA and ADDHNB patterns
to match the lowered forms of the shifts, as the predicate register is
not required for these instructions.
Bootstrapped and regtested
Thanks. I will pay attention to this.
Dongyan Chen
在 2025/5/22 11:49, Jeff Law 写道:
On 5/21/25 9:16 PM, Dongyan Chen wrote:
Failed testcases occurred in the regression test of gcc:
cset-sext-sfb.c failed
the -Oz test, and zba-slliuw.c failed the -Og test.
This patch solves the problem by ski
From: Dhruv Chawla
This patch folds the following pattern:
lsl , ,
lsr , ,
orr , ,
to:
revb/h/w ,
when the shift amount is equal to half the bitwidth of the
register.
Bootstrapped and regtested on aarch64-linux-gnu.
Signed-off-by: Dhruv Chawla
Co-authored-by: Richard Sandiford
Fix PR 118541, do not generate unordered fp cmoves for IEEE compares.
This is version 3 of patch. I re-implemented the patch to just focus on the
generation of the XSCMP{EQ,GT,GE}{DP,QP} instructions.
In bug PR target/118541 on power9, power10, and power11 systems, for the
function:
ext
I got the version number of the patch wrong. This patch is something like V6
of the patch, not V3.
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Patch is originally from Siarhei Volkau .
RISC-V has a zero register (x0) which we can use to store zero into memory
without loading the constant into a distinct register. Adjust the
constraints
of the 32-bit movdi_32bit pattern to recognize that we can store 0.0 into
memory using x0 as the source
On 5/21/25 9:16 PM, Dongyan Chen wrote:
Failed testcases occurred in the regression test of gcc: cset-sext-sfb.c failed
the -Oz test, and zba-slliuw.c failed the -Og test.
This patch solves the problem by skipping the optimization.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/cset-sex
On Wed, May 21, 2025 at 10:20 AM Luc Grosheintz
wrote:
>
>
> On 5/21/25 08:29, Tomasz Kaminski wrote:
> > On Tue, May 20, 2025 at 3:16 PM Luc Grosheintz >
> > wrote:
> >
> >> Implements the parts of layout_left that don't depend on any of the
> >> other layouts.
> >>
> >> libstdc++-v3/ChangeLog:
On Wed, May 21, 2025 at 5:41 PM Jonathan Wakely wrote:
> Because this constructor delegates to vector(a) the object has been
> fully constructed and the destructor will run if an exception happens.
> That means we need to set _M_finish == _M_start so that the destructor
> doesn't try to destroy a
Add support of double trap extension [1], enabling GCC
to recognize the following extensions at compile time.
New extensions:
- ssdbltrp
- smdbltrp
[1]
https://github.com/riscv/riscv-double-trap/releases/download/v1.0/riscv-double-trap.pdf
gcc/ChangeLog:
* config/riscv/riscv-ext.def
Hi Jakub,
On Wed, May 21, 2025 at 11:12:07PM +0200, Jakub Jelinek wrote:
> > warning_at (loc, OPT_Wc___compat,
> > "defining type in %qs expression is invalid in C++",
> > (in_sizeof
> > ? "sizeof"
> > -: (in_typeof ? "typeof" : "alignof")));
>
1 - 100 of 145 matches
Mail list logo
