On Tue, Mar 4, 2025 at 9:49 AM Richard Sandiford
wrote:
>
> Wilco Dijkstra writes:
> > Hi Richard&Kyrill,
> >
> >>> I’m in favour of this.
> >>
> >> Yeah, seems ok to me too. I suppose we ought to update the documentation
> >> too:
> >
> > I've added a note to the documentation. However it is i
Wilco Dijkstra writes:
> Hi Richard&Kyrill,
>
>>> I’m in favour of this.
>>
>> Yeah, seems ok to me too. I suppose we ought to update the documentation
>> too:
>
> I've added a note to the documentation. However it is impossible to be
> complete here
> since many targets switch off early schedu
On 3/4/25 9:51 AM, Patrick Palka wrote:
On Sun, 2 Mar 2025, Da Xie wrote:
Add check for constrained auto type specifier in function declaration or
function type declaration with trailing return type. Issue error if such
usage is detected.
Test file renamed, and added a new test for type declar
On 3/4/25 2:49 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
In the three-parameter version of satisfy_declaration_constraints, when
't' isn't the most general template, then 't' won't correspond with
'args' after we augment
Hi Andre,
while the patch looks ok to me, why did you not choose to generate a "22.7.2
Variable-Length Parameter Lists"
https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Variable-Number-of-Arguments.html
when the arguments differ? Then its the callee responsibility to figure
stuff
On Tue, Mar 4, 2025 at 2:12 AM Richard Biener wrote:
> As PR119098 shows the gccgo driver uses the install path compiled
> into the shared libgo and thus updating that but not the driver
> will cause the driver to fail to find other tools like cgo.
>
> Thus bump the SONAME for GCC 15 as well, as
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
In the three-parameter version of satisfy_declaration_constraints, when
't' isn't the most general template, then 't' won't correspond with
'args' after we augment the latter via add_outermost_template_arg
Hi Ramana,
> -Generate code for the large code model. This makes no assumptions about
> -addresses and sizes of sections. Programs can be statically linked only.
> The
> +Generate code for the large code model. This allows large .bss and .data
> +sections, however .text and .rodata must still
On Tue, Mar 4, 2025 at 6:31 PM Richard Biener
wrote:
>
> On Tue, Mar 4, 2025 at 11:18 AM Richard Sandiford
> wrote:
> >
> > Richard Sandiford writes:
> > > Jan Hubicka writes:
> > >>>
> > >>> Thanks for running these. I saw poor results for perlbench with my
> > >>> initial aarch64 hooks becau
LGTM!
Thanks.
在 2025/3/3 下午3:29, Xi Ruoyao 写道:
They could be incorrectly reordered with store instructions like st.b
because the RTL expression does not have a memory_operand or a (mem)
expression. The incorrect reorder has been observed in openh264 LTO
build.
Expand them to a (mem) expressio
On Wed, 2025-03-05 at 10:52 +0800, Lulu Cheng wrote:
> LGTM!
Pushed to trunk. The draft of gcc-14 backport is attached, I'll push it
if it builds & tests fine and there's no objection.
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
From 6e4ca8b9c4944ffe896f4d8952f2
在 2025/3/5 上午11:03, Xi Ruoyao 写道:
On Wed, 2025-03-05 at 10:52 +0800, Lulu Cheng wrote:
LGTM!
Pushed to trunk. The draft of gcc-14 backport is attached, I'll push it
if it builds & tests fine and there's no objection.
Thanks a lot.
> On 3 Mar 2025, at 19:52, Wilco Dijkstra wrote:
>
>
> Outline atomics is not designed to be used with -mcmodel=large, so disable
> it automatically if the large code model is used.
>
> Passes regress, OK for commit?
>
This restriction should be documented in invoke.texi IMO.
I also think i
Hi Steve,
thanks for the review. Committed as gcc-15-7804-g5bd66483839.
Thanks again,
Andre
On Mon, 3 Mar 2025 12:34:49 -0800
Steve Kargl wrote:
> On Mon, Mar 03, 2025 at 03:58:24PM +0100, Andre Vehreschild wrote:
> >
> > attached patches fix a 12-regression, when a caf token is reques
Hi all,
attached patch fixes a 12-regression when an assignment to a pointer array is
done. The issue was a missing indirect ref on assign as it was already done for
allocatable arrays.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email
Hi Andre,
You beat me to it! I had just noticed the missing indirect reference. Yes,
this is good for mainline and backporting to 14-branch at very least.
Thanks for the patch. If you want to do the push to mainline, I will do the
backporting if you like? I'll not be back at base for a little whi
Hi Thomas,
Am 03.03.25 um 22:50 schrieb Thomas Koenig:
Hello world,
this patch is a bit more complicated than originally envisioned.
The problem was that we were not handling external dummy arguments
with -fc-prototypes-external. In looking at this, I found that we
were not warning about exter
Hi,
Zen5 on some variants has false dependency on tzcnt, blsi, blsr and blsmsk
instructions. Those can be tested by the following benchmark
jh@shroud:~> cat ee.c
int
main()
{
int a = 10;
int b = 0;
for (int i = 0; i < 10; i++)
{
#ifdef BREAK
asm
Hi GCC team,
This patch introduces inline definitions for the __fma and __fmaf
functions in the ARM ACLE headers for both aarch64 and arm targets. The
new implementations use the built-in functions (__builtin_fma and
__builtin_fmaf) to ensure proper inlining and adherence to the ARM ACLE
requireme
Oscar Gustafsson writes:
> ChangeLog:
>
> * doc/extend.texi: Improve example for __builtin_swap16.
>
> ---
>
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index ec9bb59900c..83f6e45170b 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -16338,7 +16338,7 @@ Return
Richard Biener writes:
> On Tue, 4 Mar 2025, Tamar Christina wrote:
>
>> Hi All,
>>
>> This fixes two PRs on Early break vectorization by delaying the safety
>> checks to
>> vectorizable_load when the VF, VMAT and vectype are all known.
>>
>> This patch does add two new restrictions:
>>
>> 1.
On 04/03/2025 14:49, Torbjorn SVENSSON wrote:
>
>
> On 2025-03-03 18:00, Richard Earnshaw wrote:
>> On 28/02/2025 16:18, Richard Earnshaw wrote:
>>> On 28/02/2025 16:12, Richard Earnshaw wrote:
On 08/11/2024 18:47, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
>
Richard Biener writes:
> When vectorizing a shift of u16 data by an amount that's known to
> be less than 16 we currently fail to emit a vector u16 shift. The
> first reason is that the promotion of the shift amount is hoisted
> only by PRE and that cannot preserve range info, the second reason
>
For strict-alignment targets we can end up with BLKmode single-element
array types when the element type is unaligned. This confuses
type checking since the canonical type would have an aligned
element type and a non-BLKmode mode. The following simply ignores
the mode we assign to array types for
Hi Paul,
thanks for the review. Committed as gcc-15-7812-g04909c7ecc0.
Yes please: you do the backport. Thank you very much.
I am looking at pr104684 at the moment, which is the last regression on my list
(i.e. that I am assigned or cc'ed to). When the regression test for this is
fine, I will co
On Fri, 28 Feb 2025, Giuseppe D'Angelo wrote:
> Hello,
>
> On 27/02/2025 15:34, Jonathan Wakely wrote:
> > On 26/02/25 17:27 +0100, Giuseppe D'Angelo wrote:
> > > On 26/02/2025 16:33, Giuseppe D'Angelo wrote:
> > > > Whops, sorry, missed this sub-thread (while replying to the other one).
> > > >
Yeah I didn't know how to articulate it (and perhaps this still requires
clarification)
Say we have following
// reduced version of gcc.target/riscv/rvv/base/float-point-frm-run-1.c
main
set_frm (4); // orig global FRM update
test_float_point_frm_run_1 (op1, op2, vl)
set_fr
On Tue, 4 Mar 2025, Tamar Christina wrote:
> Hi All,
>
> This fixes two PRs on Early break vectorization by delaying the safety checks
> to
> vectorizable_load when the VF, VMAT and vectype are all known.
>
> This patch does add two new restrictions:
>
> 1. On LOAD_LANES targets, where the buf
When vectorizing a shift of u16 data by an amount that's known to
be less than 16 we currently fail to emit a vector u16 shift. The
first reason is that the promotion of the shift amount is hoisted
only by PRE and that cannot preserve range info, the second reason
is that pattern detection doesn't
Hi all,
attached patch fixes a gimplification fault when a pointer assignment to an
allocatable array is done. The tree type is different, because of that flag in
the lang_specific structure. View-converting the type fixes the issue.
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Reg
On 2025-03-04 16:44, Richard Earnshaw (lists) wrote:
On 04/03/2025 14:49, Torbjorn SVENSSON wrote:
On 2025-03-03 18:00, Richard Earnshaw wrote:
On 28/02/2025 16:18, Richard Earnshaw wrote:
On 28/02/2025 16:12, Richard Earnshaw wrote:
On 08/11/2024 18:47, Torbjörn SVENSSON wrote:
Ok for
On Tue, 4 Mar 2025 00:08:16 +0100
Jakub Jelinek wrote:
> On Mon, Mar 03, 2025 at 05:21:38PM -0500, James K. Lowden wrote:
> > However IMO, the incantation:
> >
> > make install DESTDIR=/foo
> >
> > is invalid. The compiler's library search path is fixed when the
> > compiler is built, base
Hi Kyrill,
> This restriction should be documented in invoke.texi IMO.
> I also think it would be more user friendly to warn them about the
> incompatibility if an explicit -moutline-atomics option is passed.
> It’s okay though to silently turn off the implicit default-on option though.
I've upd
On Tue, Mar 4, 2025 at 11:47 PM Wilco Dijkstra wrote:
>
> Hi Kyrill,
>
> > This restriction should be documented in invoke.texi IMO.
> > I also think it would be more user friendly to warn them about the
> > incompatibility if an explicit -moutline-atomics option is passed.
> > It’s okay though t
Hi Andre,
Am 04.03.25 um 17:11 schrieb Andre Vehreschild:
Hi all,
attached patch fixes a gimplification fault when a pointer assignment to an
allocatable array is done. The tree type is different, because of that flag in
the lang_specific structure. View-converting the type fixes the issue.
Re
On 3/4/25 3:26 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR complains that we issue a -Wnonnull even in a decltype.
Since we can't use cp_unevaluated_operand in c-common.cc, this
Would it make sense to check c_inhibit_evaluation_warning
On 2/11/25 6:24 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we ICE since r11-7740 because we no longer say that (long)&a
(where a is a global var) is non_constant_p. So VERIFY_CONSTANT
does not return and we crash on tree_to_uhwi. We shou
On 2/24/25 1:55 PM, David Faust wrote:
On 2/24/25 11:04, Indu Bhagat wrote:
On 2/6/25 11:54 AM, David Faust wrote:
Translate DW_TAG_GNU_annotation DIEs created for C attributes
btf_decl_tag and btf_type_tag into an in-memory representation in the
CTF/BTF container. They will be output in B
Ping.
On Tue, Feb 11, 2025 at 06:24:32PM -0500, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> Here we ICE since r11-7740 because we no longer say that (long)&a
> (where a is a global var) is non_constant_p. So VERIFY_CONSTANT
> does not return
On Sun, 2 Mar 2025, xxie-xd wrote:
> * Patrick Palka [2025-02-28 10:37:37]:
>
> > Hi,
> >
> > On Fri, 28 Feb 2025, Da Xie wrote:
> >
> > > This bug comes from a missing check when a function declaration has a
> > > late-specified return type and a constrained auto type specifier. By
> > > addi
On 2025-03-03 18:00, Richard Earnshaw wrote:
On 28/02/2025 16:18, Richard Earnshaw wrote:
On 28/02/2025 16:12, Richard Earnshaw wrote:
On 08/11/2024 18:47, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
A long time ago, this test forced -march=armv6.
With -marm, the genera
On Sun, 2 Mar 2025, Da Xie wrote:
> Add check for constrained auto type specifier in function declaration or
> function type declaration with trailing return type. Issue error if such
> usage is detected.
>
> Test file renamed, and added a new test for type declaration.
>
> Successfully bootstra
Agree with Robin and Andrew.
I was thinking we may not need to take care of vxrm similar as frm in previous,
but seems
not that simple up to a point after Richard S points it out.
I also failed to locate some spec/doc about the details. I remember Jeff has
some findings/comments,
and may wait f
On 2025-02-28 16:06, Richard Earnshaw wrote:
On 08/11/2024 17:44, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr68674.c: Use effective-target arm_arch_v7a
and arm_libc_fp_abi.
Signed-off-by: Torbjörn SVENSSON
---
gcc/t
Kyrylo Tkachov writes:
> Hi all,
>
> In this testcase late-combine was failing to merge:
> dup v31.4s, v31.s[3]
> fmla v30.4s, v31.4s, v29.4s
> into the lane-wise fmla form.
> This is because late-combine checks may_trap_p under the hood on the dup insn.
> This ended up returning true for the insn
Hi Richard&Kyrill,
>> I’m in favour of this.
>
> Yeah, seems ok to me too. I suppose we ought to update the documentation too:
I've added a note to the documentation. However it is impossible to be complete
here
since many targets switch off early scheduling under various circumstances. So
I'v
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
This PR complains that we issue a -Wnonnull even in a decltype.
Since we can't use cp_unevaluated_operand in c-common.cc, this
fix targets even -Wformat and -Wrestrict. I think that's fine.
PR c++/115580
gcc/cp/Change
Hi all,
For bf8 -> pf16 convert, when dst is 256 bit, the mask should be
16 bit since 16*16=256, not the 8 bit in the current intrin. In
512 bit intrin, the mask bit is also halved. This patch will fix
both of them.
Ok for trunk?
Thx,
Haochen
gcc/ChangeLog:
* config/i386/avx10_2-512con
On 2/18/25 8:00 AM, Simon Martin wrote:
A checking assert triggers upon the following invalid code since
GCC 11:
=== cut here ===
class { a (struct b;
} struct b
=== cut here ===
The problem is that during error recovery, we call
set_identifier_type_value_with_scope for B in the global namespac
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here gimplification got confused because extend_temps_r messed up the types
of the arms of a COND_EXPR.
PR c++/119073
gcc/cp/ChangeLog:
* call.cc (extend_temps_r): Preserve types of COND_EXPR arms.
gcc/testsuite/ChangeLog
On 2/18/25 5:12 AM, Simon Martin wrote:
We've been rejecting this valid code since r8-4571:
=== cut here ===
void foo (float);
int main () {
constexpr float x = 0;
(void) [&] () {
foo (x);
(void) [] () {
foo (x);
};
};
}
=== cut here ===
The problem is that when p
On 2/11/25 1:04 PM, Jakub Jelinek wrote:
Hi!
The following testcase IMO in violation of the P2552R3 paper doesn't
pedwarn on alignas applying to dependent types or alignas with dependent
argument.
tsubst was just ignoring TYPE_ATTRIBUTES.
The following patch fixes it for the POINTER/REFERENCE_
On 2/14/25 12:08 PM, Simon Martin wrote:
We have been miscompiling the following valid code since GCC8, and
r8-3497-g281e6c1d8f1b4c
=== cut here ===
struct span {
span (const int (&__first)[1]) : _M_ptr (__first) {}
int operator[] (long __i) { return _M_ptr[__i]; }
const int *_M_ptr;
};
Hi!
modules.cc has apparently support for extensions and attempts to ensure
that if a module is compiled with those extensions enabled, sources which
use the module are compiled with the same extensions.
The only extension supported is SE_OPENMP right now.
And the use of the extension is keyed on
On Fri, 28 Feb 2025 12:48:36 +0100, "Robin Dapp" wrote:
> > Okay, let me explain the background of my previous patch.
> >
> > Prior to applying my patch, for the test case bug-10.c (a reduced example
> > of
> > a larger program with incorrect runtime results),
> > the vsetvli sequence compiled wi
Hi!
During the 118874 coro investigation I found a typo in a comment.
Fixed thusly, committed to trunk as obvious.
2025-03-05 Jakub Jelinek
* typeck.cc (check_return_expr): Fix comment typo, rom -> from.
--- gcc/cp/typeck.cc.jj 2025-02-25 09:26:38.761944513 +0100
+++ gcc/cp/typeck.c
There was an embarrassing typo in the folding of BIT_NOT_EXPR for
POLY_INT_CSTs: it used - rather than ~ on the poly_int. Not sure
how that happened, but it might have been due to the way that
~x is implemented as -1 - x internally.
Tested on aarch64-linux-gnu & powerpc64le-linux-gnu (as part
of
On Tue, Mar 04, 2025 at 09:26:07AM +, Richard Sandiford wrote:
> gcc/
> PR rtl-optimization/119002
> * simplify-rtx.cc
> (simplify_context::simplify_logical_relational_operation): Handle
> comparisons between CC values. If there is no evidence that the
> CC values
Richard Sandiford writes:
> Jakub Jelinek writes:
>> On Mon, Mar 03, 2025 at 01:46:20PM +, Richard Sandiford wrote:
>>> Jakub Jelinek writes:
>>> > On Mon, Mar 03, 2025 at 01:02:07PM +, Richard Sandiford wrote:
>>> >> ...how about something like this? Completely untested, and I haven't
Hi!
Uros' r15-7793 fixed this PR as well, I'm just committing tests
from the PR so that it can be closed.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk
as obvious.
2025-03-04 Jakub Jelinek
PR rtl-optimization/119071
* gcc.dg/pr119071.c: New test.
Hi!
On 2025-03-03T17:30:06+0100, I wrote:
> On 2002-04-17T21:37:50-0400, Phil Edwards wrote:
>> If the user decides to build the library with extra compiler options
>> via --enable-cxx-flags, the testsuite should (by default) use those same
>> options when running.
>
> Hmm, are we sure that's wha
Commit r9-4307-g89d7557202d25a forgot to accept a fixed PIC register
when extending the assert in require_pic_register.
arm_pic_register can be set explicitly by the user
(e.g. -mpic-register=r9) or implicitly as the default value with
-fpic/-fPIC/-fPIE and -mno-pic-data-is-text-relative -mlong-ca
libstdc++-v3/ChangeLog:
* doc/xml/manual/test.xml: Remove stray comma.
* doc/html/manual/test.html: Regenerate.
---
Pushed to trunk.
libstdc++-v3/doc/html/manual/test.html | 2 +-
libstdc++-v3/doc/xml/manual/test.xml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
di
Wilco Dijkstra writes:
> Feedback from the kernel team suggests that it's best to only use HWCAPs
> rather than also use low-level checks as done by has_lse128() and has_rcpc3().
> So change these to just use HWCAPs which simplifies the code and speeds up
> ifunc selection by avoiding expensive sy
Hi!
On Fri, Nov 22, 2024 at 07:25:23PM -0500, Andrew MacLeod wrote:
> I will shortly be submitting , and presumable committing, this patch as
> part of a series to improve VRP time for 117467..
>
> So it may be in place by the time you need it
> On 11/18/24 09:31, Andrew MacLeod wrote:
> > Atta
Kyrylo Tkachov writes:
>> On 3 Mar 2025, at 19:58, Wilco Dijkstra wrote:
>>
>>
>> Enable the early scheduler on AArch64 for O3/Ofast. This means GCC15
>> benefits
>> from much faster build times with -O2, but avoids the regressions in lbm
>> which
>> is very sensitive to minor scheduling cha
> On 3 Mar 2025, at 19:58, Wilco Dijkstra wrote:
>
>
> Enable the early scheduler on AArch64 for O3/Ofast. This means GCC15 benefits
> from much faster build times with -O2, but avoids the regressions in lbm which
> is very sensitive to minor scheduling changes due to long FMA chains. We can
On Tue, Mar 4, 2025 at 11:18 AM Richard Sandiford
wrote:
>
> Richard Sandiford writes:
> > Jan Hubicka writes:
> >>>
> >>> Thanks for running these. I saw poor results for perlbench with my
> >>> initial aarch64 hooks because the hooks reduced the cost to zero for
> >>> the entry case:
> >>>
>
As PR119098 shows the gccgo driver uses the install path compiled
into the shared libgo and thus updating that but not the driver
will cause the driver to fail to find other tools like cgo.
Thus bump the SONAME for GCC 15 as well, as we've done for each
release in the past.
I think libgo changes
Richard Sandiford writes:
> Jan Hubicka writes:
>>>
>>> Thanks for running these. I saw poor results for perlbench with my
>>> initial aarch64 hooks because the hooks reduced the cost to zero for
>>> the entry case:
>>>
>>> auto entry_cost = targetm.callee_save_cost
>>> (spil
Hi!
The following testcases (one with #embed, one with large initializer
turned into RAW_DATA_CST) show that I forgot to handle RAW_DATA_CST in
module streaming.
Similar to the PCH case we need to stream out RAW_DATA_CST with NULL
RAW_DATA_OWNER (i.e. a tree which has data owned by libcpp buffer)
Hi Thomas,
while the patch looks ok to me, why did you not choose to generate a "22.7.2
Variable-Length Parameter Lists"
https://www.gnu.org/software/c-intro-and-ref/manual/html_node/Variable-Number-of-Arguments.html
when the arguments differ? Then its the callee responsibility to figure
stuff o
Let's see if I get this correct... Apologies in advance if not.
While browsing the intrinsic/built-in functions documentation, I had to
think a bit extra to see what the function did as the example was ambiguous.
Searching for the place to change it, I also realized that the tests were
not ideal
ChangeLog:
* doc/extend.texi: Improve example for __builtin_swap16.
---
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index ec9bb59900c..83f6e45170b 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -16338,7 +16338,7 @@ Returns the first argument raised to the power of
t
gcc/testsuite/ChangeLog
* gcc.dg/builtin-bswap-5.c: improve test vector to avoid nibble swaps
passing
---
diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-5.c
b/gcc/testsuite/gcc.dg/builtin-bswap-5.c
index b29931e4e10..2ba6c31194f 100644
--- a/gcc/testsuite/gcc.dg/builtin-bswap-5.c
+++ b/gcc/
75 matches
Mail list logo
