Hi!
When adding _BitInt support I was hoping all or most of arches would
implement it already for GCC 14. That didn't happen and with
new hosts adding support for _BitInt for GCC 16 (s390x-linux and as was
posted today loongarch-linux too), we need the _BitInt support functions
exported on those
Hi Richard, thanks for your response.
On Tue, May 20, 2025 at 8:05 AM Richard Biener
wrote:
>
> On Mon, May 19, 2025 at 4:14 PM Konstantinos Eleftheriou
> wrote:
> >
> > This patch adds the `bitmap_is_range_set_p` function in sbitmap,
> > which checks if all the bits in a range are set. This fun
On Mon, 19 May 2025, Jakub Jelinek wrote:
Hi!
On s390x-linux I've run into the gcc.dg/torture/bitint-27.c test ICEing in
build_nonstandard_integer_type called from convert_affine_scev (not sure
why it doesn't trigger on x86_64/aarch64).
The problem is clear, when ct is a BITINT_TYPE with some l
LGTM for the whole series.
Thanks,
Uros.
On Tue, May 20, 2025 at 6:17 AM Alexandre Oliva wrote:
>
>
> Some tsvc tests add vect_early_break options without requiring the
> feature to be available. Add the requirements.
>
> Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
>
On Mon, 19 May 2025, Tamar Christina wrote:
-Original Message-
From: Richard Biener
Sent: Friday, May 16, 2025 11:35 AM
To: gcc-patches@gcc.gnu.org
Cc: Richard Sandiford ; Tamar Christina
Subject: [PATCH][RFC] Allow the target to request a masked vector epilogue
Targets recently got t
The 8-byte memory operations will only be inlined on ia32 with
-msse2. Bump it.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
arm-, x86-, and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* memcpy-6.c: Bump to -msse2.
---
gcc/testsuite/gcc.
OK
On Tue, May 20, 2025 at 6:20 AM Alexandre Oliva wrote:
>
>
> Some tsvc tests add vect_early_break options without requiring the
> feature to be available. Add the requirements.
>
> Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
> arm-, x86-, and x86_64-vxworks7r2. Ok
On Mon, May 19, 2025 at 4:14 PM Konstantinos Eleftheriou
wrote:
>
> This patch adds the `bitmap_is_range_set_p` function in sbitmap,
> which checks if all the bits in a range are set. This function
> calls `bitmap_bit_in_range_p_1`, which has been updated to use
> the `any_inverted` parameter. Whe
Some tsvc tests add vect_early_break options without requiring the
feature to be available. Add the requirements.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
arm-, x86-, and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.dg/vect/tsvc/
The vector operations are only turned into BIT_INSERT_EXPR with -msse
on ia32.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
arm-, x86-, and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.dg/tree-ssa/forwprop-41.c: Add -msse on x86.
---
Since r13-6296, we haven't got 4 simdclone calls for these tests on
ia32 without avx_runtime. With avx_runtime, we get 3 such calls even
on ia32, but we didn't test for anything on ia32 with avx_runtime.
Adjust and simplify the expectations and comments.
Regstrapped on x86_64-linux-gnu. Also t
If the toolchain is built with --enable-frame-pointer,
gcc.target/i386/no-callee-saved-16.c will not get the expected
optimization without -fomit-frame-pointer, that would be enabled by
-O2 without the configure flag. Add it.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-
(The backport I've only just posted is not enough for the tests to pass;
there's another problem)
r14-10824 is a backport of r15-4549, that rewrote and extended into
check-function-bodies the save/restore expectations introduced in
r15-2160. Alas, r15-2160 mentions an insn_propagation patch tha
The backport of commit 205515da82a2914d765e74ba73fd2765e1254112 to
gcc-14 as 8b1146fe46e62f8b03bd9ddee48995794e192e82, rewriting
gcc.target/arm/fp16-aapcs-[1234].c into check-function-bodies, requires
the following patch for the one-character function names used in those
tests. Tested with gcc-14
On an --enable-frame-pointer toolchain, pr31985.c gets an extra movl
and fails. Enable -fomit-frame-pointer explicitly.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
arm-, x86-, and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/
Without SSE2, we don't combine the separate loads in foo2 and get
separate rotates, instead of a bswap.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
arm-, x86-, and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/i386/pr108938-3.c
The string length optimizations at 8-byte blocks requires -msse2;
-msse is not enough. Bump it.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
arm-, x86-, and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.dg/strlenopt-80.c: Bump to -mss
SSE_FLOAT_MODE_P only holds for DFmode with SSE2, and that's a
condition for copysign3 to be available under TARGET_SSE_MATH.
Various copysign testcases use -msse -mfpmath=sse on ia32 to enable
the copysign builtins and patterns, but that would only be enough if
the tests were limited to floats.
On May 8, 2025, Alexandre Oliva wrote:
> * gcc.dg/fold-copysign-1.c: Add -mcmpb on ppc.
Uhh, sorry, I've accidentally dropped this bit from the patch posted a
couple of weeks ago. Here it is.
BTW, Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683066.html
diff --git a/gcc/te
The test calls sysconf but it doesn't require it as it should.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
arm-, x86-, and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.dg/vect/vect-early-break_109-pr113588.c: Require sysconf.
---
..
vxworks calls cacheTextUpdate instead of __clear_cache.
Adjust the sme/nonlocal_goto_*.c tests for inexact matches.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
arm-, x86-, and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/aarc
stdint.h defines uint64_t instead of __uint64_t, so use the former.
__uint64_t is not available on e.g. vxworks.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
arm-, x86-, and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/aarch64/
basic_string.h doesn't define the non-w string version of std::stold
when certain conditions aren't met, and then a couple of tests fail to
compile.
Guard the portions of the tests that depend on std::stold with the
conditions for it to be defined.
Regstrapped on x86_64-linux-gnu. Also tested
The pr115485.C testcase uses -fPIE, so it needs to state a PIC
requirement.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
arm-, x86-, and x86_64-vxworks7r2. Ok to install?
for gcc/testsuite/ChangeLog
* g++.target/arm/pr115485.C: Require a pic effective targe
Various arm tests, specifically epilog-1.c and fp16-aapcs-*.c, need
-mno-long-calls to match the expected asm outputs on targets that
default to -mlong-calls. fp16-aapcs-2.c has that flag already.
Regstrapped on x86_64-linux-gnu. Also tested with gcc-14 on aarch64-,
arm-, x86-, and x86_64-vxwo
vxworks' libatomic comes from its libc, and it's missing
__atomic_feraiseexcept. ARM and AArch64 ports call it implicitly in
c11-atomic-exec-[23].c, so these tests fail.
No exceptions are expected to be raised by these tests, so I'm working
around and silencing the failures by defining the miss
On 5/19/25 11:11 PM, Nathaniel Shead wrote:
On Mon, May 19, 2025 at 04:56:38PM -0400, Jason Merrill wrote:
On 5/19/25 8:27 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively could go back to always marking vtables as DECL_EXTERNAL
as well
Hi,
This is a proposition of a _BitInt(N) implementation for LoongArch,
with the following psABI description:
```
=== Fundamental types of N-bit integers
`_BitInt(N)` (as proposed in ISO/IEC WG14 N2763) is a family of integer types
where `N` specifies the exact number of bits used for its repres
The padding bits of _BitInt(N) are undefined in the x86-64 and
the aarch64 ABI. In general, the current lowering and expand process
perform truncations when taking a _BitInt value as input,
while leaving them as-is in the output.
By adding truncation on the output side, we can define psABIs
(e.g.
gcc/ChangeLog:
* stor-layout.cc (layout_type): Allow limb_mode to be DImode
while abi_limb_mode is TImode for _BitInt(N), N > 64.
---
gcc/stor-layout.cc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/stor-layout.cc b/gcc/stor-layout.cc
index 18b5af56124.
This patch adds support for C23's _BitInt for LoongArch.
Though there's not an official psABI definition, our plan
is to have 16-byte alignment for N > 64 and the padding bits
sign/zero-extended when passed between procedures.
One exception would be "unsigned _BitInt(32)". To match the
behavior o
On 5/19/25 1:50 PM, Harald Anlauf wrote:
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it fixes only the case of direct use of iso_c_binding, but not the
indirect one thru the other module, which is the reason for the
original ICE and the PR.
So if you want to pu
On Mon, May 19, 2025 at 04:56:38PM -0400, Jason Merrill wrote:
> On 5/19/25 8:27 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > Alternatively could go back to always marking vtables as DECL_EXTERNAL
> > as well but that doesn't seem to be ne
在 2025-5-13 17:18, LIU Hao 写道:
Hello,
Attached is a patch for PR 53929, but is also required by PR 80881.
Ping.
Also I just notice that Clang also quotes mangled MSVC++ symbols in this way, at least since Clang 3.5,
so it's accepted by both GAS and LLVM:
(https://gcc.godbolt.org/z/9xjKb4YP6
On 4/15/25 6:31 AM, Alfie Richards wrote:
This change refactors FMV handling in the frontend to allows greater
reasoning about versions in shared code.
Looking at the cp/ changes:
diff --git a/gcc/cp/class.cc b/gcc/cp/class.cc
index c28d9e5b3ab..4f195ae06cd 100644
--- a/gcc/cp/class.cc
+++ b/
> The series LGTM. I didn't check all the tests in detail to be honest :)
Thanks Robin, the tests is similar and expected up to a point.
Pan
-Original Message-
From: Robin Dapp
Sent: Monday, May 19, 2025 7:06 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch
Thanks a lot for the review and comments.
I am on a short vacation this week. And will respond to all your questions
after I am back the end of this week.
Qing
> On May 19, 2025, at 06:44, Richard Biener wrote:
>
> On Fri, May 16, 2025 at 3:34 PM Qing Zhao wrote:
>>
>> Control this with a ne
I goof'd when doing analysis of missed bext cases. For the shift into
the sign bit, then shift into the low bit case (thankfully the least
common), I got it in my brain that the field is at the left shift count.
It's actually at word_size - 1 - left shift count.
One the subtraction is inclu
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/15/14?
-- >8 --
Here we declare f twice, first ordinarily and then using a dependent
alias template. Due to alias template transparency these logically
declare the same overload. But now the function type of f, which
Add constructors to stringbuf, stringstream, istringstream,
and ostringstream, and a matching overload of str(sv) in each,
that take anything convertible to a string_view where the
existing functions take a string.
libstdc++-v3/ChangeLog:
P2495R3 stringstream to init from string_view-ish
Add constructors to stringbuf, stringstream, istringstream,
and ostringstream, and a matching overload of str(sv) in each,
that take anything convertible to a string_view where the
existing functions take a string.
libstdc++-v3/ChangeLog:
P2495R3 stringstream to init from string_view-ish
On 5/17/25 10:38 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
OK.
-- >8 --
When we import a pending instantiation that matches an existing partial
specialisation, we don't find the slot in the entity map because for
partial specialisations we
On 5/19/25 8:27 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively could go back to always marking vtables as DECL_EXTERNAL
as well but that doesn't seem to be necessary that I can tell.
DECL_NOT_REALLY_EXTERN doesn't make sense without DE
Hi Jerry,
so contrary to what the name of patch claims (pr120049-final.diff),
it fixes only the case of direct use of iso_c_binding, but not the
indirect one thru the other module, which is the reason for the
original ICE and the PR.
So if you want to push the incremental patch now, go ahead.
C
We've got 'gcc/stor-layout.cc:finalize_type_size':
/* Handle empty records as per the x86-64 psABI. */
TYPE_EMPTY_P (type) = targetm.calls.empty_record_p (type);
(Indeed x86_64 is still the only target to define 'TARGET_EMPTY_RECORD_P',
calling 'gcc/tree.cc-default_is_empty_record'.)
An
On Fri, May 16, 2025 at 01:34:14PM +, Qing Zhao wrote:
> Adding -fdiagnotics-details into GCC to provide more hints to the
> end users on how the warnings come from, in order to help the user
> to locate the exact location in source code on the specific warnings
> due to compiler optimizations.
libgomp/
* testsuite/libgomp.c-c++-common/target-abi-struct-1-O0.c: New.
* testsuite/libgomp.oacc-c-c++-common/abi-struct-1.c: Likewise.
---
.../target-abi-struct-1-O0.c | 3 +
.../libgomp.oacc-c-c++-common/abi-struct-1.c | 96 +++
2 files
From: Julian Brown
libgomp/
* testsuite/libgomp.oacc-fortran/lib-13.f90: End data region after
wait API calls.
---
libgomp/testsuite/libgomp.oacc-fortran/lib-13.f90 | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libgomp/testsuite/libgomp.oacc-fortra
On 5/18/25 8:53 AM, Mark Wielaard wrote:
Should output here be initialized to NULL_RTX?
Yea, plus an assert to verify it's sensible after the two blobs of code
that emit the [x]ori + bclr/binv sequences. I've pushed a fix to the trunk.
jeff
As Mark and I independently tripped, there's a Wuninitialized issue in
the RISC-V backend. While *I* know the value would always be properly
initialized, it'd be somewhat painful to either eliminate the infeasible
paths or do deep enough analysis to suppress the false positive.
So this initia
Hi!
On s390x-linux I've run into the gcc.dg/torture/bitint-27.c test ICEing in
build_nonstandard_integer_type called from convert_affine_scev (not sure
why it doesn't trigger on x86_64/aarch64).
The problem is clear, when ct is a BITINT_TYPE with some large
TYPE_PRECISION, build_nonstandard_intege
Hi!
The big-endian _BitInt support in libgcc was written without any
testing and so I haven't discovered I've made one mistake in it
(in multiple places).
The bitint_reduce_prec function attempts to optimize inputs
which have some larger precision but at runtime they are found
to need smaller numb
Some fields (e.g., zero_op0_p and zero_op1_p) of the struct "newd" may be left
uninitialized in aarch64_evpc_reencode. This can cause reading of uninitialized
data. I found this oversight when testing my patches on and/fmov
optimizations. This patch fixes the bug by zero initializing the struct.
P
Pushed as r16-734-gbf98b735ae01c6 after an off-list OK by Jerry,
and no other responses to the opposite.
Harald
On 5/18/25 22:53, Harald Anlauf wrote:
Dear all,
the attached proposed patch fixes PR120099 by modifying
gfc_return_by_reference so that it returns true with -ff2c
also for intrinsic
Kugan Vivekanandarajah writes:
> diff --git a/Makefile.in b/Makefile.in
> index b1ed67d3d4f..b5e3e520791 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -4271,7 +4271,7 @@ all-stageautoprofile-bfd: configure-stageautoprofile-bfd
> $(HOST_EXPORTS) \
> $(POSTSTAGE1_HOST_EXPORTS) \
>
It's not enough to just check that a memory operand is of the form
mem(reg); after RA we also need to validate the register being used.
The safest way to do this is to call memory_operand.
PR target/120351
gcc/ChangeLog:
* config/arm/predicates.md (mem_noofs_operand): Also check
On Mon, 19 May 2025, Tomasz Kaminski wrote:
>
>
> On Mon, May 19, 2025 at 9:59 AM Tomasz Kaminski wrote:
>
>
> On Mon, May 19, 2025 at 6:47 AM Patrick Palka wrote:
> I would appreciate a short explanation on the approach being put here,
> in the message. Like passing -1 as means of saying,
On 5/19/25 11:54 AM, Jason Merrill wrote:
On 5/16/25 10:11 AM, Iain Sandoe wrote:
Hi Jason,
+ returned reference or prvalue result object ...
+ When we use a local to hold this, it is decltype(auto). */
+ tree gro_type
+ = finish_decltype_type (get_ro, /
*id_expression_or_member_
On 5/19/25 9:37 AM, Nathaniel Shead wrote:
Regtested on x86_64-pc-linux-gnu (so far just modules.exp), OK for
trunk if full bootstrap+regtest succeeds? And maybe 15?
OK for both.
-- >8 --
We need to mark type info decls as addressable if we take them by
reference; this is done by walking th
On 5/16/25 10:04 AM, Iain Sandoe wrote:
+ /* We must manage the cleanups ourselves, because the responsibility for
+ them changes after the initial suspend. However, any use of
+ cxx_maybe_build_cleanup () can set the throwing_cleanup flag. */
+ cp_function_chain->throwing_cleanup = f
On Mon, 19 May 2025, Patrick Palka wrote:
> Changes in v3:
> * Use the forward_range code path for a (non-sized) bidirectional
> haystack, since it's slightly fewer increments/decrements
> overall.
> * Fix wrong iter_difference_t cast in starts_with.
>
> Changes in v2:
> Addressed T
On 5/16/25 10:11 AM, Iain Sandoe wrote:
Hi Jason,
+ returned reference or prvalue result object ...
+ When we use a local to hold this, it is decltype(auto). */
+ tree gro_type
+= finish_decltype_type (get_ro, /*id_expression_or_member_access_p*/true,
This should be false, not
On Mon, 19 May 2025, Tomasz Kaminski wrote:
>
>
> On Mon, May 19, 2025 at 4:11 PM Patrick Palka wrote:
> Changes in v2:
> Addressed Tomasz's review comments, namely:
> * Added explicit iter_difference_t casts
> * Made _S_impl member private
> * Optimized si
Changes in v3:
* Use the forward_range code path for a (non-sized) bidirectional
haystack, since it's slightly fewer increments/decrements
overall.
* Fix wrong iter_difference_t cast in starts_with.
Changes in v2:
Addressed Tomasz's review comments, namely:
* Added explicit iter_di
On Fri, May 16, 2025 at 3:34 PM Qing Zhao wrote:
>
> Control this with a new option -fdiagnostics-details.
>
> $ cat t.c
> extern void warn(void);
> static inline void assign(int val, int *regs, int *index)
> {
> if (*index >= 4)
> warn();
> *regs = val;
> }
> struct nums {int vals[4];};
>
On Wed, May 7, 2025 at 11:29 AM Richard Sandiford
wrote:
>
> Konstantinos Eleftheriou writes:
> > Hi Richard,
> >
> > Thanks for the feedback! We have sent a new version that uses
> > lowpart_subreg
> > (https://gcc.gnu.org/pipermail/gcc-patches/2025-May/682835.html).
> > We had tried that befor
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677788.html .
Thanks,
Konstantinos
On Mon, May 19, 2025 at 4:11 PM Patrick Palka wrote:
> Changes in v2:
> Addressed Tomasz's review comments, namely:
> * Added explicit iter_difference_t casts
> * Made _S_impl member private
> * Optimized sized bidirectional case of ends_with
> * Rearranged control flow of starts_with::
On Mon, 19 May 2025 at 16:10, Konstantinos Eleftheriou
wrote:
>
> This patch adds the `bitmap_bit_in_range_p_1` helper function,
> in order to be used by `bitmap_bit_in_range_p`. The helper function
> contains the previous implementation of `bitmap_bit_in_range_p` and
> `bitmap_bit_in_range_p` has
On Mon, 19 May 2025, Patrick Palka wrote:
> Changes in v2:
> Addressed Tomasz's review comments, namely:
> * Added explicit iter_difference_t casts
> * Made _S_impl member private
> * Optimized sized bidirectional case of ends_with
> * Rearranged control flow of starts_with::_S_impl
>
>
On 5/16/25 10:15 AM, Iain Sandoe wrote:
Hi Jason,
+ = build1_loc (loc, TRUTH_NOT_EXPR, boolean_type_node, iarc_x);
+ do_fr_cleanup = build2_loc (loc, TRUTH_AND_EXPR, boolean_type_node,
+ do_fr_cleanup, coro_before_return);
This also needs reversing
Hi Richard, thanks again for the feedback.
We have sent an updated version, which removes the redundant store
operations (https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684096.html).
This one is a series as we needed to update sbitmap with a function
that checks if a range in the bitmap is set
On Mon, May 19, 2025 at 4:09 PM Tomasz Kaminski wrote:
>
>
> On Mon, May 19, 2025 at 4:02 PM Patrick Palka wrote:
>
>> On Mon, 19 May 2025, Tomasz Kaminski wrote:
>>
>> >
>> >
>> > On Mon, May 19, 2025 at 6:47 AM Patrick Palka
>> wrote:
>> > I would appreciate a short explanation on the approac
On Mon, May 19, 2025 at 4:05 PM Patrick Palka wrote:
> On Mon, 19 May 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Mon, May 19, 2025 at 9:59 AM Tomasz Kaminski
> wrote:
> >
> >
> > On Mon, May 19, 2025 at 6:47 AM Patrick Palka wrote:
> > I would appreciate a short explanation on the approach b
Regtested on x86_64-pc-linux-gnu (so far just modules.exp), OK for
trunk if full bootstrap+regtest succeeds? And maybe 15?
-- >8 --
We need to mark type info decls as addressable if we take them by
reference; this is done by walking the declaration during parsing and
marking the decl as needed.
This patch uses `lowpart_subreg` for the base register initialization,
instead of zero-extending it. We had tried this solution before, but
we were leaving undefined bytes in the upper part of the register.
This shouldn't be happening as we are supposed to write the whole
register when the load is
Changes in v2:
Addressed Tomasz's review comments, namely:
* Added explicit iter_difference_t casts
* Made _S_impl member private
* Optimized sized bidirectional case of ends_with
* Rearranged control flow of starts_with::_S_impl
Still left to do:
* Add tests for integer-class types
This patch adds the `bitmap_bit_in_range_p_1` helper function,
in order to be used by `bitmap_bit_in_range_p`. The helper function
contains the previous implementation of `bitmap_bit_in_range_p` and
`bitmap_bit_in_range_p` has been updated to call the helper function.
gcc/ChangeLog:
* sbi
During the base register initialization, when we are eliminating the load
instruction, we were calling `emit_move_insn` on registers of the same
size but of different mode in some cases, causing an ICE.
We update the base register initialization to use `lowpart_subreg`
instead of zero-extending th
This patch adds the `bitmap_is_range_set_p` function in sbitmap,
which checks if all the bits in a range are set. This function
calls `bitmap_bit_in_range_p_1`, which has been updated to use
the `any_inverted` parameter. When `any_inverted` is true, the helper
function checks if any of the bits in
On Mon, May 19, 2025 at 4:02 PM Patrick Palka wrote:
> On Mon, 19 May 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Mon, May 19, 2025 at 6:47 AM Patrick Palka wrote:
> > I would appreciate a short explanation on the approach being put here,
> > in the message. Like passing -1 as means of saying,
On Mon, 19 May 2025, Tomasz Kaminski wrote:
>
>
> On Mon, May 19, 2025 at 6:47 AM Patrick Palka wrote:
> I would appreciate a short explanation on the approach being put here,
> in the message. Like passing -1 as means of saying, size not know.
>
> Tested on x86_64-pc-linux-gnu, does th
On 5/19/25 3:16 AM, Richard Sandiford wrote:
Richard Sandiford writes:
Jeff Law writes:
So two questions. Is there any meanginful performance impact expected
here using the array form rather than locals? And does this impact how
folks write their C/C++ fragments in the expanders and suc
On Mon, May 19, 2025 at 9:59 AM Tomasz Kaminski wrote:
>
>
> On Mon, May 19, 2025 at 6:47 AM Patrick Palka wrote:
> I would appreciate a short explanation on the approach being put here,
> in the message. Like passing -1 as means of saying, size not know.
>
> Tested on x86_64-pc-linux-gnu, does
On 5/18/25 2:24 PM, Richard Sandiford wrote:
gcc/
* genemit.cc (gen_rtx_scratch, gen_exp): Use operands[%d] rather than
operand%d.
(start_gen_insn): Store the incoming arguments to an operands array.
(gen_expand, gen_split): Remove copies into and out of the o
The next two commits fix two mapping issues, the rest are test cases
that should have been in GCC 15 pre-branch. Namely:
r15-9707-g57f73c3956572f OpenMP/Fortran: Fix allocatable-component
mapping of derived-type array comps r15-9706-gab9ca3a8b1af41 OpenMP:
Fix mapping of zero-sized arrays w
On 5/18/25 2:19 PM, Richard Sandiford wrote:
Jeff Law writes:
On 5/16/25 11:32 AM, Jeff Law wrote:
On 5/16/25 11:21 AM, Richard Sandiford wrote:
This pattern used operands[2] to hold the shift amount, even though
the pattern doesn't have an operand 2 (not even as a match_dup).
This cause
Thank you for the patches.
I have reviewed the layout_left and test, and posted some suggestions there.
I will follow up with a review for other mapping later.
On Sun, May 18, 2025 at 10:07 PM Luc Grosheintz
wrote:
> Technically, this is the second iteration of these patches. Previous
> discussi
On Sun, May 18, 2025 at 10:14 PM Luc Grosheintz
wrote:
> 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_co
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively could go back to always marking vtables as DECL_EXTERNAL
as well but that doesn't seem to be necessary that I can tell.
-- >8 --
I missed a testcase in r16-688-gc875748cdc468e for whether a GM vtable
should be emitted
From: xuli
This patch would like to support .SAT_ADD when IMM=-1.
Form1:
T __attribute__((noinline)) \
sat_s_add_imm_##T##_fmt_1##_##INDEX (T x) \
{\
T sum = (UT)x + (UT)IMM; \
return (x ^ IMM) < 0
> > +-param=vect-scalar-cost-multiplier=
> > +Common Joined UInteger Var(param_vect_scalar_cost_multiplier) Init(1)
> IntegerRange(0, 10) Param Optimization
> > +The scaling multiplier to add to all scalar loop costing when performing
> vectorization profitability analysis. The default value i
On Sun, May 18, 2025 at 10:11 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
> ---
> libstdc++-v3/include/std
Hi Thomas,
coming back to the patch itself – having sent comments in previous email.
As mentioned, I think you either want to have:
* Check whether the runtime knows that USM is supported for the default
device (that is a non-host device), i.e. a no-host device is available
with 'required uni
> >/* Complete the target-specific cost calculations. */
> >loop_vinfo->vector_costs->finish_cost (loop_vinfo->scalar_costs);
> >vec_prologue_cost = loop_vinfo->vector_costs->prologue_cost ();
> > @@ -12373,6 +12394,13 @@ vect_transform_loop (loop_vec_info loop_vinfo,
> gimple *loop_ve
The series LGTM. I didn't check all the tests in detail to be honest :)
--
Regards
Robin
On Mon, 19 May 2025 at 10:35, Tomasz Kaminski wrote:
>
>
>
> On Mon, May 19, 2025 at 11:29 AM Jonathan Wakely wrote:
>>
>> On Mon, 19 May 2025 at 05:46, Patrick Palka wrote:
>> >
>> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>> >
>> > -- >8 --
>> >
>> > libstdc++-v3/ChangeLog:
On Linux/x86_64,
b6d37ec1dd2a228d94e7b5b438f3aa53684316bc is the first bad commit
commit b6d37ec1dd2a228d94e7b5b438f3aa53684316bc
Author: Florian Weimer
Date: Thu May 1 19:06:45 2025 +0200
c: Suppress -Wdeprecated-non-prototype warnings for builtins
caused
FAIL: gcc.c-torture/compile/cal
> On 16 May 2025, at 12:10 am, Andi Kleen wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Wed, May 14, 2025 at 02:46:15AM +, Kugan Vivekanandarajah wrote:
>> Adding Eugene and Andi to CC as Sam suggested.
>>
>>> On 13 May 2025, at 12:57 am, Richard Sandiford
>>
Richard Sandiford writes:
> Jeff Law writes:
>> So two questions. Is there any meanginful performance impact expected
>> here using the array form rather than locals? And does this impact how
>> folks write their C/C++ fragments in the expanders and such?
>
> I don't think there should be an
1 - 100 of 119 matches
Mail list logo
