Ping patch 1/2.
I think we can skip patch 2/2 since this was meanwhile fixed in
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/692272.html
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/692268.html
On Thu, Jul 24, 2025 at 12:03:43PM +0200, Stefan Schulze Frielinghaus wrote:
> It loo
>
> The comment doesn't match the bool type.
>
Fixed.
>
> is_gimple_assign (stmt_info->stmt)
>
Changed.
> There's also SAD_EXPR? The vectorizer has lane_reducing_op_p ()
> for this that also lists WIDEN_SUM_EXPR.
Add SAD_EXPR since x86 supports usad{v16qi, v32qi, v64qi}.
Not add WIDEN_SUM_EXPR s
On 8/7/25 10:58 AM, Jakub Jelinek wrote:
Hi!
My C++26 P2686R4 PR117784 caused ICE on the following testcase.
While the earlier conditions guarantee decl2 is not error_mark_node,
decl can be (that is used when something erroneous has been seen earlier
and the whole structured bindings will be ign
On 8/7/25 2:18 PM, Jakub Jelinek wrote:
Hi!
I've realized I haven't added testsuite coverage for name independent
structured binding packs. And the
auto [i, ..._, j] = T {};
auto [k, ..._, l] = T {};
case shows a problem with that. The elements of the structured binding
pack have #i appe
On 8/7/25 11:04 AM, Jakub Jelinek wrote:
On Wed, Aug 06, 2025 at 11:53:55AM -0700, Jason Merrill wrote:
And one thing still unresolved is debug info, I've just added DECL_IGNORED_P
on the structured binding pack VAR_DECL because there were ICEs with -g
for now, hope it can be fixed incrementally
Tested on x86_64-darwin (i.e. that the string is now seen as a regular
c-string and placed in the appropriate section).
OK for trunk?
thanks
Iain
--- 8< ---
In this function, we are generating a string constant but do so with
a mismatch between the actual string length and the length specified
On 8/8/25 9:46 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Alternatively, if preferred I also experimented with a patch that
cached the property as a TYPE_LANG_FLAG for ENUMERAL_TYPEs, which
was possibly slightly neater at the cost of using up a fl
On 8/10/25 3:24 PM, Andrew Pinski wrote:
On Fri, Feb 23, 2024 at 12:33 AM Jeff Law wrote:
On 2/23/24 01:05, Richard Biener wrote:
The following deprecates ia64*-*-* for GCC 14. Since we plan to
force LRA for GCC 15 and the target only has slim chances of getting
updated this notifies pe
I've come up with the attached patch to fix an ICE and clean up error
checking for "declare variant", primarily related to the C front end
handling of unprototyped functions. I've tested on x86_64-linux-gnu;
I've started a build for AMD offload testing but that won't be finished
until tomorrow
On Sun, Aug 10, 2025 at 11:46:53PM +0200, Gerald Pfeifer wrote:
> On Mon, 4 Aug 2025, Sam James wrote:
> > .. as we did for <= 10.
> :
> > GCC 11 Release Series
> >
> > +(This release series is no longer supported.)
>
> Is there some place where we ought to document this? Richi?
https://gcc.gn
On Mon, 4 Aug 2025, Sam James wrote:
> .. as we did for <= 10.
:
> GCC 11 Release Series
>
> +(This release series is no longer supported.)
Is there some place where we ought to document this? Richi?
Gerald
On Fri, Feb 23, 2024 at 12:33 AM Jeff Law wrote:
>
>
>
> On 2/23/24 01:05, Richard Biener wrote:
> > The following deprecates ia64*-*-* for GCC 14. Since we plan to
> > force LRA for GCC 15 and the target only has slim chances of getting
> > updated this notifies people in advance. Given both Li
On 8/8/25 11:37 AM, Marek Polacek wrote:
On Tue, Aug 05, 2025 at 02:54:01PM -0700, Jason Merrill wrote:
On 8/4/25 4:53 PM, Marek Polacek wrote:
Now that even dummy lambdas have an operator(), I had to tweak
resolvable_dummy_lambda to give the right answer. This I did by
checking DECL_LAMBDA_FU
On Sun, 10 Aug 2025, Jeff Law wrote:
> The question we need to ask is whether or not MSA+R5+MICROMIPS makes sense at
> all. If not, then we can deprecate. If it's just that we can't test, then
> it's not so clear.
FWIW we have support for microMIPSr5 encodings of the MSA instructions in
binut
On 7/27/25 2:50 PM, Aleksandar Rakic wrote:
From: Aleksandar Rakic
There are no platforms nor simulators for MSA and microMIPS R5 so
turning off this support for now.
gcc/ChangeLog:
* config/mips/mips.cc (mips_option_override): Error out for
-mmicromips -mmsa for MIPSr5 and
On 7/27/25 2:49 PM, Aleksandar Rakic wrote:
I tried to use just "TARGET_MICROMIPS" instead of "is_micromips", but
the compiler optimized "TARGET_MICROMIPS" away for some reason and
encoded it as "false".
That sounds like it's worth debugging; in general a TARGET_XXX macro
shouldn't have a con
On 7/27/25 11:00 AM, Aleksandar Rakic wrote:
Public
Hi,
I was going to apply this patch as it seems reasonable and independent
of everything else. But unfortunately it appears that you have munged
tabs into spaces.
While we could potentially use "-l" to ignore that problem and allow the
p
On 8/8/25 1:27 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
At some point these flag start getting defined in terms of the previous
flag, which is inconvenient when we want to test if the flag is set
during a debugging session
On 7/27/25 3:35 AM, Artemiy Volkov wrote:
From: Artemiy Volkov
Consider the following (RISC-V) instruction pair:
mul s6,a1,a2
add s6,a4,s6
Without this patch, while handling the second instruction, (a) the
existing chain for s6 will first be closed (upon the terminate_write
action for the
On 7/27/25 3:35 AM, Artemiy Volkov wrote:
From: Artemiy Volkov
Some of the instruction pairs recognized as fusible by a preceding
invocation of the dep_fusion pass require that both components of a pair
have the same hard register output for the fusion to work in hardware.
(An example of thi
On 8/6/25 8:29 AM, pan2...@intel.com wrote:
From: Pan Li
The previous cost value for vec_duplicate almost bases on the operators
like add/minus. The rtx_cost function try to match them case by case
and find if it has vec_duplicate, then update the cost values.
It is Ok when we initially ad
On 8/7/25 8:55 PM, Andrew Pinski wrote:
We increased the switch conversion array decl alignment
for better mergeability but it turns out that we increase
the alignment on targets which don't support mergeable sections
(e.g. NVPTX). Also after the fix for PR 121394, it becomes
obvious that we c
On 8/7/25 8:55 PM, Andrew Pinski wrote:
Now there are mergeable sections which have an entity size, we can place
decls (constants) that are smaller in size in these sections.
An example is an `long double` which has a size of 12 bytes on i686 and is
placed in the 16 bytes shareable section.
F
Regenerate configure files after
commit 8a3ad190c14789cde0b03142760b14b5675e8b39
Author: Ijaz, Abdul B
Date: Sun Aug 10 08:33:30 2025 -0600
config: Handle dash in library name for AC_LIB_LINKAGEFLAGS_BODY
gcc/
* configure: Regenerated.
libcpp/
* configure: Regenerated.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Croatian team of translators. The file is available at:
https://translationproject.org/latest/gcc/hr.po
(This file, 'gcc-15.2.0.hr.po', has j
On 7/30/25 3:29 PM, Joseph Myers wrote:
On Tue, 15 Jul 2025, Ijaz, Abdul B wrote:
config/ChangeLog:
* lib-link.m4: Handle dash in the library name for
AC_LIB_LINKFLAGS_BODY.
OK.
THanks. I kept meaning to look at this older patch, but never found the
time.
I've pushed i
On 8/4/25 3:09 AM, Robin Dapp wrote:
Hi,
In PR121334 we are asked to expand a const_vector of size 4 with
poly_int elements. It has 2 elts per pattern so is neither a
const_vector_duplicate nor a const_vector_stepped.
We don't allow this kind of constant in legitimate_constant_p but expr
ap
On 8/8/25 3:31 AM, Richard Sandiford wrote:
In g:965564eafb721f813a3112f1bba8d8fae32b I'd added code
to try distributing non-widening subregs through logic ops,
in cases where that would eliminate a term of the logic op.
For "reasons", this indirectly caused combine to generate:
(set
Hi,
On 2025-08-08 17:04, Richard Earnshaw wrote:
On 04/07/2025 23:00, Christophe Lyon wrote:
Like we do in other effective-targets, add
"-mcpu=unset -march=armv8-a"
directly when setting et_arm_v8_neon_flags in arm_v8_neon_ok_nocache,
to avoid having to add these two flags in all users of arm_v
Hi,
Can this patch (r16-799-g57cc4f8bf31) also be cherry-picked to releases/gcc-15
and releases/gcc-14?
This patch by itself would not fix the issues that I've seen, but together with
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/688620.html, it would fix
the failing test cases for me.
I
Ok for trunk and releases/gcc-15?
For releases/gcc-15, I would also want to cherry-pick r16-562-g20c25919132 that
converts
the test to use function body instead of three scan-assembler.
Changes since v1:
- Removed the acceptance of LDR as it's only generated without
r15-7373-g5163cf2ae14. Since
Will commit the series if no comments for this(3/3) RISC-V test patch in next
24H.
Pan
-Original Message-
From: Li, Pan2
Sent: Friday, August 1, 2025 3:31 PM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com;
rdapp@gmail.com; Chen, K
On 2025-08-07 20:19, Mike Stump wrote:
On Jul 17, 2025, at 5:48 AM, Torbjörn SVENSSON
wrote:
Ok for trunk, gcc-15 and gcc-14?
Ok.
Pushed as r16-3107-g7494e197e44, r15-10214-g45212364fd8 and
r14-11945-g0f8bacc8b2e.
Kind regards,
Torbjörn
gcc/testsuite/ChangeLog:
* lib/mul
On Sat, Aug 9, 2025 at 11:04 AM Xi Ruoyao wrote:
>
> Ping.
>
> On Wed, 2025-07-30 at 04:36 -0700, harish.sadin...@windriver.com wrote:
> > From: Harish Sadineni
> >
> > When gcc build with --enable-deafult-pie the following tests
> > were getting failed:
> > FAIL: gcc.target/i386/pr90579.c scan-
On Sun, Aug 10, 2025 at 12:02 AM H.J. Lu wrote:
>
> Since i?86 and x86_64 GCC can generate codes for ia32, x32 and lp64, adjust
> asm-hard-reg-1.c scan for x86 with ia32, x32 and lp64.
>
> PR testsuite/121205
> * gcc.dg/asm-hard-reg-1.c: Adjust scan for x86 with ia32, x32 and
>
35 matches
Mail list logo
