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 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 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 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.
>
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
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
> -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
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
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
> -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 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, 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
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_
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
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 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
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 addresses the clarification that, when the get_return_object is of a
different type from the ramp return, any necessary conversions should be
performed on the return expression (so that they typically occur after the
function body has started execution
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
https://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-15.1.0.sv.po', has ju
On Wed, May 14, 2025 at 09:31:59PM +0100, Jonathan Wakely wrote:
> The timeline hasn't shown any tentative dates for future releases since
> 2006-03-06 when GCC 3.4.6 was released and the tentative date got
> replaced with the real date. Since then only actual release dates have
> been added, on th
On Wed, 14 May 2025, Patrick Palka wrote:
> On Wed, 14 May 2025, Jason Merrill wrote:
>
> > On 5/14/25 2:44 PM, Patrick Palka wrote:
> > > 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:
On Wed, 14 May 2025, Jason Merrill wrote:
> On 5/14/25 2:44 PM, Patrick Palka wrote:
> > 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-gn
Use __builtin_signbit directly instead of std::signbit.
libstdc++-v3/ChangeLog:
* include/std/complex (arg(T)): Use __builtin_signbit instead of
std::signbit.
---
This would avoid overload resolution for std::signbit, and avoid a
function call for -O0, but I'm not sure it's worth
On Mon, 12 May 2025 at 21:30, Jonathan Wakely wrote:
>
> On Mon, 12 May 2025 at 16:13, Jason Merrill wrote:
> >
> > On 5/9/25 1:31 PM, Jonathan Wakely wrote:
> > > On Fri, 9 May 2025 at 18:13, Jonathan Wakely wrote:
> > >>
> > >> On Fri, 9 May 2025 at 11:19, Jonathan Wakely wrote:
> > >>>
> > >
There was an overload of fabs for std::complex in TR1 and in some C++0x
drafts, but it was removed from the working draft by LWG 595.
Since we've been providing it for decades we should deprecate it before
removing it.
libstdc++-v3/ChangeLog:
PR libstdc++/120235
* doc/html/*: Reg
The timeline hasn't shown any tentative dates for future releases since
2006-03-06 when GCC 3.4.6 was released and the tentative date got
replaced with the real date. Since then only actual release dates have
been added, on the day when the release happens.
---
OK for wwwdocs?
htdocs/develop.htm
On Wed, 14 May 2025, Yuao Ma wrote:
> 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?
This version is OK in t
On 5/14/25 2:44 PM, Patrick Palka wrote:
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::t
The testcase was found when looking at mapping fails with
SPEC HPC's 619.clvleaf_s; however, the variant fixed by the
attached patch only showed up when experimenting and not
in the SPEC testcase itself.
Before the included fix, to be added testcase failed with
an ICE.
I intent to commit the atta
On Wed, 14 May 2025 at 20:50, Iain Sandoe wrote:
>
>
>
> > On 14 May 2025, at 18:42, Rainer Orth wrote:
> >
> > 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)
On 5/14/25 2:10 PM, Iain Sandoe wrote:
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 initi
> On 14 May 2025, at 18:42, Rainer Orth wrote:
>
> 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
On Mon, May 12, 2025 at 3:53 AM Richard Biener
wrote:
>
> On Fri, May 9, 2025 at 10:12 PM Andrew Pinski wrote:
> >
> > On Mon, Apr 21, 2025 at 1:42 AM Richard Biener
> > wrote:
> > >
> > > On Thu, Apr 17, 2025 at 7:37 PM Andrew Pinski
> > > wrote:
> > > >
> > > > So unlike constants, address i
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.
Note a few match patterns needed to be updated for this change b
To make review easier, I'd like to provide links to the
sections in the standard I used.
mandate: https://eel.is/c++draft/mdspan.extents#overview-1.1
signed integer: https://eel.is/c++draft/basic.fundamental#1
unsigned integer: https://eel.is/c++draft/basic.fundamental#2
integral: https://eel.i
The standard states that the IndexType must be a signed or unsigned
integer. This mandate was implemented using `std::is_integral_v`. Which
also includes (among others) char and bool, which neither signed nor
unsigned integers.
libstdc++-v3/ChangeLog:
* include/std/mdspan: Implement the m
cpplib-15.1-b20250316.es.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Spanish team of translators. The file is available at:
https://translationproject.org/latest/cpplib/es.po
(This file, 'cpplib-15.1-b202503
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
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
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, 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
Hi Paul,
Same remark as for PR120107! LGTM for both branches.
Committed both patches. Thanks for the reviews!
Best regards
Thomas
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
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
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.
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
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 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 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.
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,
Joseph Myers writes:
> On Wed, 14 May 2025, Sam James wrote:
>
>> > (cherry picked from commit 3d525fce70fa0ffa0b22af6e213643e1ceca5ab5)
>> > ---
>> > As discussed on the PR, I feel like this is worth having for 14 as we're
>> > asking upstreams to try reproduce issues w/ -std=gnu23 (or -std=c23)
Kugan Vivekanandarajah writes:
> Adding Eugene and Andi to CC as Sam suggested.
>
>> On 13 May 2025, at 12:57 am, Richard Sandiford
>> wrote:
>>
>> External email: Use caution opening links or attachments
>>
>>
>> Kugan Vivekanandarajah writes:
>>> diff --git a/configure.ac b/configure.ac
>>> i
On Wed, May 14, 2025 at 6:29 PM James K. Lowden
wrote:
>
> On Wed, 14 May 2025 11:04:50 +0200
> Rainer Orth wrote:
>
> > Work around what appears to be a GNU make bug handling MAKEFLAGS
>
> Before I say Yes, could someone please tell me why this rumored bug is
> responsible for so much boilerplat
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've
> >> completed it for t
On Wed, 14 May 2025, Sam James wrote:
> > (cherry picked from commit 3d525fce70fa0ffa0b22af6e213643e1ceca5ab5)
> > ---
> > As discussed on the PR, I feel like this is worth having for 14 as we're
> > asking upstreams to try reproduce issues w/ -std=gnu23 (or -std=c23) if
> > they don't have access
On 07/05/2025 13:00, Kyrylo Tkachov wrote:
Hi Karl,
On 7 May 2025, at 12:27, Karl Meakin wrote:
This patch series adds support for the CMPBR extension. It includes the
new `+cmpbr` option and rules to generate the new instructions when
lowering conditional branches.
Thanks for the series.
On 07/05/2025 12:48, Kyrylo Tkachov wrote:
On 7 May 2025, at 12:27, Karl Meakin wrote:
Add the `+cmpbr` option to enable the FEAT_CMPBR architectural
extension.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def (cmpbr): new
option.
* config/aarch64/aarch64.h (TARGET_CMPBR): ne
On Wed, 14 May 2025, Yuao Ma wrote:
> 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 implementati
On 5/13/25 11:06 AM, Iain Sandoe wrote:
This could not be done as a cherry-pick from the trunk resolution.
Tested on x86_64-darwin, powerpc64le linux sparc9 solaris,
OK for 14.3 ?
thanks
Iain
--- 8< ---
This is a GCC-14 version of the same strategy as used on trunk, but
with the more wide-rangi
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've
completed it for the _Safe_unordered_container_base type and
implemented the rest of the change to
[I intent to commit this patch later today or probably tomorrow,
unless there are comments, questions or concerns.]
The issue showed up for SPEC HPC's 634.hpgmgfv_s benchmark, but only when
running with multiple MPI processes. The reason is that in that case, the
work is distributed over multiple
On Wed, 14 May 2025 11:04:50 +0200
Rainer Orth wrote:
> Work around what appears to be a GNU make bug handling MAKEFLAGS
Before I say Yes, could someone please tell me why this rumored bug is
responsible for so much boilerplate in our Makefile.am files? You
say,
> Unlike some runtime libs tha
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 runtime enviroment[2] to calculate a location for the variable for
> each thre
On Mon, 12 May 2025 14:05:50 +0200
Rainer Orth wrote:
> Before going further, I'd first like to understand why you chose to
> use syslog in a runtime lib. While logging to syslog is certainly
> useful in daemons and such, a runtime lib is different IMO: while
> regular users can log to syslog, a
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
pushed :)
On Wed, May 14, 2025 at 9:18 PM Christoph Müllner <
christoph.muell...@vrull.eu> wrote:
> 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
Sam James writes:
> From: Joseph Myers
>
> As reported in bug 112556, GCC wrongly rejects conversion of null
> pointer constants with bool or enum type to pointers in
> convert_for_assignment (assignment, initialization, argument passing,
> return). Fix the code there to allow BOOLEAN_TYPE and
Pushed, thanks :)
On Tue, May 13, 2025 at 3:25 PM Jiawei wrote:
>
> The augmented hypervisor series extensions 'sha'[1] is a new profile-defined
> extension series that captures the full set of features that are mandated to
> be supported along with the 'H' extension.
>
> [1]
> https://github.c
gcc/ChangeLog:
* config/riscv/riscv-ext.opt.urls: Regenerate.
---
gcc/config/riscv/riscv-ext.opt.urls | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/config/riscv/riscv-ext.opt.urls
b/gcc/config/riscv/riscv-ext.opt.urls
index e69de29bb2d..c4f471079df 100644
--- a/gcc/config/ris
Hi Mark:
Thanks for your reminder, I got a few mails from buildbot, but didn't
figure out how to regen that correctly yesterday, and I finally found
the right way to regen...(Yeah, I was add an empty manually to make it
buildable since it actually not introduce new command line option)
https://gc
From: Dhruv Chawla
This patch modifies the intrinsic expanders to expand svlsl and svlsr to
unpredicated forms when the predicate is a ptrue. It also folds the
following pattern:
lsl , ,
lsr , ,
orr , ,
to:
revb/h/w ,
when the shift amount is equal to half the bitwidth of the
reg
On 06/05/25 21:57, Richard Sandiford wrote:
External email: Use caution opening links or attachments
Dhruv Chawla writes:
This patch modifies the intrinsic expanders to expand svlsl and svlsr to
unpredicated forms when the predicate is a ptrue. It also folds the
following pattern:
lsl , ,
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-
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
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/14/25 3:43 AM, Simon Martin wrote:
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.
OK.
Successfully tested on
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
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 vect_get_{load,store}_cost API is used from both vectorizable_*
where we've done SLP analysis and from alignment peeling analysis
with is done before this and thus only stmt_vec_infos are available.
The following patch makes sure we pick the vector type relevant
for costing from the SLP node wh
Since this optimization now walks the vops, it is better to only
do it in forwprop rather than in all the time in fold_stmt.
The next patch will add the limit to the alias walk.
gcc/ChangeLog:
* gimple-fold.cc (optimize_memcpy_to_memset): Move to
tree-ssa-forwprop.cc.
(gi
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 +++-
The following changes the record_stmt_cost calls in
vectorizable_load/store to only pass the SLP node when costing
vector stmts. For now we'll still pass the stmt_vec_info,
determined from SLP_TREE_REPRESENTATIVE, so this merely cleans up
the API.
v2 does away with the idea to use stmt_info and n
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
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
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
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.
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
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
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
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 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
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
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
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
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
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
1 - 100 of 151 matches
Mail list logo
