Hi!
I'd like to ping some C family patches:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681741.html
- PR44677 - c, c++: Extend -Wunused-but-set-* warnings
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/685543.html
- PR120520 - Extend nonnull_if_nonzero attribute
plus a questio
On Sun, 22 Jun 2025, Jan Hubicka wrote:
> Hi,
> auto-fdo is currently confused by a fact that all inlined functions get
> locators with 0 discriminator, so it is not bale to distinguish multiple
> inlined calls from single line.
>
> Discriminator is lost by calling LOCATION_LOCUS before copying i
On Sat, Jun 21, 2025 at 11:09 PM H.J. Lu wrote:
>
> On Fri, Jun 20, 2025 at 4:12 PM H.J. Lu wrote:
> >
> > Don't use vmovdqu16/vmovdqu8 with non-EVEX registers even if AVX512BW is
> > available.
> >
> > gcc/
> >
> > PR target/120728
> > * config/i386/i386.cc (ix86_get_ssemov): Use vmovdqu16/vmovd
When attempting to bootstrap arm-linux-gnueabihf with
{BOOT_C,T}FLAGS='-g -O2 -fnon-call-exceptions
-fstack-clash-protection', gmp fails to build in stage2: gen-fac's
mpz_and gets miscompiled.
A pseudo is initialized before a loop and used in a PRE_INC load
inside a loop. It gets spilled just a
On Jun 13, 2025, Vladimir Makarov wrote:
>> * lra-eliminations.cc (lra_update_fp2sp_elimination):
>> Inactivate the unused fp2sp elimination right away.
Alas, this seems to cause trouble on arm-linux-gnueabihf bootstraps.
Here's an alternate approach that builds on it to solves the earlier
prob
And here's a followup to clean up the mess I made in
lra_update_fp2sp_elimination, without any functional changes.
The various recent additions to lra_update_fp2sp_elimination rendered
it somewhat confusing, with intermixed groups of statements pertaining
to three different major actions: disabli
> Add a PROCESSOR_XXX comment to each entry in processor_cost_table to
> describe which processor the cost enry is applied to.
>
> * config/i386/i386-options.cc (processor_cost_table): Add a
> PROCESSOR_XXX comment to each entry.
>
>
> --
> H.J.
> From 8b37db60ec21c1c673eb1e336208dc10a5d86d5c
An x86_64-linux-gnu native with ix86_frame_pointer_required modified
to return true for nonzero frames, to exercize
lra_update_fp2sp_elimination, reveals in stage1 testing that wrong
code is generated for gcc.c-torture/execute/ieee/fp-cmp-8l.c:
argp-to-sp eliminations are used for one_test to pas
acats' fdd2a00.read is miscompiled on arm-linux-gnu with -O2
-fstack-clash-protection -march=armv7-a -marm: a clobbered scratch
register in a *iorsi3_compare0_scratch pattern gets initially assigned
to the frame pointer register, but at some point during lra the frame
size grows to nonzero, arm_f
On Mon, Jun 23, 2025 at 11:03 AM H.J. Lu wrote:
>
> Add a PROCESSOR_XXX comment to each entry in processor_cost_table to
> describe which processor the cost enry is applied to.
Ok as obvious.
>
> * config/i386/i386-options.cc (processor_cost_table): Add a
> PROCESSOR_XXX comment to each entry.
>
>
Add a PROCESSOR_XXX comment to each entry in processor_cost_table to
describe which processor the cost enry is applied to.
* config/i386/i386-options.cc (processor_cost_table): Add a
PROCESSOR_XXX comment to each entry.
--
H.J.
From 8b37db60ec21c1c673eb1e336208dc10a5d86d5c Mon Sep 17 00:00:00 2
On Fri, Jun 20, 2025 at 10:04 AM Haochen Jiang wrote:
>
> Hi all,
>
> CLDEMOTE is not enabled on clients according to SDM. SDM only mentioned
> it will be enabled on Xeon and Atom servers, not clients. Remove them
> since Alder Lake (where it is introduced).
>
> Also will backport this patch to GC
On Sun, Jun 22, 2025 at 9:54 PM Max Filippov wrote:
>
> On Sun, Jun 22, 2025 at 5:49 AM Takayuki 'January June' Suwa
> wrote:
> >
> > On 2025/06/22 6:41, Max Filippov wrote:
> > > On Sat, Jun 21, 2025 at 2:12 PM Takayuki 'January June' Suwa
> > > wrote:
> > >>
> > >> That hook has since been dep
Hi,
This patch adds GUESSED_GLOBAL0_AFDO profile quality. It can
be used to preserve local counts of functions which have 0 AFDO
profile.
I originally did not include it as it was not clear it will be useful and
it turns quality from 3bits to 4bits which means that we need to steal another
bit fro
On Sat, Jun 21, 2025 at 3:54 PM H.J. Lu wrote:
> On Sun, Jun 22, 2025 at 6:35 AM Max Filippov wrote:
> > On Sat, Jun 21, 2025 at 2:41 PM Max Filippov wrote:
> > > On Sat, Jun 21, 2025 at 2:12 PM Takayuki 'January June' Suwa
> > > wrote:
> > > >
> > > > That hook has since been deprecated
> > >
On Mon, Jun 16, 2025 at 6:33 AM Takayuki 'January June' Suwa
wrote:
>
> This patch implements the target-specific ZERO_CALL_USED_REGS hook, since
> if -fzero-call-used-regs=all the default hook tries to assign 0 to B0
> (bit 0 of the BR register) and the ICE will be thrown.
>
> gcc/ChangeLog:
>
>
On 2025/06/23 6:20, H.J. Lu wrote:
On Sun, Jun 22, 2025 at 9:54 PM Max Filippov wrote:
On Sun, Jun 22, 2025 at 5:49 AM Takayuki 'January June' Suwa
wrote:
On 2025/06/22 6:41, Max Filippov wrote:
On Sat, Jun 21, 2025 at 2:12 PM Takayuki 'January June' Suwa
wrote:
That hook has since been
Hi Mikael!
Am 20.06.25 um 12:08 schrieb Mikael Morin:
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
Ok for master?
-- >8 --
The temporary variables that are generated to implement SELECT TYPE
and TYPE IS statements have (before this change) a name depending only
on the typ
From: Mikael Morin
See the description in the ChangeLog entry below.
The testcases are best effort; for some operators the fortran frontend
generates a temporary variable, so the simplification doesn't happen.
Those cases are not tested.
Regression tested on x86_64-linux. OK for master?
-- 8<
This bug was found by Edwin's fuzzing efforts on RISC-V, though it
likely affects other targets.
In simplest terms when ext-dce converts an extension into a (possibly
simplified) subreg copy it may make an attached REG_EQUAL note invalid.
In the case Edwin found the note was an extension, but
Hi Tomasz and others,
please don't review this. I found some preprequisites I'm not
checking. While implementing the checks for std::extents, I
got saved by one of the tests that exercises the code with an
IntLike (instead of an int).
Therefore, the first task has to be to tighten up the testing
On Sun, Jun 22, 2025 at 5:49 AM Takayuki 'January June' Suwa
wrote:
>
> On 2025/06/22 6:41, Max Filippov wrote:
> > On Sat, Jun 21, 2025 at 2:12 PM Takayuki 'January June' Suwa
> > wrote:
> >>
> >> That hook has since been deprecated
> >> (commit a670ebde3995481225ec62b29686ec07a21e5c10) and has
On 2025/06/22 6:41, Max Filippov wrote:
On Sat, Jun 21, 2025 at 2:12 PM Takayuki 'January June' Suwa
wrote:
That hook has since been deprecated
(commit a670ebde3995481225ec62b29686ec07a21e5c10) and has led to incorrect
results on Xtensa:
/* example */
#define
uint32_t __att
So this is Andrew's patch from the PR. We weren't clean for a 32bit
host in some of the arithmetic for constant synthesis.
I confirmed the bug on a 32bit linux host, then confirmed that Andrew's
patch from the PR fixes the problem, then ran Andrew's patch through my
tester successfully.
Nat
Regtested for target=xtensa-linux-uclibc, no new regressions.
Committed to master.
On Mon, Jun 16, 2025 at 11:56 PM Takayuki 'January June' Suwa
wrote:
>
> This patch implements bitfield insertion MD pattern using the DEPBITS
> machine instruction, the counterpart of the EXTUI instruction, if
> av
Hi,
This patch fixes problems I noticed by exploring profiles of some hot
functions in GCC. In particular the propagation sometimes changed
precise 0 to afdo 0 for paths calling abort and sometimes we could
propagate more when we accept that some paths has 0 count.
Finally there was important bug
On Sun, Jun 22, 2025 at 2:57 PM Jan Hubicka wrote:
>
> > This contradicts
> >
> > /* X86_TUNE_READ_MODIFY_WRITE: Enable use of read modify write instructions
> >such as "add $1, mem". */
> > DEF_TUNE (X86_TUNE_READ_MODIFY_WRITE, "read_modify_write",
> > ~(m_PENT | m_LAKEMONT))
> >
>
On Sun, Jun 22, 2025 at 2:12 PM Jan Hubicka wrote:
>
> >
> > Since read-modify-write is enabled for PentiumPro:
> >
> > /* X86_TUNE_READ_MODIFY_WRITE: Enable use of read modify write instructions
> >such as "add $1, mem". */
> > DEF_TUNE (X86_TUNE_READ_MODIFY_WRITE, "read_modify_write",
> >
> This contradicts
>
> /* X86_TUNE_READ_MODIFY_WRITE: Enable use of read modify write instructions
>such as "add $1, mem". */
> DEF_TUNE (X86_TUNE_READ_MODIFY_WRITE, "read_modify_write",
> ~(m_PENT | m_LAKEMONT))
>
> which enables "andl $0, (%edx)" for PentiumPro. "andl $0, (%edx
On Sun, Jun 22, 2025 at 1:32 PM Jan Hubicka wrote:
>
> > Since there is
> >
> > /* X86_TUNE_SPLIT_LONG_MOVES: Avoid instructions moving immediates
> >directly to memory. */
> > DEF_TUNE (X86_TUNE_SPLIT_LONG_MOVES, "split_long_moves", m_PPRO)
>
> If I recall correctly, this tune was added for
>
> Since read-modify-write is enabled for PentiumPro:
>
> /* X86_TUNE_READ_MODIFY_WRITE: Enable use of read modify write instructions
>such as "add $1, mem". */
> DEF_TUNE (X86_TUNE_READ_MODIFY_WRITE, "read_modify_write",
> ~(m_PENT | m_LAKEMONT))
>
> should this
>
> /* Generate
> Since there is
>
> /* X86_TUNE_SPLIT_LONG_MOVES: Avoid instructions moving immediates
>directly to memory. */
> DEF_TUNE (X86_TUNE_SPLIT_LONG_MOVES, "split_long_moves", m_PPRO)
If I recall correctly, this tune was added for PentiumPro which had
problem decoding moves with long immediate an
Hi,
auto-fdo is currently confused by a fact that all inlined functions get
locators with 0 discriminator, so it is not bale to distinguish multiple
inlined calls from single line.
Discriminator is lost by calling LOCATION_LOCUS before copying it from
former call statement. I believe this is only
Hi,
This is the last part of the infrastructure to allow functions with
local profiles and 0 global autofdo counts.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
* auto-profile.cc (afdo_set_bb_count): Dump inline stacks
and reasons when lookup failed.
(afd
> In addition to working with you on the issues of profile being lost with
> LTO, cloning and other cases, my plan is to
> 1) finish the VPT reorganization
> 2) make AFD reader to scale up the profile since at least in data from
> SPEC or profiledbootstrap the counters are quite small integers w
I see, thanks Jeff, will make sure the online CI is OK before commit.
Pan
-Original Message-
From: Jeff Law
Sent: Saturday, June 21, 2025 10:32 PM
To: Robin Dapp ; Li, Pan2 ;
gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Chen, Ken ;
Liu, Hongtao
Subject: Re:
36 matches
Mail list logo
