Hi Joseph,
I have updated the patch based on your review comments. I added the newly
introduced builtin to extend.texi and mentioned the PR in the commit message.
Could you please take another look when you have a moment?
Yuao
From: Joseph Myers
Sent: Thursday,
Hi Jonathan,
> On 14/05/25 10:01 +0200, Tomasz Kamiński wrote:
>>This commits adjust the way how the arguments are stored in the _Arg_value
>>(and thus basic_format_args), by preserving the types of fixed width
>>floating-point types, that were previously converted to float, double,
>>long double.
On 07/05/2025 14:32, Richard Sandiford wrote:
Karl Meakin writes:
Add rules for lowering `cbranch4` to CBB/CBH/CB when CMPBR
extension is enabled.
gcc/ChangeLog:
* config/aarch64/aarch64.md (cbranch4): emit CMPBR
instructions if possible.
(cbranch4): new expand rule.
FYI.
This feature has been committed into CLANG yesterday.
https://github.com/llvm/llvm-project/pull/137250
Qing
> On May 13, 2025, at 17:03, Qing Zhao wrote:
>
> Hi,
>
> This is the 4th version of the patch set to extend "counted_by" attribute
> to pointer fields of structures.
>
> compare
> With the avx512_two_epilogues tuning enabled for zen4 and zen5
> the gcc.target/i386/vect-epilogues-5.c testcase below regresses
> and ends up using AVX2 sized vectors for the masked epilogue
> rather than AVX512 sized vectors. The following patch rectifies
> this and adds coverage for the inten
On 5/12/25 7:53 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK
for trunk/15/14?
-- >8 --
Here unification of P=Wrap::type, A=Wrap::type wrongly
succeeds ever since r14-4112 which made the RECORD_TYPE case of unify
no longer recurse into template ar
On 06/05/25 19:35, Richard Sandiford wrote:
External email: Use caution opening links or attachments
Hi,
Thanks for the update. The patch mostly looks good, but one minor and
one more substantial comment below.
BTW, the patch seems to have been corrupted en route, in that unchanged
lines hav
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
With the avx512_two_epilogues tuning enabled for zen4 and zen5
the gcc.target/i386/vect-epilogues-5.c testcase below regresses
and ends up using AVX2 sized vectors for the masked epilogue
rather than AVX512 sized vectors. The following patch rectifies
this and adds coverage for the intended behavi
The following includes whether we vectorize an epilogue, whether
we use loop masking and what vectorization factor (unroll factor)
we use. So it's now
t.c:4:21: optimized: loop vectorized using 64 byte vectors and unroll factor 32
t.c:4:21: optimized: epilogue loop vectorized using masked 64 byte
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
On 5/12/25 8:34 PM, Kito Cheng wrote:
We forgot to initialize m_allow_adding_dup in the constructor of
riscv_subset_list, then that will be a random value...that will lead
to a random behavior of the -march may accpet duplicate extension.
gcc/ChangeLog:
* common/config/riscv/riscv-co
On 07/05/2025 14:32, Richard Sandiford wrote:
Karl Meakin writes:
Add rules for lowering `cbranch4` to CBB/CBH/CB when CMPBR
extension is enabled.
gcc/ChangeLog:
* config/aarch64/aarch64.md (cbranch4): emit CMPBR
instructions if possible.
(cbranch4): new expand rule.
Hi Paul,
Same remark as for PR120107! LGTM for both branches.
Committed both patches. Thanks for the reviews!
Best regards
Thomas
On Wed, 14 May 2025, Jason Merrill wrote:
> On 5/12/25 7:53 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK
> > for trunk/15/14?
> >
> > -- >8 --
> >
> > Here unification of P=Wrap::type, A=Wrap::type wrongly
> > succeeds ever since r14-4112 whic
Karl Meakin writes:
> On 07/05/2025 14:32, Richard Sandiford wrote:
>> Karl Meakin writes:
>>> Add rules for lowering `cbranch4` to CBB/CBH/CB when CMPBR
>>> extension is enabled.
>>>
>>> gcc/ChangeLog:
>>>
>>> * config/aarch64/aarch64.md (cbranch4): emit CMPBR
>>> instructions if possibl
>> that indicates we have not yet reached the ramp return.
>This flag was not part of the fix on trunk, and could use more rationale.
The original fix was OK on trunk because exceptions thrown from the
return expression would happen before the initial suspend. Having fixed
BZ199916 (which r
On Wed, 14 May 2025, Patrick Palka wrote:
> On Wed, 14 May 2025, Jason Merrill wrote:
>
> > On 5/12/25 7:53 PM, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK
> > > for trunk/15/14?
> > >
> > > -- >8 --
> > >
> > > Here unification of P=Wrap::typ
On 5/13/25 10:07, Vineet Gupta wrote:
>
>
> On 5/10/25 07:20, Jeff Law wrote:
>> On 5/9/25 2:27 PM, Vineet Gupta wrote:
>>> This is effectively reverting e5d1f538bb7d
>>> "(RISC-V: Allow different dynamic floating point mode to be merged)"
>>> while retaining the testcase.
>>>
>>> The change itself
Karl Meakin writes:
>>> + else
>>> +{
>>> + operands[1] = aarch64_gen_compare_reg (GET_CODE (operands[0]),
>>> +operands[1], operands[2]);
>>> + operands[2] = const0_rtx;
>>> +}
>>> + }
>>> +)
>>> +
>>> @@ -758,6 +781,58 @@ (define_expand
Richard Biener writes:
> The following includes whether we vectorize an epilogue, whether
> we use loop masking and what vectorization factor (unroll factor)
> we use. So it's now
>
> t.c:4:21: optimized: loop vectorized using 64 byte vectors and unroll factor
> 32
> t.c:4:21: optimized: epilogu
On 5/13/25 10:30 AM, Iain Sandoe wrote:
The revised wording for coroutines, uses decltype(auto) for the
type of the get return object, which preserves references. The
test is expected to fail, since it attempts to initialize the
return object from an object that has already been destroyed.
gcc/c
On 5/13/25 10:30 AM, Iain Sandoe wrote:
This replaces the cleanup try-catch block in the ramp with a series of
eh-only cleanup statements.
gcc/cp/ChangeLog:
* coroutines.cc
(cp_coroutine_transform::build_ramp_function): Replace ramp
cleanup try-catch block with eh-only c
> Am 13.05.2025 um 19:24 schrieb Andrew Pinski :
>
> r10-2587-gcc19f80ceb27cc added a loop over the current statment if there was
> a change. Except in some cases it turns out changed will turn from true to
> false
> because instead of doing |= after the fold_stmt, there was an just an `=`.
>
> Am 13.05.2025 um 19:24 schrieb Andrew Pinski :
>
> r10-2587-gcc19f80ceb27cc added a loop over the current statment if there was
> a change. Except in some cases it turns out changed will turn from true to
> false
> because instead of doing |= after the fold_stmt, there was an just an `=`.
>
The file now includes copyable_function in addition to
move_only_function.
PR libstdc++/119125
libstdc++-v3/ChangeLog:
* include/bits/move_only_function.h: Move to...
* include/bits/funcwrap.h: ...here.
* doc/doxygen/stdheader.cc (init_map): Replaced move_only_func
> Am 14.05.2025 um 03:12 schrieb Andrew Pinski :
>
> This moves the canonicalization of `bool==0` and `bool!=1` from
> forwprop to cleanupcfg. We will still need to call it from forwprop
> so we don't need to call forwprop a few times to fp comparisons in some
> cases (forwprop-16.c was added
> Am 14.05.2025 um 03:13 schrieb Andrew Pinski :
>
> Since the merge of the tuples branch (r0-88576-g726a989a8b74bf), the
> if:
> ```
> if (TREE_CODE_CLASS (gimple_cond_code (stmt)) != tcc_comparison)
> ```
> Will always be false so let's change it into an assert.
Ok
Richard
> gcc/ChangeL
Based on the provision in C++26 [func.wrap.general] p2 this patch adjust the
generic
move_only_function(_Fn&&) constructor, such that when _Fn refers to selected
move_only_function instantiations, the ownership of the target object is
direclty
transfered to constructor object. This avoid cost of
> Am 14.05.2025 um 03:12 schrieb Andrew Pinski :
>
> We have code later on that verifies the code is a comparison. So let's
> try to catch it earlier. So it is easier to debug where the incorrect code
> gets set.
>
> Bootstrapped and tested on x86_64-linux-gnu.
Ok
> gcc/ChangeLog:
>
>*
Prompted by Jakub's recent work to enable a 32-bit biarch gcobol to
compile 64-bit COBOL code, I tried to bootstrap with cobol included on
Solaris/i386, Linux/i686, Darwin/i386, and Solaris/sparc.
While the builds mostly finished, all tests failed since the 64-bit
libgcobol was missing. As it tur
* libiberty.h (mkstemps): Remove duplicate.
---
include/libiberty.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/libiberty.h b/include/libiberty.h
index d4e8791b14b..4ec9b9afd17 100644
--- a/include/libiberty.h
+++ b/include/libiberty.h
@@ -215,10 +215,6 @@ extern int ffs
On Tue, May 13, 2025 at 4:34 AM Kito Cheng wrote:
>
> We forgot to initialize m_allow_adding_dup in the constructor of
> riscv_subset_list, then that will be a random value...that will lead
> to a random behavior of the -march may accpet duplicate extension.
>
> gcc/ChangeLog:
>
> * common
Hi,
This patch set has been waiting for the Middle-end review for a very long time
since last year.
Could you Please take a look and let me know whether it’s ready for GCC16?
Thanks a lot.
Qing
On May 1, 2025, at 10:02, Qing Zhao wrote:
>
> Hi,
>
> A gentle ping on review of the Middle-
On Wed, May 14, 2025 at 9:26 AM Richard Biener
wrote:
>
> On Wed, May 14, 2025 at 5:25 AM Kyle Huey wrote:
> >
> > For a debugger to display statically-allocated[0] TLS variables the compiler
> > must communicate information[1] that can be used in conjunction with
> > knowledge
> > of the runtim
On Wed, 14 May 2025, Tomasz Kamiński wrote:
> 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
> chan
On 4/29/25 18:00, Andrew MacLeod wrote:
On 3/28/25 05:25, Jakub Jelinek wrote:
On Fri, Mar 28, 2025 at 08:12:35AM +0100, Richard Biener wrote:
On Thu, Mar 27, 2025 at 8:14 PM Andrew MacLeod
wrote:
This patch backports the ASSUME support that was rewritten in GCC 15.
Its slightly more compl
This is the next step in removing forward_propagate_into_comparison
and forward_propagate_into_gimple_cond; In the case of `((int)(a cmp b)) != 0`
we want to do the transformation to `a cmp b` even if the cast is used twice.
This is exactly what
forward_propagate_into_comparison/forward_propagate_
> -Original Message-
> From: Uros Bizjak
> Sent: Tuesday, May 13, 2025 6:04 PM
> To: Cui, Lili
> Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao
> Subject: Re: [PATCH] x86: Enable separate shrink wrapping
>
> On Tue, May 13, 2025 at 8:15 AM Cui, Lili wrote:
> >
> > From: Lili Cui
> >
> >
This commit introduces a new operand constraint `cR` for the RISC-V
architecture, which allows the use of an even-odd RVC general purpose register
(x8-x15) in inline asm.
Ref: https://github.com/riscv-non-isa/riscv-c-api-doc/pull/102
gcc/ChangeLog:
* config/riscv/constraints.md (cR): New
This commit adds the code gen support for Zilsd, which is a
newly added extension for RISC-V. The Zilsd extension allows
for loading and storing 64-bit values using even-odd register
pairs.
We only try to do miminal code gen support for that, which means only
use the new instructions when the load
On Wed, May 14, 2025 at 7:39 PM Andrew Pinski wrote:
>
> This is the next step in removing forward_propagate_into_comparison
> and forward_propagate_into_gimple_cond; In the case of `((int)(a cmp b)) != 0`
> we want to do the transformation to `a cmp b` even if the cast is used twice.
> This is ex
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, May 13, 2025 7:49 PM
> To: Uros Bizjak
> Cc: Cui, Lili ; gcc-patches@gcc.gnu.org; Liu, Hongtao
>
> Subject: Re: [PATCH] x86: Enable separate shrink wrapping
>
> On Tue, May 13, 2025 at 12:36 PM Uros Bizjak wrote:
> >
> > On T
Got
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, François Dumont wrote:
Hi
Following this previous patch
https://gcc.gnu.org/pipermail/libstdc++/2024-August/059418.html I
On 14/05/25 11:52 +0100, Jonathan Wakely wrote:
On 14/05/25 10:48 +0200, Tomasz Kamiński wrote:
Based on the provision in C++26 [func.wrap.general] p2 this patch adjust the
generic
move_only_function(_Fn&&) constructor, such that when _Fn refers to selected
move_only_function instantiations, th
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
On 13/05/2025 16:26, Marcus Shawcroft wrote:
> Hello GCC Community,
>
> Many years have past since I actively worked on the aarch64 backend, so this
> email is long over due. I’ll be leaving Arm shortly so this seems like a good
> time to formerly step down as an AArch64 maintainer. It has been
On 14/05/25 10:48 +0200, Tomasz Kamiński wrote:
This patch implements C++26 copyable_function as specified in P2548R6.
It also implements LWG 4255 that adjust move_only_function so constructing
from empty copyable_function, produces empty functor. This falls from
existing checks, after specializi
> -Original Message-
> From: Tamar Christina
> Sent: Wednesday, May 14, 2025 12:19 PM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de
> Subject: [PATCH v2 1/2]middle-end: Add new parameter to scale scalar loop
> costing in vectorizer
>
> Hi All,
>
> This patch adds a new param
> > > >
> > > > - /* Loops vectorized with a variable factor won't benefit from
> > > > + /* Loops vectorized would have already taken into account unrolling
> specified
> > > > + by the user as the suggested unroll factor, as such we need to
> > > > prevent the
> > > > + RTL unroller fr
Hi All,
The vectorizer now tries to maintain the target VF that a user wanted through
uncreasing the unroll factor if the user used pragma GCC unroll and we've
vectorized the loop.
This change makes the AArch64 backend honor this initial value being set by
the vectorizer.
Consider the loop
void
On Wed, May 14, 2025 at 12:52 PM Jonathan Wakely wrote:
> On 14/05/25 10:48 +0200, Tomasz Kamiński wrote:
> >Based on the provision in C++26 [func.wrap.general] p2 this patch adjust
> the generic
> >move_only_function(_Fn&&) constructor, such that when _Fn refers to
> selected
> >move_only_functi
> Thansk for review.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> n some benchmark, I notice stv failed due to cost unprofitable, but the igain
> is inside the loop, but sse<->integer conversion is outside the loop, current
> cost
> model doesn't consider the
On Tue, May 13, 2025 at 10:42 PM Andrew Pinski wrote:
>
> This is the followup mentioned in
> https://gcc.gnu.org/pipermail/gcc-patches/2025-May/683444.html .
> It adds the check for cfun before accessing function specific flags.
> We handle the case where !cfun as conservative in that it the fun
This commits adjust the way how the arguments are stored in the _Arg_value
(and thus basic_format_args), by preserving the types of fixed width
floating-point types, that were previously converted to float, double,
long double.
The _Arg_value union now contains alternatives with std::bfloat16_t,
s
This patch implements C++26 copyable_function as specified in P2548R6.
It also implements LWG 4255 that adjust move_only_function so constructing
from empty copyable_function, produces empty functor. This falls from
existing checks, after specializing __is_polymorphic_function_v for
copyable_functi
On Wed, May 14, 2025 at 1:07 PM Jonathan Wakely wrote:
> On 14/05/25 10:48 +0200, Tomasz Kamiński wrote:
> >The file now includes copyable_function in addition to
> >move_only_function.
> >
> > PR libstdc++/119125
> >
> >libstdc++-v3/ChangeLog:
> > * include/bits/move_only_function.h:
On Mon, Apr 28 2025, Rasmus Villemoes wrote:
> On Thu, 3 Apr 2025 at 13:58, Rasmus Villemoes wrote:
>>
>> In many setups, especially when CI and/or some meta-build system like
>> Yocto or buildroot, is involved, gcc ends up being invoked using
>> absolute path names, which are often long and uni
On Wed, May 14, 2025 at 1:06 PM Jonathan Wakely wrote:
> On 14/05/25 10:48 +0200, Tomasz Kamiński wrote:
> >This patch implements C++26 copyable_function as specified in P2548R6.
> >It also implements LWG 4255 that adjust move_only_function so constructing
> >from empty copyable_function, produce
On Wed, 14 May 2025 at 12:57, Tomasz Kaminski wrote:
>
>
>
> On Wed, May 14, 2025 at 1:07 PM Jonathan Wakely wrote:
>>
>> On 14/05/25 10:48 +0200, Tomasz Kamiński wrote:
>> >The file now includes copyable_function in addition to
>> >move_only_function.
>> >
>> > PR libstdc++/119125
>> >
>>
On Wed, 14 May 2025 at 13:59, Tomasz Kaminski wrote:
>
>
> On Wed, May 14, 2025 at 1:06 PM Jonathan Wakely wrote:
>>
>> On 14/05/25 10:48 +0200, Tomasz Kamiński wrote:
>> >This patch implements C++26 copyable_function as specified in P2548R6.
>> >It also implements LWG 4255 that adjust move_only_
As a followup to PAREN_EXPR verification, let's ensure that CONJ_EXPR is
only used with COMPLEX_TYPE. While at it, move the whole block towards
the end of the switch, because unlike the other entries it needs to
break out of the switch, not immediately return from the function,
as after the switch
On Wed, 14 May 2025 at 16:32, Ville Voutilainen
wrote:
>
> On Wed, 14 May 2025 at 16:30, Ville Voutilainen
> wrote:
> >
> > On Wed, 14 May 2025 at 16:26, Patrick Palka wrote:
> > > > r = CALL_EXPR_ARG (x, 0);
> > > > /* Check that the return and argument types are sane before
On Tue, 13 May 2025, Ville Voutilainen wrote:
> On Tue, 13 May 2025 at 23:34, Jason Merrill wrote:
> >
> > On 5/13/25 4:29 PM, Ville Voutilainen wrote:
> > > On Tue, 13 May 2025 at 23:23, Jason Merrill wrote:
> > >>>/* Check that the return and argument types are sane before
> > >>>
On Wed, 14 May 2025 at 16:30, Ville Voutilainen
wrote:
>
> On Wed, 14 May 2025 at 16:26, Patrick Palka wrote:
> > > r = CALL_EXPR_ARG (x, 0);
> > > /* Check that the return and argument types are sane before
> > > folding. */
> >
> > This comment should be remove
On Thu, 8 May 2025, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> This tweak to CWG2369 has gotten more discussion lately in CWG, including in
> P3606. In those discussions, it occurred to me that having the check depend
> on whether a class has been ins
On Wed, 14 May 2025 at 16:26, Patrick Palka wrote:
> > r = CALL_EXPR_ARG (x, 0);
> > /* Check that the return and argument types are sane before
> > folding. */
>
> This comment should be removed too, along with the sanity check.
I'll commit-as-obvious that remov
On Wed, 14 May 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Tamar Christina
> > Sent: Wednesday, May 14, 2025 12:19 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: nd ; rguent...@suse.de
> > Subject: [PATCH v2 1/2]middle-end: Add new parameter to scale scalar loop
> > costing
On Wed, May 14, 2025 at 3:20 PM Andreas Schwab wrote:
Looks obvious to me.
Richard.
> * libiberty.h (mkstemps): Remove duplicate.
> ---
> include/libiberty.h | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/include/libiberty.h b/include/libiberty.h
> index d4e8791b14b..4ec9b
On Wed, May 14, 2025 at 3:24 PM Qing Zhao wrote:
>
> Hi,
>
> This patch set has been waiting for the Middle-end review for a very long
> time since last year.
>
> Could you Please take a look and let me know whether it’s ready for GCC16?
I plan to look at this next week while idling on a train.
On Mon, 2025-04-07 at 15:04 +, Qing Zhao wrote:
[...snip...]
> diff --git a/gcc/move-history-rich-location.cc b/gcc/move-history-
> rich-location.cc
> new file mode 100644
> index 000..120498d165e
> --- /dev/null
> +++ b/gcc/move-history-rich-location.cc
[...snip...]
> +
> +/* Imple
On Wed, May 14, 2025 at 3:41 PM Alexander Monakov wrote:
>
> As a followup to PAREN_EXPR verification, let's ensure that CONJ_EXPR is
> only used with COMPLEX_TYPE. While at it, move the whole block towards
> the end of the switch, because unlike the other entries it needs to
> break out of the s
Floating-point to integer conversions can be inexact or invalid (e.g., the
latter due to overflow or NaN). However, since users of operation_could_trap_p
infer the bool FP_OPERATION argument from the expression's type, FIX_TRUNC_EXPR
is considered non-trapping here. This patch handles FIX_TRUNC_E
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, FIX_TRUNC_EXPR is
considered non-trapping here.
This patch handles FIX_TRUNC_EXPR explici
HTEC Public
Hi,
> > GCC can modify a rtx which was created using stack_pointer_rtx.
> > This means that just doing a straight address comparision of a rtx
> > against stack_pointer_rtx to see whether it is the stack pointer
> > register will not be correct in all cases.
> Umm, no. There is one a
HTEC Public
Hi,
Could you please let us know if you have any comments
on the latest version of this patch?
Kind regards,
Aleksandar Rakic
On Thu, 2025-04-03 at 13:58 +0200, Rasmus Villemoes wrote:
> In many setups, especially when CI and/or some meta-build system like
> Yocto or buildroot, is involved, gcc ends up being invoked using
> absolute path names, which are often long and uninteresting.
>
> That amounts to a lot of noise bo
On Wed, 14 May 2025, Tomasz Kaminski wrote:
>
>
> On Wed, May 14, 2025 at 9:41 AM Tomasz Kaminski wrote:
>
>
> On Tue, May 13, 2025 at 11:16 PM Patrick Palka wrote:
> On Mon, 12 May 2025, Tomasz Kamiński wrote:
>
> > Based on the provision in C++26 [func.wrap.general] p2 this pa
On Wed, May 14, 2025 at 9:41 AM Tomasz Kaminski wrote:
>
>
> On Tue, May 13, 2025 at 11:16 PM Patrick Palka wrote:
>
>> On Mon, 12 May 2025, Tomasz Kamiński wrote:
>>
>> > Based on the provision in C++26 [func.wrap.general] p2 this patch
>> adjust the generic
>> > move_only_function(_Fn&&) const
Hi all,
This patch adds trigonometric pi-based functions as gcc builtins: acospi,
asinpi, atan2pi,
atanpi, cospi, sinpi, and tanpi. Latest glibc already provides support for
these functions, which we plan to leverage in future gfortran implementations.
The patch includes two test cases to verify
As we mentioned in GCC 15, we will remove avx10.1-256/512 in GCC 16.
Also, the combination of AVX10 and AVX512 option behavior will also be
simplified in GCC 16 since AVX10.1 now implied AVX512, making the
behavior matching everyone else.
gcc/ChangeLog:
* common/config/i386/cpuinfo.h
There are several iterators no longer needed in md files since
after refactor in AVX10, they could directly use legacy AVX512
ones. Remove those duplicate iterators.
gcc/ChangeLog:
* config/i386/sse.md (VF1_VF2_AVX10_2): Removed.
(VF2_AVX10_2): Ditto.
(VI1248_AVX10_2): Dit
Hi all,
This is the v2 patch to remove -mavx10.1/256-512 and -mno-evex512. I suppose
this time all the patches will not be held due to size.
As mentioned in GCC 15, we will remove -mavx10.1-256/512 and -mno-evex512
options in GCC 16. Also we will do some clean up in code for all the size
happenin
Am 14.05.25 um 08:42 schrieb FX Coudert:
[…] more trigonometric
functions changes are coming, I think it would be useful to agree
that this is a good approach.
Patch is OK to push.
Thanks for the review.
However, I messed up with 'git add' at some point and committed now a
version that didn't
Insn tf_to_fprx2 moves a TF value into a floating-point register pair.
For alternative 0, the input is a vector register, however, in the else
case instruction ldr is emitted which expects floating-point register
operands only. Thus, this works only for vector registers which overlap
with floating
On 14/05/25 10:01 +0200, Tomasz Kamiński wrote:
This commits adjust the way how the arguments are stored in the _Arg_value
(and thus basic_format_args), by preserving the types of fixed width
floating-point types, that were previously converted to float, double,
long double.
The _Arg_value union
On 14/05/25 10:48 +0200, Tomasz Kamiński wrote:
Based on the provision in C++26 [func.wrap.general] p2 this patch adjust the
generic
move_only_function(_Fn&&) constructor, such that when _Fn refers to selected
move_only_function instantiations, the ownership of the target object is
direclty
s
On Tue, May 13, 2025 at 7:23 PM Andrew Pinski wrote:
>
> When moving the optimize_memcpy_to_memset optimization to forwprop from
> fold_stmt, the marking
> of the bb to purge for eh cleanup was not happening for the local
> optimizations but only after
> the fold_stmt, this causes g++.dg/torture
Bootstrapped and regtested (just modules.exp and dg.exp=lambda*) on
x86_64-pc-linux-gnu, OK for 14 if full regtest succeeds?
-- >8 --
r14-9232-g3685fae23bb008 broke the ABI for lambdas in base classes,
causing ICEs when different lambdas got given the same mangled name.
This patch reverts the pa
Hi Kito,
On Mon, May 12, 2025 at 10:17:36PM +0800, Kito Cheng wrote:
> Leverage the centralized riscv-ext.def definitions to auto-generate
> the target option parsing and associated internal flags, replacing
> manual listings in riscv.opt; `riscv_ext_flag_table` part will remove in
> later patch.
On 14/05/25 10:48 +0200, Tomasz Kamiński wrote:
The file now includes copyable_function in addition to
move_only_function.
PR libstdc++/119125
libstdc++-v3/ChangeLog:
* include/bits/move_only_function.h: Move to...
* include/bits/funcwrap.h: ...here.
* doc/doxyge
On Tue, May 13, 2025 at 11:16 PM Patrick Palka wrote:
> On Mon, 12 May 2025, Tomasz Kamiński wrote:
>
> > Based on the provision in C++26 [func.wrap.general] p2 this patch adjust
> the generic
> > move_only_function(_Fn&&) constructor, such that when _Fn refers to
> selected
> > move_only_functio
Patrick noticed that this PR's testcase has been fixed by the patch for
PR c++/114292 (r15-7238-gceabea405ffdc8), more specifically the part
that walks the type of DECL_EXPR DECLs.
This simply adds the case to the testsuite.
Successfully tested on x86_64-pc-linux-gnu.
PR c++/120126
gcc/
On Tue, May 13, 2025 at 12:40:30PM -0400, Jason Merrill wrote:
> On 5/9/25 11:48 AM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
> >
> > One slight concern I have is why we end up in 'maybe_thunk_body' to
> > start with: the imported constructor i
On 5/14/25 6:54 AM, Nathaniel Shead wrote:
Bootstrapped and regtested (just modules.exp and dg.exp=lambda*) on
x86_64-pc-linux-gnu, OK for 14 if full regtest succeeds?
OK.
-- >8 --
r14-9232-g3685fae23bb008 broke the ABI for lambdas in base classes,
causing ICEs when different lambdas got giv
Since floating point and vector registers overlap on s390, more
efficient code can be generated to extract FPRs from VRs.
Additionally, for double vectors, more efficient code can be generated
to load specific lanes.
gcc/ChangeLog:
* config/s390/vector.md (VF): New mode iterator.
Hi, David,
Thanks a lot for the info.
> On May 14, 2025, at 09:50, David Malcolm wrote:
>
> On Mon, 2025-04-07 at 15:04 +, Qing Zhao wrote:
>
> [...snip...]
>
>> diff --git a/gcc/move-history-rich-location.cc b/gcc/move-history-
>> rich-location.cc
>> new file mode 100644
>> index 000
On 5/14/25 9:32 AM, Ville Voutilainen wrote:
On Wed, 14 May 2025 at 16:30, Ville Voutilainen
wrote:
On Wed, 14 May 2025 at 16:26, Patrick Palka wrote:
r = CALL_EXPR_ARG (x, 0);
/* Check that the return and argument types are sane before
folding. */
This
gcc/ChangeLog:
* config/riscv/t-riscv: Drop duplicate build rule for
riscv-ext.opt.
---
gcc/config/riscv/t-riscv | 2 --
1 file changed, 2 deletions(-)
diff --git a/gcc/config/riscv/t-riscv b/gcc/config/riscv/t-riscv
index e99d6689ba0..854daa96e73 100644
--- a/gcc/config/riscv/t-
As sugguested in
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681507.html,
this adds the aliasing walk limit.
gcc/ChangeLog:
* tree-ssa-forwprop.cc (optimize_memcpy_to_memset): Add a limit on the
alias walk.
Signed-off-by: Andrew Pinski
---
gcc/tree-ssa-forwprop.cc | 4 +++-
1 - 100 of 151 matches
Mail list logo
