> Is that done automatically or do you need to write an explicit
> disable_interrupts()
> before you use FP/SIMD operations?
I want to thank you for introducing some much needed clarity on this
topic.
We held an informal chat amongst a few Zephyr toolchain developers on
this topic, and I think
On Thu, Aug 07, 2025 at 10:02:33PM +0100, Paul Richard Thomas wrote:
> Hi Jerry et al.,
>
> I attached an earlier version of the patch - apologies!
>
> Please find the latest attached.
>
Thanks for taking my comments into account. The
patch passes regression testing on amf64-*-freebsd.
The on
On 08/08/2025 15:59, Andre Vieira (lists) wrote:
Fix the bound checking for the opc1 operand of the following intrinsics:
__arm_mcrr
__arm_mcrr2
__arm_mrrc
__arm_mrrc2
Built arm-none-linux-gnueabihf and ran full regression test, and built
arm-none-eabi but only ran the changed tests
writes:
> From: Alfie Richards
>
> Adds an optimisation in FMV to redirect to a specific target if possible.
>
> A call is redirected to a specific target if both:
> - the caller can always call the callee version
> - and, it is possible to rule out all higher priority versions of the callee
>
On 20/05/2025 05:28, Alexandre Oliva wrote:
(The backport I've only just posted is not enough for the tests to pass;
there's another problem)
r14-10824 is a backport of r15-4549, that rewrote and extended into
check-function-bodies the save/restore expectations introduced in
r15-2160. Alas, r1
On 08/08/2025 16:56, Christophe Lyon wrote:
On Fri, 8 Aug 2025 at 16:51, Richard Earnshaw wrote:
On 26/05/2025 17:08, Christophe Lyon wrote:
This effective target implicitly expects -march=armv8-a, otherwise
with a toolchain configured for instance with
--with-cpu=cortex-m0 --with-float=soft,
On 08/08/2025 16:49, Christophe Lyon wrote:
On Fri, 8 Aug 2025 at 17:04, Richard Earnshaw wrote:
On 04/07/2025 23:00, Christophe Lyon wrote:
Like we do in other effective-targets, add
"-mcpu=unset -march=armv8-a"
directly when setting et_arm_v8_neon_flags in arm_v8_neon_ok_nocache,
to avoid h
On Fri, 8 Aug 2025 at 16:58, Richard Earnshaw wrote:
>
> On 04/07/2025 23:00, Christophe Lyon wrote:
> > A few arm effective-targets call check_effective_target_arm32 even
> > though they would force a -march=XXX flag which supports Arm and/or
> > Thumb-2, thus making the arm32 check useless. Thi
On Fri, 8 Aug 2025 at 16:51, Richard Earnshaw wrote:
>
> On 26/05/2025 17:08, Christophe Lyon wrote:
> > This effective target implicitly expects -march=armv8-a, otherwise
> > with a toolchain configured for instance with
> > --with-cpu=cortex-m0 --with-float=soft,
> > it fails even when trying
>
On Fri, 8 Aug 2025 at 17:04, Richard Earnshaw wrote:
>
> On 04/07/2025 23:00, Christophe Lyon wrote:
> > Like we do in other effective-targets, add
> > "-mcpu=unset -march=armv8-a"
> > directly when setting et_arm_v8_neon_flags in arm_v8_neon_ok_nocache,
> > to avoid having to add these two flags
OK for:
writes:
> gcc/cgraph.cc | 4 +-
> gcc/cgraph.h | 2 +
> gcc/cgraphunit.cc | 9 +
> gcc/config/aarch64/aarch64.cc | 43 ++--
> gcc/ipa.cc
On 04/07/2025 23:00, Christophe Lyon wrote:
Like we do in other effective-targets, add
"-mcpu=unset -march=armv8-a"
directly when setting et_arm_v8_neon_flags in arm_v8_neon_ok_nocache,
to avoid having to add these two flags in all users of arm_v8_neon_ok.
This avoids duplication and possible ty
On 04/07/2025 23:00, Christophe Lyon wrote:
A few arm effective-targets call check_effective_target_arm32 even
though they would force a -march=XXX flag which supports Arm and/or
Thumb-2, thus making the arm32 check useless. This has an impact when
the toolchain is configured with a default -mar
On 26/05/2025 17:08, Christophe Lyon wrote:
This effective target implicitly expects -march=armv8-a, otherwise
with a toolchain configured for instance with
--with-cpu=cortex-m0 --with-float=soft,
it fails even when trying
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp:
arm_neon.h:45:2: error: #er
On 11/07/2025 09:46, Torbjörn SVENSSON wrote:
Ok for trunk, gcc-15 and gcc-14.
I discovered that the dg-require-effective-target is missing on gcc-14,
but it's probably the right thing to add on gcc-15 and trunk too.
Without the `dg-require-effective-target vect_early_break`, the
`dg-add-option
On 09/07/2025 19:55, Torbjorn SVENSSON wrote:
Hi Christophe,
On 2025-07-09 17:31, Christophe Lyon wrote:
On Wed, 9 Jul 2025 at 10:25, Torbjörn SVENSSON
wrote:
Ok for trunk and releases/gcc-15?
Changes since v1:
- Removed the acceptance of LDR as it's only generated without
r15-7373-g5163cf
On 08/07/2025 16:14, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-15?
--
The scheduler allows the `and` instruction to be placed at 3 different
locations. Update the function body to contain all 3 locations.
Also, armv8.1-m.main can use `ldr` instead of `pop` to return.
gcc/testsuite
Christophe Lyon writes:
> In commit r15-4417-g71c7b446b98aa5, I made -werror mandatory when
> building libgcc for aarch64.
>
> While it achieved its goal (make us fix problems unnoticed so far),
> there has a been a lot of debate because it couldn't be disabled
> easily.
As discussed off-list: yo
Joseph,
Thanks a lot for your review on patch #1 and #4.
Could you also take another look at patch #3: Use the counted_by attribute of
pointers in array bound checker?
You have reviewed and approved the previous version, in this new version, the
only difference compared
with the previous one
On 10/07/2025 15:08, Christophe Lyon wrote:
As discussed in https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685733.html
the operand of the call should be a mem rather than an unspec.
This patch moves the unspec to an additional argument of the parallel
and adjusts cmse_nonsecure_call_inline_
On 04/07/2025 23:04, Christophe Lyon wrote:
We get lots of error messages when compiling arm_neon.h under
e.g. -mcpu=cortex-m55, because Neon builtins are enabled only when
!TARGET_HAVE_MVE. This has been the case since MVE support was
introduced.
This patch uses an approach similar to what we
> On 8 Aug 2025, at 14:23, Tamar Christina wrote:
>
>> -Original Message-
>> From: Pengfei Li
>> Sent: Friday, August 8, 2025 11:00 AM
>> To: Kyrylo Tkachov
>> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
>> Tamar Christina
>> Subject: [PATCH v2] AArch64: Fix invalid immediate of
Hi,
Just realized I forgot to overload `get_name` for `local` so here is
the patch with the improved version.
Cordially.
Le ven. 18 juil. 2025 à 16:38, Guillaume Gomez
a écrit :
>
> Hi,
>
> Sorry for the very long delay (more than one year O.o).
>
> I finally took time to apply suggestions and
doc/tm.texi.in: Add Vectorization and OpenMP and OpenACC
> sub-sections to the list of target macros and functions.
> * doc/tm.texi: Re-generate.
LGTM.
Jakub
> -Original Message-
> From: Pengfei Li
> Sent: Friday, August 8, 2025 11:00 AM
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford ;
> Tamar Christina
> Subject: [PATCH v2] AArch64: Fix invalid immediate offsets in SVE
> gather/scatter
> [PR121449]
>
> Below v2 patch
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, August 8, 2025 11:40 AM
> To: Richard Henderson
> Cc: gcc-patches@gcc.gnu.org; Karl Meakin ;
> pins...@gmail.com; Wilco Dijkstra ; Tamar Christina
>
> Subject: Re: [PATCH v2 05/1
Richard Henderson writes:
> Reject QI/HImode conditions, which would require extension in
> order to compare. Fixes
>
> z.c:10:1: error: unrecognizable insn:
>10 | }
> | ^
> (insn 23 22 24 2 (set (reg:CC 66 cc)
> (compare:CC (reg:HI 128)
> (reg:HI 127))) "z.c":6:6 -1
but given the change to
> movcc, it is no longer required to fix an ICE.
>
> TODO list:
> - Drop cbranch4, and direct expansion of CMPBR from cbranch4,
> so that we always get CCmode comparisons out of expand. Rely on combine
> to re-assemble CBB/CBH when there's n
Richard Henderson writes:
> Restrict the immediate range to the intersection of LT/GE and GT/LE
> so that cfglayout can invert the condition to redirect any branch.
>
> gcc:
> * config/aarch64/aarch64.cc (aarch64_cb_rhs): Restrict the
> range of LT/GE and GT/LE to their intersections.
x-predication-of-FP8-FDOT-insns-PR120986.patch>
> >>
> >> +(define_mode_attr HAVE_FP8_DOT_INSN [(VNx4SF "TARGET_SSVE_FP8DOT4")
> >> + (VNx8HF "TARGET_SSVE_FP8DOT2")])
> >> +
> >> +
> >>
> >> I think a more n
Richard Henderson writes:
> The enable for the test was wrong, so it never ran.
>
> gcc/testsuite:
> * gcc.target/aarch64/cmpbr.c: Use dg-require-effective-target.
> ---
> gcc/testsuite/gcc.target/aarch64/cmpbr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/t
Richard Henderson writes:
> The save/restore_stack_nonlocal patterns passed a DImode rtx
> to gen_tbranch_neqi3 for a QImode compare. The tbranch expander
> did not do what it said on the tin, that is: emit TBNZ.
> It only made it as far as AND+CMP+B.cond.
Yeah, that was done to allow ifcombine
On Wed, Aug 6, 2025 at 7:04 AM Edwin Lu wrote:
>
> This patch tries to add support for a variant of SAT_TRUNC where
> negative numbers are clipped to 0 instead of NARROW_TYPE_MAX_VALUE.
> This form is seen in x264, aka
>
> UT clip (T a)
> {
> return a & (UT)(-1) ? (-a) >> 31 : a;
the patch belo
On Fri, Aug 8, 2025 at 10:13 AM Stefan Schulze Frielinghaus
wrote:
>
> From: Stefan Schulze Frielinghaus
>
> In case an asm operand is an error node, constraints etc. are still
> validated. Furthermore, all other operands are gimplified, although an
> error is returned in the end anyway. For ha
Hi H.J.,
> When GNU binutils is configured with --enable-targets=all on Linux,
> "ld -V" will report both elf_x86_64_sol2 and elf_i386_sol2 as supported
> emulations. But they should only be used for Solaris 2 targets. Check
> for Solaris 2 targets before using sol2 linker emulations.
please le
Here is a patch which conforms to the style requirements.
On Thu, Aug 7, 2025 at 9:30 PM Ben Wu wrote:
>
> PR 120618
>
> gcc/cp/ChangeLog:
>
> * constraint.cc (tsubst_compound_requirement): Return NULL_TREE when
> t1
> is not a TEMPLATE_TYPE_PARM
> (tsubst_requires_expr):
On Thu, 7 Aug 2025, Jakub Jelinek wrote:
> Hi!
>
> My earlier r16-1886 PR120608 change incorrectly assumed that the
> finally_tmp.N vars introduced by eh pass will be only initialized
> to values 0 and 1 and there will be only EQ_EXPR/NE_EXPR comparisons
> of those.
>
> The following testcases s
On Thu, Aug 7, 2025 at 4:42 PM Gerald Pfeifer wrote:
>
> On Thu, 7 Aug 2025, Richard Biener wrote:
> > On Wed, Aug 6, 2025 at 9:19 PM Gerald Pfeifer wrote:
> >> In addition to gzip format our snapshots and releases have been using
> >> xz instead of bzip2 for a while.
> > Note download_prerequesi
* Gerald Pfeifer:
> diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
> index 52b10f33..48aeb9bd 100644
> --- a/htdocs/projects/cxx-status.html
> +++ b/htdocs/projects/cxx-status.html
> @@ -731,9 +731,6 @@
>extensions in addition to C++20 features,
> add -
On Fri, Aug 8, 2025 at 6:26 AM H.J. Lu wrote:
>
> When GNU binutils is configured with --enable-targets=all on Linux,
> "ld -V" will report both elf_x86_64_sol2 and elf_i386_sol2 as supported
> emulations. But they should only be used for Solaris 2 targets. Check
> for Solaris 2 targets before u
On Thu, Aug 7, 2025, at 3:21 PM, Joseph Myers wrote:
> On Thu, 7 Aug 2025, John Ericson wrote:
>
> > I think upon further reflection, I have a slightly different read of
> > what's going on.
> >
> > See also https://gcc.gnu.org/legacy-ml/gcc/2005-07/msg00236.html /
> > https://www.airs.com/ian/
On Thu, Aug 7, 2025 at 7:58 PM Andrew Pinski wrote:
>
> Now there are mergeable sections which have an entity size, we can place
> decls (constants) that are smaller in size in these sections.
> An example is an `long double` which has a size of 12 bytes on i686 and is
> placed in the 16 bytes sha
On 8/7/25 23:35, Karl Meakin wrote:
I have updated the tests in `cmpbr.c` to reflect the fixes. There are a
few regressions, but they can be fixed later; let's just make GCC
crash-free first.
I should have replied sooner. The patch set breaks atomics.
I am re-working it not to do so and
It's still experimental.
On Thu, 7 Aug 2025, 18:16 Gerald Pfeifer, wrote:
> Looking at projects/cxx-status.html I noticed we state
>
>Important: Because the ISO C++20 standard is recent, GCC's support
>is *experimental*.
>
> Do we still need/want this, or shall we drop it per the patch b
On Fri, 1 Aug 2025, Qing Zhao wrote:
> Currently, we generate a call to a .ACCESS_WITH_SIZE for a FAM with counted_by
> attribute for every component_ref that corresponds to such an object.
> Actually, such .ACCESS_WITH_SIZE calls are useless when they are generated
> for a written site or an addr
Hi Jerry et al.,
I attached an earlier version of the patch - apologies!
Please find the latest attached.
Paul
On Thu, 7 Aug 2025 at 17:07, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi Jerry, Steve and co.,
>
> Thanks for the reviews.
>
> I have made extensive changes to t
On Thu, Aug 7, 2025 at 4:55 AM Wilco Dijkstra wrote:
>
>
> Add an optab for isnan. This requires changes to the existing folding code
> to extend the interclass_mathfn infrastructure to support BUILT_IN_ISNAN.
> It now checks for a valid optab before emitting the generic expansion.
> There is no
On Fri, 1 Aug 2025, Qing Zhao wrote:
> gcc/c-family/ChangeLog:
>
> * c-attribs.cc (handle_counted_by_attribute): Accept counted_by
> attribute for pointer fields.
>
> gcc/c/ChangeLog:
>
> * c-decl.cc (verify_counted_by_attribute): Change the 2nd argument
> to a vector of
On Thu, 7 Aug 2025, David Faust wrote:
> Changes from v6:
> - Patch 1: Check for and reject wide string arguments in the attribute
>handlers. Factor common argument checking shared by both attribute
>handlers to a small helper.
I think there should be testcases for this error (with L",
Hi Pengfei,
> On 7 Aug 2025, at 18:45, Pengfei Li wrote:
>
> This patch fixes incorrect constraints in RTL patterns for AArch64 SVE
> gather/scatter with type widening/narrowing and vector-plus-immediate
> addressing. The bug leads to below "immediate offset out of range"
> errors during assembl
On Thu, 7 Aug 2025 at 20:59, Mike Stump wrote:
>
> On Aug 7, 2025, at 9:15 AM, Gerald Pfeifer wrote:
> >
> > Looking at projects/cxx-status.html I noticed we state
> >
> > Important: Because the ISO C++20 standard is recent, GCC's support
> > is *experimental*.
> >
> > Do we still need/want t
On Thu, 7 Aug 2025, John Ericson wrote:
> I think upon further reflection, I have a slightly different read of
> what's going on.
>
> See also https://gcc.gnu.org/legacy-ml/gcc/2005-07/msg00236.html /
> https://www.airs.com/ian/configure/configure_8.html (rendering of
> since-deleted from the
On Jul 17, 2025, at 5:48 AM, Torbjörn SVENSSON
wrote:
>
> Ok for trunk, gcc-15 and gcc-14?
Ok.
> gcc/testsuite/ChangeLog:
>
> * lib/multiline.exp: Added pruning of .exe.
On Thu, 7 Aug 2025 at 21:07, Ville Voutilainen
wrote:
>
> On Thu, 7 Aug 2025 at 20:59, Mike Stump wrote:
> >
> > On Aug 7, 2025, at 9:15 AM, Gerald Pfeifer wrote:
> > >
> > > Looking at projects/cxx-status.html I noticed we state
> > >
> > > Important: Because the ISO C++20 standard is recent,
On Thu, Aug 07, 2025 at 10:57:49AM -0700, Mike Stump wrote:
> On Aug 7, 2025, at 9:15 AM, Gerald Pfeifer wrote:
> >
> > Looking at projects/cxx-status.html I noticed we state
> >
> > Important: Because the ISO C++20 standard is recent, GCC's support
> > is *experimental*.
> >
> > Do we sti
On Thu, Aug 7, 2025 at 12:00 AM Richard Biener
wrote:
>
> On Thu, Aug 7, 2025 at 8:37 AM Andrew Pinski wrote:
> >
> > Like r0-46282-gf41115930523b3, but this time for normal variables
> > rather than the constant pool.
> > With the simple C++ code on ia32:
> > ```
> > std::initializer_list a = {0
On Aug 7, 2025, at 9:15 AM, Gerald Pfeifer wrote:
>
> Looking at projects/cxx-status.html I noticed we state
>
> Important: Because the ISO C++20 standard is recent, GCC's support
> is *experimental*.
>
> Do we still need/want this, or shall we drop it per the patch below?
Drop it. Featur
Add a couple of tests to ensure that BTF type/decl tags do not interfere
with generation of BPF CO-RE relocations.
gcc/testsuite/
* gcc.target/bpf/core-btf-tag-1.c: New test.
* gcc.target/bpf/core-btf-tag-2.c: New test.
---
gcc/testsuite/gcc.target/bpf/core-btf-tag-1.c | 23
terrupts()
> before you use FP/SIMD operations?
It's automatic; the FPU is disabled at interrupt entry. When a trap
occurs, the FPU register contents are saved to the current task block.
Interrupts are left disabled and the FPU re-enabled.
There's currently a special hack for va_start
Hi Jerry, Steve and co.,
Thanks for the reviews.
I have made extensive changes to this patch. Relative to the original
submission, the changes are:
(i) Cleaned up the comments in decl.cc. 'binding' removed from generic
statement comments;
(ii) 'generic_spec_name' used for formatted name instead o
Hi Richard,
On Thu, 2025-08-07 at 13:56 +0200, Richard Biener wrote:
> The following handles value-numbering of a BIT_FIELD_REF of
> a register that's defined by a load by looking up a subset
> load similar to how we handle bit-and masked loads. This
> allows the testcase to be simplified by two
Hi Tobias,
On 8/7/2025 8:59 PM, Tobias Burnus wrote:
Yuao Ma wrote:
Given the "Fortran 2023:" prefix, I wonder whether the wording shouldn't
be tweaked:
+ call c_f_pointer(x, ptr_2d, shape=myshape_2d, lower=mylower_2d) !
{ dg-error "Fortran 2023: Unexpected LOWER argument at" }
It reads
writes:
> From: Alfie Richards
>
> This patch introduces the TARGET_CHECK_TARGET_CLONE_VERSION hook
> which is used to determine if a target_clones version string parses.
>
> The hook has a flag to enable emitting diagnostics.
>
> This is as specified in the Arm C Language Extension. The purpose
On Thu, 7 Aug 2025, Richard Biener wrote:
> On Wed, Aug 6, 2025 at 9:19 PM Gerald Pfeifer wrote:
>> In addition to gzip format our snapshots and releases have been using
>> xz instead of bzip2 for a while.
> Note download_prerequesites pulls .bz2 tarballs.
Hmm, how do we best go about that?
I ha
Hi Keith,
Thanks for the explanation - however I'm afraid compilers don't have a concept
of implicit vs explicit use of operations or registers.
> I'm trying to find all cases where that happens for data types other
> than SIMD/FP. Do you know of other places where the compiler implicitly
> uses
On Thu, Aug 7, 2025 at 2:14 PM Richard Sandiford
wrote:
>
> simplify_gen_subreg rejected subregs of literal constants if
> MODE_COMPOSITE_P. This was added by the fix for PR96648 in
> g:c0f772894b6b3cd8ed5c5dd09d0c7917f51cf70f. Jakub said:
>
> As for the simplify_gen_subreg change, I think it
Hi Richard,
> Unlike base PCS functions, __arm_streaming and __arm_streaming_compatible
> functions allow/require PSTATE.SM to be 1 on entry, so they need to
> be treated as STO_AARCH64_VARIANT_PCS.
>
> Similarly, functions that share ZA or ZT0 with their callers require
> ZA to be active on entry
On 01/08/2025 13:27, Richard Biener wrote:
On Thu, Jul 31, 2025 at 11:44 AM Richard Biener
wrote:
On Mon, May 19, 2025 at 6:38 PM Richard Earnshaw wrote:
It's not enough to just check that a memory operand is of the form
mem(reg); after RA we also need to validate the register being used.
T
Yuao Ma wrote:
On 8/6/2025 10:57 PM, Yuao Ma wrote:
On 8/6/2025 4:32 PM, Tobias Burnus wrote:
Hi Yuao,
thanks for your patch. I have two nits:
* There is no diagnostic for -std=f2018 (or lower);
can you add the 'gfc_notify_std (GFC_STD_F2023' ?
Done. Testcase added.
Given the "Fortran
writes:
> From: Alfie Richards
>
> This patch is an overhaul of how FMV name mangling works. Previously
> mangling logic was duplicated in several places across both target
> specific and independent code. This patch changes this such that all
> mangling is done in targetm.mangle_decl_assembler_n
writes:
> From: Alfie Richards
>
> This is similar to clone_function_name and its siblings but takes an
> identifier tree node rather than a function declaration.
>
> This is to be used in conjunction with the identifier node stored in
> cgraph_function_version_info::assembler_name to mangle FMV
On Wed, Aug 6, 2025 at 7:34 PM Andrew Pinski wrote:
>
> This implements the simple copy prop of aggregates into
> arguments of function calls. This can reduce the number of copies
> done. Just like removing of an extra copy in general, this can and
> will help out SRA; since we might not need to d
On Wed, Aug 6, 2025 at 7:30 PM Andrew Pinski wrote:
>
> While looking into the gimple level after optimization of the highway code
> from google, I noticed in .optimized we still have:
> ```
> MEM [(short int *)&a] = { 0, 0, 0, 0, 0, 0, 0, 0 };
> D.4398 = a;
> a ={v} {CLOBBER(eos)};
> D.4
Uros Bizjak writes:
> On Tue, Aug 5, 2025 at 1:32 PM Richard Sandiford
> wrote:
>> It's coming from:
>>
>> (define_split
>> [(set (match_operand:SWI 0 "register_operand")
>> (any_rotate:SWI
>> (match_operand:SWI 1 "const_int_operand")
>> (subreg:QI
>> (an
On Wed, Aug 6, 2025 at 7:30 PM Andrew Pinski wrote:
>
> In the testcase provided, currently we lose the landing pad for the exception
> that could
> throw from the aggregate load as we remove one copy and the second statement
> where load
> happens was not marked as throwable before so the landi
On Thu, Aug 7, 2025 at 1:22 PM Richard Biener
wrote:
>
> On Wed, Aug 6, 2025 at 7:29 PM Andrew Pinski wrote:
> >
> > One thing I noticed while working on copy prop for aggregates is that we
> > start with
> > a memcpy like statement and then walk backwards. This means we could have a
> > few wa
On Wed, Aug 6, 2025 at 7:29 PM Andrew Pinski wrote:
>
> One thing I noticed while working on copy prop for aggregates is that we
> start with
> a memcpy like statement and then walk backwards. This means we could have a
> few walks
> backwards to see there was no statement for zeroing. Instead t
On Wed, Aug 6, 2025 at 7:29 PM Andrew Pinski wrote:
>
> While thinking about how to implement the rest of the copy prop and makes
> sure not
> to introduce some compile time problems, optimize_agr_copyprop should be
> changed
> into a forwproping rather than looking backwards.
>
> Bootstrapped a
On 06/08/2025 12:47, Richard Henderson wrote:
On 8/6/25 00:45, Karl Meakin wrote:
Now that the body of `cbranch` and `cbranch` are the
same, could we merge them into one rule?
No, the bodies are the same but the predicates are not.
r~
Good point, I missed that
orward and backward. However, this
printing is not needed outside of debugging, and confuses people
because
the output is not only composed of PASS: lines.
This patch disables the printing of the list content by default. If
one wants to re-enable it for debugging, he can
Committed as r16-3063-gb399a0084bc962 fix the file name in
download_prerequisites fixed.
And ...
Richard Biener wrote:
On Wed, 6 Aug 2025, Tobias Burnus wrote:
OK for mainline? (Requires a prior update of 'infrastructure').
-gmp='gmp-6.2.1.tar.bz2'
…
+gmp='gmp-6.3.0.tar.xz'
…
+++ b/contr
On Wed, Aug 6, 2025 at 9:19 PM Gerald Pfeifer wrote:
>
> In addition to gzip format our snapshots and releases have been using
> xz instead of bzip2 for a while.
Note download_prerequesites pulls .bz2 tarballs.
>
> gcc:
> PR target/69374
> * doc/install.texi (Prerequisites): Repl
On Thu, Aug 7, 2025 at 8:37 AM Andrew Pinski wrote:
>
> Like r0-46282-gf41115930523b3, but this time for normal variables
> rather than the constant pool.
> With the simple C++ code on ia32:
> ```
> std::initializer_list a = {0.3l};
> ```
> GCC currently produces:
> ```
> .section.
On Wed, 6 Aug 2025, Robin Dapp wrote:
> > + elsvals)
> > + || gs_info->decl != NULL_TREE)
>
> Does GATHER_SCATTER_LEGACY_P work here? Or is ifn != IFN_LAST?
It should work. Note I'm a bit unhappy about GATHER_SCATTER_LEGACY_P
and friend
gt; mpfr_compound_si.
> - New functions mpfr_fmod_ui, mpfr_powr, mpfr_pown, mpfr_pow_uj, mpfr_pow_sj
> and mpfr_rootn_si (mpfr_pown is actually a macro defined as an alias for
> mpfr_pow_sj).
> - Bug fixes.
> In particular, for the formatted output functions (mpfr_printf, etc.),
>
On Wed, Aug 06, 2025 at 05:57:14PM +0200, Jakub Jelinek wrote:
> On Wed, Aug 06, 2025 at 05:40:09PM +0200, Stefan Schulze Frielinghaus wrote:
> > On Tue, Aug 05, 2025 at 04:55:37PM +0200, Stefan Schulze Frielinghaus wrote:
> > > On Tue, Aug 05, 2025 at 04:25:43PM +0200, Jakub Jelinek wrote:
> > > >
I think upon further reflection, I have a slightly different read of what's
going on.
See also https://gcc.gnu.org/legacy-ml/gcc/2005-07/msg00236.html /
https://www.airs.com/ian/configure/configure_8.html (rendering of since-deleted
from the GDB repo item referenced in reply), which I also foun
On 8/6/25 3:34 PM, Patrick Palka wrote:
On Tue, 5 Aug 2025, Jason Merrill wrote:
On 7/31/25 10:51 AM, Patrick Palka wrote:
On Thu, 31 Jul 2025, Jason Merrill wrote:
On 7/30/25 5:48 PM, Patrick Palka wrote:
On Wed, 30 Jul 2025, Patrick Palka wrote:
On Wed, 30 Jul 2025, Patrick Palka wrote:
On 8/6/25 6:27 PM, Sam James wrote:
This fails for me as:
+ERROR: g++.dg/cpp26/constexpr-new3.C -std=c++26: unknown dg option: 2 for "
dg-error 40 "accessing value of 'int [2]' object through a 'long int' glvalue in a
constant expression" "
otherwise.
Escape '[' and ']'.
Oops, thanks.
gc
On 7/25/25 2:24 PM, Patrick Palka wrote:
After r16-2519-gba5a6787374dea, we should never see a C++20 rewritten
comparison operator expressed as a built-in acting on an operator<=>
call, e.g. operator<=>(x, y) < 0. This is because operator<=> always
returns a class type (std::strong/weak/partial_
On 8/6/25 7:13 AM, Jakub Jelinek wrote:
Hi!
Another part of the C++26 P2843R3, this time in
https://eel.is/c++draft/cpp.include#7
changing former (compile time) undefined behavior to IFNDR.
With IFNDR we wouldn't have to test anything I guess, but this still adds
the cases from the 3.4 section
On 8/6/25 8:17 AM, Jakub Jelinek wrote:
Hi!
From the paper it isn't clear what caused the decision changes, not to drop
the "the token defined is generated as a result of this replacement process or"
part and make [cpp.cond]/10 violations IFNDR rather than ill-formed (the
latter maybe so that t
On 8/6/25 10:29 AM, Jakub Jelinek wrote:
Hi!
And here is the last part of the paper. Contrary what the paper claims
(clearly they haven't tried -pedantic nor -pedantic-errors), I think we
already diagnose everything we should.
Tested on x86_64-linux and i686-linux, ok for trunk?
OK.
2025-0
LGTM.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2025-08-04 17:09
To: gcc-patches
CC: kito.ch...@gmail.com; juzhe.zh...@rivai.ai; jeffreya...@gmail.com;
pan2...@intel.com; rdapp@gmail.com
Subject: [PATCH] RISC-V: Expand const_vector with 2 elts per pattern.
Hi,
In PR121334 we are asked
change
too.
Let's wait for the CI and see.
Pan
-Original Message-
From: Robin Dapp
Sent: Wednesday, August 6, 2025 10:35 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com;
rdapp@gmail.com; Chen, Ken ; Liu, Hong
OK I am going to submit a new version which is now in 4 steps. The first 3
steps are entirely behavior non-changing (or at least that is their intent) ---
pure refactors. The 4th and final one along does the behavior change, and
contains the motivation for that behavior change. Clang prior art i
On 8/6/25 13:22, Joseph Myers wrote:
> On Wed, 6 Aug 2025, David Faust wrote:
>
>> So IMO the best option will be to reject wide strings in the attribute
>> handler. (The alternative, I guess, is to ensure the argument is
>> always exported to UTF-8 before being written (?))
>>
>> I see that w
On Wed, 6 Aug 2025, David Faust wrote:
> So IMO the best option will be to reject wide strings in the attribute
> handler. (The alternative, I guess, is to ensure the argument is
> always exported to UTF-8 before being written (?))
>
> I see that we can get the character size from the TREE_TYPE
> I don't see how this makes any sense. If TARGET_SIMD or TARGET_FP
> are true, the compiler may at any time use a SIMD register for anything -
> including in integer-only code.
Thanks for reviewing my proposed patch. I'm struggling to migrate the
Zephyr project from GCC 12.2 to a more recent ver
On Fri, 25 Jul 2025, Patrick Palka wrote:
>
> On Fri, 25 Jul 2025, Patrick Palka wrote:
>
> > After r16-2519-gba5a6787374dea, we should never see a C++20 rewritten
> > comparison operator expressed as a built-in acting on an operator<=>
> > call, e.g. operator<=>(x, y) < 0. This is because oper
1 - 100 of 12548 matches
Mail list logo
