> 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
On Mon, 12 May 2025, Richard Sandiford wrote:
> Richard Biener writes:
> > The following moves vector lowering to before vectorization - in fact
> > to before DCE/forwprop and CSE. This gets us the chance to re-vectorize
> > the lowered form eventually. Note that when the vectorizer learns to
>
On Tue, 13 May 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, May 13, 2025 12:44 PM
> > To: Eric Botcazou
> > Cc: Tamar Christina ; gcc-patches@gcc.gnu.org; nd
> >
> > Subject: Re: [PATCH 1/4]middle-end: document pragma unroll n
> > [PR1
On Wed, 14 May 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, May 13, 2025 12:08 PM
> > To: Richard Sandiford
> > Cc: gcc-patches@gcc.gnu.org; Tamar Christina
> > Subject: Re: [PATCH][RFC] Add vector_costs::add_vector_cost vector stmt
> >
On Wed, 14 May 2025, Richard Sandiford wrote:
> 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 vec
On Wed, May 14, 2025 at 9:34 PM Andrew Pinski wrote:
>
> This is the followup based on the review at
> https://inbox.sourceware.org/gcc-patches/cafiyyc3xeg75dswaf63zbu5uelpeaeohwgfogavydwouuj7...@mail.gmail.com/
> .
> We should put ADDR_EXPR last instead of just is_gimple_invariant_address ones.
>
101 - 151 of 151 matches
Mail list logo
