On Fri, May 30, 2025 at 6:44 PM Luc Grosheintz
wrote:
> 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 f
DR_INIT is already measured in bytes, so there's no need to multiply
the DR_INIT difference of two DRs by the size of one of the DRs when
comparing that difference against MAX_BITSIZE_MODE_ANY_MODE.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/120517
On Fri, May 9, 2025 at 4:05 PM Tamar Christina wrote:
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Friday, May 9, 2025 2:44 PM
> > To: Tamar Christina
> > Cc: Richard Sandiford ; Pengfei Li
> > ; gcc-patches@gcc.gnu.org; ktkac...@n
On Tue, Jun 3, 2025 at 2:50 PM Luc Grosheintz
wrote:
>
>
> On 6/3/25 14:31, Tomasz Kaminski wrote:
> > On Mon, Jun 2, 2025 at 9:07 AM Luc Grosheintz
> > wrote:
> >
> >>
> >>
> >> On 5/30/25 18:42, Luc Grosheintz wrote:
> >>> Implements a suite of tests for the currently implemented parts of
> >>
e we could switch
> > create_tmp_reg to always yield a SSA name.
> >
> > Thus for the fixup here I'd suggest using make_ssa_name (type) instead.
>
> yes that worked, I submitted
> https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685263.html for
> that.
> I
On Tue, 3 Jun 2025 at 13:08, Tomasz Kaminski wrote:
>
>
>
> On Fri, May 30, 2025 at 6:45 PM Luc Grosheintz
> wrote:
>>
>> libstdc++-v3/ChangeLog:
>>
>> * include/std/mdspan(__mdspan::_ExtentsStorage): Change name
>> of private member _M_dynamic_extens to _M_dyn_exts.
>> *
Floating-point to integer conversions can be inexact or invalid (e.g., due to
overflow or NaN). However, since users of operation_could_trap_p infer the
bool FP_OPERATION argument from the expression's type, the FIX_TRUNC family
are considered non-trapping here.
This patch handles
Hi,
This is a V2 of https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683650.html.
Apologies for the delay - I was hesistant to push without preserving
sve/pr96357.c and regtesting x86. The change to sve/pr96357.c means that it
can still be vectorized, and will still trigger the ICE without Prz
On Tue, 3 Jun 2025 at 13:13, Tomasz Kaminski wrote:
>
>
>
> On Fri, May 30, 2025 at 6:47 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 clas
On 6/3/25 14:31, Tomasz Kaminski wrote:
On Mon, Jun 2, 2025 at 9:07 AM Luc Grosheintz
wrote:
On 5/30/25 18:42, 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
On Fri, May 30, 2025 at 6:47 PM Luc Grosheintz
wrote:
> Implements the remaining parts of layout_left and layout_right; and all
> of layout_stride.
>
> The implementation of layout_stride::mapping::is_exhaustive applies
> the following change to the standard:
>
> 4266. layout_stride::mapping sh
etail::__wait_until):
Remove incorrect comment.
* src/c++20/atomic.cc (__spin_until_impl): Fix incorrect
return value. Reuse result of first call to clock.
---
Patch v2 adjusts the commit summary to not say it only changes comments.
Also removed the change t
On Fri, May 30, 2025 at 6:50 PM Luc Grosheintz
wrote:
> 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_right.
>
On Fri, May 30, 2025 at 6:49 PM Luc Grosheintz
wrote:
> 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.
> * src/c++23
On Mon, Jun 2, 2025 at 9:07 AM Luc Grosheintz
wrote:
>
>
> On 5/30/25 18:42, 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.
> >
> >
On Mon, Jun 2, 2025 at 10:56 PM Jonathan Wakely wrote:
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (is_destructible, is_destructible_v):
> Define using new built-in.
> (is_nothrow_destructible, is_nothrow_destructible_v): Likewise.
> (is_trivially_destr
On Fri, May 30, 2025 at 6:52 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_con
On Fri, May 30, 2025 at 6:47 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.
> * src/c++23/std.cc.in: Add layout_left.
>
> Signed-off-by:
On Fri, May 30, 2025 at 6:45 PM Luc Grosheintz
wrote:
> libstdc++-v3/ChangeLog:
>
> * include/std/mdspan(__mdspan::_ExtentsStorage): Change name
> of private member _M_dynamic_extens to _M_dyn_exts.
> * include/std/mdspan(extents): Change name of private member
> f
Thanks, Alfie. I agree that having a table with just one entry looks a
little odd, but the rest of the file follows this pattern. For example:
;; -
;; [FP] Absolute difference
;;
ic_wait_address_for_v): Change parameter type from
>> >> time_point
>> >> to duration.
>> >> ---
>> >>
>> >> Tested x86_64-linux.
>> >
>> > LGTM.
>>
>> I'm actually going to move the &__args
Hi Sandra, hello world,
Sandra Loosemore wrote:
On 6/2/25 12:15, Tobias Burnus wrote:
The problem is that 'int'/'int*' became 'omp_interop_rc_t ret_code'
and 'omp_interop_rc_t *ret_code'.
...
I think the patch just confuses readers, as-is. Plus it h
on of
patch attached. I only can speculate what is going wrong with the first version
of the patch. Obviously the type of array the first patch introduced can not be
layed out correctly. There is a mult of arg 0 NOP arg 0 NOP in there which is
more than odd. I would expect something like mult arg 0
Hi All,
With the middle-end providing a way to make vectorization more profitable by
scaling vect-scalar-cost-multiplier this makes a more user friendly option
to make it easier to use.
I propose making it an actual -m option that we document and retain vs using
the parameter name. In the future
Adding a tests for behavior of the ostream operator and the formatting
with empty chronio-spec for the chrono types. Current coverage is:
* time point, zoned_time and local_time_format in this commit,
* calendar types in r16-1016-g28a17985dd34b7.
libstdc++-v3/ChangeLog:
* testsuite/std/
Gentle ping for https://gcc.gnu.org/pipermail/gcc-patches/2025-March/676875.html
This patch would like to introduce the combine of vec_dup + vdiv.vv into
vdiv.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:
The series is OK, thanks
: Change parameter type from time_point
to duration.
---
Patch v2 adds the __res.first change to this patch, which was previously
included in a different patch. It makes more sense to combine that with
this patch.
Tested x86_64-linux.
libstdc++-v3/include/bits/atomic_timed_wait.h | 6 +++---
On Tue, 3 Jun 2025 at 10:54, Tomasz Kaminski wrote:
>
>
>
> On Mon, Jun 2, 2025 at 10:56 PM Jonathan Wakely wrote:
>>
>> libstdc++-v3/ChangeLog:
>>
>> * include/std/type_traits (is_destructible, is_destructible_v):
>> Define using new built-in.
>> (is_nothrow_destructible,
The documentation for outline atomics is missing the entry for
-mno-outline-atomics which this patch adds.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* doc/extend.texi (outline-atomics): Document the inverse -mno flag
With the change to the title, this looks good to me.
On Tue, Jun 3, 2025 at 12:02 PM Tomasz Kaminski wrote:
> The tile says that you are doing only comment fixes, while there is code
> change
> in __spin_until_impl. Could you please adjust it:
> Fix incorrect returns and comments on atomic timed
> (__atomic_wait_address_until_v):
> >> Do not take address of __args in call to __detail::__wait_until.
> >> (__atomic_wait_address_for_v): Change parameter type from
> time_point
> >> to duration.
> >> ---
> >>
> >> Tested
The tile says that you are doing only comment fixes, while there is code
change
in __spin_until_impl. Could you please adjust it:
Fix incorrect returns and comments on atomic timed waits
On Mon, Jun 2, 2025 at 7:24 PM Jonathan Wakely wrote:
> The __detail::__wait_until function has a comment tha
x86_64-linux.
> >
> > LGTM.
>
> I'm actually going to move the &__args to __args change from the "Fix
Oops, I mean move the __res.first to !__res._M_timeout change from
that patch to this one.
> incorrect comments on atomic timed waits" patch to this one,
(__atomic_wait_address_for_v): Change parameter type from time_point
>> to duration.
>> ---
>>
>> Tested x86_64-linux.
>
> LGTM.
I'm actually going to move the &__args to __args change from the "Fix
incorrect comments on atomic t
On Tue, 3 Jun 2025 at 09:23, Tomasz Kaminski wrote:
>
>
>
>
> On Mon, Jun 2, 2025 at 7:28 PM Jonathan Wakely wrote:
>>
>> This suppresses some -Wsign-conversion warnings from Clang when
>> compiling with -Wsystem-headers.
>>
>> libstdc++-v3/ChangeLog:
>>
>> * include/std/bit (__rotl, __ro
Hi @Jeff Law , @pal...@dabbelt.com
and all ,
Please can you pass your comments on the below changes ,thank you
~U
On Tue, May 27, 2025 at 4:36 PM Umesh Kalappa
wrote:
> The P8700 is a high-performance processor from MIPS by extending RISCV with
> the MIPS custom instruction and the followin
This adds a new implementation of std::counting_semaphore for the
case where Max == 1, i.e. the std::binary_semaphore typedef. When the
maximum counter value is 1 we don't need to load the current counter
value before doing a compare-exchange to acquire the semaphore. We can
just optimisitcally ass
Add a test for PR target/103750 fixed by r16-170-ga670ebde399548.
PR target/103750
* g++.target/i386/pr103750.C: New test.
I am checking in this.
--
H.J.
From 4ab36e8e56280d774d4b5ef07b0838020ba20a6a Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Tue, 3 Jun 2025 17:17:57 +0800
Subje
On Mon, Jun 2, 2025 at 7:33 PM Jonathan Wakely wrote:
> This replaces two implicit conversions from ptrdiff_t to size_t with
> explicit conversions that include unreachable hints for the ptrdiff_t
> value not being negative.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/stl_vector.h (~_V
>>gcc/cp/ChangeLog:
>> * pt.cc (lookup_template_class): Honour provided namespace contexts
>> when looking up class templates.
>This is good, but I'd also expect namespace context to take priority over
>innermost_non_namespace_value just above?
So the attached version is more aggressiv
There's a deadlock in std::counting_semaphore that occurs when the
semaphore is under contention. The bug happens when one thread tries to
acquire the mutex, calling __semaphore_base::_S_do_try_acquire to
atomically decrement the counter using compare_exchange_strong. If the
counter is non-zero (an
On Mon, Jun 2, 2025 at 10:59 PM Jonathan Wakely wrote:
> These function templates are apparently never used or instantiated,
> because they don't compile. This fixes them, but they're still unused.
> I plan to make use of them in a later commit.
>
> libstdc++-v3/ChangeLog:
>
> * include/b
On 02/06/25 12:30 pm, Surya Kumari Jangala wrote:
>
> On 30/05/25 1:37 am, Peter Bergner wrote:
>> On 5/29/25 5:35 AM, Segher Boessenkool wrote:
>>>
+#define _AMO_LD_INCREMENT(NAME, TYPE, OPCODE, FC) \
+static __inline__ TYPE
When the semaphore counter is __platform_wait_t we can use the simpler
atomic waiting functions that just take a value and wait for it to
change, instead of using an accessor function and a predicate to fetch
and compare the value.
Because the simpler value-based waiting functions don't return the
Replace the _S_get_current and _S_do_try_acquire static member functions
with non-static member functions _M_get_current and _M_do_try_acquire.
This means they don't need the address of _M_counter passed in.
libstdc++-v3/ChangeLog:
* include/bits/semaphore_base.h (_S_get_current): Replace
On Mon, Jun 2, 2025 at 7:28 PM Jonathan Wakely wrote:
> This suppresses some -Wsign-conversion warnings from Clang when
> compiling with -Wsystem-headers.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/bit (__rotl, __rotr): Use static_cast for
> conversion from int to unsigned.
> -
On Mon, Jun 2, 2025 at 7:25 PM Jonathan Wakely wrote:
> __cpp_lib_any and __cpp_lib_chrono are defined unconditionally in C++20
> and __cpp_lib_three_way_comparison and __cpp_lib_concepts depend on
> front-end features which are definitely supported by GCC trunk.
>
> libstdc++-v3/ChangeLog:
>
>
Hi!
On Mon, 2 Jun 2025 at 20:53, Andre Vehreschild wrote:
>
> Hi Thomas,
>
> thanks for the ok. Unfortunately does the patch regress in gomp (test case
> gomp/pr104382 when I am not mistaken ; the one with the lone 'save'
> statement). This was reported by the regr
> Am 02.06.2025 um 14:16 schrieb Tamar Christina :
>
>
>>
>> -Original Message-
>> From: Richard Biener
>> Sent: Monday, May 26, 2025 2:56 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd
>> Subject: RE: [PATCH 1/2]mi
This series is OK now, thanks.
--
Regards
Robin
1. riscv64-linux-gcc -march=rv64gc -march=foo-cpu -mtune=foo-cpu
2. riscv64-linux-gcc -march=rv64gc -march=foo-cpu
3. riscv64-linux-gcc -march=rv64gc -march=unset -mtune=unset -mcpu=foo-cpu
Preference to me:
- Prefer option 1.
- Less prefer option 3. (acceptable but I don't like)
- Strongly disli
Hi!
When reading the code, I've noticed various function definitions
with misaligned parameters, they should IMHO always align below the first
character after opening ( and in most cases they do, but in some
cases they were indented more or less. Perhaps the functions changed
name or something.
;> To: Tamar Christina
>>> Cc: gcc-patches@gcc.gnu.org; nd
>>> Subject: RE: [PATCH 1/2]middle-end: Apply loop->unroll directly in
>>> vectorizer
>>>
>>>> On Mon, 19 May 2025, Tamar Christina wrote:
>>>
>>>>>> /
Hi!
I've noticed we don't even support say float -> double and other
scalar floating point to scalar floating point conversions in the
ranger, we just end up with VARYING for those.
The following patch attempts to fix that.
The reverse cast case uses float_binary_op_range_finish e.
From 165331762869ba61477699a5fe097de7d2a56443 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Fri, 9 May 2025 07:17:07 +0800
Subject: [PATCH] x86: Extend the remove_redundant_vector pass
Extend the remove_redundant_vector pass to handle vector broadcasts from
constant and variable scalars. When broadcasting fro
sign of zero would need to be checked specifically (via
> copysign or signbit).
Thanks for the suggestions! The tests are now added; please check the attached
patch.
> Similar considerations may apply to other functions as well - and would be
> avoided by not trying to do the optimizations
> Am 03.06.2025 um 05:59 schrieb Andrew Pinski :
>
> This testcase was fixed by r16-906-g8da568c885dc90. Since
> this is a C testcase, it would be useful to have a C testcase besides
> a C++ one too.
>
> Tested for x86_64-linux-gnu.
Ok
Richard
>PR tree-optimization/116824
>
> gcc/tes
> Am 03.06.2025 um 04:51 schrieb Andrew Pinski :
>
> When we have a smallish CSWTCH, it could be placed in the rodata.cst16
> section so it can be merged with other constants across TUs.
>
> The fix is simple; just mark the decl as mergable (DECL_MERGEABLE).
> DECL_MERGEABLE was added with r1
When we have a smallish CSWTCH, it could be placed in the rodata.cst16
section so it can be merged with other constants across TUs.
The fix is simple; just mark the decl as mergable (DECL_MERGEABLE).
DECL_MERGEABLE was added with r14-1500-g4d935f52b0d5c0 specifically
to improve these kind of decls
This testcase was fixed by r16-906-g8da568c885dc90. Since
this is a C testcase, it would be useful to have a C testcase besides
a C++ one too.
Tested for x86_64-linux-gnu.
PR tree-optimization/116824
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/phiprop-2.c: New test.
Signed-off-b
I am a little hesitant about whether to let -march implicitly set
-mtune, because this is equivalent to making -march become another
-mcpu with higher priority, and we cannot avoid discussing the
priority of -march and -mtune again, and no matter what the priority
is, it will introduce more complic
On 6/2/25 7:34 PM, Kito Cheng wrote:
LGTM, and will commit once CI happy, BTW, next time you could name the
testcase into arch-.c e.g. arch-svbare.c, that could prevent
potential filename conflict. :)
Yea, I nearly made a similar suggestion. Not sure why we're using
numeric suffixes here. T
I add a ChangeLog and update testname in
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685401.html
Thanks
Dongyan Chen
在 2025/6/3 3:34, Jeff Law 写道:
On 5/29/25 7:27 AM, Dongyan Chen wrote:
This patch support svbare extension, which is an extension in RVA23
profile.
To enable GCC to
Okay, thanks, I get that.
Dongyan Chen
在 2025/6/3 9:34, Kito Cheng 写道:
LGTM, and will commit once CI happy, BTW, next time you could name the
testcase into arch-.c e.g. arch-svbare.c, that could prevent
potential filename conflict. :)
On 6/2/25 6:28 PM, Iain Sandoe wrote:
Tested on x86_64-darwin and powerpc64le so far, how does this look?
thanks
Iain
--- 8< ---
Using lookup_template_class () directly on the coroutine_handle identifier
fails in the reported test because the using TYPE_DECL is found. This is
because
lookup i
ish_expr_stmt (r);
Hmm, if this tail-call ends up returning to the ramp, can we get the same
lifetime problem?
I think this is correct, because if the tailcall returns to the ramp it means
that the coroutine has suspended.
Then the patch is OK, thanks.
(I actually do have local tests that c
LGTM, and will commit once CI happy, BTW, next time you could name the
testcase into arch-.c e.g. arch-svbare.c, that could prevent
potential filename conflict. :)
On Tue, Jun 3, 2025 at 9:22 AM Dongyan Chen
wrote:
>
> This patch support svbare extension, which is an extension in RVA23 p
This patch support svbare extension, which is an extension in RVA23 profile.
To enable GCC to recognize and process svbare extension correctly at compile
time.
gcc/ChangeLog:
* config/riscv/riscv-ext.def: New extension defs.
* config/riscv/riscv-ext.opt: Ditto.
* doc
Tested on x86_64-darwin and powerpc64le so far, how does this look?
thanks
Iain
--- 8< ---
Using lookup_template_class () directly on the coroutine_handle identifier
fails in the reported test because the using TYPE_DECL is found. This is
because
lookup is called with default parameters that me
> > if (CALL_P (insn))
> > > {
> > > tree fndecl = get_call_fndecl_from_rtx (insn);
> > > if (fndecl == current_function_decl
> > > && decl_binds_to_current_def_p (fndecl))
> > > {
> > > recursive_call_p = true;
> > > break;
> > > }
> > > }
> > >
> > > If get_call_fndecl works without a REG_CALL_DECL note, I can use it
> > > instead of writing my own.
> >
> > I think we should consider removing the flag_ipa_ra guards around
> > the code that adds REG_CALL_DECLs.
> >
>
> Like this?
>
> Always add REG_CALL_DECL note for CALL so that get_call_fndecl works
> without -fipa-ra.
>
> PR other/120494
> * calls.cc (expand_call): Always add REG_CALL_DECL note.
> (emit_library_call_value_1): Likewise.
>
> Thanks.
>
>
> --
> H.J.
I found another way to check recursive function. I don't need this patch for
my pass.
--
H.J.
Joseph Myers wrote:
On Sun, 1 Jun 2025, Yuao Ma wrote:
For MPFR versions older than 4.2.0, we've included our own folding functions.
I think the normal practice in GCC would be to avoid the optimizations
when the MPFR support is absent, instead of working around the absence
with possibly less a
decl_from_rtx (insn);
> > if (fndecl == current_function_decl
> > && decl_binds_to_current_def_p (fndecl))
> > {
> > recursive_call_p = true;
> > break;
> >
> On 2 Jun 2025, at 21:17, Jason Merrill wrote:
>
> On 6/1/25 3:30 AM, Iain Sandoe wrote:
>> Updated. I realised we no longer need to refer to
>> initial_await_resume_called in the ramp at all, v2 removes the setting
>> of the variable from there and puts it into the start of the actor.
>> Tes
From: Gwenole Beauchesne
Handle '#pragma GCC optimize' earlier as the __OPTIMIZE__ macro may need
to be defined as well for certain usages. Add additional tests for the
'#pragma GCC target' case with auto-vectorization enabled and multiple
combinations of namespaces and/or class member functions.
0x930f8b try_split(rtx_def*, rtx_insn*, int)
> > /home/dinux/projects/pru/local-workspace/gcc/gcc/emit-rtl.cc:3952
> > 0xd18ab5 split_insn
> > /home/dinux/projects/pru/local-workspace/gcc/gcc/recog.cc:3479
> > 0xd1e877 split_all_insns()
> >
On Mon, 02 Jun 2025 12:35:45 PDT (-0700), Robin Dapp wrote:
I don't quite follow this part. IIUC the rules before this patch were
-march=ISA: Generate code that requires the given ISA, without
changing the tuning model.
-mcpu=CPU: Generate code for the given CPU, targeting al
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_destructible, is_destructible_v):
Define using new built-in.
(is_nothrow_destructible, is_nothrow_destructible_v): Likewise.
(is_trivially_destructible, is_trivially_destructible_v):
Likewise.
---
Thanks
On 6/1/25 3:30 AM, Iain Sandoe wrote:
Updated. I realised we no longer need to refer to
initial_await_resume_called in the ramp at all, v2 removes the setting
of the variable from there and puts it into the start of the actor.
Tested on x86_64-darwin and powerp64le-linux.
Confirmed that the sani
These function templates are apparently never used or instantiated,
because they don't compile. This fixes them, but they're still unused.
I plan to make use of them in a later commit.
libstdc++-v3/ChangeLog:
* include/bits/atomic_timed_wait.h (__atomic_wait_address_until_v):
Do n
here is no real solution in C++ and only an
ugly for C.]
See also
https://gcc.gnu.org/onlinedocs/libgomp/Interoperability-Routines.html
Comments, suggestions, remarks before I commit it?
I think the patch just confuses readers, as-is. Plus it has a grammar
bug. How about instead of
+Note
same, just the limit
> > "this is *too* annoying" shifted a bit.
>
> It would cause false positives, e.g. occasionally for the "goto fail"
> idiom in C, so I think it is not acceptable for -Wall. I based
> this also on the comments in the bug report.
Yea
Hi Andre,
attached patch fixes a missing substring ref on a saved allocatable string.
The issue seems to be, that the variable is declared to be a character pointer
and not a character array. When using the latter (why not), it works as
expected and does not produce any regressions.
Regtests
On 5/27/25 1:32 AM, Jiawei wrote:
This patch add the RISC-V Shlcofideleg extension. It supports delegating
LCOFI interrupts(the count-overflow interrupts) to VS-mode.[1]
[1] https://riscv.github.io/riscv-isa-manual/snapshot/privileged
gcc/ChangeLog:
* config/riscv/riscv-ext.def
I don't quite follow this part. IIUC the rules before this patch were
-march=ISA: Generate code that requires the given ISA, without
changing the tuning model.
-mcpu=CPU: Generate code for the given CPU, targeting all the
extensions that CPU supports and using the best
es of interest where this detects buggy code that isn't
> > detected by -Wmaybe-uninitialized (also included in -Wextra)? Is this
> > about -O0 compilations?
>
> One example would be:
>
> void t(int *);
> void m(void)
> {
> goto foo;
> int i
On 5/29/25 7:27 AM, Dongyan Chen wrote:
This patch support svbare extension, which is an extension in RVA23 profile.
To enable GCC to recognize and process svbare extension correctly at compile
time.
Needs a ChangeLog entry and the testname needs to be updated now that
arch-59 is taken
On 5/29/25 5:44 AM, Dongyan Chen wrote:
This patch support smcntrpmf extension[1].
To enable GCC to recognize and process smcntrpmf extension correctly at compile
time.
[1]https://github.com/riscvarchive/riscv-smcntrpmf
gcc/ChangeLog:
* config/riscv/riscv-ext.def: New extension
uninitialized (also included in -Wextra)? Is this
> about -O0 compilations?
One example would be:
void t(int *);
void m(void)
{
goto foo;
int i = 0;
foo:
t(&i);
}
>
> If it's not working for -Wc++-compat I'd expect a testcase added (fails
> before t
On 6/1/25 1:12 AM, H.J. Lu wrote:
Move get_call_rtx_from to final.c and call call_from_call_insn.
PR other/120493
* final.cc (call_from_call_insn): Change the argument type to
const rtx_call_insn *.
(get_call_rtx_from): New.
* rtl.h (is_a_helper ::test): New.
(get_call_rtx_from): Moved to the
fic target
features or detect incompatibilities.
* We landed the commit 4a182418c89666e7594bcb0e5edc5194aa147910
hastily on May 23, 2025, with far-reaching implications that weren't
fully considered.
Sorry if I'ma bit lost here, 4a182418c89 ("RISC-V: Support CPUs in
-march.")
Hi Thomas,
thanks for the ok. Unfortunately does the patch regress in gomp (test case
gomp/pr104382 when I am not mistaken ; the one with the lone 'save'
statement). This was reported by the regression testing host at first for
arm, but also occurs on x86_64. Since when are propos
On Mon, 2 Jun 2025, Martin Uecker wrote:
> I *believe* TYPE_PACKED should be propagated to existing main
> variants.
>
>
> Bootstrapped and regression tested for x86_64.
>
> Martin
>
>
> c: fix ICE with enum completed with packed attribute after forward decl
> [PR116892]
>
> Aft
pat I'd expect a testcase added (fails
before the patch, passes after) that tests the warning with -Wc++-compat.
--
Joseph S. Myers
josmy...@redhat.com
On Sun, 1 Jun 2025, Peter Frost wrote:
> Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html
This needs various coding style fixes. Lines should be broken before
binary operators such as && or || rather than after, and there should be a
space before '(' in function and macr
. occasionally for the "goto fail"
idiom in C, so I think it is not acceptable for -Wall. I based
this also on the comments in the bug report.
>
> Why do this in -Wc++-compat at all? You don't say. Well, you say that
> is a bugfix, so it should be a separate (and trivi
Not really new - but as the topic came up elsewhere (OpenMP issue 4455),
I had a second thought about this and I think it make sense to add a note.
GCC uses the OpenMP 6.0 version.
The problem is that 'int'/'int*' became 'omp_interop_rc_t ret_code'
and 'omp_interop_rc_t *ret_code'.
For C++, pas
On Sun, 1 Jun 2025, Martin Uecker wrote:
> This patch now moves the checking assertion out of the recursion,
> which seems better anyhow. I could not do the check unconditionally
> for all types. because we sometimes call composite_type for with
> mismatching qualifiers.
Calling co
noying, but the
requirements for the two are essentially the same, just the limit
"this is *too* annoying" shifted a bit.
Why do this in -Wc++-compat at all? You don't say. Well, you say that
is a bugfix, so it should be a separate (and trivial) patch.
Segher
This replaces two implicit conversions from ptrdiff_t to size_t with
explicit conversions that include unreachable hints for the ptrdiff_t
value not being negative.
libstdc++-v3/ChangeLog:
* include/bits/stl_vector.h (~_Vector_base): Add unreachable
hint for negative capacity and
1 - 100 of 15939 matches
Mail list logo
