On Thu, Dec 5, 2024 at 1:55 AM Heiko Eißfeldt wrote:
>
> As commented in PR114541 here is a first patch that
> 1. replaces atoi() with strtoul() with ERANGE checking and
> 2. fixes the handling of misparsed gimple compounds to return early.
> 3. adds two new test cases.
>
> There is more work to d
function_shape::get_name is the funciton for building intrinsic function name,
the result should not be changed by others once it built.
So add const to the return type to make sure no one change that by
accident.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-shapes.cc
(vset
From: Hau Hsu
Sometimes we want to use default cmodel other than medlow. Add a GCC
configure option for that.
gcc/ChangeLog:
* config.gcc (riscv*-*-*): Add support for --with-cmodel configure
option.
(all_defaults): Add cmodel.
* config/riscv/riscv.h (TARGET_DEFAULT_CMO
On Mon, Dec 02, 2024 at 02:04:44PM +0530, jeevitha wrote:
> Ping!
>
> please review.
I don't see an issue with the patch. Hopefully Segher can approve it shortly.
> Thanks & Regards
> Jeevitha
>
> On 15/10/24 12:49 pm, jeevitha wrote:
> > Hi All,
> >
> > Removed powerpc*-*-* from the target t
Ping.
On 27/11/24 10:23, Dhruv Chawla wrote:
External email: Use caution opening links or attachments
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
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we ICE with a partially-substituted pack indexing. The pack
expanded to an empty pack, which we can't index. It seems reasonable
to detect this case in make_pack_index. Other erroneous cases can
wait until pack_index_ele
From: Pan Li
This patch would like to refactor the all unsigned SAT_TRUNC patterns,
aka:
* Extract type check outside.
* Re-arrange the related match pattern forms together.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
* The x86 bootstrap test.
* The x86
As commented in PR114541 here is a first patch that
1. replaces atoi() with strtoul() with ERANGE checking and
2. fixes the handling of misparsed gimple compounds to return early.
3. adds two new test cases.
There is more work to do for Andrews testcase to succeed, so PR114541
is not done yet.
=
This patch to the Go frontend changes traversal to always traverse
method declarations (method definitions were already traversed). This
removes one existing case that explicitly traversed method
declarations, in favor of the common approach.
Note that the gc Go compiler rejects method declaratio
On Fri, 2024-11-22 at 17:04 -0500, Marek Polacek wrote:
> On Fri, Nov 22, 2024 at 04:56:08PM -0500, David Malcolm wrote:
> > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> >
> > OK for trunk?
>
> Not an approval, but the patch LGTM -- it follows the usual
> hint.suggestion()
> p
Le mer. 4 déc. 2024, 21:56, Christophe Lyon a
écrit :
> On Wed, 4 Dec 2024 at 12:39, Richard Earnshaw (lists)
> wrote:
> >
> > On 25/11/2024 20:08, Christophe Lyon wrote:
> > > In this PR, we have to handle a case where MVE predicates are supplied
> > > as a const_int, where individual predicate
Ping #2 for this kit:
On Fri, 2024-11-22 at 17:21 -0500, David Malcolm wrote:
> I'd like to ping this patch kit.
>
> I've already pushed "[PATCH 1/3] diagnostics: add support for nested
> diagnostics [PR116253]" but was hoping for review from C++
> maintainers
> for patches 2 and 3:
>
> [PATCH 2
On Wed, Dec 4, 2024 at 1:28 PM Jonathan Wakely wrote:
>
> On Wed, 4 Dec 2024 at 20:43, Vineet Gupta wrote:
> >
> > On 12/4/24 11:48, Jonathan Wakely wrote:
> > >> gcc/ChangeLog:
> > >> PR target/11472
> > > Note that you typo'd the PR number here, so that it added a comment
> > > to https://
On Wed, 4 Dec 2024 at 21:50, Jonathan Wakely wrote:
>
> On 04/12/24 19:27 +0100, François Dumont wrote:
> >Hi
> >
> >I've completed the synchronization with your equivalent PR for
> >std::list so here is the updated patch.
> >
> >PR updated a couple of days ago.
> >
> >Note that I've started to re
On 04/12/24 19:27 +0100, François Dumont wrote:
Hi
I've completed the synchronization with your equivalent PR for
std::list so here is the updated patch.
PR updated a couple of days ago.
Note that I've started to rework the patch for the same in _Hashtable.
Great, thanks.
François
On 3
On Wed, 4 Dec 2024 at 20:43, Vineet Gupta wrote:
>
> On 12/4/24 11:48, Jonathan Wakely wrote:
> >> gcc/ChangeLog:
> >> PR target/11472
> > Note that you typo'd the PR number here, so that it added a comment
> > to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11472
>
> Apologies my bad.
>
> In
On Wed, 4 Dec 2024 at 20:47, Vineet Gupta wrote:
>
> On 12/4/24 11:52, Jonathan Wakely wrote:
> >> I see you've been using the PR/nnn form for all your commits, please
> >> use the [PRnnn] form as described at
> >> https://gcc.gnu.org/contribute.html#patches
> > Also it looks like the actual comp
Promote integer arguments smaller than int if TARGET_PROMOTE_PROTOTYPES
returns true.
PR middle-end/112877
* calls.c (initialize_argument_information): Promote small integer
arguments if TARGET_PROMOTE_PROTOTYPES returns true.
gcc/testsuite/
PR middle-end/112877
Remove the targetm.calls.promote_prototypes call from C, C++ and Ada
frontends.
gcc/
PR c/48274
PR middle-end/14907
PR middle-end/112877
* gimple.cc (gimple_builtin_call_types_compatible_p): Remove the
targetm.calls.promote_prototypes call.
* tree.c
On Wed, 4 Dec 2024 at 12:39, Richard Earnshaw (lists)
wrote:
>
> On 25/11/2024 20:08, Christophe Lyon wrote:
> > In this PR, we have to handle a case where MVE predicates are supplied
> > as a const_int, where individual predicates have illegal boolean
> > values (such as 0xc for a 4-bit boolean p
For targets, like x86, which define TARGET_PROMOTE_PROTOTYPES to return
true, all integer arguments smaller than int are passed as int:
[hjl@gnu-tgl-3 pr14907]$ cat x.c
extern int baz (char c1);
int
foo (char c1)
{
return baz (c1);
}
[hjl@gnu-tgl-3 pr14907]$ gcc -S -O2 -m32 x.c
[hjl@gnu-tgl-3 p
Since the C frontend no longer promotes char and short arguments, expect
in-branch clones for x86.
PR middle-end/14907
* gcc.dg/vect/vect-simd-clone-16c.c: Expect in-branch clones for
x86.
* gcc.dg/vect/vect-simd-clone-16d.c: Likewise.
* gcc.dg/vect/vect-sim
Since the C frontend no longer promotes char argument, enable ssa-fre-4.c
for all targets and adjust scan match.
PR middle-end/14907
* gcc.dg/tree-ssa/ssa-fre-4.c: Enable for all targets and adjust
scan match.
Signed-off-by: H.J. Lu
---
gcc/testsuite/gcc.dg/tree-ssa/ssa-
Since the C frontend no longer promotes char argument, enable scev-cast.c
for all targets and adjust scan matches.
PR middle-end/14907
* gcc.dg/tree-ssa/scev-cast.c: Enable for all targets and adjust
scan match.
Signed-off-by: H.J. Lu
---
gcc/testsuite/gcc.dg/tree-ssa/sc
Changes from v5:
1. Properly check x86 targets in gfortran.dg/pr112877-1.f90.
Changes from v4:
1. Rename gcc/testsuite/gfortran.dg/pr14907-1.f90 to
gcc/testsuite/gfortran.dg/pr112877-1.f90
2. Mention
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id
Since the C frontend no longer promotes integer argument smaller than int,
the apx-ndd.c codgen is slightly different:
apx-ndd.s (original)2024-11-10 06:07:09.894876973 +0800
apx-ndd.s (updated) 2024-11-10 06:06:59.371860565 +0800
@@ -17,7 +17,7 @@ foo_add_char:
foo1_add_char:
.LFB1:
On 12/4/24 11:52, Jonathan Wakely wrote:
>> I see you've been using the PR/nnn form for all your commits, please
>> use the [PRnnn] form as described at
>> https://gcc.gnu.org/contribute.html#patches
> Also it looks like the actual component in bugzilla is
> "rtl-optimization" not "target", so sho
On 12/4/24 11:48, Jonathan Wakely wrote:
>> gcc/ChangeLog:
>> PR target/11472
> Note that you typo'd the PR number here, so that it added a comment
> to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11472
Apologies my bad.
In my defense I ran following:
./contrib/gcc-changelog/git_check_comm
Applied the following patch that fixed an ICE when
-fdump-rtl-avr-fuse-move is on, because when 2 insn have been
combined into a single one, then m_insn is undefined.
To date, m_insn is only used in dumps.
Applied as obvious.
Johann
--
AVR: ad target/84211 - Fix dumping INSN_UID for null insn.
In nonlocal_goto sets, change hard_frame_pointer_rtx only after
emit_stack_restore() restored SP. This is needed because SP
my be stored in some frame location.
The only change to test results is that gcc.c-torture/execute/pr64242.c
is passing now.
Ok to apply?
Johann
--
AVR: target/64242 -
Pushed to trunk as r15-5927-g68aefc6988dc34.
gcc/ChangeLog:
* doc/libgdiagnostics/topics/execution-paths.rst: Add '§' before
references to section of SARIF spec.
* doc/libgdiagnostics/topics/fix-it-hints.rst: Likewise.
* doc/libgdiagnostics/tutorial/01-hello-world.r
On 04/12/24 19:48 +, Jonathan Wakely wrote:
On 04/12/24 11:03 -0800, Vineet Gupta wrote:
sched1 computes ECC (Excess Change Cost) for each insn, which represents
the register pressure attributed to the insn.
Currently the pressure sensitive scheduling algorithm deliberately ignores
negative
Hi,
I’d like to ping the following C++ patches:
PR c++/109918: Unexpected -Woverloaded-virtual with virtual conversion
operators
=> https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665650.html
PR c++/114619:ICE with -fno-elide-constructors in C++14 mode for
non-constant initializer in
On 04/12/24 11:03 -0800, Vineet Gupta wrote:
sched1 computes ECC (Excess Change Cost) for each insn, which represents
the register pressure attributed to the insn.
Currently the pressure sensitive scheduling algorithm deliberately ignores
negative ECC values (pressure reduction), making them 0 (n
On 11/22/24 4:45 AM, Jakub Jelinek wrote:
2024-11-22 Jakub Jelinek
PR c/41045
gcc/
* output.h (insn_noperands): Declare.
* final.cc (insn_noperands): No longer static.
* varasm.cc (assemble_asm): Handle ASM_EXPR.
* lto-streamer-out.cc (lto_output_tople
On 12/4/24 5:52 AM, Simon Martin wrote:
Hi Jason,
On 3 Dec 2024, at 22:37, Jason Merrill wrote:
On 12/3/24 12:25 PM, Simon Martin wrote:
We currently reject the following valid code:
=== cut here ===
struct Base {
virtual void doit (int v) const {}
};
struct Derived : Base {
void
On 12/4/24 8:26 AM, Matthew Malcomson wrote:
Attaching a patch with the changes requested.
Have adjusted the case statement formatting back to how it was
beforehand (also sending a separate patch for the relevant clang-format
config change
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/
sched1 computes ECC (Excess Change Cost) for each insn, which represents
the register pressure attributed to the insn.
Currently the pressure sensitive scheduling algorithm deliberately ignores
negative ECC values (pressure reduction), making them 0 (neutral), leading
to more spills. This happens d
This is broken out of predecessor promotion patch so that debugging can
proceed during stage1 restrictions.
gcc/ChangeLog:
* haifa-sched.cc (model_choose_insn): Dump unscheduled_preds.
(model_dump_pressure_summary): Dump bb->index.
(model_start_schedule): Pass bb.
*
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
> Update test case to use -mcpu=unset/-march=unset feature introduced in
> r15-3606-g7d6c6a0d15c.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/lto/pr96939_0.c: Use effective-target
> arm_arch_v8a.
> * gcc.target/arm/lto/pr96939_
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
> The test case gcc.target/arm/its.c was created together with restriction
> of IT blocks for Cortex-M7. As the test case fails on all tunes that
> does not match Cortex-M7, explicitly test it for Cortex-M7. To have some
> additional faith that GCC does
The flag now known as FLAG_QUIET is an odd-one-out in that it
removes side-effects rather than adding them. This patch inverts
it and gives it the old name FLAG_AUTO_FP. FLAG_QUIET now means
"no flags" instead.
gcc/
* config/aarch64/aarch64-builtins.cc (FLAG_QUIET): Redefine to 0,
This patch fixes the vluti* definitions to say that they don't
raise FP exceptions even for floating-point modes.
gcc/
* config/aarch64/aarch64-simd-pragma-builtins.def
(ENTRY_TERNARY_VLUT8): Use FLAG_QUIET rather than FLAG_DEFAULT.
(ENTRY_TERNARY_VLUT16): Likewise.
---
..
This patch renames to FLAG_NONE to FLAG_DEFAULT. "NONE" suggests
that the function has no side-effects, whereas it actually means
that floating-point operations are assumed to read FPCR and to
raise FP exceptions.
gcc/
* config/aarch64/aarch64-builtins.cc (FLAG_NONE): Rename to...
I'd suggested the name "FLAG_AUTO_FP" to mean "automatically derive
FLAG_FP from the mode", i.e. automatically decide whether the function
might read the FPCR or might raise FP exceptions. However, the flag
currently suppresses that behaviour instead.
This patch renames FLAG_AUTO_FP to FLAG_QUIET
The arm_neon.h intrinsic definitions use a bitmask of flags to
indicate what side-effects the intrinsic might have. However,
their names are a bit confusing:
- FLAG_AUTO_FP was originally suggested as a way of saying
"automatically derive FLAG_FP from the mode", i.e. automatically
decide whet
On Tue, Dec 03, 2024 at 04:27:22PM -0500, Jason Merrill wrote:
> On 12/3/24 2:46 PM, Marek Polacek wrote:
> > On Thu, Nov 28, 2024 at 12:04:56PM -0500, Jason Merrill wrote:
> > > On 11/27/24 9:06 PM, Marek Polacek wrote:
> > > > Not a bugfix, but this should only affect C++26.
> > > >
> > > > Boot
On Wed, 4 Dec 2024, Prathamesh Kulkarni wrote:
> Hi Joseph,
> Updated the assert together with setting of CFLAGS in attached patch.
> Bootstrapped+tested on aarch64-linux-gnu (so far).
> Does it look OK ?
This version is OK.
--
Joseph S. Myers
josmy...@redhat.com
> Am 04.12.2024 um 16:26 schrieb Tamar Christina :
>
>
>>
>> -Original Message-
>> From: Richard Biener
>> Sent: Wednesday, December 4, 2024 2:43 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd
>> Subject: Re: [PATCH 4/7]middle-end: Fix mask length arg in call to
>> v
This patch splits multi-byte loads and stores into single-byte
ones provided:
- New option -msplit-ldst is on (e.g. -O2 and higher), and
- The memory is non-volatile, and
- The address space is generic, and
- The split addresses are natively supported by the hardware.
Passes without regressi
Hi Andre,
The patch looks to be straightforward. OK for mainline.
Thanks!
Paul
On Wed, 4 Dec 2024 at 12:16, Andre Vehreschild wrote:
> Hi all,
>
> I figured this patch has not been okay'ed yet. Anyone in for a review?
>
> Regtests ok on x86_64-pc-linux-gnu / F39. Ok for trunk?
>
> Regards,
>
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, December 4, 2024 2:43 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 4/7]middle-end: Fix mask length arg in call to
> vect_get_loop_mask [PR96342]
>
> On Wed, 4 Dec 2024, Tamar Christina wro
On 12/3/24 12:56 AM, Xi Ruoyao wrote:
On Tue, 2024-12-03 at 15:23 +0800, Bohan Lei wrote:
diff --git a/gcc/testsuite/gcc.dg/crc-linux-1.c
b/gcc/testsuite/gcc.dg/crc-linux-1.c
index 918b423a583..3261ba48b8b 100644
--- a/gcc/testsuite/gcc.dg/crc-linux-1.c
+++ b/gcc/testsuite/gcc.dg/crc-linux-1
-Original Message-
> From: Tamar Christina
> Sent: Wednesday, December 4, 2024 3:02 PM
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Sandiford
>
> Subject: RE: [PATCH 6/7]middle-end: add vec_init support for variable length
> subvector concatenation.
>
> > -Origi
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, December 4, 2024 2:53 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Sandiford
>
> Subject: Re: [PATCH 6/7]middle-end: add vec_init support for variable length
> subvector concatenation.
>
> On Wed, 4 D
Hi All,
Commiting this as obvious.
Cheers,
Filip Kastl
-- 8< --
In my last patch for check-params-in-docs.py I accidentally
1. left one occurence of the 'help_params' variable not renamed
2. converted 'help_params' from a dict to a list
These issues cause the script to error when encounterin
On Wed, 4 Dec 2024, Tamar Christina wrote:
> Hi All,
>
> For architectures where the vector-length is a compile-time variable,
> rather representing a runtime constant, as is the case with SVE it is
> perfectly reasonable that such vector be made up of two (or more) subvector
> components of a co
On Wed, 4 Dec 2024, Tamar Christina wrote:
> Hi All,
>
> When issuing multiple calls to a simdclone in a vectorized loop,
> TYPE_VECTOR_SUBPARTS(vectype) gives the incorrect number when compared
> to the TYPE_VECTOR_SUBPARTS result we get from the mask type derived
> from the relevant `rgroup_con
On Wed, Dec 4, 2024 at 1:21 PM Tamar Christina wrote:
>
> Hi All,
>
> While `poly_int64' has been the default representation of bitfield size
> and offset for some time, there was a lack of support for the use of
> non-constant `poly_int64' values for those values throughout the
> compiler, limit
> -Original Message-
> From: Joseph Myers
> Sent: 03 December 2024 03:34
> To: Prathamesh Kulkarni
> Cc: Xi Ruoyao ; Matthew Malcomson
> ; gcc-patches@gcc.gnu.org
> Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic
>
> External email: Use caution opening links or attach
On Wed, 2024-12-04 at 11:22 +, Richard Earnshaw (lists) wrote:
> On 26/11/2024 15:51, David Malcolm wrote:
> > OK for trunk?
>
> OK
>
> > (caveat: I haven't done a full test on this patch)
>
> Linaro's CI has, it's clean.
Thanks; pushed as r15-5922-ga0ac8fa55a4749.
On Wed, 4 Dec 2024 at 12:20, Giuseppe D'Angelo
wrote:
>
> On 03/12/2024 18:02, Jonathan Wakely wrote:
> > On Tue, 3 Dec 2024 at 16:56, Jonathan Wakely wrote:
> >>
> >> On Tue, 3 Dec 2024 at 16:19, Giuseppe D'Angelo
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> The attached patch changes std::weak_p
Hi Arthur!
On 2024-11-25T11:24:08+0100, Arthur Cohen wrote:
> Thanks, this patch (and your other one on the matter) looks good
Oh, wow -- I passed the first non-trivial Rust programming I've done!
:-D ;-)
> but I
> have a slight issue with it. We had previously done something similar to
> ada
Hi All,
For architectures where the vector-length is a compile-time variable,
rather representing a runtime constant, as is the case with SVE it is
perfectly reasonable that such vector be made up of two (or more) subvector
components of a compatible sub-length variable.
One example of this would
Hi All,
This patch adds support for vector constructor from two partial SVE vectors into
a full SVE vector. It also implements support for the standard vec_init obtab to
do this.
gcc/ChangeLog:
PR target/96342
* config/aarch64/aarch64-sve.md (vec_init): New.
(@aarch64_pac
Hi All,
When issuing multiple calls to a simdclone in a vectorized loop,
TYPE_VECTOR_SUBPARTS(vectype) gives the incorrect number when compared
to the TYPE_VECTOR_SUBPARTS result we get from the mask type derived
from the relevant `rgroup_controls' entry within `vect_get_loop_mask'.
By passing `m
On 03/12/2024 18:02, Jonathan Wakely wrote:
On Tue, 3 Dec 2024 at 16:56, Jonathan Wakely wrote:
On Tue, 3 Dec 2024 at 16:19, Giuseppe D'Angelo
wrote:
Hello,
The attached patch changes std::weak_ptr "converting move
constructor/assignment" -- that is, from a rvalue weak_ptr to a
weak_ptr.
Hi All,
While `poly_int64' has been the default representation of bitfield size
and offset for some time, there was a lack of support for the use of
non-constant `poly_int64' values for those values throughout the
compiler, limiting the applicability of the BIT_FIELD_REF rtl expression
for variab
Hi All,
These tests are x86 specific and shouldn't be run for aarch64.
gcc/testsuite/ChangeLog:
PR target/96342
* c-c++-common/gomp/declare-variant-14.c: Make i?86 and x86_64 target
only test.
* gfortran.dg/gomp/declare-variant-14.f90: Likewise.
Bootstrapped Regt
Hi All,
This patch finalizes adding support for the generation of SVE simd clones when
no simdlen is provided, following the ABI rules where the widest data type
determines the minimum amount of elements in a length agnostic vector.
gcc/ChangeLog:
PR target/96342
* config/aarch64
Hi all,
I figured this patch has not been okay'ed yet. Anyone in for a review?
Regtests ok on x86_64-pc-linux-gnu / F39. Ok for trunk?
Regards,
Andre
On Thu, 26 Sep 2024 16:02:21 +0200
Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes an ICE when a derived type was used as a
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
> Update test cases to use -mcpu=unset/-march=unset feature introduced in
> r15-3606-g7d6c6a0d15c.
>
> gcc/testsuite/ChangeLog:
> * gcc.dg/pr41574.c: Added option "-mcpu=unset".
> * gcc.dg/pr59418.c: Likewise.
> * lib/target-supports.
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
> Update test cases to use -mcpu=unset/-march=unset feature introduced in
> r15-3606-g7d6c6a0d15c.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/bfloat16_scalar_1_1.c: Use effective-target
> arm_arch_v8_2a_bf16_hard.
> * gcc.targ
On 21/11/2024 14:24, Torbjörn SVENSSON wrote:
> Update test cases to use -mcpu=unset/-march=unset feature introduced in
> r15-3606-g7d6c6a0d15c.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/other/pr56184.C: Use effective-target
> arm_arch_v7a_neon_thumb.
> * g++.dg/other/pr59985.C:
On 21/11/2024 17:23, Torbjörn SVENSSON wrote:
> I'm not sure how to verify that adding the parameter won't destroy the test.
> I've tried to repoduce the ICE on old Arm builds of arm-none-eabi, but none of
> them ICE. I suppose it should be safe to add the parameter as the PR talks
> about the lite
On 21/11/2024 19:01, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> On Cortex-M4, the code generated is:
> cmp r0, r1
> ittene
> lslne r0, r0, r1
> asrne r0, r0, #1
> moveq r0, r1
> add r0, r0, r1
> bx lr
>
> On C
On 22/11/2024 09:37, Torbjörn SVENSSON wrote:
> Changes since v1:
>
> - Rewrote the padding instructions in the macro to instead write to volatile
> memory. This ensures that every expansion of the base macro is exactly 2
> bytes.
>
> If the `GO()` in f3 is removed, the generated assembly wou
On 25/11/2024 20:08, Christophe Lyon wrote:
> In this PR, we have to handle a case where MVE predicates are supplied
> as a const_int, where individual predicates have illegal boolean
> values (such as 0xc for a 4-bit boolean predicate). To avoid the ICE,
> fix the constant (any non-zero value is
PR bootstrap/117893
* configure.ac: Use shell loop to remove -O flags.
* configure: Regenerate.
diff --git a/gcc/configure.ac b/gcc/configure.ac
index e9bddc6db21..ed8d9596668 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -463,12 +463,28 @@ ACX_PROG_GDC([-I"$srcdi
On 26/11/2024 15:51, David Malcolm wrote:
> OK for trunk?
OK
> (caveat: I haven't done a full test on this patch)
Linaro's CI has, it's clean.
R.
>
> gcc/ChangeLog:
> PR translation/90160
> * config/arm/arm.cc (arm_option_check_internal): Use quotes in
> messages that refer
From: Matthew Malcomson
This setting seems to better match the indentation that is used in GCC.
Adds an exra level of indentation after braces in a case statement.
Only manual testing done on the switch statements in
c-common.cc:resolve_overloaded_builtin and
alias.cc:record_component_aliases.
Hi Jason,
On 3 Dec 2024, at 22:37, Jason Merrill wrote:
> On 12/3/24 12:25 PM, Simon Martin wrote:
>> We currently reject the following valid code:
>>
>> === cut here ===
>> struct Base {
>> virtual void doit (int v) const {}
>> };
>> struct Derived : Base {
>> void doit (int v) const {
On Wed, Dec 4, 2024 at 11:10 AM Andreas Schwab wrote:
>
> PR bootstrap/117893
> * configure.ac: Use shell loop to remove -O flags.
> * configure: Regenerate.
OK.
Richard.
> diff --git a/gcc/configure.ac b/gcc/configure.ac
> index e9bddc6db21..ed8d9596668 100644
> --- a/g
Hi!
I'd like to ping 20 C++ patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658137.html
libcpp, c++: Optimize initializers using #embed in C++
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659333.html
c++: Speed up compilation of large char array initializers when not us
Hi Tobias!
On 2024-12-03T11:28:19+0100, Tobias Burnus wrote:
> Thomas Schwinge wrote:
>> That's a bug in 'libgomp/plugin/plugin-gcn.c:maybe_init_omp_async' (or
>> its users); the real user of ['GOMP_OFFLOAD_openacc_async_construct'] does
>> handle the error condition:
>
> Well, it does not really
This patch reworks patterns that add / subtract an (inverted) MSB.
It handles more cases by using mode iterators.
Ok for trunk?
Johann
--
AVR: Rework patterns that add / subtract an (inverted) MSB.
gcc/
* config/avr/avr-protos.h (avr_out_add_msb): New proto.
* config/avr/avr.c
On Tue, 3 Dec 2024, Richard Biener wrote:
> One large constant factor of SLP discovery is figuring the vector
> type for each individual lane of each node. That should be redundant
> since the structual comparison of stmts should ensure they end up
> the same so the following computes them only o
On Wed, Dec 4, 2024 at 1:00 AM Lewis Hyatt wrote:
>
> On Tue, Dec 3, 2024 at 7:33 AM Richard Biener
> wrote:
> >
> > On Mon, Dec 2, 2024 at 1:50 AM Lewis Hyatt wrote:
> > >
> > > With the codebase having already been prepared to handle it, change
> > > location_t to be a 64-bit integer instead o
LGTM
On Wed, Dec 4, 2024 at 4:31 PM wrote:
>
> From: Pan Li
>
> According to the the initial analysis of PR117878, the ice comes from
> the out-of-range operand access for recog_data.operand[]. Thus, add
> one assert here to expose this explicitly.
>
> PR target/117878
>
> gcc/ChangeLog
I have posted a new version of this patch. The only difference is that patches
#3 and #4 in this patch set are now deleted. Those patches changed the
mnemonic of the MMA instruction from the version used on the power10/power11 to
the new version for dense math registers if -mcpu=future is used.
From: Pan Li
According to the the initial analysis of PR117878, the ice comes from
the out-of-range operand access for recog_data.operand[]. Thus, add
one assert here to expose this explicitly.
PR target/117878
gcc/ChangeLog:
* config/riscv/riscv-v.cc (vlmax_avl_type_p): Add a
This patch is a prelimianry patch to add the full 1,024 bit dense math register
(DMRs) for -mcpu=future. The MMA 512-bit accumulators map onto the top of the
DMR register.
This patch only adds the new 1,024 bit register support. It does not add
support for any instructions that need 1,024 bit re
The MMA subsystem added the notion of accumulator registers as an optional
feature of ISA 3.1 (power10). In ISA 3.1, these accumulators overlapped with
the VSX registers 0..31, but logically the accumulator registers were separate
from the FPR registers. In ISA 3.1, it was anticipated that in fut
This patch adds a new constraint ('wD') that matches the accumulator registers
that overlap with VSX registers 0..31 on power10. Future patches will add the
support for a separate accumulator register class that will be used when the
support for dense math registes is added.
2024-12-04 Michael
I have posted this patch several times over the years. This patch is a minor
update of the patch I posted on November 16th, 2024:
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669140.html
This patch eliminates patches #3 and #4 from the previous patch set. Those
patches change the MMA
I provided an update to this patch here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/670787.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
This is the 2nd version of the patch to add a new include file (vector-pair.h)
that adds support so that users writing high performance libraries can change
their code to allow the generation of the vector pair load and store
instructions on power10.
The previous version of the patch was posted at
Ping patch for PR target/108958, Use mtvsrdd to zero extend GPR DImode to VSX
TImode
Message-ID
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669242.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Ping patch to fix PR target/117251, Add PowerPC XXEVAL support for fusion
optimization in power10
Message-ID
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669138.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
Ping patch to fix PR target/117487, Add power9/power10 float to logical
operations
Message-ID
https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669137.html
--
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com
1 - 100 of 102 matches
Mail list logo