Thomas, Steve,
thanks for the swift feedback!
Am 10.01.25 um 23:57 schrieb Thomas Koenig:
Hello Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
I just started to run a bootstrap on cfarm120 (because it is
the only machine I can lay my hands on where I can run
"make -j128" withou
On Fri, Jan 10, 2025 at 05:19:34PM +, Paul Richard Thomas wrote:
>
> As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
> out of a total of 54 for fortran and libgfortran. It's time that some of
> these bugs are swatted, I think :-)
>
PR 70949 appears to have been fi
On Fri, Jan 10, 2025 at 05:19:34PM +, Paul Richard Thomas wrote:
>
> As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name
> out of a total of 54 for fortran and libgfortran. It's time that some of
> these bugs are swatted, I think :-)
>
This patch fixes PR71844. As th
On Fri, Jan 10, 2025 at 09:41:13PM +, Harald Anlauf wrote:
>
> There is one question to the reviewer(s), or those knowing better
> than me how to handle IEEE infinity and NaN: with -Ofast, I needed
> to add "-fno-finite-math-only" to the new testcase
> gfortran.dg/ieee/out_of_range.f90, as the
When using a proxy object for atomic waiting and notifying operations,
we need to ensure that the _M_ver value is always incremented by a
notifying operation, even if we return early without doing the futex
wake syscall. Otherwise we get missed wake-ups because the notifying
thread doesn't modify t
> Strided load store should demand RATIO instead of SEW and LMUL.
> Is it VSETVL PASS bug ? I don't understand why configure it depand SEW + LMUL
Yeah, you're right, I was looking at indexed loads in the spec...
It's a problem in the vsetvl pass, yes. Half of it I already fixed but the
other hal
This is an equality comparison rather than a three-way comparison like
memcmp and <=>, so name it more precisely.
libstdc++-v3/ChangeLog:
* include/bits/atomic_timed_wait.h
(__atomic_wait_address_until_v): Replace __atomic_compare with
__atomic_eq.
(__atomic_wait_a
Making these non-templates will allow them to be moved into the library
at some point.
libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h (__platform_wait): Change function
template to a normal function. The parameter is always
__platform_wait_t* which is just int* for t
Also add missing precondition check to constructor and fix existing
check in count_down which was duplicated by mistake.
libstdc++-v3/ChangeLog:
PR libstdc++/98749
* include/std/latch (latch::max()): Use std::cmp_less to handle
the case where __platform_wait_t is wider tha
Dear all,
the attached patch is supposed to be a complete implementation of
the F2018 intrinsic OUT_OF_RANGE. This is mostly straightforward,
with runtime code fully expanded inline. It is also extended to
support the new UNSIGNED type of gfortran as of current 15-mainline.
The testcases are cr
On 1/10/25 12:20 AM, Kito Cheng wrote:
Could you rebase and send the patch set again? I can't apply the patch set:
[kitoc@hsinchu18 gcc]$ git am
/tmp/git-pw8sm7zbop/RISC-V-Add-intrinsics-support-and-testcases-for-SiFive-Xsfvcp-extension..patch
Applying: RISC-V: Add intrinsics support for SiFi
On 1/10/25 4:59 PM, Palmer Dabbelt wrote:
On Fri, 10 Jan 2025 12:21:15 PST (-0800), jeffreya...@gmail.com wrote:
On 1/10/25 12:11 PM, Robin Dapp wrote:
Integer values and floating-point values need to be converted
by fmv series instructions. So if mode1 is MODE_INT and mode2
is MODE_FLOAT,
Pushed to r15-6817.
在 2025/1/10 上午10:27, mengqinggang 写道:
Generate 0x1010 instead of 0x101>>12 for lu12i.w. lu32i.d and lu52i.d use
the same processing.
gcc/ChangeLog:
* config/loongarch/lasx.md: Use new loongarch_output_move.
* config/loongarch/loongarch-protos.h (loongarc
On 1/10/25 2:43 PM, Andrew MacLeod wrote:
This should have been done a while ago.
Funny I said kind of the same thing when I did the DOM variant for
integral types a little while back.
The call to simplify MIN and MAX was guarded by a check for INTEGRAL, so
I removed that as the code was
libstdc++-v3/ChangeLog:
* include/bits/atomic_timed_wait.h: Whitespace fixes.
* include/bits/atomic_wait.h: Likewise.
---
libstdc++-v3/include/bits/atomic_timed_wait.h | 198 +-
libstdc++-v3/include/bits/atomic_wait.h | 8 +-
2 files changed, 100 insertions
We don't need to wait if we know the counter has reached zero.
libstdc++-v3/ChangeLog:
* include/std/latch (latch::arrive_and_wait): Optimise.
---
This one's commented out for now, but sending for review anyway.
libstdc++-v3/include/std/latch | 12
1 file changed, 12 inser
> On Jan 10, 2025, at 15:34, Jeff Law wrote:
>
>
>
> On 1/9/25 1:39 PM, Qing Zhao wrote:
>>> On Jan 9, 2025, at 14:10, Jeff Law wrote:
>>>
>>>
>>>
>>> On 1/9/25 10:48 AM, Qing Zhao wrote:
>>>
>
> I think Jeff's patch is not reasonable since it boils down to not diagnose
> -W
Hello Harald,
Regtested on x86_64-pc-linux-gnu. OK for mainline?
I just started to run a bootstrap on cfarm120 (because it is
the only machine I can lay my hands on where I can run
"make -j128" without disturbing anybody :-) and I got
../../trunk/gcc/fortran/trans-intrinsic.cc: In function ‘
Hi,
the zbb-rol-ror and stack_save_restore tests use the -fno-lto option and
scan the final assembly. For an invocation like -flto ... -fno-lto the
output file we scan is still something like
zbb-rol-ror-09.ltrans0.ltrans.s.
Therefore skip the tests when "-flto" is present. This gets rid
of a
Hi,
in PR118154 we emit strided stores but the first of those does not
always have the proper VTYPE. That's because we assume it only
demands an SEW/LMUL ratio rather than the proper SEW and LMUL and
subsequently optimize away the accompanying vsetvl.
This patch corrects the ratio attribute for
Hi,
in PR118140 we simplify
_ifc__33 = .COND_IOR (_41, d_lsm.7_11, _46, d_lsm.7_11);
to "1":
Match-and-simplified .COND_IOR (_41, d_lsm.7_11, _46, d_lsm.7_11) to 1
when _46 == 1. This happens by removing the conditional and applying
a | 1 = 1. Normally we re-introduce the conditional and
Strided load store should demand RATIO instead of SEW and LMUL.
Is it VSETVL PASS bug ? I don't understand why configure it depand SEW + LMUL
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2025-01-10 16:42
To: gcc-patches
CC: pal...@dabbelt.com; kito.ch...@gmail.com; juzhe.zh...@rivai.ai;
jeffr
Hi!
In the following testcase there are 2 issues, one is that B doesn't
have operator<=> and the other is that A's operator<=> has int return
type, i.e. not the standard comparison category.
Because of the int return type, retcat is cc_last; when we first
try to synthetize it, it is therefore with
"Richard Earnshaw (lists)" writes:
> On 09/01/2025 14:50, Christophe Lyon wrote:
>> The previous fix only worked for C, for C++ we need to add more
>> information to the underlying type so that
>> finish_class_member_access_expr accepts it.
>>
>> We use the same logic as in aarch64's register_tup
> On 10 Jan 2025, at 00:07, Tamar Christina wrote:
>
> Hi All,
>
> The Parts Num field for the MIDR for Cortex-X4 is wrong. It's currently the
> parts number for a Cortex-A720 (which does have the right number).
>
> The correct number can be found in the Cortex-X4 Technical Reference Manual
As Jakub pointed out in PR118206, the use of uniform_integer_cst_p in
ifcombine makes no sense, we're not dealing with vectors. Indeed,
I've been misunderstanding and misusing it since I cut&pasted it from
some preexisting match predicate in earlier version of the ifcombine
field-merge patch.
R
On Fri, 10 Jan 2025, Alexandre Oliva wrote:
>
> As Jakub pointed out in PR118206, the use of uniform_integer_cst_p in
> ifcombine makes no sense, we're not dealing with vectors. Indeed,
> I've been misunderstanding and misusing it since I cut&pasted it from
> some preexisting match predicate in
writes:
> This patch adds a warning when FMV is used for Aarch64.
>
> The reasoning for this is the ACLE [1] spec for FMV has diverged
> significantly from the current implementation and we want to prevent
> potential future compatability issues.
>
> There is a patch for an ACLE compliant version
On 09/01/2025 21:42, Torbjörn SVENSSON wrote:
> Changes since v1:
>
> - Added dg-add-options arm_arch_v5te_thumb
> - Added -std=c17 to dg-options.
> - Removed -march=armv5te -mfloat-abi=soft -mthumb from dg-options
> - Updated the commit message to reflect the new changes
>
> Note: This changes f
On 2025-01-10 11:19, Richard Earnshaw (lists) wrote:
On 09/01/2025 21:42, Torbjörn SVENSSON wrote:
Changes since v1:
- Added dg-add-options arm_arch_v5te_thumb
- Added -std=c17 to dg-options.
- Removed -march=armv5te -mfloat-abi=soft -mthumb from dg-options
- Updated the commit message to re
On 22/12/2024 15:35, Torbjorn SVENSSON wrote:
>
>
> On 2024-12-19 12:48, Richard Earnshaw (lists) wrote:
>> On 18/12/2024 16:24, Torbjörn SVENSSON wrote:
>>> Changes since v1:
>>>
>>> - Updated the commit message to reflect the changes (including the subject).
>>> - Replaced the POP/BEQ checks wi
On 2025-01-10 11:27, Richard Earnshaw (lists) wrote:
On 22/12/2024 15:35, Torbjorn SVENSSON wrote:
On 2024-12-19 12:48, Richard Earnshaw (lists) wrote:
On 18/12/2024 16:24, Torbjörn SVENSSON wrote:
Changes since v1:
- Updated the commit message to reflect the changes (including the subje
On Thu, Jan 9, 2025 at 9:39 PM Qing Zhao wrote:
>
>
>
> > On Jan 9, 2025, at 14:10, Jeff Law wrote:
> >
> >
> >
> > On 1/9/25 10:48 AM, Qing Zhao wrote:
> >
> >>>
> >>> I think Jeff's patch is not reasonable since it boils down to not diagnose
> >>> -Warray-bounds but instead remove those stmts.
Hi!
Seems I forgot to set_c_expr_source_range for the __builtin_stdc_rotate_*
case (the other __builtin_stdc_* cases already have it), which means
the locations in expr are uninitialized, sometimes causing ICEs in linemap
code, at other times just valgrind errors about uninitialized var uses.
Boo
From: Piotr Trojanek
Several AST nodes had their syntactic fields in a different order than
specified by the Ada RM grammar. With the variable-size nodes this no longer
had an impact on the AST memory layout and was making the automatically
generated Nmake routines a bit unintuitive to use.
gcc/
From: Piotr Trojanek
For a USE clause being effective is a semantic property, not a syntactic.
AST cleanup; behavior is unaffected.
gcc/ada/ChangeLog:
* gen_il-gen-gen_nodes.adb (Gen_Nodes): Change Is_Effective_Use_Clause
from syntactic to semantic property.
Tested on x86_64-pc
gcc/ada/ChangeLog:
* env.h: Remove last empty line.
Tested on x86_64-pc-linux-gnu, committed on master.
---
gcc/ada/env.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/ada/env.h b/gcc/ada/env.h
index b80b7e9a0fc..58a92b9d7f2 100644
--- a/gcc/ada/env.h
+++ b/g
"Robin Dapp" writes:
> Hi,
>
> in PR118140 we simplify
>
> _ifc__33 = .COND_IOR (_41, d_lsm.7_11, _46, d_lsm.7_11);
>
> to "1":
>
> Match-and-simplified .COND_IOR (_41, d_lsm.7_11, _46, d_lsm.7_11) to 1
>
> when _46 == 1. This happens by removing the conditional and applying
> a | 1 = 1. Nor
From: Piotr Trojanek
When creating a node, we can directly set its syntactic properties.
Code cleanup; semantics is unaffected.
gcc/ada/ChangeLog:
* contracts.adb (Build_Call_Helper_Decl): Tune whitespace.
* exp_attr.adb (Analyze_Attribute): Set Of_Present while
creating
From: squirek
The patch fixes an issue in the compiler whereby accessibility level
calculations for objects declared witihin library-level subprograms
were done incorrectly - potentially allowing runtime accessibility
checks to spuriously pass.
gcc/ada/ChangeLog:
* accessibility.adb:
Hello,
On Wed, Dec 11 2024, Martin Jambor wrote:
> Hello,
>
> even though it is not my work, I would like to ping this patch. Having
> it upstream would really help us a lot.
>
Please, pretty please, consider reviewing this in time for GCC 15,
having it upstream would really help us a lot and fr
We currently accept the following invalid code (EDG and MSVC do as well)
=== cut here ===
struct A {
*A ();
};
=== cut here ===
The problem is that we end up in grokdeclarator with a cp_declarator of
kind cdk_pointer but no type, and we happily go through (if we have a
reference instead we even
On 1/6/25 5:01 PM, Hans-Peter Nilsson wrote:
Regtested native x86_64-linux. Also tested mmix-knuth-mmixware,
where it fixes ONE testcase, but one which is a regression on
master. The PR component is currently ipa, changed from the
original middle-end. IIUC this bug-fix doesn't fit the ipa
c
This should have been done a while ago.
The call to simplify MIN and MAX was guarded by a check for INTEGRAL, so
I removed that as the code was already generalized to work with any type.
And no attempt was being made to pass in a relation... so I query for a
relation between op0 and op1, and
On Fri, 10 Jan 2025 12:21:15 PST (-0800), jeffreya...@gmail.com wrote:
On 1/10/25 12:11 PM, Robin Dapp wrote:
Integer values and floating-point values need to be converted
by fmv series instructions. So if mode1 is MODE_INT and mode2
is MODE_FLOAT, we should return false in riscv_modes_tieable
On 1/7/25 7:24 PM, YunQiang Su wrote:
Jeff Law 于2025年1月8日周三 07:06写道：
On 1/1/25 6:42 PM, YunQiang Su wrote:
Matthias Klose 于2025年1月1日周三 22:37写道：
in https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641619.html
there are two typos in the patch, compared to the local Debian patch,
On Linux/x86_64,
68326d5d1a593dc0bf098c03aac25916168bc5a9 is the first bad commit
commit 68326d5d1a593dc0bf098c03aac25916168bc5a9
Author: Alex Coplan
Date: Mon Mar 11 13:09:10 2024 +
vect: Force alignment peeling to vectorize more early break loops [PR118211]
caused
FAIL: gcc.dg/tree
On Linux/x86_64,
f4e259b4a66c81c234608056117836e13606e4c8 is the first bad commit
commit f4e259b4a66c81c234608056117836e13606e4c8
Author: Alex Coplan
Date: Thu Jul 25 16:34:05 2024 +
vect: Ensure we add vector skip guard even when versioning for aliasing
[PR118211]
caused
FAIL: gcc.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
30_threads/stop_token/stop_source/109339.cc was failing because we weren't
representing attribute access on the METHOD_TYPE for _Stop_state_ref.
The modules code expected attributes to appear on tt_variant_type and not
on tt_derived_type, b
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
std/time/traits/is_clock.cc was getting a warning about applying the
deprecated attribute to a variant of auto_ptr, which was wrong because it's
on the primary type. This turned out to be because we were ignoring the
attributes on the defin
On Fri, Jan 10, 2025 at 10:45:18AM +0100, Jakub Jelinek wrote:
> Hi!
>
> Seems I forgot to set_c_expr_source_range for the __builtin_stdc_rotate_*
> case (the other __builtin_stdc_* cases already have it), which means
> the locations in expr are uninitialized, sometimes causing ICEs in linemap
> c
Akram Ahmad writes:
> Rename the existing SVE unpredicated saturating arithmetic instructions
> to use standard names which are used by IFN_SAT_ADD and IFN_SAT_SUB.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-sve.md: Rename insns
>
> gcc/testsuite/ChangeLog:
>
> * gcc/testsuite/gcc
ILP32 was originally intended to make porting to AArch64 easier. Support was
never merged in the Linux kernel or GLIBC, so it has been unsupported for many
years. There isn't a benefit in keeping unsupported features forever, so
deprecate it now (and it could be removed in a future release).
Pa
ping
Add FULLY_PIPELINED_FMA to tune baseline - this is a generic feature that is
already enabled for some cores, but benchmarking it shows it is faster on all
modern cores (SPECFP improves ~0.17% on Neoverse V1 and 0.04% on Neoverse N1).
Passes regress & bootstrap, OK for commit?
gcc/ChangeLo
ping
Add AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS and
AARCH64_EXTRA_TUNE_MATCHED_VECTOR_THROUGHPUT
to the baseline tuning since all modern cores use it. Fix the neoverse512tvb
tuning to be
like Neoverse V1/V2.
gcc/ChangeLog:
* config/aarch64/aarch64-tuning-flags.def (AARCH64_EXTRA_TU
On Sun, 8 Dec 2024 at 15:36, Jan Hubicka wrote:
>
> Hi,
> std::vector has independent implementation for bool which has its won
> size/capacity functions. I updated them to add __builtin_unreachable to
> announce that size is never more than max_size. However while testing the
> code
> I notice
> On 10 Jan 2025, at 15:30, Richard Sandiford wrote:
>
> Wilco Dijkstra writes:
>> As a minor cleanup remove Cortex-A57 FMA steering pass. Since Cortex-A57 is
>> pretty old, there isn't any benefit of keeping this.
>>
>> Passes regress & bootstrap, OK for commit?
>>
>> gcc:
>> * config.gcc
On Fri, 10 Jan 2025 at 14:51, Jonathan Wakely wrote:
>
> On Sun, 8 Dec 2024 at 15:36, Jan Hubicka wrote:
> >
> > Hi,
> > std::vector has independent implementation for bool which has its won
> > size/capacity functions. I updated them to add __builtin_unreachable to
> > announce that size is nev
> On 10 Jan 2025, at 15:54, Wilco Dijkstra wrote:
>
> ping
>
>
> Add AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS and
> AARCH64_EXTRA_TUNE_MATCHED_VECTOR_THROUGHPUT
> to the baseline tuning since all modern cores use it. Fix the neoverse512tvb
> tuning to be
> like Neoverse V1/V2.
For neovers
Ah whoops- I didn't see this before sending off V4 just now, my apologies.
I'll try my best to get this implemented before the end of the day so that
it doesn't miss the deadline.
On 09/01/2025 23:04, Richard Sandiford wrote:
Akram Ahmad writes:
In the above example, subtraction replaces the a
Hi!
The following patch on top of
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673177.html
(in review currently)
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672055.html
(acked but waiting for the former)
https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672438.html
https
The std::barrier constructor should be constexpr, which means we need to
defer the dynamic allocation if the constructor is called during
constant-initialization. We can defer it to the first call to
barrier::arrive, using compare-and-swap on an atomic (instead of the
unique_ptr currently used).
A
Denormal behaviour is well defined for IEEE128 long doubles, so don't
XFAIL some gfortran tests on ppc64le when configured with the IEEE128
long double ABI.
gcc/testsuite/ChangeLog:
PR testsuite/118127
* lib/target-supports.exp
(check_effective_target_ppc_default_long_doub
Thank you both for feedback.
On 10/01/2025 10:47, Kyrylo Tkachov wrote:
On 10 Jan 2025, at 11:22, Richard Sandiford wrote:
writes:
This patch adds a warning when FMV is used for Aarch64.
The reasoning for this is the ACLE [1] spec for FMV has diverged
significantly from the current implemen
The first change is a simple, generic Fortran change.
Without it, external declarations have odd locations
(namely their input_location):
gcc/testsuite/gfortran.dg/gomp/dispatch-11.f90:67:46:
67 | !$omp dispatch interop(obj2, obj1) device(3)
|
Wilco Dijkstra writes:
> As a minor cleanup remove Cortex-A57 FMA steering pass. Since Cortex-A57 is
> pretty old, there isn't any benefit of keeping this.
>
> Passes regress & bootstrap, OK for commit?
>
> gcc:
> * config.gcc (extra_objs): Remove cortex-a57-fma-steering.o.
> * config
Hi All,
This is a backport version of the same patch as
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671618.html
for the release branches. I'd like to backport this to GCC 14,13 and 12 where
the first regression showed up. I am however aware that GCC 12 is going to
get it's last rele
On Fri, 10 Jan 2025 at 14:32, Tamar Christina wrote:
>
> Hi All,
>
> This is a backport version of the same patch as
> https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671618.html
>
> for the release branches. I'd like to backport this to GCC 14,13 and 12 where
> the first regression showe
> -Original Message-
> From: Jonathan Wakely
> Sent: Friday, January 10, 2025 2:36 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; libstd...@gcc.gnu.org
> Subject: Re: [PATCH][libstdc++]: backport inline keyword on std::find
>
> On Fri, 10 Jan 2025 at 14:32, Tamar Christin
On Thu, Jan 09, 2025 at 06:00:34PM +, Richard Sandiford wrote:
> Richard Sandiford writes:
> > Andrew Carlotti writes:
> >> On Mon, Nov 25, 2024 at 11:26:39PM +, Richard Sandiford wrote:
> >>> Sorry for the slow review.
> >>>
> >>> Andrew Carlotti writes:
> >>> > These new flags (+fcma,
On Fri, 27 Dec 2024 at 20:13, Jan Hubicka wrote:
>
> Hi,
> the following testcase:
>
> bool f(const std::vector& v, std::size_t x) {
> return v[x];
> }
>
> is compiled as:
>
> f(std::vector > const&, unsigned long):
> testq %rsi, %rsi
> leaq63(%rsi), %rax
> mo
Pushed as obvious.
* gcse.cc (pass_hardreg_pre::gate): Wrap possibly unused
fun argument.
---
gcc/gcse.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/gcse.cc b/gcc/gcse.cc
index 3f3f7fe15b0..4ae19f28430 100644
--- a/gcc/gcse.cc
+++ b/gcc/gcse.cc
@@ -435
Hi Kyrill,
Thanks for the very quick response! V4 of the patch can be found
below the line.
Best wishes,
Akram
---
This renames the existing {s,u}q{add,sub} instructions to use the
standard names {s,u}s{add,sub}3 which are used by IFN_SAT_ADD and
IFN_SAT_SUB.
The NEON intrinsics for saturatin
ping
Simplify and cleanup ifunc selection logic. Since LRCPC3 does
not imply LSE2, has_rcpc3() should also check LSE2 is enabled.
Passes regress and bootstrap, OK for commit?
libatomic:
* config/linux/aarch64/host-config.h (has_lse2): Cleanup.
(has_lse128): Likewise.
(
As a minor cleanup remove Cortex-A57 FMA steering pass. Since Cortex-A57 is
pretty old, there isn't any benefit of keeping this.
Passes regress & bootstrap, OK for commit?
gcc:
* config.gcc (extra_objs): Remove cortex-a57-fma-steering.o.
* config/aarch64/aarch64-passes.def: Remo
On Fri, Jan 10, 2025 at 3:27 PM Qing Zhao wrote:
>
>
>
> > On Jan 10, 2025, at 03:00, Richard Biener
> > wrote:
> >
> > On Thu, Jan 9, 2025 at 9:39 PM Qing Zhao wrote:
> >>
> >>
> >>
> >>> On Jan 9, 2025, at 14:10, Jeff Law wrote:
> >>>
> >>>
> >>>
> >>> On 1/9/25 10:48 AM, Qing Zhao wrote:
>
On 09/01/2025 23:04, Richard Sandiford wrote:
+ gcc_assert (imm != 0);
The constraints do allow 0, so I'm not sure this assert is safe.
Certainly we shouldn't usually get unfolded instructions, but strange
things can happen with fuzzed options.
Does the code mishandle that case? It looke
The following fixes memory leaks found compiling SPEC CPU 2017 with
valgrind.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
* df-core.cc (rest_of_handle_df_finish): Release dflow for
problems without free function (like LR).
* gimple-crc-optimization.cc (c
Wilco Dijkstra writes:
> ILP32 was originally intended to make porting to AArch64 easier. Support was
> never merged in the Linux kernel or GLIBC, so it has been unsupported for many
> years. There isn't a benefit in keeping unsupported features forever, so
> deprecate it now (and it could be re
Hi Wilco,
> On 10 Jan 2025, at 15:05, Wilco Dijkstra wrote:
>
>
> ILP32 was originally intended to make porting to AArch64 easier. Support was
> never merged in the Linux kernel or GLIBC, so it has been unsupported for many
> years. There isn't a benefit in keeping unsupported features foreve
On Tue, Jan 07, 2025 at 06:17:02PM +, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > I forgot to include this in the earlier patch; is this ok for master (once
> > the
> > pass is merged, of course)?
> >
> > gcc/ChangeLog:
> >
> > * doc/passes.texi: Document hardreg PRE pass.
> >
On Jan 10 2025, Wilco Dijkstra wrote:
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index
> 17fe2c64c1f85ad8db8b61f040aafe5f8212e488..6722ad5281541e499d5b3916179d9a4d1b39097f
> 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -21472,6 +21472,8 @@ The default depen
> On Jan 10, 2025, at 03:00, Richard Biener wrote:
>
> On Thu, Jan 9, 2025 at 9:39 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jan 9, 2025, at 14:10, Jeff Law wrote:
>>>
>>>
>>>
>>> On 1/9/25 10:48 AM, Qing Zhao wrote:
>>>
>
> I think Jeff's patch is not reasonable since it boils down
The commit message contains an explanation.
commit 94d8de53388793f4d5fc0d0aa00fef32ca4aa870
Author: Vladimir N. Makarov
Date: Fri Jan 10 10:36:24 2025 -0500
[PR118017][LRA]: Fix test for i686
My previous patch for PR118017 contains a test which fails on i686. The patch fixes this
On 07/01/2025 20:16, Torbjörn SVENSSON wrote:
> Ok for trunk and releases/gcc-14?
>
> --
>
> Since armv8-m.base uses thumb1 that does not suport sigcall/tailcall,
> a pattern is needed that uses PUSH/BL/POP sequence instead of a single
> B instruction to reuse an already existing function in the
The following puts in a hard limit on ext-dce because it might end
up requiring memory on the order of the number of basic blocks
times the number of pseudo registers. The limiting follows what
GCSE based passes do and thus I re-use --param max-gcse-memory here.
This doesn't in any way address th
Richard Biener writes:
> On Mon, Jan 6, 2025 at 2:12 PM Richard Sandiford
> wrote:
>>
>> g:d882fe5150fbbeb4e44d007bb4964e5b22373021, posted at
>> https://gcc.gnu.org/pipermail/gcc-patches/2000-July/033786.html ,
>> added code to treat:
>>
>> (set (reg:CC cc) (compare:CC (gt:M (reg:CC cc) 0) (lt
On 2025-01-06 11:34, Jakub Jelinek wrote:
That looks incorrect to me.
ppc_ieee128_ok just means that one can use the __ieee128 type (and only if
-mfloat128 option is passed).
What the tests care is whether real(16) is IEEE128 or IBM128.
That is dependent on what glibc gcc has been configured agai
The following were found compiling SPEC CPU 2017 with valgrind.
Bootstrap and regtest pending on x86_64-unknown-linux-gnu.
* tree-vect-slp.cc (vect_analyze_slp): Release saved_stmts
vector.
(vect_build_slp_tree_2): Release new_oprnds_info when not
used.
---
gcc/tr
Hi Tobias,
On 07/01/2025 12:13, Tobias Burnus wrote:
Paul-Antoine Arras wrote:
This is a followup to
ed49709acda OpenMP: C++ front-end support for dispatch + adjust_args.
The call to cp_parser_omp_dispatch only belongs in
cp_parser_omp_construct. In
cp_parser_pragma, handle PRAGMA_OMP_DISPATC
Hi Kyrill,
>> Add AARCH64_EXTRA_TUNE_USE_NEW_VECTOR_COSTS and
>> AARCH64_EXTRA_TUNE_MATCHED_VECTOR_THROUGHPUT
>> to the baseline tuning since all modern cores use it. Fix the
>> neoverse512tvb tuning to be
>> like Neoverse V1/V2.
>
> For neoversev512tvb this means adding AARCH64_EXTRA_TUNE_AVOI
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
We need to remember that the ::operator new is replaceable to avoid a bogus
error about __builtin_operator_new finding a non-replaceable function.
This affected __get_temporary_buffer in stl_tempbuf.h.
gcc/cp/ChangeLog:
* module.c
Integer values and floating-point values need to be converted
by fmv series instructions. So if mode1 is MODE_INT and mode2
is MODE_FLOAT, we should return false in riscv_modes_tieable_p,
and vice versa.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_modes_tieable_p):
gcc/testsuite/Change
Akram Ahmad writes:
> Ah whoops- I didn't see this before sending off V4 just now, my apologies.
> I'll try my best to get this implemented before the end of the day so that
> it doesn't miss the deadline.
No rush! The delay here is entirely my fault, so no problem if the
patch lands early stage
On Fri, Jan 10, 2025 at 6:06 AM Wilco Dijkstra wrote:
>
>
> ILP32 was originally intended to make porting to AArch64 easier. Support was
> never merged in the Linux kernel or GLIBC, so it has been unsupported for many
> years. There isn't a benefit in keeping unsupported features forever, so
> d
Aside from moving the functions, the only changes are to make them
non-static, and to use the existing info arrays within aarch64-common.cc
instead of the info arrays remaining in aarch64.cc.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(aarch64_get_all_extension_candi
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(aarch64_get_all_extension_candidates): Inline into...
(aarch64_print_hint_for_extensions): ...this.
diff --git a/gcc/common/config/aarch64/aarch64-common.cc
b/gcc/common/config/aarch64/aarch64-common.cc
index
5cc
Add infrastructure to allow rewriting the architecture strings passed to
the assembler (either as -march options or .arch directives). There was
already canonicalisation everywhere except for an -march driver option
passed directly to the compiler; this patch applies the same
canonicalisation ther
Replace `const struct processor *` in output parameters with
`aarch64_arch` or `aarch64_cpu`.
Replace `std:string` parameter in aarch64_print_hint_for_extensions with
`char *`.
Also name the return parameters more clearly and consistently.
gcc/ChangeLog:
* config/aarch64/aarch64.cc
Features from a cpu or base architecture that were explicitly disabled
by a +nofeat option were being incorrectly added back in before checking
for conflicts between -mcpu and -march options. This patch instead
compares the returned feature masks directly.
gcc/ChangeLog:
* config/aarch64
1 - 100 of 154 matches
Mail list logo
