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
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.
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/
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
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.
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
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
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/
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 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 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.
---
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
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 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
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, 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
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
>>Every type listed in that attribute must have a mapping to a function unit in
>>your scheduler model
Thank you Jeff and added the dummies reservation for the leftout attributes and
tested with dejagnu riscv.exp.
Thank you again for reference
~U
---
gcc/config/riscv/mips-p8700.md | 28
1 file changed, 28 insertions(+)
diff --git a/gcc/config/riscv/mips-p8700.md b/gcc/config/riscv/mips-p8700.md
index 11d0b1ca793..ae0ea8dc896 100644
--- a/gcc/config/riscv/mips-p8700.md
+++ b/gcc/config/riscv/mips-p8700.md
@@ -3
During the GCC compilation, some warnings about temporary object dangling
references emerged. They appeared in these code lines in riscv-common.cc:
const riscv_ext_info_t &implied_ext_info, const riscv_ext_info_t &ext_info =
get_riscv_ext_info (ext) and auto &ext_info = get_riscv_ext_info (search
---
gcc/config/riscv/mips-p8700.md | 139 +++
gcc/config/riscv/riscv-cores.def | 5 ++
gcc/config/riscv/riscv-opts.h| 3 +-
gcc/config/riscv/riscv.cc| 22 +
gcc/config/riscv/riscv.md| 3 +-
5 files changed, 170 insertions(+), 2 deletions
I fix the code by changing the argument type of get_riscv_ext_info to
`const char *` and the link is:
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684057.html
在 2025/5/16 10:35, Kito Cheng 写道:
Hm, it really doesn't make too much sense to get that warning, but
I can reproduce that whe
---
gcc/cobol/lexio.cc | 2 +-
gcc/cobol/parse.y | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/cobol/lexio.cc b/gcc/cobol/lexio.cc
index 2db1af273e9..4f68bf65887 100644
--- a/gcc/cobol/lexio.cc
+++ b/gcc/cobol/lexio.cc
@@ -1455,7 +1455,7 @@ cdftext::lex_open( const
Hello,
On Thu, May 15 2025, Jan Hubicka wrote:
>> Hi,
>>
>> starting with GCC 15 the order is not unique for any symtab_nodes but
>> m_uid is, I believe we ought to dump the latter in the ipa-clones dump,
>> if only so that people can reliably match entries about new clones to
>> those about remo
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 this look OK for trunk?
>
>From the non-stylistic changes, I have noti
On Fri, May 16, 2025 at 7:35 PM Jonathan Wakely wrote:
> libstdc++-v3/ChangeLog:
>
> * include/std/ranges (_ZipTransform::operator()): Remove name of
> unused parameter.
> (chunk_view::_Iterator, stride_view::_Iterator): Likewise.
> (join_with_view): Declare _Itera
On Fri, May 16, 2025 at 7:33 PM Jonathan Wakely wrote:
> Formatting of chrono::local_days with an empty chrono-specs should be
> equivalent to inserting it into an ostream, which should use the
> overload for inserting chrono::sys_days into an ostream. The
> implementation of empty chrono-specs i
On Sun, 16 Mar 2025 11:23:07 -0600, Jeff Law wrote:
>
>
> On 3/10/25 2:26 AM, Kito Cheng wrote:
> > This patch fixes the multilib_os_dir and multiarch_dir for those targets
> > that use TARGET_COMPUTE_MULTILIB, since the TARGET_COMPUTE_MULTILIB hook
> > only update/fix the multilib_dir but not th
Pushed to trunk :)
On Mon, May 19, 2025 at 3:18 PM Dongyan Chen
wrote:
>
> During the GCC compilation, some warnings about temporary object dangling
> references emerged. They appeared in these code lines in riscv-common.cc:
> const riscv_ext_info_t &implied_ext_info, const riscv_ext_info_t &ext
From: xuli
This patch adds testcase for form1, as shown below:
T __attribute__((noinline)) \
sat_s_add_imm_##T##_fmt_1##_##INDEX (T x) \
{\
T sum = (UT)x + (UT)IMM; \
return (x ^ IMM) < 0
From: xuli
This patch would like to support vector SAT_ADD when one of the op
is singed IMM.
void __attribute__((noinline)) \
vec_sat_s_add_imm_##T##_fmt_1##_##INDEX (T *out, T *op_1, unsigned limit) \
{
From: xuli
This patch adds testcase for form1, as shown below:
void __attribute__((noinline)) \
vec_sat_s_add_imm_##T##_fmt_1##_##INDEX (T *out, T *op_1, unsigned limit) \
{\
unsigned i;
Committed to trunk, thanks :)
On Mon, May 19, 2025 at 10:44 AM Songhe Zhu
wrote:
>
> From: zhusonghe
>
> The variables `major` and `minor` in `gen-riscv-ext-texi.cc`
> conflict with the macros of the same name defined in ``,
> which are exposed when building with newer versions of GCC on older
>
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:
> >
> > * include/bits/ranges_algo.h (__starts_with_fn, starts
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:
>
> * include/bits/ranges_algo.h (__starts_with_fn, starts_with):
> Define.
> (__ends_with_fn, ends_with): Define.
>
Richard Biener writes:
> On Fri, 16 May 2025, Richard Sandiford wrote:
>> > The simple prototype below uses a separate flag from the epilogue
>> > mode, but I wonder how we want to more generally want to handle
>> > whether to use masking or not when iterating over modes. Currently
>> > we mostly
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
> 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
>>
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 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:
The series LGTM. I didn't check all the tests in detail to be honest :)
--
Regards
Robin
> >/* 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
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
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
> > +-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
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
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
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
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 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
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: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
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/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, 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 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,
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
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_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
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 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
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.
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
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
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 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
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 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, 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::
Ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677788.html .
Thanks,
Konstantinos
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
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];};
>
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 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
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, 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: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 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/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 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,
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
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) \
>
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
1 - 100 of 119 matches
Mail list logo