A possible approach to reference is detection of tabled-based CTZ in
ssa-forward pass, which might be a suitable position for this pattern, in
that ssa-forward pass is invoked more than one time, some happen before
reassociation pass. But simplification of the 64x64->128 patt
On Sat, Dec 6, 2025 at 1:33 PM Jonathan Wakely wrote:
> On Sat, 06 Dec 2025 at 12:30 +, Jonathan Wakely wrote:
> >On Fri, 29 Aug 2025 at 13:33 +0200, Tomasz Kamiński wrote:
> >>The changes the _Variadic_union implementation, in a way that the
> >>_Unitialized partial specialization for non-tr
On Mon, Dec 8, 2025 at 2:51 PM Hongtao Liu wrote:
>
> On Mon, Dec 8, 2025 at 1:42 PM H.J. Lu wrote:
> >
> > When -march=cascadelake is added, we generate
> >
> > vmovdqa x(%rip), %ymm0
> > vpcmpq $1, x(%rip), %ymm0, %k0
> > vpmovm2q %k0, %ymm0
> > vmovdqa %ymm0, x(%rip)
> >
> > instead of
> >
> >
On Mon, Dec 8, 2025 at 1:42 PM H.J. Lu wrote:
>
> When -march=cascadelake is added, we generate
>
> vmovdqa x(%rip), %ymm0
> vpcmpq $1, x(%rip), %ymm0, %k0
> vpmovm2q %k0, %ymm0
> vmovdqa %ymm0, x(%rip)
>
> instead of
>
> vmovdqa x(%rip), %ymm1
> vmovdqa x(%rip), %ymm0
> vpcmpgtq %ymm1, %ymm0, %ym
> -Original Message-
> From: H.J. Lu
> Sent: Monday, December 8, 2025 1:40 PM
> To: Liu, Hongtao ; GCC Patches [email protected]>; Uros Bizjak ; Jiang, Haochen
>
> Subject: [PATCH] x86: Don't allow 2 volatile memory references
>
> Don't allow 2 volatile memory references in *_cmp3_d
When -march=cascadelake is added, we generate
vmovdqa x(%rip), %ymm0
vpcmpq $1, x(%rip), %ymm0, %k0
vpmovm2q %k0, %ymm0
vmovdqa %ymm0, x(%rip)
instead of
vmovdqa x(%rip), %ymm1
vmovdqa x(%rip), %ymm0
vpcmpgtq %ymm1, %ymm0, %ymm0
vmovdqa %ymm0, x(%rip)
Compile avx2-vpcmpgtq-1.c with -fno-fuse-op
Don't allow 2 volatile memory references in *_cmp3_dup_op
so that gcc.target/i386/avx2-vpcmpeqq-1.c will generate 2 loads when
-march=cascadelake is used.
PR target/122343
* config/i386/sse.md (*_cmp3_dup_op): Don't allow
2 volatile memory references.
--
H.J.
From 858c0e212162c832cdb3e6c2b56a76
On Fri, 2025-12-05 at 22:05 -0700, Jeff Law wrote:
>
> Here's an update that adds a pattern to the SH port to recognize the
> slightly different RTL presented for this scenario. Essentially it just
> needs to recognize (xor (rotate)) for a count of 1 and flipping the low bit.
>
> OK for the
On Linux/x86_64,
a6c50ec2c6ebcbda2b032eee0552a6a486355e12 is the first bad commit
commit a6c50ec2c6ebcbda2b032eee0552a6a486355e12
Author: H.J. Lu
Date: Fri Oct 24 09:00:59 2025 +0800
Add -ffuse-ops-with-volatile-access
caused
FAIL: gcc.target/i386/avx2-vpcmpeqq-1.c scan-assembler vpcmpeq
> -Original Message-
> From: H.J. Lu
> Sent: Sunday, December 7, 2025 10:42 AM
> To: Florian Weimer
> Cc: [email protected]; [email protected]; Liu, Hongtao
>
> Subject: Re: [PATCH] x86-64: Remove redundant TLS calls
>
> On Sun, Dec 7, 2025 at 3:31 AM Florian Weimer wrote:
> >
On Sun, Dec 7, 2025, 12:45 PM Florian Weimer wrote:
> * Jeff Law:
>
> > This is Shreya's work except for the SH testcase which I added after
> > realizing her work would also fix the testcases for that port. I
> > bootstrapped and regression tested this on sh4-linux-gnu, x86_64 &
> > risc-v. It
These functions should return false for error_mark_node to properly
propagate errors from callers.
gcc/cp/ChangeLog:
* decl2.cc (mark_single_function): Return false for error_mark_node.
(mark_used): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/DRs/dr3061.C: Remove cascadi
When checking a deleted explicit specialization in a SFINAE context,
we were incorrectly selecting a partial specialization because
resolve_nondeduced_context was calling mark_used. But resolving an
overload to a single function (per DR 115) does not constitute ODR-use,
so mark_used shouldn't be c
On 12/7/25 1:44 PM, Florian Weimer wrote:
* Jeff Law:
This is Shreya's work except for the SH testcase which I added after
realizing her work would also fix the testcases for that port. I
bootstrapped and regression tested this on sh4-linux-gnu, x86_64 &
risc-v. It also was tested across a
Regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
When processing inherited CTAD in C++23, type_targs_deducible_from can
be called with a synthetic alias template whose TREE_VALUE is a type
alias like std::string_view. Since type aliases don't have their own
TEMPLATE_INFO, calling TI_TEMP
This was reported as a regression in GCC 14: the compiler resolves Accum_Type
to Positive for a reduction expression whose "expected subtype" is Positive,
which means that 0 cannot be used as initial value in the expression:
Sum : Positive := V'Reduce ("+", 0);
without always raising Constrai
> For __MINGW32__, we need to include for malloc.
>
> gcc/ada/ChangeLog:
> PR ada/123037
> * rtinit.c: Include for __MINGW32__.
OK, but please include it before mingw32.h and let's remove some duplication
in the process:
PR ada/123037
* rtinit.c [__MINGW32__]: In
On 12/7/25 13:18, Paul Koning wrote:
The pdp-11 changes look mostly ok but I have two questions.
1. Why did you remove -munix-asm, mdec-asm and -mgnu-asm along with -mlro from
the gccoptlist at the top?
My patch doesn't do that. :-)
2. -m40 and -m45 aren't supposed to have negative forms.
On 2025-12-07 13:28, Patrick Palka wrote:
> > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > index 7a019d33bda..f992bf5c0bb 100644
> > --- a/gcc/cp/pt.cc
> > +++ b/gcc/cp/pt.cc
> > @@ -24815,8 +24815,6 @@ resolve_nondeduced_context (tree orig_expr,
> > tsubst_flags_t complain)
> > }
> >i
* Jeff Law:
> This is Shreya's work except for the SH testcase which I added after
> realizing her work would also fix the testcases for that port. I
> bootstrapped and regression tested this on sh4-linux-gnu, x86_64 &
> risc-v. It also was tested across all the embedded targets in my tester
The pdp-11 changes look mostly ok but I have two questions.
1. Why did you remove -munix-asm, mdec-asm and -mgnu-asm along with -mlro from
the gccoptlist at the top?
2. -m40 and -m45 aren't supposed to have negative forms. I guess I'm missing
RejectNegative in the option definition.
p
* Stefan Schulze Frielinghaus:
> So far only a per thread canary in the TLS block is supported. This
> patch adds support for a global canary, too. For this the new option
> -mstack-protector-guard={global,tls} is added which defaults to tls.
>
> The global canary is expected at symbol __stack_c
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Modules allow temploid friends to no longer be implicitly inline, as
functions defined in a class body will not be implicitly inline if
attached to a named module.
This requires us to clean up linkage handling a little bit
* Marc Poulhiès:
> From: Ronan Desplanques
>
> On some platforms, Long_Long_Float'Size (and Long_Long_Float'Stream_Size)
> is 128 but only 80 bits are effectively used. This pack makes it so
> 'Write in this case write zeros for the padding bits instead of
> unspecified values.
>
> gcc/ada/Change
On Sat, Dec 06, 2025 at 05:10:30PM -0700, Sandra Loosemore wrote:
> gcc/ChangeLog
> PR other/122243
> * doc/invoke.texi (Option Summary) : Fix whitespace
> in option list.
> (PRU Options): Copy-editing. Index and list negative option forms.
> ---
> gcc/doc/invoke.texi | 23
Hi Sandra,
Good to see you around!
> * config/mips/mips.opt (mfix4300): Mark as "Undocumented".
We might well take the opportunity and actually document the option:
;; Early VR4300 silicon has a CPU bug where multiplies with certain
;; operands may corrupt immediately following multipli
On Sat, 6 Dec 2025, Egas Ribeiro wrote:
> Removing mark_used from resolve_nondeduced_context as Patrick and Jason
> suggested caused no regressions.
>
> Regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> When checking a deleted explicit specialization in a SFINAE context,
> we wer
On 2025-12-06 7:10 p.m., Sandra Loosemore wrote:
> Note that the default for the -mlra option on HPPA was recently
> changed from 0 to 1. This option has never been documented for this
> target and reload is supposed to be going away entirely soon, so I
> see no reason to document it now.
>
> gcc
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r16-5949-g01d4414e3ea409.
gcc/analyzer/ChangeLog:
* kf.cc (register_known_functions): Remove duplicate calls to
register_atomic_builtins and register_varargs_builtins.
Signed-off-by: David Malcolm
-
The following patch has remained unreviewed for a week and a half:
Fix PID_TYPE on 32-bit Solaris
https://gcc.gnu.org/pipermail/gcc-patches/2025-November/701988.html
Thanks.
Rainer
--
-
Rainer Or
There are targets, which only offer 32-bit atomic operations (for
example 32-bit RISC-V). For these targets, split the 64-bit atomic
bitwise-or operation into two parts.
For this test case
int a(int i);
int b(int i);
int f(int i)
{
if (i) {
return a(i);
} else {
return b(i);
}
}
The pattern ends up using the argument more than one time which
isn't supported. When FFS directly maps to CTZ + 1 it works though.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimization/123038
* tree-vect-patterns.cc (vect_recog_ctz_ffs_pattern): Reject
On Sat, Dec 6, 2025 at 11:21 AM Jakub Jelinek wrote:
>
> On Sat, Dec 06, 2025 at 11:17:11AM +0100, Richard Biener wrote:
> > > The following testcase ICEs since checking has been added to
> > > TYPE_PRECISION
> > > macro. check_bitfield_type_and_width is called when attributes haven't
> > > been
> ... and here's that part split out for the next stage1. Ok then?
Sure.
--
Eric Botcazou
34 matches
Mail list logo
