On Tue, Mar 26, 2024 at 11:37 PM Peter Damianov wrote:
>
> lto-wrapper generates Makefiles that use the following:
> touch -r file file.tmp && mv file.tmp file
> to truncate files.
> If there is no suitable "touch" or "mv" available, then this errors with
> "The system cannot find the file specifi
Hi,
This patch folds builtin_isinf on IBM long double to builtin_isinf on
double type. The former patch
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648304.html
implemented the DFmode isinf_optab.
Bootstrapped and tested on powerpc64-linux BE and LE with no
regressions. Is it OK for ne
On Tue, Mar 26, 2024 at 10:52 AM Xi Ruoyao wrote:
>
> The latency of LA464 and LA664 division instructions depends on the
> input. When I updated the costs in r14-6642, I unintentionally set the
> division costs to the best-case latency (when the first operand is 0).
> Per a recent discussion [1]
I accidentally replied off-list. Sorry.
27 Mar 2024 8:09:30 am Peter0x44 :
27 Mar 2024 7:51:26 am Richard Biener :
On Tue, Mar 26, 2024 at 11:37 PM Peter Damianov
wrote:
lto-wrapper generates Makefiles that use the following:
touch -r file file.tmp && mv file.tmp file
to truncate files.
If
This is broken on GCC 13 and 14 (https://compiler-explorer.com/z/GPKGPGs6T)
Tested on x86_64-linux-gnu.
OK for trunk and 13?
--- 8< -
This resolves failures in the "expensive" where-* test of check-simd
when targeting AVX-512.
Signed-off-by: Matthias Kre
On Wed, Mar 27, 2024 at 9:13 AM Peter0x44 wrote:
>
> I accidentally replied off-list. Sorry.
>
> 27 Mar 2024 8:09:30 am Peter0x44 :
>
>
> 27 Mar 2024 7:51:26 am Richard Biener :
>
> > On Tue, Mar 26, 2024 at 11:37 PM Peter Damianov
> > wrote:
> >>
> >> lto-wrapper generates Makefiles that use the
On 2024-03-27 01:58, Richard Biener wrote:
On Wed, Mar 27, 2024 at 9:13 AM Peter0x44
wrote:
I accidentally replied off-list. Sorry.
27 Mar 2024 8:09:30 am Peter0x44 :
27 Mar 2024 7:51:26 am Richard Biener :
> On Tue, Mar 26, 2024 at 11:37 PM Peter Damianov
> wrote:
>>
>> lto-wrapper gener
On Wed, 27 Mar 2024 at 08:51, Matthias Kretz wrote:
>
> This is broken on GCC 13 and 14 (https://compiler-explorer.com/z/GPKGPGs6T)
>
> Tested on x86_64-linux-gnu.
>
> OK for trunk and 13?
OK for both, thanks.
>
> --- 8< -
>
> This resolves failures in th
On Fri, 8 Mar 2024 at 09:58, Matthias Kretz wrote:
>
> Hi,
>
> I applied and did extended testing on x86_64 (no regressions) and aarch64
> using qemu testing SVE 256, 512, and 1024. Looks good!
>
> While going through the applied patch I noticed a few style issues that I
> simply turned into a patc
Jonathan Wakely writes:
> On Fri, 8 Mar 2024 at 09:58, Matthias Kretz wrote:
>>
>> Hi,
>>
>> I applied and did extended testing on x86_64 (no regressions) and aarch64
>> using qemu testing SVE 256, 512, and 1024. Looks good!
>>
>> While going through the applied patch I noticed a few style issues
On 3/26/24 12:26, Richard Sandiford wrote:
Victor Do Nascimento writes:
Given how, at present, the choice of using LSE128 atomic instructions
by the toolchain is delegated to run-time selection in the form of
Libatomic ifuncs, responsible for querying target support, the
`+lse128' target archit
On Tue, Mar 26, 2024 at 02:28:52PM +, Cupertino Miranda wrote:
> GCC was defining bts_offset entry to always contain 0.
> When comparing with clang, the same entry is instead a label to the
> respective variable or function. The assembler emits relocations for
> those labels.
>
> gcc/ChangeLog
Hi!
As written in the PR, torture/bitint-64.c test fails with -O2 -flto
and the reason is that on _BitInt arches where the padding bits
are undefined, the padding bits in the _Atomic vars are also undefined,
but when __atomic_load or __atomic_exchange on a _BitInt _Atomic variable
with some paddin
On Wednesday, 27 March 2024 11:07:14 CET Richard Sandiford wrote:
> I'm still worried about:
>
> #if _GLIBCXX_SIMD_HAVE_SVE
> constexpr inline int __sve_vectorized_size_bytes = __ARM_FEATURE_SVE_BITS
> / 8; #else
> constexpr inline int __sve_vectorized_size_bytes = 0;
> #endif
>
> and the
Hi!
The following patch attempts to fix the (view_convert (convert@0 @1))
optimization. If TREE_TYPE (@0) is a _BitInt type with padding bits
and @0 has the same precision as @1 and it has a different sign
and _BitInt with padding bits are extended on the target (x86 doesn't,
aarch64 doesn't, but
On Wed, 2024-03-27 at 10:38 +0800, chenglulu wrote:
>
> 在 2024/3/26 下午5:48, Xi Ruoyao 写道:
> > The latency of LA464 and LA664 division instructions depends on the
> > input. When I updated the costs in r14-6642, I unintentionally set the
> > division costs to the best-case latency (when the first
Hi!
These tests FAIL for quite a while on i686-linux since July last year,
likely r14-2628 . Since that patch gcc claims _Float16 and __bf16
support even without -msse2 because some functions could be using
target attribute.
Later r14-2691 added -msse2 to add_options_for_float16, but didn't do th
On Wed, Mar 27, 2024 at 11:48 AM Jakub Jelinek wrote:
>
> Hi!
>
> These tests FAIL for quite a while on i686-linux since July last year,
> likely r14-2628 . Since that patch gcc claims _Float16 and __bf16
> support even without -msse2 because some functions could be using
> target attribute.
> La
Jeff,
just a heads-up that that trunk (i.e., the soon-to-be GCC14) still
generates the suboptimal sequence:
https://godbolt.org/z/K9YYEPsvY
Thanks,
Philipp.
On Mon, 21 Nov 2022 at 18:00, Philipp Tomsich wrote:
>
> On Sun, 20 Nov 2022 at 17:38, Jeff Law wrote:
> >
> >
> > On 11/9/22 16:10, P
Hi!
We got internally a question about the Spec File syntax, misunderstanding
what is the literal syntax and what are the placeholder variables in
the syntax descriptions.
The following patch attempts to use @var{S} etc. instead of just S
to clarify it stands for any option (or start of option etc
On Wed, Mar 27, 2024 at 11:18:49AM +0100, Jakub Jelinek wrote:
> > -/* The offset entry for each variable in a DATSEC should be 0 at compile
> > time. */
> > -/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 7 } } */
> > +/* The offset entry for each variable in a DATSEC should
I remind you that the patch for the computation of complexity for unsupported
addressing modes ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429 ) has
been sent:
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647966.html
On Wed, Mar 27, 2024 at 10:13 AM peter0x44 wrote:
>
> On 2024-03-27 01:58, Richard Biener wrote:
> > On Wed, Mar 27, 2024 at 9:13 AM Peter0x44
> > wrote:
> >>
> >> I accidentally replied off-list. Sorry.
> >>
> >> 27 Mar 2024 8:09:30 am Peter0x44 :
> >>
> >>
> >> 27 Mar 2024 7:51:26 am Richard Bi
On Wed, 27 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> The following patch attempts to fix the (view_convert (convert@0 @1))
> optimization. If TREE_TYPE (@0) is a _BitInt type with padding bits
> and @0 has the same precision as @1 and it has a different sign
> and _BitInt with padding bits are ex
The following makes sure to record the scalars we add to the BB
reduction vectorization result as scalar uses for the purpose of
computing live lanes. This restores vectorization in the
bondfree.c TU of 435.gromacs.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-opt
Hi Richard,
sorry for not answering sooner. I took action on your mail but failed to also
give feedback. Now in light of your veto of Srinivas patch I wanted to use the
opportunity to pick this up again.
On Dienstag, 23. Januar 2024 21:57:23 CET Richard Sandiford wrote:
> However, we also suppo
Matthias Kretz writes:
> On Wednesday, 27 March 2024 11:07:14 CET Richard Sandiford wrote:
>> I'm still worried about:
>>
>> #if _GLIBCXX_SIMD_HAVE_SVE
>> constexpr inline int __sve_vectorized_size_bytes = __ARM_FEATURE_SVE_BITS
>> / 8; #else
>> constexpr inline int __sve_vectorized_size_by
On Wed, Mar 27, 2024 at 12:48:29PM +0100, Richard Biener wrote:
> > The following patch attempts to fix the (view_convert (convert@0 @1))
> > optimization. If TREE_TYPE (@0) is a _BitInt type with padding bits
> > and @0 has the same precision as @1 and it has a different sign
> > and _BitInt with
On Wed, 2024-03-27 at 08:54 +0100, Richard Biener wrote:
> On Tue, Mar 26, 2024 at 10:52 AM Xi Ruoyao wrote:
> >
> > The latency of LA464 and LA664 division instructions depends on the
> > input. When I updated the costs in r14-6642, I unintentionally set the
> > division costs to the best-case
On Wed, Mar 27, 2024 at 1:20 PM Xi Ruoyao wrote:
>
> On Wed, 2024-03-27 at 08:54 +0100, Richard Biener wrote:
> > On Tue, Mar 26, 2024 at 10:52 AM Xi Ruoyao wrote:
> > >
> > > The latency of LA464 and LA664 division instructions depends on the
> > > input. When I updated the costs in r14-6642, I
On Wed, 27 Mar 2024, Jakub Jelinek wrote:
> On Wed, Mar 27, 2024 at 12:48:29PM +0100, Richard Biener wrote:
> > > The following patch attempts to fix the (view_convert (convert@0 @1))
> > > optimization. If TREE_TYPE (@0) is a _BitInt type with padding bits
> > > and @0 has the same precision as
On Wed, 2024-03-27 at 18:39 +0800, Xi Ruoyao wrote:
> On Wed, 2024-03-27 at 10:38 +0800, chenglulu wrote:
> >
> > 在 2024/3/26 下午5:48, Xi Ruoyao 写道:
> > > The latency of LA464 and LA664 division instructions depends on the
> > > input. When I updated the costs in r14-6642, I unintentionally set th
On Wed, 17 Jan 2024, Jonathan Wakely wrote:
>
>
> On Wed, 17 Jan 2024, 02:37 Patrick Palka, wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
>
> OK
Thanks a lot. For the record I ended up not pushing this patch because
all the range adaptors it touches are C++23
On Wed, 27 Mar 2024 at 12:13, Richard Sandiford
wrote:
>
> Matthias Kretz writes:
> > On Wednesday, 27 March 2024 11:07:14 CET Richard Sandiford wrote:
> >> I'm still worried about:
> >>
> >> #if _GLIBCXX_SIMD_HAVE_SVE
> >> constexpr inline int __sve_vectorized_size_bytes = __ARM_FEATURE_SVE_
And one more to fix follow-up / remaining failures. Tested on x86_64-linux-
gnu.
OK for trunk and 13?
8< --
This resolves further failures (-Wreturn-type warnings) and test
failures for where-* tests targeting AVX-512.
Signed-off-by: Matthias Kretz
libstdc++-v3/Change
On Wed, 27 Mar 2024 at 12:48, Matthias Kretz wrote:
>
> And one more to fix follow-up / remaining failures. Tested on x86_64-linux-
> gnu.
>
> OK for trunk and 13?
OK for both, thanks.
>
> 8< --
>
> This resolves further failures (-Wreturn-type warnings) and test
> fail
Hi!
On 2024-03-22T14:15:36+, Andrew Stubbs wrote:
> On 22/03/2024 08:43, Richard Biener wrote:
> Thanks, here's what I pushed.
> vect: more oversized bitmask fixups
>
> These patches fix up a failure in testcase vect/tsvc/vect-tsvc-s278.c when
> configured to use V32 instead of V64 (I plan t
Matthias Kretz writes:
> Hi Richard,
>
> sorry for not answering sooner. I took action on your mail but failed to also
> give feedback. Now in light of your veto of Srinivas patch I wanted to use
> the
> opportunity to pick this up again.
>
> On Dienstag, 23. Januar 2024 21:57:23 CET Richard Sa
On Mon, 25 Mar 2024, Patrick Palka wrote:
> On Mon, 25 Mar 2024, Patrick Palka wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk?
> >
> > -- >8 --
> >
> > The below testcases use a lambda-expr as a template argument and they
> > all trip over the be
On Wednesday, 27 March 2024 10:50:41 CET Jonathan Wakely wrote:
> As discussed on IRC, please push the revised patch with your
> suggestions incorporated (and post to the lists for posterity).
The patch as pushed is attached.
--
───
On Mon, 25 Mar 2024, centurion wrote:
> From b34312d82b236601c348382d30e625558f37d40c Mon Sep 17 00:00:00 2001
> From: centurion
> Date: Mon, 25 Mar 2024 01:57:21 +0400
> Subject: [PATCH] c++: fix alias CTAD [PR114377]
>
> PR c++/114377
>
> gcc/cp/ChangeLog:
>
> PR c++/114377
> * p
On 3/27/24 04:57, Jakub Jelinek wrote:
Hi!
We got internally a question about the Spec File syntax, misunderstanding
what is the literal syntax and what are the placeholder variables in
the syntax descriptions.
The following patch attempts to use @var{S} etc. instead of just S
to clarify it stan
On Wed, Mar 27, 2024 at 01:42:03PM +0100, Richard Biener wrote:
> The comment says it was added for (char)_Bool, probably
> gcc.dg/tree-ssa/vce-1.c will fail. But I'm not sure this optimization
> is important, it seems early SRA introduces a V_C_E here and then
> phiopt the conversion to unsigned
Hell(o),
it didn't take long for my recent patch for PR111781 to show a regression.
The fix proposed here is actually the one Harald posted in the PR.
I can't imagine a case where it wouldn't do the right thing.
Regression tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
The patch fixing P
The testcase in this PR shows very slow IDF compute:
tree SSA rewrite : 76.99 ( 31%)
24.78%243663 cc1plus cc1plus [.] compute_idf
which can be mitigated to some extent by refactoring the bitmap
operations to simpler variants. With the patch below this
On Wed, Mar 27, 2024 at 04:42:21PM +0100, Richard Biener wrote:
> PR middle-end/114480
> * cfganal.cc (compute_idf): Use simpler bitmap iteration,
> touch work_set only when phi_insertion_points changed.
> ---
> gcc/cfganal.cc | 10 +++---
> 1 file changed, 3 insertions(+), 7
In some cases combine will "combine" an I2 and I3, but end up putting
exactly the same thing back as I2 as was there before. This is never
progress, so we shouldn't do it, it will lead to oscillating behaviour
and the like.
If we want to canonicalise things, that's fine, but this is not the
way t
On Wed, Mar 27, 2024 at 04:30:42PM +0100, Mikael Morin wrote:
> Hell(o),
>
> it didn't take long for my recent patch for PR111781 to show a regression.
> The fix proposed here is actually the one Harald posted in the PR.
> I can't imagine a case where it wouldn't do the right thing.
> Regression t
>> > Another way would be to have a portable solution to truncate a file
>> > (maybe even removing it would work). I don't think we should override
>> > SHELL.
I've been thinking harder about this, these files get unlinked at the
end if they are temporary.
Is there no way to get make to communic
On Wed, 27 Mar 2024, Jakub Jelinek wrote:
> Hi!
>
> As written in the PR, torture/bitint-64.c test fails with -O2 -flto
> and the reason is that on _BitInt arches where the padding bits
> are undefined, the padding bits in the _Atomic vars are also undefined,
> but when __atomic_load or __atomic_
> Am 27.03.2024 um 18:37 schrieb Peter0x44 :
>
>
>>
>>> >> > Another way would be to have a portable solution to truncate a file
>>> >> > (maybe even removing it would work). I don't think we should override
>>> >> > SHELL.
> I've been thinking harder about this, these files get unlinked at
Hi,
Introduced a new patch to disable diagnostics for ABI breaks involving
_BitInt(N) given the type didn't exist, let me know what you think of that.
Also added further testing to replicate the ABI diagnostic tests to use
_BitInt(N).
Andre Vieira (2)
aarch64: Do not give ABI change diagnos
This patch makes sure we do not give ABI change diagnostics for the ABI
breaks of GCC 9, 13 and 14 for any type involving _BitInt(N), since that
type did not exist before this GCC version.
ChangeLog:
* config/aarch64/aarch64.cc (bitint_or_aggr_of_bitint_p): New function.
(aarch
This patch adds support for C23's _BitInt for the AArch64 port when
compiling for little endianness. Big Endianness requires further
target-agnostic support and we therefor disable it for now.
The tests expose some suboptimal codegen for which I'll create PR's for
optimizations after this goe
This patch to the Go frontend fixes an uninitialized variables in
lower_method_expression. This fixes GCC PR 114463. Bootstrapped and
ran Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
7b2a24f3964509bd5b74c4579c7ea5684e82aee1
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofron
>From 22056e95bde82b1dc45b8b611be4c8d756122b02 Mon Sep 17 00:00:00 2001
From: centurion
Date: Wed, 27 Mar 2024 22:29:57 +0400
Subject: [PATCH] c++: fix alias CTAD [PR114377]
PR c++/114377
gcc/cp/ChangeLog:
PR c++/114377
* pt.cc (find_template_parameter_info::found): Use
Hey,
On Wed, 27 Mar 2024, Jakub Jelinek wrote:
> > @@ -1712,12 +1711,9 @@ compute_idf (bitmap def_blocks, bitmap_head *dfs)
> >gcc_checking_assert (bb_index
> >< (unsigned) last_basic_block_for_fn (cfun));
> >
> > - EXECUTE_IF_AND_COMPL_IN_BITMAP (&dfs[bb_in
This patch to the Go testsuite updates issue16016.go. This backports
https://go.dev/cl/574536 into the GCC testsuite. This fixes PR
go/114453. Bootstrapped and ran test. Committed to mainline.
Ian
5b6f599670994bef957bd15c683102468a7104f1
diff --git a/gcc/testsuite/go.test/test/fixedbugs/issue1
Add a multilib with workarounds for Cortex-A53 errata.
gcc/ChangeLog:
* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
gcc/config.gcc | 1 +
gcc/config/aarch64/t-aarch64-rte
On Wed, Mar 27, 2024 at 07:44:28PM +0100, Michael Matz wrote:
> Hey,
>
> On Wed, 27 Mar 2024, Jakub Jelinek wrote:
>
> > > @@ -1712,12 +1711,9 @@ compute_idf (bitmap def_blocks, bitmap_head *dfs)
> > >gcc_checking_assert (bb_index
> > > < (unsigned) last_basic_block_f
Hi Jakub,
Thanks for the patch and appologies for the results regression.
Cupertino
Jakub Jelinek writes:
> On Tue, Mar 26, 2024 at 02:28:52PM +, Cupertino Miranda wrote:
>> GCC was defining bts_offset entry to always contain 0.
>> When comparing with clang, the same entry is instead a la
Hi Jakub,
On 3/27/24 04:16, Jakub Jelinek wrote:
> On Wed, Mar 27, 2024 at 11:18:49AM +0100, Jakub Jelinek wrote:
>>> -/* The offset entry for each variable in a DATSEC should be 0 at compile
>>> time. */
>>> -/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 7 } } */
>>> +/* Th
> On Mar 26, 2024, at 13:20, Joseph Myers wrote:
>
> On Tue, 26 Mar 2024, Qing Zhao wrote:
>
>>> What happens when there are multiple counted_by attributes on the same
>>> field? As far as I can see, all but one end up being ignored (by the code
>>> that actually uses the attribute).
>>
>>
Dear all,
the attached patch fixes a 10+ regression for cases where a
derived type with a pointer component is used in a DATA statement.
The failure looked obscure, see testcase comments, and pointed
to a possible issue in the resolution (order). For the failing
test, the target variable was seen
Hello—just pinging again about the following two patches I submitted. Each
fixes small access-out-of-bounds errors in libdecnumber.
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644840.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644910.html
Also, the documentation indic
We aren't doing anything with vxsat right now, but I'd like to add it as
an accepted register to the clobber list. If we get this into GCC-14
then we'll avoid some preprocessor-based twiddling if we ever start
using vxsat in the future.
gcc/ChangeLog:
* config/riscv/riscv.h (REGISTER_NAM
On Linux/x86_64,
839bc42772ba7af66af3bd16efed4a69511312ae is the first bad commit
commit 839bc42772ba7af66af3bd16efed4a69511312ae
Author: Segher Boessenkool
Date: Wed Mar 27 14:09:52 2024 +
combine: Don't combine if I2 does not change
caused
FAIL: gcc.target/i386/pr101950-2.c scan-as
Per classic Vector calling convention ABI, vtype is call clobbered,
so ensure gcc generates fresh a VSETVLI after a function call or an
inline asm which clobbers vtype.
ATM gcc seems to be doing the right thing, but a test can never be
harmful.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9697-gfdd59818e2abf6.
gcc/analyzer/ChangeLog:
PR analyzer/114473
* call-summary.cc
(call_summary_replay::convert_svalue
This patch to the Go frontend uses the correct size and comparison
when doing an index value overflow check. This has apparently been
wrong since I introduced the code ten years ago. This fixes GCC PR
114500. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
1
On 3/27/24 1:42 PM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a 10+ regression for cases where a
derived type with a pointer component is used in a DATA statement.
The failure looked obscure, see testcase comments, and pointed
to a possible issue in the resolution (order). For the
auto-profile currently doesn't guarantee that it will set probabilities
on all edges because of zero basic block counts. Normally those edges
just have probabilities set by the preceding profile_estimate pass but
under -O0 profile_estimate pass doesn't run. The patch removes setting
of full_profile
在 2024/3/27 下午8:42, Xi Ruoyao 写道:
On Wed, 2024-03-27 at 18:39 +0800, Xi Ruoyao wrote:
On Wed, 2024-03-27 at 10:38 +0800, chenglulu wrote:
在 2024/3/26 下午5:48, Xi Ruoyao 写道:
The latency of LA464 and LA664 division instructions depends on the
input. When I updated the costs in r14-6642, I unin
LGTM, and committed to trunk :)
On Thu, Mar 28, 2024 at 5:37 AM Palmer Dabbelt wrote:
>
> We aren't doing anything with vxsat right now, but I'd like to add it as
> an accepted register to the clobber list. If we get this into GCC-14
> then we'll avoid some preprocessor-based twiddling if we eve
Just tried something interesting:
$ riscv64-unknown-linux-gnu-gcc -march=rv64gc -O
target_attribute_v_with_intrinsic-9.c -S # Work
$ riscv64-unknown-linux-gnu-gcc -march=rv64gc_zve32x -O
target_attribute_v_with_intrinsic-9.c -S # Not work
Also I guess all zvk* and zvbb may also need to be added a
75 matches
Mail list logo
