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
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 +++-
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
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 , ,
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
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
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
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
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
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)
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 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)
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 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
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
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 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
[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, 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 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 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
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 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
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
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
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
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 :)
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
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
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
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
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
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 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:
> > >>>
> > >
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 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
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
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 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
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, 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 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, 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
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
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
> 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 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
1 - 100 of 151 matches
Mail list logo
