Hi,
Same like PR101168, this patch is need for s390 to
avoid peeking eof after vector keyword.
And similar test case is also ok for s390.
Is this ok for trunk?
Jeff (Jiufu Guo)
PR target/95782
gcc/ChangeLog:
* config/s390/s390-c.cc (s390_macro_to_expand): Avoid empty
在 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
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
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 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
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.
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
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
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
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
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
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
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,
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
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
>
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
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, 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, 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
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 =
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
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
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
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
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
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
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
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
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
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.
>
>
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
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
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
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
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 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
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,
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.
>
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 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
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
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
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,
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
> *
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
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
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(+),
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
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 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
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
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
>> > 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
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
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.
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 +
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 } } */
>>> +/*
> 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
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
>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
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
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
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)
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
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
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
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
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
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
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
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
> 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).
>>
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:
*
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
74 matches
Mail list logo
