gcc/ChangeLog:
* config/i386/i386-expand.cc (ix86_can_cfcmov_p): New func
that test if the cfcmov can be generated.
(ix86_expand_int_cfmovcc): Expand to cfcmov pattern.
* config/i386/i386-opts.h (enum apx_features): New.
*
Hi,
This version has added a new optab named 'cfmovcc'. The new optab is used
in the middle end to expand to cfcmov. And simplified my patch by trying to
generate the conditional faulting movcc in noce_try_cmove_arith function.
All the changes passed bootstrap & regtest x86-64-pc-linux-gnu.
We al
On Linux/x86_64,
a51f2fc0d80869ab079a93cc3858f24a1fd28237 is the first bad commit
commit a51f2fc0d80869ab079a93cc3858f24a1fd28237
Author: liuhongt
Date: Wed Sep 4 15:39:17 2024 +0800
Handle const0_operand for *avx2_pcmp3_1.
caused
FAIL: gcc.target/i386/pr59539-1.c scan-assembler-times vm
This patch aims to add the missing instruction types to the XiangShan-Nanhu
scheduler model.
The current XiangShan -Nanhu model lacks the trap, atomic trap, fcvt_i2f, and
fcvt_f2i instructions.
The trap, atomic, and i2f instructions belong to xs_jmp_rs. [1]
The f2i instruction belongs to xs_fmis
On 9/5/24 1:50 PM, Raphael Moreira Zinsly wrote:
Changes since v1:
- Fix synthesis-15.c.
-- >8 --
Improve handling of constants where the high half can be constructed by
inverting the lower half.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_build_integer): Detect constants
Hi all,
This patch will add those recent aliased CPU names into documentation
for clearness.
Ready to push for trunk and backport to GCC14 and part of the patch to
GCC13 as an obvious fix if no objection.
Thx,
Haochen
gcc/ChangeLog:
PR target/116617
* doc/invoke.texi: Add meteo
ChangeLog
* .gitignore: Add .vscode.
---
.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/.gitignore b/.gitignore
index 93a16b0b950..f044fe16b5f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -38,6 +38,7 @@ cscope.out
.local.vimrc
.lvimrc
+.vscode
.clang-format
.clang-ti
On Fri, Sep 6, 2024 at 10:34 AM Jiang, Haochen wrote:
>
> > From: Levy Hsu
> > Sent: Thursday, September 5, 2024 4:55 PM
> > To: gcc-patches@gcc.gnu.org
> >
> > Simple testcase fix, ok for trunk?
> >
> > This patch removes specific register checks to account for possible
> > register spills and d
On 9/5/24 1:50 PM, Raphael Moreira Zinsly wrote:
Changes since v1:
- Fix bit31.
- Remove negative shift checks.
- Fix synthesis-7.c expected output.
-- >8 --
Improve handling of large constants in riscv_build_integer, generate
better code for constants where the high
On Tue, Sep 3, 2024 at 11:30 PM Kyrylo Tkachov wrote:
>
> Hi Andrew,
>
> > On 3 Sep 2024, at 20:11, Andrew Pinski wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > This moves the check for # of statements to copy in join to
> > be the first check. This check is t
> From: Levy Hsu
> Sent: Thursday, September 5, 2024 4:55 PM
> To: gcc-patches@gcc.gnu.org
>
> Simple testcase fix, ok for trunk?
>
> This patch removes specific register checks to account for possible
> register spills and disables tests in 32-bit mode. This adjustment
> is necessary because V4
On 8/28/24 6:22 AM, Jason Merrill wrote:
On 8/28/24 6:09 AM, Jonathan Wakely wrote:
On Wed, 28 Aug 2024 at 10:58, Jason Merrill wrote:
On 8/28/24 5:55 AM, Jonathan Wakely wrote:
On Wed, 28 Aug 2024 at 10:54, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, OK for trunk?
Redefining that m
On 9/4/24 11:02 AM, Marek Polacek wrote:
+handle_flag_enum_attribute (tree *node, tree ARG_UNUSED(name), tree args,
+ int ARG_UNUSED (flags), bool *no_add_attrs)
+{
+ if (args)
+warning (OPT_Wattributes, "%qE attribute arguments ignored", name);
You don't need this
On Thu, Sep 5, 2024 at 12:26 AM Richard Biener
wrote:
>
> On Thu, Sep 5, 2024 at 8:25 AM Andrew Pinski wrote:
> >
> > When optimize_memcpy was added in r7-5443-g7b45d0dfeb5f85,
> > a path was added such that a statement was turned into a non-throwing
> > statement and maybe_clean_or_replace_eh_st
On Sun, 11 Aug 2024 14:00:27 PDT (-0700), Robin Dapp wrote:
> I figured it's easier to parse this as a series rather than one big
> patch, in particular since target-specific code is involved.
>
> This adds an else operand to masked-load operations in order to avoid
> implicit dependencies on zeroe
On Thu, 05 Sep 2024 14:57:06 PDT (-0700), a...@baylibre.com wrote:
On Thu, 5 Sept 2024, 21:10 Robin Dapp, wrote:
> > +(define_predicate "maskload_else_operand"
> > + (and (match_code "const_int,const_vector")
> > + (match_test "op == CONST0_RTX (GET_MODE (op))")))
>
> This forces masklo
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
We ICE in decay_conversion with this test:
struct S {
S() {}
};
S arr[1][1];
auto [m](arr3);
But not when the last line is:
auto [n] = arr3;
Therefore the difference is between copy- and direct-init. In
par
Hi Qing,
Sorry for my late reply.
On Thu, Aug 29, 2024 at 7:22 AM Qing Zhao wrote:
>
> Hi,
>
> Thanks for the information.
>
> Yes, providing a unary operator similar as __counted_by(PTR) as suggested by
> multiple people previously is a cleaner approach.
>
> Then the programmer will use the fo
On Thu, Sep 5, 2024 at 2:57 PM Jeff Law wrote:
>
>
>
> On 9/5/24 12:59 PM, Palmer Dabbelt wrote:
> > On Thu, 05 Sep 2024 11:52:57 PDT (-0700), Palmer Dabbelt wrote:
> >> We have cheap logical ops, so let's just move this back to the default
> >> to take advantage of the standard branch/op hueristi
On Thu, 5 Sept 2024, 21:10 Robin Dapp, wrote:
> > > +(define_predicate "maskload_else_operand"
> > > + (and (match_code "const_int,const_vector")
> > > + (match_test "op == CONST0_RTX (GET_MODE (op))")))
> >
> > This forces maskload and mask_gather_load to only accept zero here, but
> > in
On 9/5/24 12:59 PM, Palmer Dabbelt wrote:
On Thu, 05 Sep 2024 11:52:57 PDT (-0700), Palmer Dabbelt wrote:
We have cheap logical ops, so let's just move this back to the default
to take advantage of the standard branch/op hueristics.
gcc/ChangeLog:
PR target/116615
* config/riscv/ris
On Thu, Sep 5, 2024 at 2:52 PM Jeff Law wrote:
>
>
>
> On 9/5/24 12:52 PM, Palmer Dabbelt wrote:
> > We have cheap logical ops, so let's just move this back to the default
> > to take advantage of the standard branch/op hueristics.
> >
> > gcc/ChangeLog:
> >
> > PR target/116615
> > *
On 9/5/24 12:52 PM, Palmer Dabbelt wrote:
We have cheap logical ops, so let's just move this back to the default
to take advantage of the standard branch/op hueristics.
gcc/ChangeLog:
PR target/116615
* config/riscv/riscv.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Remove.
---
There's
On Thu, 5 Sept 2024 at 22:00, Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu, OK for trunk?
OK, thanks.
>
> -- 8< --
>
> In addition to marking it as flag_enum, we want to avoid warnings about
> not having a case for the implementation detail enumerators
> _S_ios_openmode_*. And also for _
Tested x86_64-pc-linux-gnu, OK for trunk?
-- 8< --
In addition to marking it as flag_enum, we want to avoid warnings about
not having a case for the implementation detail enumerators
_S_ios_openmode_*. And also for _S_noreplace in standard modes before it
was added.
libstdc++-v3/ChangeLog:
On 9/4/24 4:00 PM, Iain Sandoe wrote:
On 4 Sep 2024, at 17:21, Jason Merrill wrote:
On 9/1/24 12:17 PM, Iain Sandoe wrote:
This came up in discussion of an earlier patch.
I'm in two minds as to whether it's a good idea or not - the underlying
issue being that libubsan does not yet (AFAICT)
On 8/28/24 12:44 PM, Joseph Myers wrote:
> On Wed, 28 Aug 2024, Jason Merrill wrote:
>
>> Tested x86_64-pc-linux-gnu. Any objections? Should I change all the other
>> instances of
>>
>> if (CPP_PEDANTIC...
>>cpp_error (...CPP_DL_PEDWARN
>>
>> the same way?
> Yes, I think that's a good change
> > +(define_predicate "maskload_else_operand"
> > + (and (match_code "const_int,const_vector")
> > + (match_test "op == CONST0_RTX (GET_MODE (op))")))
>
> This forces maskload and mask_gather_load to only accept zero here, but
> in fact the hardware would allow us to accept any value (incl
Thanks, Jerry.
Pushed as r15-3494-g1f462b5072a5e8 .
Am 05.09.24 um 21:46 schrieb Jerry D:
On 9/5/24 12:42 PM, Harald Anlauf wrote:
Dear all,
the attached simple patch fixes a corner case related to pr84868,
which was tracked separately. While Paul's patch for pr84868 added
the framework for
Changes since v1:
- Fix synthesis-15.c.
-- >8 --
Improve handling of constants where the high half can be constructed by
inverting the lower half.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_build_integer): Detect constants
were the higher half is the lower half inverte
Changes since v1:
- Fix bit31.
- Remove negative shift checks.
- Fix synthesis-7.c expected output.
-- >8 --
Improve handling of large constants in riscv_build_integer, generate
better code for constants where the high half can be constructed
by shifting/shiftNadding the l
On 9/5/24 12:42 PM, Harald Anlauf wrote:
Dear all,
the attached simple patch fixes a corner case related to pr84868,
which was tracked separately. While Paul's patch for pr84868 added
the framework for treating len_trim in the specification part of
a character function, it missed the possibilit
Dear all,
the attached simple patch fixes a corner case related to pr84868,
which was tracked separately. While Paul's patch for pr84868 added
the framework for treating len_trim in the specification part of
a character function, it missed the possibility that that function
need not appear at the
On 9/5/24 12:46 PM, Palmer Dabbelt wrote:
On Thu, 05 Sep 2024 11:03:18 PDT (-0700), jeffreya...@gmail.com wrote:
So the first patch failed the pre-commit CI; it didn't fail in my
testing because I'm using --with-arch to set a default configuration
that includes things like zicond to ensure t
On Thu, 2024-09-05 at 11:59 -0700, Palmer Dabbelt wrote:
> On Thu, 05 Sep 2024 11:52:57 PDT (-0700), Palmer Dabbelt wrote:
> > We have cheap logical ops, so let's just move this back to the default
> > to take advantage of the standard branch/op hueristics.
> >
> > gcc/ChangeLog:
> >
> > PR t
On 9/5/24 2:28 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
mark_vtable_entries already has
/* It's OK for the vtable to refer to deprecated virtual functions. */
warning_sentinel w(warn_deprecated_decl);
but that doesn't cover
On 9/5/24 2:28 PM, Patrick Palka wrote:
On Thu, 5 Sep 2024, Jason Merrill wrote:
On 9/5/24 1:26 PM, Patrick Palka wrote:
On Thu, 5 Sep 2024, Jason Merrill wrote:
On 9/5/24 10:54 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >
On Thu, Sep 5, 2024 at 3:41 PM Jeff Law wrote:
>
>
>
> On 9/5/24 12:38 PM, Raphael Zinsly wrote:
> > On Thu, Sep 5, 2024 at 3:10 PM Jeff Law wrote:
> >> On 9/5/24 6:16 AM, Raphael Zinsly wrote:
> >>> On Wed, Sep 4, 2024 at 8:32 PM Jeff Law wrote:
> On 9/2/24 2:01 PM, Raphael Moreira Zinsly
On Thu, 05 Sep 2024 11:52:57 PDT (-0700), Palmer Dabbelt wrote:
We have cheap logical ops, so let's just move this back to the default
to take advantage of the standard branch/op hueristics.
gcc/ChangeLog:
PR target/116615
* config/riscv/riscv.h (LOGICAL_OP_NON_SHORT_CIRCUIT): R
We have cheap logical ops, so let's just move this back to the default
to take advantage of the standard branch/op hueristics.
gcc/ChangeLog:
PR target/116615
* config/riscv/riscv.h (LOGICAL_OP_NON_SHORT_CIRCUIT): Remove.
---
There's a bunch more discussion in the bug, but it's st
On Thu, 05 Sep 2024 11:03:18 PDT (-0700), jeffreya...@gmail.com wrote:
So the first patch failed the pre-commit CI; it didn't fail in my
testing because I'm using --with-arch to set a default configuration
that includes things like zicond to ensure that's always tested. And
the failing test is
On 9/5/24 12:38 PM, Raphael Zinsly wrote:
On Thu, Sep 5, 2024 at 3:10 PM Jeff Law wrote:
On 9/5/24 6:16 AM, Raphael Zinsly wrote:
On Wed, Sep 4, 2024 at 8:32 PM Jeff Law wrote:
On 9/2/24 2:01 PM, Raphael Moreira Zinsly wrote:
...
+ bool bit31 = (hival & 0x8000) != 0;
+ int
On 9/5/24 6:18 AM, Raphael Zinsly wrote:
On Wed, Sep 4, 2024 at 8:35 PM Jeff Law wrote:
On 9/2/24 2:01 PM, Raphael Moreira Zinsly wrote:
...
+unsigned long foo_0x4afe605fb5019fa0(void) { return 0x4afe605fb5019fa0UL; }
+unsigned long foo_0x07a80d21f857f2de(void) { return 0x07a80d21f857f2deUL
On Thu, Sep 5, 2024 at 3:10 PM Jeff Law wrote:
> On 9/5/24 6:16 AM, Raphael Zinsly wrote:
> > On Wed, Sep 4, 2024 at 8:32 PM Jeff Law wrote:
> >> On 9/2/24 2:01 PM, Raphael Moreira Zinsly wrote:
> >> ...
> >>> + bool bit31 = (hival & 0x8000) != 0;
> >>> + int trailing_shift = ctz_hw
On Thu, 5 Sep 2024, Jason Merrill wrote:
> On 9/5/24 1:26 PM, Patrick Palka wrote:
> > On Thu, 5 Sep 2024, Jason Merrill wrote:
> >
> > > On 9/5/24 10:54 AM, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > > > for trunk/14?
> > > >
> > > > --
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
mark_vtable_entries already has
/* It's OK for the vtable to refer to deprecated virtual functions. */
warning_sentinel w(warn_deprecated_decl);
but that doesn't cover __attribute__((unavailable)). We can use the
follo
On 9/5/24 6:16 AM, Raphael Zinsly wrote:
On Wed, Sep 4, 2024 at 8:32 PM Jeff Law wrote:
On 9/2/24 2:01 PM, Raphael Moreira Zinsly wrote:
...
+ bool bit31 = (hival & 0x8000) != 0;
+ int trailing_shift = ctz_hwi (loval) - ctz_hwi (hival);
+ int leading_shift = clz_hwi (lova
On 9/5/24 1:26 PM, Patrick Palka wrote:
On Thu, 5 Sep 2024, Jason Merrill wrote:
On 9/5/24 10:54 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
A lambda within a default template argument used in some template-id
may have
So the first patch failed the pre-commit CI; it didn't fail in my
testing because I'm using --with-arch to set a default configuration
that includes things like zicond to ensure that's always tested. And
the failing test is skipped when zicond is enabled by default.
The failing test is desi
[Sorry I crossed the streams here, I had to run out in the middle of
writing up that other reply.]
On Thu, 05 Sep 2024 10:49:47 PDT (-0700), jeffreya...@gmail.com wrote:
On 9/5/24 8:27 AM, Nathan Sidwell wrote:
Hi,
looking at the RISCV code, it seems that there are several vendor-
specific f
On Thu, 05 Sep 2024 07:27:57 PDT (-0700), nat...@acm.org wrote:
Hi,
looking at the RISCV code, it seems that there are several vendor-specific files
in config/riscv. For instance sifive-7.md and xiangshan.md. It seems these are
unconditionally included for all riscv targets. I guess then one doe
On 9/5/24 8:27 AM, Nathan Sidwell wrote:
Hi,
looking at the RISCV code, it seems that there are several vendor-
specific files in config/riscv. For instance sifive-7.md and
xiangshan.md. It seems these are unconditionally included for all riscv
targets. I guess then one doesn't end up with
On Thu, 5 Sep 2024, Jason Merrill wrote:
> On 9/5/24 10:54 AM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk/14?
> >
> > -- >8 --
> >
> > A lambda within a default template argument used in some template-id
> > may have a smaller temp
Applying to trunk as obvious.
-- >8 --
There's an extra '+'.
gcc/ChangeLog:
* doc/invoke.texi: Remove an extra char in @item sme2.
---
gcc/doc/invoke.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 193db761d64..0f9
(Sorry, I missed this because I was on vacation.)
On 11/08/2024 22:00, Robin Dapp wrote:
This patch adds a zero else operand to the masked loads.
The patch is OK, but I have a question below.
gcc/ChangeLog:
* config/gcn/predicates.md (maskload_else_operand): New
predicate.
On 9/5/24 7:02 AM, Simon Martin wrote:
Hi Jason,
On 4 Sep 2024, at 18:09, Jason Merrill wrote:
On 9/1/24 2:51 PM, Simon Martin wrote:
Hi Jason,
On 26 Aug 2024, at 19:23, Jason Merrill wrote:
On 8/25/24 12:37 PM, Simon Martin wrote:
On 24 Aug 2024, at 23:59, Simon Martin wrote:
On 24 Aug
On 9/5/24 10:54 AM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
A lambda within a default template argument used in some template-id
may have a smaller template depth than the context of the template-id.
For example, the lambd
On Arm only r0-r3 (the argument registers) and IP are available for
use as an address for an indirect sibcall. But if all the argument
registers are used and IP is clobbered during the epilogue, or is used
to pass closure information, then there is no spare register to hold
the address and we must
Tested adding 0..more-than-four environment variables,
running cris-sim+cris-elf. I also checked that foo stays
the same generated code regardless of the new code: this is
not obviously true as foo is "just" noinline, not __noipa__.
Ok to commit?
-- >8 --
This test awkwardly "blinks"; xfails and
On 9/5/24 11:14 AM, Jakub Jelinek wrote:
On Thu, Sep 05, 2024 at 10:51:47AM -0400, Jason Merrill wrote:
@@ -8993,6 +9010,11 @@ cp_finish_decl (tree decl, tree init, bo
if (var_definition_p)
abstract_virtuals_error (decl, type);
+ if (decomp
+ && !processing_template
On Wed, 04 Sep 2024 15:20:45 PDT (-0700), jeffreya...@gmail.com wrote:
On 9/4/24 4:07 PM, Palmer Dabbelt wrote:
These tests were checking that the output of the setCC instruction was bit
flipped, but it looks like they're really designed to test that
redundant sign extension elimination fires
On 9/5/24 11:10 AM, Marek Polacek wrote:
On Thu, Sep 05, 2024 at 10:42:22AM -0400, Jason Merrill wrote:
On 9/4/24 1:18 PM, Marek Polacek wrote:
On Wed, Sep 04, 2024 at 12:28:49PM -0400, Jason Merrill wrote:
+ if (!validate_constexpr_redeclaration (alias, decl))
+return;
+
retrofit
On 9/5/24 9:03 AM, Jakub Jelinek wrote:
Hi!
I've tried to do the same thing I did for normal standard attributes
also for alignas, but there are way too many cases which are silently
accepted although my reading of:
"An alignment-specifier may be applied to a variable or to a class data member,
On Thu, Sep 05, 2024 at 10:51:47AM -0400, Jason Merrill wrote:
> > @@ -8993,6 +9010,11 @@ cp_finish_decl (tree decl, tree init, bo
> > if (var_definition_p)
> > abstract_virtuals_error (decl, type);
> > + if (decomp
> > + && !processing_template_decl
> > + && !cp_finish_dec
On Thu, Sep 05, 2024 at 10:42:22AM -0400, Jason Merrill wrote:
> On 9/4/24 1:18 PM, Marek Polacek wrote:
> > On Wed, Sep 04, 2024 at 12:28:49PM -0400, Jason Merrill wrote:
>
> > > > + if (!validate_constexpr_redeclaration (alias, decl))
> > > > +return;
> > > > +
> > > > retrofit_lang_de
> It's worth noting there is a newer way which is usually slightly simpler
> than a match_operator. Specifically code iterators.
Thank you for the very detailed feedback. It is not a problem to add code
iterators. I would add iterators for "eq" and "ne" in riscv/iterators.md since
they don't cur
Bootstrapped and regtested (so far just dg.exp) on x86_64-pc-linux-gnu,
OK for trunk if full regtest passes? Or would it be better to try to
implement all the rules mentioned in the linked pull request for one
commit; I admit I haven't looked very closely yet at how else we
diverge?
-- >8 --
Thi
On Thu, 5 Sep 2024, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> for trunk/14?
>
> -- >8 --
>
> A lambda within a default template argument used in some template-id
> may have a smaller template depth than the context of the template-id.
> For exa
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
A lambda within a default template argument used in some template-id
may have a smaller template depth than the context of the template-id.
For example, the lambda in v1's default template argument has tem
On 9/4/24 2:03 PM, Jakub Jelinek wrote:
On Wed, Sep 04, 2024 at 01:22:47PM -0400, Jason Merrill wrote:
@@ -8985,6 +9003,13 @@ cp_finish_decl (tree decl, tree init, bo
if (var_definition_p)
abstract_virtuals_error (decl, type);
+ if (decomp && !processing_template_decl)
+
On 9/4/24 1:18 PM, Marek Polacek wrote:
On Wed, Sep 04, 2024 at 12:28:49PM -0400, Jason Merrill wrote:
+ if (!validate_constexpr_redeclaration (alias, decl))
+return;
+
retrofit_lang_decl (decl);
DECL_LOCAL_DECL_ALIAS (decl) = alias;
}
I don't think we need this in the case
Hi,
looking at the RISCV code, it seems that there are several vendor-specific files
in config/riscv. For instance sifive-7.md and xiangshan.md. It seems these are
unconditionally included for all riscv targets. I guess then one doesn't end up
with some combinatorial explosion of possible risc
> On Tue, Sep 3, 2024 at 4:00 AM Jan Hubicka wrote:
> >
> > > > >
> > > > > PR ipa/116410
> > > > > * ipa-modref.cc (analyze_parms): Always analyze function
> > > > > parameter
> > > > > for LTO streaming.
> > > > >
> > > > > Signed-off-by: H.J. Lu
> > > > > ---
> > > > >
The following fixes a mistake when applying the bias for peeling via
masking to the inital value of SLP inductions.
This resolves gcc.target/aarch64/sve/peel_ind_1.c (a scan-assembler
only unfortunately) when forcing single-lane SLP for it.
PR tree-optimization/116610
* tree-vect-
The following enables single-lane loop SLP discovery for non-grouped stores
and adjusts vectorizable_store to properly handle those.
For gfortran.dg/vect/vect-8.f90 we vectorize one additional loop,
not running into the "not falling back to strided accesses" bail-out.
I have not investigated in de
The following implements the simple case of single-lane SLP when
using partial vectors which can use the VEC_EXTRACT_LAST code
generation without changes. I'll keep the PR open for further
enhancements.
This avoids FAILs of gcc.target/aarch64/sve/live_1.c when using
single-lane SLP for non-groupe
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, September 3, 2024 2:09 PM
> To: Prathamesh Kulkarni
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [gimplify.cc] Avoid ICE when passing VLA vector to
> accelerator
>
> External email: Use caution opening links or attachments
>
Hi!
I've tried to do the same thing I did for normal standard attributes
also for alignas, but there are way too many cases which are silently
accepted although my reading of:
"An alignment-specifier may be applied to a variable or to a class data member,
but it shall not be applied to a bit-fiel
Hi!
Another non-problematic attribute.
Tested on x86_64-linux and i686-linux, ok for trunk?
2024-09-05 Jakub Jelinek
PR c++/110345
* g++.dg/cpp0x/attr-no_unique_address1.C: New test.
--- gcc/testsuite/g++.dg/cpp0x/attr-no_unique_address1.C.jj 2024-09-05
14:01:00.3968869
Hi!
Another non-problematic attribute.
Tested on x86_64-linux and i686-linux, ok for trunk?
2024-09-05 Jakub Jelinek
PR c++/110345
* g++.dg/cpp0x/attr-noreturn1.C: New test.
--- gcc/testsuite/g++.dg/cpp0x/attr-noreturn1.C.jj 2024-09-05
13:45:58.193567109 +0200
+++ gcc/
Hi!
Fairly non-problematic attribute, again on top of the whole series.
Tested on x86_64-linux, ok for trunk?
2024-09-05 Jakub Jelinek
PR c++/110345
* g++.dg/cpp0x/attr-nodiscard1.C: New test.
--- gcc/testsuite/g++.dg/cpp0x/attr-nodiscard1.C.jj 2024-09-05
13:11:26.91404
Hi!
On 2024-09-05T14:42:00+0200, I wrote:
> On 2024-09-05T14:39:46+0200, I wrote:
>> On 2024-09-05T14:36:54+0200, I wrote:
>>> On 2022-03-22T14:41:46+0100, Tom de Vries via Gcc-patches
>>> wrote:
[nvptx] Use .alias directive for mptx >= 6.3
>>>
--- a/gcc/config/nvptx/nvptx.cc
+++
Hi!
On 2024-09-05T14:39:46+0200, I wrote:
> On 2024-09-05T14:36:54+0200, I wrote:
>> On 2022-03-22T14:41:46+0100, Tom de Vries via Gcc-patches
>> wrote:
>>> [nvptx] Use .alias directive for mptx >= 6.3
>>
>>> --- a/gcc/config/nvptx/nvptx.cc
>>> +++ b/gcc/config/nvptx/nvptx.cc
>>
>>> @@ -968,7 +9
Hi!
On 2024-09-05T14:36:54+0200, I wrote:
> On 2022-03-22T14:41:46+0100, Tom de Vries via Gcc-patches
> wrote:
>> [nvptx] Use .alias directive for mptx >= 6.3
>
>> --- a/gcc/config/nvptx/nvptx.cc
>> +++ b/gcc/config/nvptx/nvptx.cc
>
>> @@ -968,7 +969,8 @@ static void
>> write_fn_proto_1 (std::s
Hi!
On 2022-03-22T14:41:46+0100, Tom de Vries via Gcc-patches
wrote:
> Starting with ptx isa version 6.3, a ptx directive .alias is available.
> Use this directive to support symbol aliases, as far as possible.
> The alias support has the following [and more] limitations.
> Aliases to aliases
Hi!
On 2022-03-22T14:41:46+0100, Tom de Vries via Gcc-patches
wrote:
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/nvptx/alias-1.c
> @@ -0,0 +1,27 @@
> +[...]
> +int v;
> +
> +void __f ()
> +{
> + v = 1;
> +}
> +
> +void f () __attribute__ ((alias ("__f")));
> +
> +int
> +main (void)
> +{
>
Hi!
On 2024-07-18T13:44:37+0200, wrote:
> OK to push (once testing completes) the attached
> "Make 'target-supports.exp' additions for nvptx target generally available"?
>
> The idea of this new scheme is that explicit feature/target-specific
> stuff isn't kept in 'gcc/testsuite/lib/target-suppor
Hi,
there is nothing exciting in this patch. I measured latencies and also
compared them with newly released optimization guide and it seems that
only important change is that addss is fastr now. It can be 2 cycles
instaead of 3 in some cases when the input parameter is computed by
another additio
On Wed, Sep 4, 2024 at 8:35 PM Jeff Law wrote:
> On 9/2/24 2:01 PM, Raphael Moreira Zinsly wrote:
>...
> > +unsigned long foo_0x4afe605fb5019fa0(void) { return 0x4afe605fb5019fa0UL; }
> > +unsigned long foo_0x07a80d21f857f2de(void) { return 0x07a80d21f857f2deUL; }
> > +unsigned long foo_0x6699f19c
On Wed, Sep 4, 2024 at 8:32 PM Jeff Law wrote:
> On 9/2/24 2:01 PM, Raphael Moreira Zinsly wrote:
> ...
> > + bool bit31 = (hival & 0x8000) != 0;
> > + int trailing_shift = ctz_hwi (loval) - ctz_hwi (hival);
> > + int leading_shift = clz_hwi (loval) - clz_hwi (hival);
> > +
From: Pan Li
This patch would like to support the form 3 of the scalar signed
integer .SAT_ADD. Aka below example:
Form 3:
#define DEF_SAT_S_ADD_FMT_3(T, UT, MIN, MAX) \
T __attribute__((noinline))\
sat_s_add_##T##_fmt_3 (T x, T y)
From: Pan Li
The gen_phi_on_cond can only support below control flow for cond
from day 1. Aka:
+--+
| def |
| ... | +-+
| cond |-->| def |
+--+ | ... |
| +-+
| |
v |
+-+ |
| PHI |<--+
+-+
U
commit b5c2aae48723c9098a8a3dab1409b30fd87bbf56
Author: YunQiang Su
Date: Thu Sep 5 15:14:43 2024 +0800
RISC-V: Lookup reversely in riscv_select_multilib_by_abi
The last element should use index
multilib_infos.size () - 1
gcc
* common/config/riscv/riscv-common.cc(riscv_select_m
Monday, September 2, 2024
Richard Sandiford wrote:
> Thanks for submitting this. I've responded with minor comments to
> some individual patches, but the rest (1, 2, 7, and 8) look good to
> me as-is.
Thank you for the review. The patch series v2 will be submitted after
the validation.
Regards
On Thu, 5 Sep 2024, Evgeny Karpov wrote:
Monday, September 2, 2024
Martin Storsjö
The patch adds support for weak references. The original MinGW
implementation targets ix86, which handles weak symbols differently
compared to AArch64.
Please clarify this statement.
Here is an explanation of
Monday, September 2, 2024
Richard Sandiford wrote:
> I realise this is pre-existing, bue the last line should probably be:
>
> fprintf ((FILE), "," HOST_WIDE_INT_PRINT_UNSIGNED "\n", (ROUNDED)))
>
> to avoid silent truncation. (Even if the format only supports 32-bit
> code and data, it's bett
On Tue, Sep 3, 2024 at 4:00 AM Jan Hubicka wrote:
>
> > > >
> > > > PR ipa/116410
> > > > * ipa-modref.cc (analyze_parms): Always analyze function
> > > > parameter
> > > > for LTO streaming.
> > > >
> > > > Signed-off-by: H.J. Lu
> > > > ---
> > > > gcc/ipa-modref.cc |
Monday, September 2, 2024
Richard Sandiford wrote:
> On patch 1, do you have a reference for how AArch64 and x86 handle weak
> references for MinGW? The code looks good, but I didn't really follow
> why it was doing what it was doing.
Monday, September 2, 2024
Martin Storsjö
>> The patch adds
Richard Biener writes:
> The following adjusts the scan-assembler to also allow predicate
> registers p8-15 to be used for the destination of the compares.
> I see that code generation with a pending vectorizer patch (the
> only assembler change is different predicate register allocation).
Oops,
Changes from previous revision:
Rename new `check_effective_target' and tests to make their intent
clearer.
* lib/target-supports.exp: For new `check_effective_target',
s/vect_dotprod_twoway/vect_dotprod_hisi/.
* One test is renamed to `vect-dotprod-conv-optab.c' to emphasize
aim of c
1 - 100 of 130 matches
Mail list logo
