On Dec 19, 2024, "haochen.jiang via Gcc-regression"
wrote:
> FAIL: gcc.dg/field-merge-16.c scan-tree-dump-times ifcombine "optimizing" 6
ACK, thanks.
I expect each of the following two patches contains a fix for this failure:
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/672161.html
On Dec 20, 2024, Jakub Jelinek wrote:
> On Wed, Dec 18, 2024 at 12:59:11AM -0300, Alexandre Oliva wrote:
>> * gcc.dg/field-merge-16.c: New.
> Note the test FAILs on i686-linux or on x86_64-linux with -m32.
Also fixed herein.
A number of tests that check for specific ifcombine transformations
On Dec 20, 2024, Jakub Jelinek wrote:
> On Wed, Dec 18, 2024 at 12:59:11AM -0300, Alexandre Oliva wrote:
>> * gcc.dg/field-merge-16.c: New.
> Note the test FAILs on i686-linux or on x86_64-linux with -m32.
Indeed, thanks. Here's a fix.
On 32-bit hosts, data types with 64-bit alignment aren't
On 12/20/24 17:16, Andrew Pinski wrote:
> On Fri, Dec 20, 2024 at 2:14 PM Vineet Gupta wrote:
>> This improves codegen for x264 sum of absolute difference routines.
>> The insn count is same, but we avoid double widening ops and ensuing
>> whole register moves.
>>
>> Also for more general applicab
On Fri, Dec 20, 2024 at 2:14 PM Vineet Gupta wrote:
>
> This improves codegen for x264 sum of absolute difference routines.
> The insn count is same, but we avoid double widening ops and ensuing
> whole register moves.
>
> Also for more general applicability, we chose to implement abs diff
> vs. t
On Dec 19, 2024, Richard Biener wrote:
> Please don't use -1 initializers, instead populate
> opts.cc:default_options_table.
ACK. This trick (that I used) will be hard to unlearn ;-)
> IMO options where it's not clear how they interact are bad.
*nod*. I struggled a bit with that.
In the end
lgtm
juzhe.zh...@rivai.ai
From: Vineet Gupta
Date: 2024-12-21 06:18
To: gcc-patches
CC: gnu-toolchain; Robin Dapp; Pan Li; Juzhe Zhong; Jeff Law; Vineet Gupta
Subject: [PATCH v2] RISC-V: vector absolute difference expander [PR117722]
Changes since v1:
- Fix snafu in test.
This improves codeg
Commit r15-6389-g670df03e5294a3 only partially fixed support for moves
of large modes: despite the introduction of V2x* and V4x* modes in
r15-6245-g4f4e13dd235b to support MVE tuples, we still need to support
TI, OI and XI modes, which appear for instance in gcc.dg/pr100887.c.
The problem was noti
When looking through the gfortran manual, I noted some problems with
hyphens being used where they're not correct or necessary,
e.g. "non-standard" vs "nonstandard", "null-pointer" vs "null pointer"
(as a noun), etc. I've made a pass through the documentation to
correct at least some of those uses
The present tense is preferred for expressing facts or enduring
behavior. Thus we should say "option X does Y" instead of "option X
will do Y", reserving the future tense for things that happen at some
later time (such as in a future release of GCC, or at run time as
explicitly contrasted with com
While working on something else I noticed there were numerous places
in the GNU Fortran manual with incorrect/missing Texinfo markup. I
made a pass through about the first third of the manual (not yet the
coarray API or intrinsics documentation) to fix at least some of those
issues, plus some typo
I've done some cleanups on the Fortran manual. None of the patches in
this series are intended to have any semantic effect -- just clean up
markup, grammar, spelling, punctuation, etc. I didn't make it through
through all the coarray and intrinsics documentation yet, but this should
be at least a
This is a long-standing documentation bug in the Fortran manual,
initially reported in 2012 as PR51820, with a quick fix applied later
for PR109216. The patch here incorporates more of the discussion from
the original issue.
gcc/fortran/ChangeLog
PR fortran/51820
PR fortran/89632
Changes since v1:
- Fix snafu in test.
This improves codegen for x264 sum of absolute difference routines.
The insn count is same, but we avoid double widening ops and ensuing
whole register moves.
Also for more general applicability, we chose to implement abs diff
vs. the sum of abs diff varian
This improves codegen for x264 sum of absolute difference routines.
The insn count is same, but we avoid double widening ops and ensuing
whole register moves.
Also for more general applicability, we chose to implement abs diff
vs. the sum of abs diff variant.
Suggested-by: Robin Dapp
Co-develope
On Fri, 20 Dec 2024, Patrick Palka wrote:
> On Fri, 20 Dec 2024, Giuseppe D'Angelo wrote:
>
> > Hello,
> >
> > On 20/12/2024 13:23, Giuseppe D'Angelo wrote:
> > > Hi,
> > >
> > > The implementation of ranges::is_permutation may create a dangling
> > > reference, which then results (sometimes) i
On Fri, 20 Dec 2024, Giuseppe D'Angelo wrote:
> Hello,
>
> On 20/12/2024 13:23, Giuseppe D'Angelo wrote:
> > Hi,
> >
> > The implementation of ranges::is_permutation may create a dangling
> > reference, which then results (sometimes) in a crash. A minimal example
> > that shows the problem under
On Fri, 20 Dec 2024 12:54:54 PST (-0800), jeffreya...@gmail.com wrote:
On 12/20/24 9:48 AM, Palmer Dabbelt wrote:
On Thu, 19 Dec 2024 15:01:26 PST (-0800), jeffreya...@gmail.com wrote:
On 12/19/24 3:08 PM, Palmer Dabbelt wrote:
I agree lacking B and V makes us very clearly uncompetitive i
On 12/20/24 9:48 AM, Palmer Dabbelt wrote:
On Thu, 19 Dec 2024 15:01:26 PST (-0800), jeffreya...@gmail.com wrote:
On 12/19/24 3:08 PM, Palmer Dabbelt wrote:
I agree lacking B and V makes us very clearly uncompetitive in the space
where these sort of things matter (ie, binary compatible di
Hi,
On 20 Dec 2024, at 20:37, Simon Martin wrote:
> We currently fail due to "infinite recursion" on the following invalid
> code with -std=c++20 and above
>
> === cut here ===
> template struct S { struct U { const S s; } u; };
> S t{2};
> === cut here ===
>
> The problem is that reshape_init_c
On Fri, Dec 20, 2024 at 05:38:57PM +0100, Christoph Müllner wrote:
> FAILs have been reported for several tree-ssa vector-*.c tests
> on i686-linux or on x86_64-linux with -m32.
> This patch addresses these fails by setting the necessary -msse2 flags.
>
> This patch also streamlines all tests to u
On Fri, Dec 20, 2024 at 05:38:56PM +0100, Christoph Müllner wrote:
> A recent bugfix (eee2891312) for PR117830 also addressed PR118149.
> This patch adds two test cases for PR118149.
> These tests are different than other tests in that one of the
> vec-perm selectors contains indices in descending
We currently fail due to "infinite recursion" on the following invalid
code with -std=c++20 and above
=== cut here ===
template struct S { struct U { const S s; } u; };
S t{2};
=== cut here ===
The problem is that reshape_init_class for S calls reshape_init_r for
its field S::u, that calls resha
Hello,
On 20/12/2024 13:23, Giuseppe D'Angelo wrote:
Hi,
The implementation of ranges::is_permutation may create a dangling
reference, which then results (sometimes) in a crash. A minimal example
that shows the problem under ASAN is https://gcc.godbolt.org/z/7bP9nE8fK
The attached patch fixes
Hello,
On 20/12/2024 18:05, Jonathan Wakely wrote:
So I think I'll just finish testing it like that, as one test, and push that.
OK, thanks.
But in fact, I've realized that it doesn't need to be run at all?
There's nothing that happens at runtime. I've therefore made the test
just a compile
On Wed, Oct 02, 2024 at 08:15:38PM +0100, Jonathan Wakely wrote:
> On Wed, 2 Oct 2024 at 19:25, Jonathan Wakely wrote:
> >
> > On Wed, 2 Oct 2024 at 19:16, Jonathan Wakely wrote:
> > >
> > > On Wed, 2 Oct 2024 at 19:15, Dmitry Ilvokhin wrote:
> > > >
> > > > Instead of looping over every byte of
Ping!
Am 14.12.24 um 20:56 schrieb Harald Anlauf:
Dear all,
this patch is the 4th part of a series on the passing of NULL() to
assumed-rank dummies. This one handles the case of a derived type
dummy and is mostly straightforward.
There was one particular problem I encountered: passing NULL()
On Fri, 20 Dec 2024 09:09:02 PST (-0800), richard.guent...@gmail.com wrote:
Am 20.12.2024 um 17:49 schrieb Palmer Dabbelt :
On Thu, 19 Dec 2024 15:01:26 PST (-0800), jeffreya...@gmail.com wrote:
On 12/19/24 3:08 PM, Palmer Dabbelt wrote:
I agree lacking B and V makes us very clearly unc
Am 20.12.24 um 00:46 schrieb Jerry D:
On 12/19/24 1:34 PM, Harald Anlauf wrote:
Dear all,
the check for potential aliasing of lhs and rhs currently shortcuts
if the types differ. This is a problem if one is of type complex
and the other is of type real (and of the same kind parameter value),
a
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Here we ICE in expand_expr_real_1:
if (exp)
{
tree context = decl_function_context (exp);
gcc_assert (SCOPE_FILE_SCOPE_P (context)
|| context == current_function_decl
on
On Fri, Dec 20, 2024 at 12:51:02PM -0500, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> Compiling this test, we emit:
>
> error: 'static void CW::operator=(int) requires
> requires(typename'decltype_type' not supported by pp_cxx_unqualified_
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Compiling this test, we emit:
error: 'static void CW::operator=(int) requires
requires(typename'decltype_type' not supported by pp_cxx_unqualified_id::type
x) {x;}' must be a non-static member function
where the DECLTYPE_T
> Am 20.12.2024 um 17:49 schrieb Palmer Dabbelt :
>
> On Thu, 19 Dec 2024 15:01:26 PST (-0800), jeffreya...@gmail.com wrote:
>>
>>
>>> On 12/19/24 3:08 PM, Palmer Dabbelt wrote:
>>>
>>> I agree lacking B and V makes us very clearly uncompetitive in the space
>>> where these sort of things m
Thank you very much Jerry.
The delta between the two patches is really minor. In resolve.c I have
removed some attr.pointer setting and in caf/single.c the handling for
those as well as treating non-descriptor arrays differently.
Most changes in the diff of v2 to v3 are about lines having moved
On Fri, 20 Dec 2024 at 14:21, Giuseppe D'Angelo
wrote:
>
> Hi,
>
> On 20/12/2024 13:37, Jonathan Wakely wrote:
> >
> > With this, I get seven PASS results for this test.
>
> Thank you; I was just thinking, would it be simpler to split the test in
> two instead rather than making it more convoluted
I got as far as applying and regression testing version 2. I have queried
around for others to look over the patch. I will scan this one.
Since you are the expert in this area, we may just have you push and let
the pieces fall out.
I will get back to you later today.
Jerry
On Fri, Dec 20, 2024,
On Thu, 19 Dec 2024 15:01:26 PST (-0800), jeffreya...@gmail.com wrote:
On 12/19/24 3:08 PM, Palmer Dabbelt wrote:
I agree lacking B and V makes us very clearly uncompetitive in the space
where these sort of things matter (ie, binary compatible distros and
long term stability type things) -- t
A recent bugfix (eee2891312) for PR117830 also addressed PR118149.
This patch adds two test cases for PR118149.
These tests are different than other tests in that one of the
vec-perm selectors contains indices in descending order (1, 1, 0, 0),
which is the root cause for the ICE observed in PR11814
FAILs have been reported for several tree-ssa vector-*.c tests
on i686-linux or on x86_64-linux with -m32.
This patch addresses these fails by setting the necessary -msse2 flags.
This patch also streamlines all tests to use dg-options instead
of dg-additional-options. This is in line with most ot
On Fri, Dec 20, 2024 at 4:51 PM Christoph Müllner
wrote:
>
> On Fri, Dec 20, 2024 at 4:27 PM Jakub Jelinek wrote:
> >
> > On Fri, Dec 20, 2024 at 04:22:19PM +0100, Christoph Müllner wrote:
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr118149-2.c
> > > @@ -0,0 +1,37 @@
> > > +/*
On 12/19/24 11:36 PM, Georg-Johann Lay wrote:
This is a ping for
https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671216.html
I'd prefer this to wait for gcc-16 as we're well into stage3. While
using a hook makes it fairly safe, I think everyone is quite busy with
stage3 activities.
On Fri, Dec 20, 2024 at 4:27 PM Jakub Jelinek wrote:
>
> On Fri, Dec 20, 2024 at 04:22:19PM +0100, Christoph Müllner wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr118149-2.c
> > @@ -0,0 +1,37 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O3 -fdump-tree-forwprop1-detai
> -Original Message-
> From: Prathamesh Kulkarni
> Sent: 18 December 2024 21:09
> To: Tobias Burnus ; Joseph Myers
>
> Cc: Xi Ruoyao ; Matthew Malcomson
> ; gcc-patches@gcc.gnu.org
> Subject: RE: [RFC] PR81358: Enable automatic linking of libatomic
>
> External email: Use caution openi
SImode and DImode moves from/to mask registers are valid only with AVX512BW,
so mark relevant alternatives in *movsi_internal and *movdi_internal as such.
Even with the patch, the testcase still fails, but now with:
pr118067.c: In function ‘foo’:
pr118067.c:13:1: internal compiler error: maximum
On Fri, Dec 20, 2024 at 04:22:19PM +0100, Christoph Müllner wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr118149-2.c
> @@ -0,0 +1,37 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -fdump-tree-forwprop1-details -Wno-psabi" } */
> +/* { dg-options "-msse2" { target i?86-*-* x8
FAILs have been reported for several tree-ssa vector-*.c tests
on i686-linux or on x86_64-linux with -m32.
This patch addresses these fails by setting the necessary -msse2 flags.
This patch also streamlines all tests to use dg-options instead
of dg-additional-options. This is in line with most ot
A recent bugfix (eee2891312) for PR117830 also addressed PR118149.
This patch adds two test cases for PR118149.
These tests are different than other tests in that one of the
vec-perm selectors contains indices in descending order (1, 1, 0, 0),
which is the root cause for the ICE observed in PR11814
On Fri, Dec 20, 2024 at 4:07 PM Jakub Jelinek wrote:
>
> On Fri, Dec 20, 2024 at 03:56:41PM +0100, Christoph Müllner wrote:
> > > Also, why are you using dg-additional-options in tree-ssa/ ? I think the
> > > default there is just -pedantic-errors which you don't really need for
> > > these
> >
On Fri, Dec 20, 2024 at 03:56:41PM +0100, Christoph Müllner wrote:
> > Also, why are you using dg-additional-options in tree-ssa/ ? I think the
> > default there is just -pedantic-errors which you don't really need for these
> > tests, so just dg-options?
>
> I will change accordingly for all vec
On Fri, Dec 20, 2024 at 3:38 PM Jakub Jelinek wrote:
>
> On Fri, Dec 20, 2024 at 02:55:51PM +0100, Christoph Müllner wrote:
> > A recent bugfix (eee2891312) for PR117830 also addressed PR118149.
> > This patch adds two test cases for PR118149.
> > These tests are different than other tests in that
On Fri, Dec 20, 2024 at 02:55:51PM +0100, Christoph Müllner wrote:
> A recent bugfix (eee2891312) for PR117830 also addressed PR118149.
> This patch adds two test cases for PR118149.
> These tests are different than other tests in that one of the
> vec-perm selectors contains indices in descending
Hi,
On 20/12/2024 13:37, Jonathan Wakely wrote:
With this, I get seven PASS results for this test.
Thank you; I was just thinking, would it be simpler to split the test in
two instead rather than making it more convoluted than necessary? Let me
know and I'll amend it, in either direction.
Ping.
Thanks,
Kyrill
> On 13 Dec 2024, at 16:47, Kyrylo Tkachov wrote:
>
> Ping.
> Thanks,
> Kyrill
>
>> On 28 Nov 2024, at 11:22, Kyrylo Tkachov wrote:
>>
>> Ping.
>>
>>> On 15 Nov 2024, at 17:04, Kyrylo Tkachov wrote:
>>>
>>> Hi all,
>>>
>>> This is a patch submission following-up from
Ping.
On Fri, Nov 15, 2024 at 09:08:18AM -0500, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> The error here should also check that we aren't nested in another
> lambda; in it, at_function_scope_p() will be false.
>
> PR c++/117602
>
>
Ping.
On Mon, Nov 25, 2024 at 04:46:56PM -0500, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
>
> -- >8 --
> In a template, for
>
> union {
> union {
> T d;
> };
> };
>
> build_anon_union_vars crates a malformed COMPONENT_REF: we have n
Ping.
On Tue, Nov 26, 2024 at 05:35:50PM -0500, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> As the manual states, using "-fhardened -fstack-protector" will produce
> a warning because -fhardened wants to enable -fstack-protector-strong,
> but
A recent bugfix (eee2891312) for PR117830 also addressed PR118149.
This patch adds two test cases for PR118149.
These tests are different than other tests in that one of the
vec-perm selectors contains indices in descending order (1, 1, 0, 0),
which is the root cause for the ICE observed in PR11814
"Robin Dapp" writes:
>> "Robin Dapp" writes:
>>> But here I intended to just change the encoded value in memory and to
>>> prevent it from aliasing with other encoded values.
>>> In an actual instruction the values we "padded" (or that are beyond the
>>> vector length) are ignored. For the purpo
On 19/12/24 14:49 +0100, Giuseppe D'Angelo wrote:
diff --git a/libstdc++-v3/testsuite/23_containers/span/init_list_cons_neg.cc
b/libstdc++-v3/testsuite/23_containers/span/init_list_cons_neg.cc
new file mode 100644
index 000..ef43541b769
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_conta
Hi all,
pinging again.
Please note, that attached patch is a slightly updated version.
Regtests ok on x86_64-pc-linux-gnu. Ok for mainline?
Regards,
Andre
On Mon, 16 Dec 2024 10:58:22 +0100
Andre Vehreschild wrote:
> PING!
>
> On Fri, 6 Dec 2024 19:10:08 +0100
> Andre Vehreschild wr
Hi,
The implementation of ranges::is_permutation may create a dangling
reference, which then results (sometimes) in a crash. A minimal example
that shows the problem under ASAN is https://gcc.godbolt.org/z/7bP9nE8fK
The attached patch fixes it. I've tested on Linux x86-64. Adding a
negative
On Thu, 19 Dec 2024 at 13:49, Giuseppe D'Angelo
wrote:
>
> Hello,
>
> On 19/12/2024 13:27, Jonathan Wakely wrote:
> > I was about to push this and realised it's missing a Signed-off-by
> > tag. I assume you meant to contribute this under the DCO terms, as
> > with your previous patches?
>
> Yes, o
Pushed as obvious.
-- >8 --
This should have been part of r15-6379-g0c2ae384326108.
gcc/c-family/ChangeLog:
* c.opt.urls: Regenerate.
Signed-off-by: Nathaniel Shead
---
gcc/c-family/c.opt.urls | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/c-family/c.opt.urls b/gcc/c-fami
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk and
maybe release branches?
-- >8 --
This patch removes the (unnecessary) CPP_PRAGMA_EOL case from
cp_parser_cache_defarg, which currently has the result that any pragmas
in the NSDMI cause an error.
PR c++/118147
gcc/cp/Ch
> "Robin Dapp" writes:
>> But here I intended to just change the encoded value in memory and to
>> prevent it from aliasing with other encoded values.
>> In an actual instruction the values we "padded" (or that are beyond the
>> vector length) are ignored. For the purpose of hashing a mask of
>>
On 19/12/2024 16:45, Christophe Lyon wrote:
> Commit r15-6245-g4f4e13dd235b introduced new modes for MVE tuples, but
> missed adding support for them in a few places.
>
> Adding them to the list in arm_attr_length_move_neon is not sufficient
> since we later face another ICE where the compiler doe
"Robin Dapp" writes:
> But here I intended to just change the encoded value in memory and to
> prevent it from aliasing with other encoded values.
> In an actual instruction the values we "padded" (or that are beyond the
> vector length) are ignored. For the purpose of hashing a mask of
> "1010"
On Thu, 19 Dec 2024 at 13:17, Christophe Lyon
wrote:
>
> Without this patch, testcases using arm_v8_3a_fp16_complex_neon fail
> to compile on arm-linux-gnueabihf with
> fatal error: gnu/stubs-soft.h: No such file or directory
> because they are actually compiled with
> -mfloat-abi=softfp -mfpu=aut
Tamar Christina writes:
>> > +}
>> > + cgraph_simd_clone *sc = node->simdclone;
>> > +
>> > + for (unsigned i = 0; i < sc->nargs; ++i)
>> > +{
>> > + bool is_mask = false;
>> > + tree type;
>> > + switch (sc->args[i].arg_type)
>> > + {
>> > + case SIMD_CLONE_ARG_TYPE_MAS
On Thu, Dec 19, 2024 at 07:01:39PM +0100, Jakub Jelinek wrote:
> So far lightly tested, ok for trunk this way if it passes bootstrap & testing?
Bootstrap/regtest found an issue, warning about
if ()
for ()
if ()
else if ()
else
so I've added {}s around it (no other changes f
>> How does encoding work for SVE's small mask modes? I suppose
>>
>> unsigned int elt_bits = vector_element_size (GET_MODE_PRECISION (mode),
>> GET_MODE_NUNITS (mode));
>>
>> is != 1 but rather adjusted so a byte is filled?
>
> It's 1 for VNx1
> Am 20.12.2024 um 04:04 schrieb Mark Harmstone :
>
> Commit 4ed189854eae ("Add block parameter to begin_block debug hook") changed
> the definition of the begin_block function pointer to add another parameter,
> but I missed a call in vmsdbgout_begin_block.
>
> Fixes bug #118123.
Ok
> gcc/
On Wed, Dec 18, 2024 at 12:59:11AM -0300, Alexandre Oliva wrote:
> * gcc.dg/field-merge-16.c: New.
Note the test FAILs on i686-linux or on x86_64-linux with -m32. The IL
is identical before ifcombine, but -m64 to -m32 ifcombine dump shows
-optimizing two comparisons to (_10 & 18446462598732
> Am 19.12.2024 um 21:47 schrieb Christoph Müllner
> :
>
> In PR117830 a miscompilation of 464.h264ref was reported.
> An analysis showed that wrong code was generated because of
> unsatisfied assuptions in the code. This patch addresses
> these issues.
>
> The first assuption was that we c
LGTM
Christoph Müllner 於 2024年12月20日 週五 04:13 寫道：
> This patch ensures that the list of valid -mtune options
> does not contain entries more than once.
> The -mtune option accepts CPU identifiers as well as
> tuning identifiers and there are cases where a CPU and
> its tuning have the same ident
ok
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-12-20 14:49
To: gcc-patches
CC: juzhe.zhong; kito.cheng; jeffreyalaw; rdapp.gcc; Pan Li
Subject: [PATCH v1] RISC-V: Fix the the operand alignment for strided
load/store pattern [NFC]
From: Pan Li
Just notice the unalignment operand for strid
76 matches
Mail list logo
