On 2/5/25 3:43 PM, Peter Frost wrote:
Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html
We're in regression fixes only phase of our development cycle. This
doesn't fix a regression, so it'll need to wait for the next development
window to open before it gets further at
On Fri, Jan 31, 2025 at 08:04:53AM +0100, Richard Biener wrote:
> I fail to see where -Ofast is allowed, but only see the pre-existing
> flag check above
> which checks for no NaN/Inf rather than sNaN - the latter would be checked
> with
> HONOR_SNANS (mode).
Well -Ofast sets the flag_finite_math
From: Zixing Liu
This set of patches will add proper IEEE 128 quad precision marking to GDC
compiler, so that it works with the new changes in D standard library
where POWER system can use any math functions inside the standard library
that requires the "real" type.
The patch also adds the ELFv1
> -Original Message-
> From: Matthias Klose
> Sent: Tuesday, December 17, 2024 04:26
> To: Joseph Myers
> Cc: gcc-patches@gcc.gnu.org; James K. Lowden
> Subject: Re: The COBOL front end, in 8 notes + toplevel patch
>
> On 17.12.24 00:58, Joseph Myers wrote:
> > On Mon, 16 Dec 2024, Matth
Ping https://gcc.gnu.org/pipermail/gcc-patches/2025-January/672568.html
I was looking at a regression on the bfin port with a recent change to
the IRA and stumbled across this just doing a general port healthyness
evaluation.
The ABS instruction in the blackfin ISA is defined as saturating on
INT_MIN, which is a bit unexpected. We certainly can't use it when
-fw
> Hi José!
>
> I intend to provide a few comments to specific code changes that I might
> have some clue about, later on -- "my later"; ask my wife what span of
> time that might mean... ;-)
Thank you :)
>
> In the following, so far, just a few high-level comments:
>
>
> On 2025-01-01T03:09:44
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115568
The patch was successfully bootstrapped and tested on x86-64.
commit 98545441308c2ae4d535f14b108ad6551fd927d5
Author: Vladimir N. Makarov
Date: Wed Feb 5 14:23:23 2025 -0500
[PR115568][LRA]: Use more strict ou
> Hi!
>
> The following test ICEs on RISC-V at least latently since
> r14-1622-g99bfdb072e67fa3fe294d86b4b2a9f686f8d9705 which added
> RISC-V specific case to get_biv_step_1 to recognize also
> ({zero,sign}_extend:DI (plus:SI op0 op1))
>
> The reason for the ICE is that op1 in this case is CONST_PO
Hi Jason,
On 4 Feb 2025, at 21:23, Jason Merrill wrote:
> On 2/4/25 3:03 PM, Jason Merrill wrote:
>> On 2/4/25 11:45 AM, Simon Martin wrote:
>>> On 4 Feb 2025, at 17:17, Jason Merrill wrote:
>>>
On 2/4/25 10:56 AM, Simon Martin wrote:
> Hi Jason,
>
> On 4 Feb 2025, at 16:39, Jaso
Hi José!
I intend to provide a few comments to specific code changes that I might
have some clue about, later on -- "my later"; ask my wife what span of
time that might mean... ;-)
In the following, so far, just a few high-level comments:
On 2025-01-01T03:09:44+0100, "Jose E. Marchesi"
wrot
On Wed, Feb 05, 2025 at 12:59:58PM +0100, Jakub Jelinek wrote:
> Hi!
>
> Kees, any progress on this?
Hi!
I need to take another run at it. I got stalled out when I discovered
that I array-of-char-arrays attributes got applied at the "wrong" depth,
and stuff wasn't working.
e.g.:
char acpi_tabl
On Mon, Jan 13, 2025 at 04:16:14PM +, Qing Zhao wrote:
> Hi,
>
> This is the 5th ping of the middle end review of the patch set.
>
> Could you please take a look at the patch set for -fdiagnostics-details, and
> provide
> more advice on:
>
> A. Whether the middle-end design and implementat
This patch updates the attributes for the relatively few builtin
functions defined by the Go frontend to the current ones in
builtins.def. This fixes PR 118746. Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
PR go/118746
* go-gcc.cc (class Gcc_backend): De
Hi GCC Steering Committee!
Please consider accepting into GCC this new -- old? ;-) -- Algol 68
front end (awaiting conclusion of the ongoing technical review), and
appointing José as its maintainer. (At FOSDEM last weekend, we were
briefly discussing this contribution, and I offered to raise and
On Wed, Feb 05, 2025 at 10:11:27AM -0800, Palmer Dabbelt wrote:
> Jeff would know way better than I do here, but I think this is just trying
> to match addiw-type patterns and thus CONST_INT would be OK because we only
> have 12-bit constants here.
The code looks at REG_EQUIV/REG_EQUAL notes, so i
On Wed, 05 Feb 2025 09:57:56 PST (-0800), ja...@redhat.com wrote:
Hi!
The following test ICEs on RISC-V at least latently since
r14-1622-g99bfdb072e67fa3fe294d86b4b2a9f686f8d9705 which added
RISC-V specific case to get_biv_step_1 to recognize also
({zero,sign}_extend:DI (plus:SI op0 op1))
The r
Hi!
The following test ICEs on RISC-V at least latently since
r14-1622-g99bfdb072e67fa3fe294d86b4b2a9f686f8d9705 which added
RISC-V specific case to get_biv_step_1 to recognize also
({zero,sign}_extend:DI (plus:SI op0 op1))
The reason for the ICE is that op1 in this case is CONST_POLY_INT
which u
Georg-Johann Lay writes:
> This patch implements a more robust parsing of the
> AVR_MCU lines in genmultlib.awk.
>
> The generated t-multilib-avr is the same.
>
> Ok for trunk?
Ok.
Please apply.
Denis.
On Wed, Feb 05, 2025 at 04:12:38PM +, Andrew Carlotti wrote:
> Various aarch64 tests attempt to reduce the batch size for parallel test
> execution to a single test per batch, but it looks like the necessary
> changes to gcc_parallel_test_run_p were accidentally omitted when the
> aarch64-*-acl
On 2/5/25 8:21 AM, Simon Martin wrote:
Hi Jason,
On 4 Feb 2025, at 21:06, Jason Merrill wrote:
On 2/4/25 11:25 AM, Simon Martin wrote:
Hi Jason,
On 4 Feb 2025, at 1:11, Jason Merrill wrote:
On 1/31/25 11:12 AM, Simon Martin wrote:
Hi Jason,
On 31 Jan 2025, at 16:29, Jason Merrill wrote:
Alfie Richards writes:
> On 04/02/2025 10:03, Richard Sandiford wrote:
>> Alfie Richards writes:
>>> + return id;
>>> + else if (cgraph_node::get_create
>>> (decl)->dispatcher_resolver_function)
>>> + id = clone_identifier (id, "resolver");
>>> + else if (DECL_FUNCTION_VERSIONED (d
Hi!
As the following testcase show (note, just for-{3,4,6,7,8}.C, constexpr-86769.C
and stmtexpr27.C FAIL without the patch, the rest is just that I couldn't
find coverage for some details and so added tests we don't regress or for5.C
is from Marek's attempt in the PR), we weren't correctly handli
Andrew Carlotti writes:
> Various aarch64 tests attempt to reduce the batch size for parallel test
> execution to a single test per batch, but it looks like the necessary
> changes to gcc_parallel_test_run_p were accidentally omitted when the
> aarch64-*-acle-asm.exp files were merged. This patch
Andrew Pinski writes:
> Instead of waiting to get combine/rtl optimizations fixed here. This fixes the
> builtins at the gimple level. It should provide for slightly faster compile
> time
> since we have a simplification earlier on.
Yeah, and it's more global than combine would be.
> Built and
Various aarch64 tests attempt to reduce the batch size for parallel test
execution to a single test per batch, but it looks like the necessary
changes to gcc_parallel_test_run_p were accidentally omitted when the
aarch64-*-acle-asm.exp files were merged. This patch corrects that
omission.
This do
Instead of waiting to get combine/rtl optimizations fixed here. This fixes the
builtins at the gimple level. It should provide for slightly faster compile time
since we have a simplification earlier on.
Built and tested for aarch64-linux-gnu.
gcc/ChangeLog:
PR target/114522
* con
On Wed, Feb 5, 2025 at 12:58 AM Richard Sandiford
wrote:
>
> gcc.target/aarch64/sve/acle/general/ldff1_8.c and
> gcc.target/aarch64/sve/ptest_1.c were failing because the
> aarch64 port was giving a zero (unknown) cost to instructions
> that compute two results in parallel. This was latent until
> On Feb 5, 2025, at 07:49, Jakub Jelinek wrote:
>
> On Wed, Feb 05, 2025 at 01:46:02PM +0100, Richard Biener wrote:
>>> Please let me know any comments on this?
>>
>> I think I've seen this elsewhere -- the issue is the unwind register API does
>> not allow for failures but I also think calli
> On Feb 5, 2025, at 07:46, Richard Biener wrote:
>
> On Tue, Feb 4, 2025 at 10:12 PM Qing Zhao wrote:
>>
>> Hi,
>>
>> One of our big application segv in libgcc code while unwinding the stack.
>>
>> This is a random crash while the application throws a c++ exception and
>> unwinds the stack
Kyrylo Tkachov writes:
> Hi Richard,
>
>> On 5 Feb 2025, at 09:57, Richard Sandiford wrote:
>>
>> gcc.target/aarch64/sve/acle/general/ldff1_8.c and
>> gcc.target/aarch64/sve/ptest_1.c were failing because the
>> aarch64 port was giving a zero (unknown) cost to instructions
>> that compute two re
Pushed to wwwdocs.
---
htdocs/gcc-15/changes.html | 7 +++
1 file changed, 7 insertions(+)
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 18484915..02f8752f 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -370,6 +370,13 @@ asm (".text;
On Wed, Feb 5, 2025 at 1:29 PM Richard Biener wrote:
>
> The PR shows fold-mem-offsets taking ages and a lot of memory computing
> DU/UD chains as that requires the RD problem. The issue is not so much
> the memory required for the pruned sets but the high CFG connectivity
> (and that the CFG is
On Wed, 5 Feb 2025, Christoph Müllner wrote:
> On Wed, Feb 5, 2025 at 1:29 PM Richard Biener wrote:
> >
> > The PR shows fold-mem-offsets taking ages and a lot of memory computing
> > DU/UD chains as that requires the RD problem. The issue is not so much
> > the memory required for the pruned se
For an example output, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113067#c2
Fixed in commit r15-7376-g6f95af4f22b641 which also fixes the testsuite
issue (off by one) of my previous commit for PR118745, ups!
Tobias
commit 6f95af4f22b641fbb3509f1436bce811d4e4acad
Author: Tobias Burnus
D
On 05/02/2025 12:51, Tobias Burnus wrote:
Hi Andrew,
Andrew Stubbs wrote:
On 05/02/2025 11:14, Tobias Burnus wrote:
Therefore, the following GPUs are now supported in addition: gfx902,
gfx904, gfx909, gfx1031, gfx1032, gfx1033, gfx1034, gfx1035, gfx1101,
gfx1102, gfx1150, gfx1151, gfx1152, an
On 28/10/24 17:15 +, mmalcom...@nvidia.com wrote:
From: Matthew Malcomson
I noticed that the libstdc++ patch is essentially separate and figured I
could send it upstream earlier to give reviewers more time to look at
it.
I am still working on adding the ability to use floating point types i
On 04/02/2025 10:03, Richard Sandiford wrote:
Alfie Richards writes:
+ return id;
+ else if (cgraph_node::get_create (decl)->dispatcher_resolver_function)
+ id = clone_identifier (id, "resolver");
+ else if (DECL_FUNCTION_VERSIONED (decl))
{
- name += ".def
On Wed, 5 Feb 2025, Tobias Burnus wrote:
> Hi Andrew,
>
> Andrew Stubbs wrote:
> > On 05/02/2025 11:14, Tobias Burnus wrote:
> >> Therefore, the following GPUs are now supported in addition: gfx902,
> >> gfx904, gfx909, gfx1031, gfx1032, gfx1033, gfx1034, gfx1035, gfx1101,
> >> gfx1102, gfx1150,
Hi Jason,
On 4 Feb 2025, at 21:06, Jason Merrill wrote:
> On 2/4/25 11:25 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 4 Feb 2025, at 1:11, Jason Merrill wrote:
>>
>>> On 1/31/25 11:12 AM, Simon Martin wrote:
Hi Jason,
On 31 Jan 2025, at 16:29, Jason Merrill wrote:
> On 1
On Wed, 5 Feb 2025, Tamar Christina wrote:
[...]
> > 6eda40267bd1382938a77826d11f20dcc959a166..d0148d4938cafc3c59edfa6a
> > > > 60002933f384f65b 100644
> > > > > --- a/gcc/tree-vect-data-refs.cc
> > > > > +++ b/gcc/tree-vect-data-refs.cc
> > > > > @@ -731,7 +731,8 @@ vect_analyze_early_break_depe
Hi!
Sorry, our CI bot just notified me I broke SPARC build. There are two
#ifdef STACK_ADDRESS_OFFSET
guarded snippets and the macro is only defined on SPARC target, so I didn't
notice there was a syntax error.
Fixed thusly, tested on a cross to sparc64-linux (just that cc1/cc1plus
builds), com
On 04/02/2025 08:41, Richard Sandiford wrote:
Alfie Richards writes:
This adds the assembler_name member to cgraph_function_version_info
to store the base assembler name for the function to be mangled. This is
used in later patches for refactoring FMV mangling.
gcc/c/ChangeLog:
* c
Hi Andrew,
Andrew Stubbs wrote:
On 05/02/2025 11:14, Tobias Burnus wrote:
Therefore, the following GPUs are now supported in addition: gfx902,
gfx904, gfx909, gfx1031, gfx1032, gfx1033, gfx1034, gfx1035, gfx1101,
gfx1102, gfx1150, gfx1151, gfx1152, and gfx1153. However, the
multilib config ha
On Wed, Feb 05, 2025 at 01:46:02PM +0100, Richard Biener wrote:
> > Please let me know any comments on this?
>
> I think I've seen this elsewhere -- the issue is the unwind register API does
> not allow for failures but I also think calling abort() is bad.
>
> Are you calling this from a JIT cont
On Tue, Feb 4, 2025 at 10:12 PM Qing Zhao wrote:
>
> Hi,
>
> One of our big application segv in libgcc code while unwinding the stack.
>
> This is a random crash while the application throws a c++ exception and
> unwinds the stack. Incidents are random and never can be reproduced by any
> test cas
The PR shows fold-mem-offsets taking ages and a lot of memory computing
DU/UD chains as that requires the RD problem. The issue is not so much
the memory required for the pruned sets but the high CFG connectivity
(and that the CFG is cyclic) which makes solving the dataflow problem
expensive.
The
On 05/02/2025 11:14, Tobias Burnus wrote:
The number of AMD GPUs is huge - and, unfortunately, every GPU device
is potentially slightly different, requiring different code generation
either in some dusty corner case or for standard code.
As for several GPUs identical code can run (either all or
On Wed, Feb 05, 2025 at 12:59:58PM +0100, Jakub Jelinek wrote:
> > > +if (warn_cxx_compat || len - unit > avail)
> > > + {
> > > + pedwarn_init (init_loc, 0,
> > > + ("initializer-string for array of %qT "
> > > +
Hi!
Kees, any progress on this?
On Mon, Jan 06, 2025 at 04:34:27PM -0500, Marek Polacek wrote:
> > - pedwarn_init (init_loc, 0,
> > - ("initializer-string for array of %qT "
> > - "is too long"), typ1);
> > - else if (warn_untermi
This pattern is intended to be used only by the epilogue generation
code and will always use fixed hard registers. As such, it does not
need any register constraints, which might be misleading if a
post-reload pass wanted to try renumbering various registers. So
remove the constraints.
Futhermor
When generating thumb2 code,
LDM SP!, {PC}
is a two-byte instruction, whereas
LDR PC, [SP], #4
is needs 4 bytes. When optimizing for size, or when there's no obvious
performance benefit prefer the former.
gcc/ChangeLog:
PR target/118089
* config/arm/arm.cc (thumb2
Overall this series addresses part of PR118089, but the first two
patches are general cleanups. Still to do is the optimization that
de-allocates small amounts of stack by popping additional registers.
Richard Earnshaw (3):
arm: cleanup code in ldm_stm_operation_p; relax limits on ldm/stm
arm
I needed to make some adjustments to this function to permit a push or
pop of a single register in thumb2 code, since ldm/stm can be a
two-byte instruction instead of 4. Trying to read the code as it was
made me scratch my head as the logic was not very clear. So this
patch cleans up the code som
The number of AMD GPUs is huge - and, unfortunately, every GPU device
is potentially slightly different, requiring different code generation
either in some dusty corner case or for standard code.
As for several GPUs identical code can run (either all or when disabling
some features), AMD introduc
On Linux/x86_64,
3a5882707df50ed29905b3c47cbaa0868ea248c9 is the first bad commit
commit 3a5882707df50ed29905b3c47cbaa0868ea248c9
Author: Tobias Burnus
Date: Wed Feb 5 08:44:41 2025 +0100
fortran/trans-openmp.cc: Use the correct member in gfc_omp_namelist
[PR118745]
caused
FAIL: gfortra
This patch implements a more robust parsing of the
AVR_MCU lines in genmultlib.awk.
The generated t-multilib-avr is the same.
Ok for trunk?
Johann
AVR: genmultilib.awk - Use more robust parsing of spaces.
gcc/
* config/avr/genmultilib.awk: Parse the AVR_MCU lines in
a more rob
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, February 5, 2025 10:16 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: RE: [PATCH]middle-end: delay checking for alignment to load
> [PR118464]
>
> On Wed, 5 Feb 2025, Tamar Christina wrote:
>
> >
> >
The vectorizer thinks it can align a vector access to 16 bytes when
using a vectorization factor of 8 and 1 byte elements. That of
course does not work for the 2nd vector iteration. Apparently we
lack a guard against such nonsense.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
On Wed, 5 Feb 2025, Tamar Christina wrote:
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, February 4, 2025 12:49 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd
> > Subject: RE: [PATCH]middle-end: delay checking for alignment to load
> > [PR1184
On Wed, 5 Feb 2025, Jakub Jelinek wrote:
> On Tue, Feb 04, 2025 at 01:11:10PM +0100, Richard Biener wrote:
> > OK, fair enough. I think there should be a comment indicating this
> > isn't a full conservative approach but handling a certain class of
> > accesses only, with the hope that this is al
On Wed, 2025-02-05 at 16:47 +0800, Li Wei wrote:
/* snip */
> +/* Try to use the [x]vbitsel.v insn to optimize the vector shuffle, which
> + can reduce one copy insn in the loop compared to [x]vshuff. */
> +static bool
> +loongarch_expand_vec_perm_bitsel (struct expand_vec_perm_d *d)
> +{
> +
Reading Lewis' patch and the original patch a bit more carefully I think
the patch I suggested should have used `additional_flags` instead of
`ldflags`.
Outside of that -- would any maintainer on Cc be OK with one of our
patches going in?
On 1/3/25 22:05, Lewis Hyatt wrote:
External email:
Hi Richard,
> On 5 Feb 2025, at 09:57, Richard Sandiford wrote:
>
> gcc.target/aarch64/sve/acle/general/ldff1_8.c and
> gcc.target/aarch64/sve/ptest_1.c were failing because the
> aarch64 port was giving a zero (unknown) cost to instructions
> that compute two results in parallel. This was late
r15-268-g9dbff9c05520 restored the original GCC 11 output for
pr100056.c, so this patch reverts the changes made to the test
in r12-7259-g25332d2325c7. (The code parts of r12-7259 still
seem useful, as a belt-and-braces thing.)
Tested on aarch64-linux-gnu & pushed.
Richard
gcc/testsuite/
In LoongArch, we have xvshuf.{b/h/w/d} instructions which can dealt the
situation that all low 128-bit elements of the target vector are shuffled
by concatenating the low 128-bit elements of the two input vectors, and
all high 128-bit elements of the target vector are similarly shuffled.
Therefore,
gcc.target/aarch64/sve/acle/general/ldff1_8.c and
gcc.target/aarch64/sve/ptest_1.c were failing because the
aarch64 port was giving a zero (unknown) cost to instructions
that compute two results in parallel. This was latent until
r15-1575-gea8061f46a30, which fixed rtl-ssa to treat zero costs
as u
In LoongArch, when the permutation idx comes from different vectors and
idx is not repeated, for V8SI/V8SF/V4DI/V4DF type vectors, we can use
two xvperm.w + one xvbitsel.v instructions or two xvpermi.d + one
xvbitsel.v instructions for shuffle optimization.
gcc/ChangeLog:
* config/loongar
Currently, the shuffle in which LoongArch selects two vectors at
corresponding positions is implemented through the [x]vshuf instruction,
but this will introduce additional index copies. In this case, the
[x]vbitsel.v instruction can be used for optimization.
gcc/ChangeLog:
* config/loong
Again -- apologies for the noise
On 1/22/25 16:16, Matthew Malcomson wrote:
*External email: Use caution opening links or attachments*
Apologies for the noise.
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, February 4, 2025 12:49 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: RE: [PATCH]middle-end: delay checking for alignment to load
> [PR118464]
>
> On Tue, 4 Feb 2025, Tamar Christina wrote:
>
> > Lo
On Tue, Feb 04, 2025 at 01:11:10PM +0100, Richard Biener wrote:
> OK, fair enough. I think there should be a comment indicating this
> isn't a full conservative approach but handling a certain class of
> accesses only, with the hope that this is all that's actually needed.
Ok, here is an updated
> Hi Robin,
> Sorry, I should have simplified the problem by presenting it in terms of
> Zve32x, because Zve32f implies Zve32x.
> As the specification states, the requirement is to support LMUL ≥ SEW/ELEN.
> Regarding the implementation,
But the spec requirement mentions SEW_min not SEW?
"In gene
> -Original Message-
> From: Jan Hubicka
> Sent: Tuesday, February 4, 2025 4:25 PM
> To: Alex Coplan
> Cc: gcc-patches@gcc.gnu.org; Richard Biener ; Tamar
> Christina
> Subject: Re: [PATCH 1/4] vect: Set counts of early break exit blocks correctly
> [PR117790]
>
> > This adds missing
On Wed, 5 Feb 2025, Xi Ruoyao wrote:
> With things like
>
> // signed char a_14, a_16;
> a.0_4 = (unsigned char) a_14;
> _5 = (int) a.0_4;
> b.1_6 = (unsigned char) b_16;
> _7 = (int) b.1_6;
> c_17 = _5 - _7;
> _8 = ABS_EXPR ;
> r_18 = _8 + r_23;
>
> An ABD pattern will be recogn
75 matches
Mail list logo
