On 31/07/2025 16:37, Richard Sandiford wrote:
Alfie Richards writes:
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 5e305643b3a..253ea6dd77f 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -12268,6 +12268,11 @@ function version at run-time for a given set of
function versions.
bo
On Fri, Aug 01, 2025 at 03:43:26PM +0800, zambar wrote:
> ping
>
Sorry, I don't normally see post from anything
coming from 163.com. Everything is automatically
forward to /dev/null due to the amount of spam that
orignated with that domain years ago.
Is there a bugzilla report about whatever y
Kyrylo Tkachov writes:
>> On 29 Jul 2025, at 18:41, Richard Sandiford
>> wrote:
>>
>> This patch continues the work of making ACLE intrinsics use VNx16BI
>> for svbool_t results. It deals with the svpnext* intrinsics.
>>
>
> I wonder if the new patterns need pred_clobber alternatives in this
On Fri, Aug 1, 2025 at 8:54 AM Richard Biener
wrote:
>
> On Thu, Jul 31, 2025 at 4:43 PM Florian Weimer wrote:
>
> OK.
I've pushed both now.
Richard.
> Thanks,
> Richard.
>
> > gcc/c/
> >
> > PR c/120055
> > * c-typeck.cc (convert_arguments): Check if fundecl is null
> >
On Thu, Jul 31, 2025 at 4:43 PM Florian Weimer wrote:
OK.
Thanks,
Richard.
> gcc/c/
>
> PR c/120055
> * c-typeck.cc (convert_arguments): Check if fundecl is null
> before checking for builtin function declaration.
>
> gcc/testsuite/
>
> * gcc.dg/Wdeprecated-non-p
On Thu, Jul 31, 2025 at 4:42 PM Florian Weimer wrote:
>
> Builtins defined with BT_FN_INT_VAR etc. show as functions without
> a prototype and trigger the warning.
OK.
Thanks,
Richard.
> gcc/c/
>
> PR c/119950
> * c-typeck.cc (convert_arguments): Check for built-in
> fun
> -Original Message-
> From: Richard Biener
> Sent: Friday, August 1, 2025 6:06 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH 2/2] Put SLP_TREE_SIMD_CLONE_INFO into type specifc data
>
>
>
> > Am 31.07.2025
> Am 31.07.2025 um 17:43 schrieb Tamar Christina :
>
>
>>
>> -Original Message-
>> From: Richard Biener
>> Sent: Thursday, July 31, 2025 3:09 PM
>> To: gcc-patches@gcc.gnu.org
>> Cc: Tamar Christina
>> Subject: [PATCH 2/2] Put SLP_TREE_SIMD_CLONE_INFO into type specifc data
>>
>>
> Am 31.07.2025 um 22:03 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcase results in compiler UB as detected by ubsan.
> find_bswap_or_nop first checks is_bswap_or_nop_p and if that fails
> on the tmp_n value, tries some rotation of that if possible.
> The discovery what rotate coun
On Thu, Jul 24, 2025 at 8:43 AM Artemiy Granat wrote:
>
> gcc/ChangeLog:
>
> * config/i386/i386-options.cc (ix86_handle_cconv_attribute):
> Handle simultaneous use of regparm and thiscall attributes in
> case when regparm is set before thiscall.
>
> gcc/testsuite/ChangeLog:
Hi Paul,
While an error is correctly generated, the wording of
the error message iand locus seems odd. I have a
code that has
module foo
implicit none
private
generic, public :: bar => bar
generic, private :: bar => bah
...
end module
% gfcx -c a_gen4.F90
a_gen4.
On Wed, 30 Jul 2025, John Ericson wrote:
> This macro deduplicates the
>
> $CC -v 2>&1 | sed -n 's/^Thread model: //p'
>
> check that was occurring in various runtime libs.
>
> Additionally, as a bit of an Easter egg, this also allows overriding
> what the compiler would return by setting t
On Wed, 30 Jul 2025, John Ericson wrote:
> My goal is to be able to build libgcc cleanly in isolation --- today one
> needs to figure `make ...` misc things in the gcc subdir.
>
> Following Andrew Pinski's suggestions in
> https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, this
> co
On Tue, 29 Jul 2025, Martin Uecker wrote:
> Fixes an ICE on invalid code (15/16 regression).
>
> Bootstrapped and regression tested on x86_64.
>
>
> c: Fix ICE on invalid code involving bit fields [PR121217]
>
> Under some error condition we can end up with NULL_TREEs for
> the
On Thu, Jul 31, 2025 at 01:34:14PM -0700, Steve Kargl wrote:
>
> It seems that
>
> module foo
> implicit none
> private
> public bar
> generic :: bar => bar, bah
> end module
>
> is not accepted.
>
As a follow-up, this is accepted with your patch.
module foo
implicit none
pr
On Wed, Jul 23, 2025 at 05:53:17PM +0100, Paul Richard Thomas wrote:
>
>
> Regtests on x86_64/FC42 - OK for mainline?
>
Here's another testcase that fails.
% gfcx -o z a_gen2.F90 && ./z
42.000
43.500
% gfcx -o z -DGEN a_gen2.F90
a_gen2.F90:9:21:
9 |generic :: ba
On Thu, Jul 24, 2025 at 06:38:26PM +0300, Artemiy Granat wrote:
> gcc/ChangeLog:
>
> * config/i386/i386-options.cc (ix86_handle_cconv_attribute):
> Handle simultaneous use of regparm and thiscall attributes in
> case when regparm is set before thiscall.
>
> gcc/testsuite/ChangeL
On Wed, Jul 23, 2025 at 05:53:17PM +0100, Paul Richard Thomas wrote:
>
> The attached implements the F2018 generic statement, which has the same
> semantics as the typebound version but can appear in any specification
> statement.
>
> As it says in the first comment in the patch, use is made of t
On Thu, 24 Jul 2025, Aaron Ballman wrote:
> Question on the .N syntax: I thought I heard that this was something
> GCC could handle, but that it still requires late parsing to ensure
> type information for N is available and that was a problem. e.g.,
>
> void func(char *buffer __counted_by(.N * s
Am 31.07.25 um 12:30 schrieb Denis Chertykov:
ср, 30 июл. 2025 г. в 14:59, Georg-Johann Lay :
Insn combine may come up with superfluous reg-reg moves, where the
combine people say that these are no problem since reg-alloc is supposed
to optimize them. The issue is that the lower-subreg pass si
On Thu, Jul 31, 2025 at 11:04:56AM -0400, Jason Merrill wrote:
> If the current backup handling is doing the wrong thing in this case, it
> seems better to fix it rather than add more earlier in the function. Would
> it be enough to move the existing CPP_PRAGMA_EOL handling into the
> not_module bl
On Wed, 23 Jul 2025, Aleksandar Rakic wrote:
> Public
>
> Hi,
>
> > So I'm not at all concerned about the mips specific bits of this patch.
> > After all, they only affect mips ports and the changes seem sensible.
> > They would need a ChangeLog entry to go forward through.
>
> > What is concer
> On 29 Jul 2025, at 18:41, Richard Sandiford wrote:
>
> After previous patches, we should always get a VNx16BI result
> for ACLE intrinsics that return svbool_t. This patch adds
> an assert that checks a more general condition than that.
>
Ok.
Thanks,
Kyrill
> gcc/
> * config/aarch64/aarc
> On 29 Jul 2025, at 18:41, Richard Sandiford wrote:
>
> This patch continues the work of making ACLE intrinsics use VNx16BI
> for svbool_t results. It deals with the predicate forms of svdupq.
>
> The general predicate expansion builds an equivalent integer vector
> and then compares it wit
> On 29 Jul 2025, at 18:41, Richard Sandiford wrote:
>
> This patch continues the work of making ACLE intrinsics use VNx16BI
> for svbool_t results. It deals with the predicate forms of svdup.
>
Ok.
Thanks,
Kyrill
> gcc/
> * config/aarch64/aarch64-protos.h
> (aarch64_emit_sve_pred_vec_dupl
> On 29 Jul 2025, at 18:41, Richard Sandiford wrote:
>
> This patch continues the work of making ACLE intrinsics use VNx16BI
> for svbool_t results. It deals with the svpnext* intrinsics.
>
I wonder if the new patterns need pred_clobber alternatives in this and the
other patches?
If they d
> On 29 Jul 2025, at 18:41, Richard Sandiford wrote:
>
> This patch continues the work of making ACLE intrinsics use VNx16BI
> for svbool_t results. It deals with the svmatch* and svnmatch*
> intrinsics.
>
Ok.
Thanks,
Kyrill
> gcc/
> * config/aarch64/aarch64-sve2.md (@aarch64_pred_):
> Spl
> On 29 Jul 2025, at 18:41, Richard Sandiford wrote:
>
> This patch continues the work of making ACLE intrinsics use VNx16BI
> for svbool_t results. It deals with the svac* intrinsics (floating-
> point compare absolute).
Ok.
Thanks,
Kyrill
>
> gcc/
> * config/aarch64/aarch64-sve.md (@aarc
> On 29 Jul 2025, at 18:41, Richard Sandiford wrote:
>
> This patch continues the work of making ACLE intrinsics use VNx16BI
> for svbool_t results. It deals with the svcmp*_wide intrinsics.
>
> Since the only uses of these patterns are for ACLE intrinsics,
> there didn't seem much point add
> On 29 Jul 2025, at 18:41, Richard Sandiford wrote:
>
> Patterns that fuse a predicate operation P with a PTEST use
> aarch64_sve_same_pred_for_ptest_p to test whether the governing
> predicates of P and the PTEST are compatible. Most patterns were also
> written as define_insn_and_rewrites,
> On 29 Jul 2025, at 18:41, Richard Sandiford wrote:
>
> The patterns for the svcmp_wide intrinsics used a VNx16BI
> input predicate for all modes, instead of the usual .
> That unnecessarily made some input bits significant, but more
> importantly, it triggered an ICE in aarch64_sve_same_pred
> On 29 Jul 2025, at 18:41, Richard Sandiford wrote:
>
> This patch continues the work of making ACLE intrinsics use VNx16BI
> for svbool_t results. It deals with the non-widening integer forms
> of svcmp*. The handling of the PTEST patterns is similar to that
> for the earlier svwhile* patc
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 31, 2025 3:09 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina
> Subject: [PATCH 2/2] Put SLP_TREE_SIMD_CLONE_INFO into type specifc data
>
> The following adds vect_simd_clone_data as a container for vect
> type sp
Alfie Richards writes:
> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> index 5e305643b3a..253ea6dd77f 100644
> --- a/gcc/doc/tm.texi
> +++ b/gcc/doc/tm.texi
> @@ -12268,6 +12268,11 @@ function version at run-time for a given set of
> function versions.
> body must be generated.
> @end deftyp
On Thu, Jul 31, 2025 at 8:11 AM Alexander Monakov wrote:
>
>
> On Thu, 31 Jul 2025, H.J. Lu wrote:
>
> > > We have a few pre-existing tests that verify that the attribute is
> > > honored,
> > > such as those added by commit 1d561e1851c4. Do they actually not fail with
> > > this patch?
> >
> > T
On Thu, Jul 31, 2025 at 04:31:14PM +0200, Jens Remus wrote:
> Hello Stefan!
>
> On 7/10/2025 4:16 PM, Stefan Schulze Frielinghaus wrote:
> > 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-pr
> -Original Message-
> From: Kyrylo Tkachov
> Sent: Thursday, July 31, 2025 3:47 PM
> To: Jennifer Schmitz
> Cc: GCC Patches ; Andrew Pinski
> ; Richard Earnshaw ; Richard
> Sandiford ; Tamar Christina
> ; Alex Coplan
> Subject: Re: [PATCH 3/3] AArch64: Ena
On Thu, 31 Jul 2025, H.J. Lu wrote:
> > We have a few pre-existing tests that verify that the attribute is honored,
> > such as those added by commit 1d561e1851c4. Do they actually not fail with
> > this patch?
>
> There are no regressions.
Sorry, I don't see how that would be possible, that's
On 6/27/25 5:54 PM, Jakub Jelinek wrote:
Hi!
My changes for "Module Declarations Shouldn’t be Macros" paper broke
the following testcase. The backup handling intentionally tries to
drop CPP_PRAGMA_EOL token if things go wrong, which is desirable for the
case where we haven't committed to the mo
On Thu, Jul 31, 2025 at 6:58 AM Alexander Monakov wrote:
>
>
> On Wed, 30 Jul 2025, H.J. Lu wrote:
>
> > According to the TLS spec, linker can optimize the TLS access by
> > overriding the TLS access model. Do the same in compiler by using
> > the default TLS mode if it is more optimized than the
On Thu, 31 Jul 2025, Jason Merrill wrote:
> On 7/30/25 5:48 PM, Patrick Palka wrote:
> > On Wed, 30 Jul 2025, Patrick Palka wrote:
> >
> > > On Wed, 30 Jul 2025, Patrick Palka wrote:
> > >
> > > > On Wed, 30 Jul 2025, Patrick Palka wrote:
> > > >
> > > > > Bootstrapped and regtested on x86_64-p
On Wed, Jul 30, 2025 at 02:13:48PM -0700, Andrew Pinski wrote:
> On Wed, Jul 30, 2025 at 4:18 AM Yury Khrustalev
> wrote:
> >
> > This optional header is used to bring in the definition of the
> > struct __ifunc_arg_t type. Since it has been added to glibc only
> > recently, the previous implemen
> On 29 Jul 2025, at 17:14, Jennifer Schmitz wrote:
>
> This patch adds dispatch constraints for Neoverse V2 and illustrates the steps
> necessary to enable dispatch scheduling for an AArch64 core.
>
> The dispatch constraints are based on section 4.1 of the Neoverse V2 SWOG.
> Please note tha
On 7/30/25 5:48 PM, Patrick Palka wrote:
On Wed, 30 Jul 2025, Patrick Palka wrote:
On Wed, 30 Jul 2025, Patrick Palka wrote:
On Wed, 30 Jul 2025, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Here the result of A::make(0, 0,
On 7/30/25 7:37 PM, Patrick Palka wrote:
On Thu, 31 Jul 2025, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
And maybe 15?
Good catch re the invisiref handling! This LGTM, Jason what do you
think?
OK for trunk and 15.
-- >8 --
When we merg
On 7/31/25 10:34 AM, Jason Merrill wrote:
On 7/29/25 8:10 AM, Nathaniel Shead wrote:
Thoughts? Another suggestion raised on the PR was to just make this a
warning or some other non-fatal diagnostic (I suppose not attached to
any particular warning option?) and continue translation; I'm not
part
On 7/29/25 8:10 AM, Nathaniel Shead wrote:
Thoughts? Another suggestion raised on the PR was to just make this a
warning or some other non-fatal diagnostic (I suppose not attached to
any particular warning option?) and continue translation; I'm not
particularly fussed either way.
An unconditio
Hello Stefan!
On 7/10/2025 4:16 PM, Stefan Schulze Frielinghaus wrote:
> 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.
To be on par
> On 31 Jul 2025, at 14:34, Tejas Belagod wrote:
>
> The test was unsafe when tested on different vector lengths. This patch
> fixes it to work on all lengths.
>
Ok. I’ve seen this test fail on GCC 15 branch too, do we want this fix there as
well?
Thanks,
Kyrill
> gcc/testsuite/ChangeLog
>
On Wed, 30 Jul 2025, H.J. Lu wrote:
> According to the TLS spec, linker can optimize the TLS access by
> overriding the TLS access model. Do the same in compiler by using
> the default TLS mode if it is more optimized than the TLS model
> attribute.
>
> gcc/
>
> PR c/121318
> * do
On Tue, Jul 29, 2025 at 11:26:40PM +0200, Georg-Johann Lay wrote:
> Am 29.07.25 um 15:56 schrieb Stefan Schulze Frielinghaus:
> > From: Stefan Schulze Frielinghaus
> >
> > Targets hppa, m68k, pdp11, rx, sh, vax do not default to LRA. Since old
> > reload pass is still used, add option -mlra for
On 7/31/25 7:12 AM, Marek Polacek wrote:
On Thu, Jul 31, 2025 at 11:43:17AM +0200, Richard Biener wrote:
On Sat, Jun 28, 2025 at 12:31 AM Jason Merrill wrote:
On 6/26/25 4:12 PM, Marek Polacek wrote:
On Wed, Jun 25, 2025 at 03:13:25PM -0400, Jason Merrill wrote:
On 6/25/25 1:28 PM, Marek Po
Passed the CI, will commit it soon.
Pan
-Original Message-
From: Li, Pan2
Sent: Wednesday, July 30, 2025 2:26 PM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com;
rdapp@gmail.com; Chen, Ken ; Liu, Hongtao
; Li, Pan2
Subject: [PATCH
On 7/30/25 7:03 PM, Marek Polacek wrote:
On Wed, Jul 30, 2025 at 03:30:06PM -0400, Jason Merrill wrote:
On 7/25/25 3:59 PM, Marek Polacek wrote:
On Tue, Jul 22, 2025 at 04:52:53PM -0400, Jason Merrill wrote:
On 7/21/25 6:28 PM, Marek Polacek wrote:
On Mon, Jul 21, 2025 at 11:26:08AM -0400, Ja
with a vla epilogue we skip it again.
>
> Cheers,
> Tamar
>
> From: Richard Biener
> Sent: Thursday, July 31, 2025 1:30 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org ; nd
> Subject: Re: [PATCH][vect] Don't set bogus bounds on epi
ourse with a vla epilogue we skip it again.
Cheers,
Tamar
From: Richard Biener
Sent: Thursday, July 31, 2025 1:30 PM
To: Tamar Christina
Cc: gcc-patches@gcc.gnu.org ; nd
Subject: Re: [PATCH][vect] Don't set bogus bounds on epilogues [PR120805]
On Thu, Jul 3
> + for (i = 0; i < old_name_len; i++)
> +if (!is_valid_asm_symbol (old_asm_name[i]))
> + new_asm_name[i] = '_';
> +else
> + new_asm_name[i] = old_asm_name[i];
> + new_asm_name[old_name_len] = '\0';
> +}
> +
> +/* This function chang
On 09.07.2025 14:48, Matthieu Longo wrote:
> Those methods's implementation is relying on duck-typing at compile
> time.
> The structure corresponding to the node of a doubly linked list needs
> to define attributes 'prev' and 'next' which are pointers on the type
> of a node.
> The structure wrapp
On Thu, Jul 31, 2025 at 2:10 PM Tamar Christina wrote:
>
> Hi All,
>
> The testcases in the PR are failing due to the code trying to set a vector
> range
> on an epilogue.
>
> However on epilogues the range doesn't make sense. In particular we are
> setting
> ranged to help niters analysis. But
On Thu, 31 Jul 2025, Richard Biener wrote:
> On Thu, 31 Jul 2025, Tamar Christina wrote:
>
> > > -Original Message-
> > > From: Richard Biener
> > > Sent: Wednesday, July 30, 2025 12:17 PM
> > > To: gcc-patches@gcc.gnu.org
> > > Cc: Tamar Christina
> > > Subject: [PATCH 2/2] Put SLP_TRE
On Thu, 31 Jul 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, July 30, 2025 12:17 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Tamar Christina
> > Subject: [PATCH 2/2] Put SLP_TREE_SIMD_CLONE_INFO into type specifc data
> >
> > The follow
On Thu, 31 Jul 2025, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, July 31, 2025 12:27 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Tamar Christina
> > Subject: [PATCH] Add checks for node in aarch64 vector cost modeling
> >
> > After removing
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 31, 2025 12:27 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina
> Subject: [PATCH] Add checks for node in aarch64 vector cost modeling
>
> After removing STMT_VINFO_MEMORY_ACCESS_TYPE we now ICE when costing
> for s
On Thu, Jul 31, 2025 at 01:23:00PM +0200, Richard Biener wrote:
> On Thu, 31 Jul 2025, Richard Biener wrote:
>
> > On Thu, 31 Jul 2025, Spencer Abson wrote:
> >
> > > On Thu, Jul 31, 2025 at 12:14:20PM +0200, Richard Biener wrote:
> > > > On Tue, 29 Jul 2025, Richard Biener wrote:
> > > >
> > >
On Thu, 31 Jul 2025, Richard Biener wrote:
> On Thu, 31 Jul 2025, Spencer Abson wrote:
>
> > On Thu, Jul 31, 2025 at 12:14:20PM +0200, Richard Biener wrote:
> > > On Tue, 29 Jul 2025, Richard Biener wrote:
> > >
> > > > This should be present only on SLP nodes now. The RISC-V changes
> > > > ar
;>>if (!mark_used (fn, complain) && !(complain & tf_error))
> > >>> return error_mark_node;
> > >
> > > OK, done here:
> > >
> > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
&
hmm...then I incline those intrinsic just put static inline
function with inline asm rather than adding pattern and "real"
intrinsic
On Wed, Jul 30, 2025 at 2:34 PM KuanLin Chen wrote:
>
> Hi Kito,
>
> Kito Cheng 於 2025年7月30日 週三 上午9:01寫道：
> >
> > > +(define_insn "@nds_vfwcvt_bf16"
> > > + [
On Thu, 31 Jul 2025, Spencer Abson wrote:
> On Thu, Jul 31, 2025 at 12:14:20PM +0200, Richard Biener wrote:
> > On Tue, 29 Jul 2025, Richard Biener wrote:
> >
> > > This should be present only on SLP nodes now. The RISC-V changes
> > > are mechanical along the line of the SLP_TREE_TYPE changes.
On Thu, Jul 31, 2025 at 12:14:20PM +0200, Richard Biener wrote:
> On Tue, 29 Jul 2025, Richard Biener wrote:
>
> > This should be present only on SLP nodes now. The RISC-V changes
> > are mechanical along the line of the SLP_TREE_TYPE changes. The
> > aarch64 changes are for removing vect_mem_ac
ср, 30 июл. 2025 г. в 14:59, Georg-Johann Lay :
>
> Insn combine may come up with superfluous reg-reg moves, where the
> combine people say that these are no problem since reg-alloc is supposed
> to optimize them. The issue is that the lower-subreg pass sitting
> between combine and reg-alloc may
On the gcc-15 branch we can have no SLP node. We have to be
careful with cherry-picks from trunk.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimization/121256
* tree-vect-loop.cc (vectorizable_recurr): Handle the case
of a NULL SLP node.
---
gcc
On Tue, 29 Jul 2025, Richard Biener wrote:
> This should be present only on SLP nodes now. The RISC-V changes
> are mechanical along the line of the SLP_TREE_TYPE changes. The
> aarch64 changes are for removing vect_mem_access_type and gating
> one problematical test with !m_costing_for_scalar (
On Thu, 31 Jul 2025, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because byte 0x2000
> is bit 0x1 and ifcombine incorrectly combines the two loads
> into a BIT_FIELD_REF even when they are very far away.
> The problem is that gimple-fold.cc ifcombine uses get
On Mon, May 19, 2025 at 6:38 PM Richard Earnshaw wrote:
>
> It's not enough to just check that a memory operand is of the form
> mem(reg); after RA we also need to validate the register being used.
> The safest way to do this is to call memory_operand.
I have bootstrapped/tested this on x86_64-li
OK, done here:
> >
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> OK.
I have bootstrapped and tested this on the 15 branch, OK there as well?
Thanks,
Richard.
> > -- >8 --
> > Here we end up with "error reporting routines re-entered" beca
Hi Mikael,
The patch applies cleanly, regtests and fixes the problem, as advertised.
It does likewise on 15-branch.
Good for mainline and, I would suggest, backporting.
Thanks for the patch.
Paul
On Wed, 30 Jul 2025 at 10:04, Mikael Morin wrote:
> From: Mikael Morin
>
> This one may look l
On 30/07/2025 18:13, Thomas Schwinge wrote:
Hi Andrew!
On 2025-07-25T14:44:06+, Andrew Stubbs wrote:
The optimization options are deliberately passed through to the LTO compiler,
but when the same mechanism is reused for offloading it ends up forcing the
host compiler settings onto the dev
Spencer Abson writes:
> GCC doesn't support SME without SVE2, so the -march=armv8-a+ argument to
> check_no_compiler_messages causes aarch64_asm__ok to return zero for SME
> and any that implies it. This patch changes the baseline architecure to
> armv9-a for these extensions.
>
> The tests for
> -Original Message-
> From: Tamar Christina
> Sent: Thursday, July 31, 2025 7:41 AM
> To: Richard Biener ; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH 2/2] Put SLP_TREE_SIMD_CLONE_INFO into type specifc data
>
> > -Original Message-
> >
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, July 30, 2025 12:17 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina
> Subject: [PATCH 2/2] Put SLP_TREE_SIMD_CLONE_INFO into type specifc data
>
> The following adds vect_simd_clone_data as a container for vect
> type
On 7/25/25 4:55 PM, Marek Polacek wrote:
On Thu, Jul 17, 2025 at 05:20:31PM -0400, Jason Merrill wrote:
On 7/16/25 5:59 PM, Marek Polacek wrote:
On Mon, Jul 14, 2025 at 12:52:41PM -0400, Jason Merrill wrote:
On 7/11/25 5:49 PM, Marek Polacek wrote:
On Thu, Jul 10, 2025 at 02:13:06PM -0400, Ja
On Wed, Jul 30, 2025 at 8:24 PM Andrew Pinski wrote:
>
> On Wed, Jul 30, 2025 at 5:33 PM H.J. Lu wrote:
> >
> > According to the TLS spec, linker can optimize the TLS access by
> > overriding the TLS access model. Do the same in compiler by using
> > the default TLS mode if it is more optimized
On Wed, Jul 30, 2025 at 5:33 PM H.J. Lu wrote:
>
> According to the TLS spec, linker can optimize the TLS access by
> overriding the TLS access model. Do the same in compiler by using
> the default TLS mode if it is more optimized than the TLS model
> attribute.
So reading the old bug reports sp
> -Original Message-
> From: H.J. Lu
> Sent: Wednesday, July 30, 2025 9:17 PM
> To: Hongtao Liu
> Cc: gcc-patches@gcc.gnu.org; ubiz...@gmail.com; Liu, Hongtao
>
> Subject: Re: [PATCH] x86: Transform to "pushq $-1; popq reg" for -Oz
>
> On Tue,
Jakub Jelinek writes:
> On Fri, Jul 25, 2025 at 07:51:41PM +0100, Sam James wrote:
>> Cherry picked from LLVM commit c99b1bcd505064f2e086e6b1034ce0b0c91ea5b9.
>>
>> The termio ioctls are no longer used after commit 59978b21ad9c
>> ("[sanitizer_common] Remove interceptors for deprecated struct te
Please find:
https://github.com/andestech/andes-v5-isa/releases/tag/ast-v5_4_0-release
These instructions are from "3.1.26. NDS.FFB" to "3.1.29. NDS.FLMISM"
in AndeStar_V5_ISA_Spec_UM165-v1.5.08-20250317.pdf.
Thanks.
Jeff Law 於 2025年7月30日 週三 下午11:22寫道：
>
>
>
> On 7/29/25 7:41 PM, KuanLin Chen wro
On Thu, 31 Jul 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> And maybe 15?
Good catch re the invisiref handling! This LGTM, Jason what do you
think?
>
> -- >8 --
>
> When we merge a function definition, if there alr
Hi Yuao,
That's exactly how I had a mind to do it. You beat me to it :-(
Just get on, polish the patch and add more tests.
Thanks
Paul
On Wed, 30 Jul 2025 at 15:53, Yuao Ma wrote:
> Hi all,
>
> This patch introduces support for conditional expressions (also known as
> ternary operators in s
On Thu, 17 Jul 2025, Simon Marchi wrote:
> On 6/26/25 12:14 PM, Simon Marchi wrote:
> > I keep hitting the bug fixed by this patch with gcc 15.1:
> >
> > make[3]: Entering directory
> > '/home/simark/build/binutils-gdb-all-targets/sim'
> > CC bfin/gui.o
> > In file included from /usr/inc
On Wed, 16 Jul 2025, John Ericson wrote:
> From: John Ericson
>
> Following Andrew Pinski's suggestions in
> https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, just
> use the output of:
>
>$(CC) -print-sysroot
>
> It is just used in one spot, in an AIX code-path. I just made
On Wed, 16 Jul 2025, John Ericson wrote:
> gcc/ChangeLog:
>
> * Makefile.in:: Remove NO_PIE_CFLAGS logic, since it is now in
> libgcc.
> * configure.ac: Remove the enable_default_pie substitution, since
> libgcc now has its own logic.
>
> libgcc/ChangeLog:
>
> * Ma
On Wed, 30 Jul 2025, Patrick Palka wrote:
> On Wed, 30 Jul 2025, Patrick Palka wrote:
>
> > On Wed, 30 Jul 2025, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > -- >8 --
> > >
> > > Here the result of A::make(0, 0
On Wed, 16 Jul 2025, John Ericson wrote:
> config/ChangeLog:
>
> * gthr.m4: Create new GCC_AC_THREAD_MODEL macro
>
> libatomic/ChangeLog:
>
> * configure.ac: Use GCC_AC_THREAD_MODEL instead of hand-rolled
>
> libgcc/ChangeLog:
>
> * configure.ac: Use GCC_AC_THREAD_MODEL inst
On Wed, 30 Jul 2025, Patrick Palka wrote:
> On Wed, 30 Jul 2025, Patrick Palka wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > Here the result of A::make(0, 0, 1), (0, 1, 0) and (1, 0, 0) are each
> > represented as a sin
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.
--
Joseph S. Myers
josmy...@redhat.com
On Wed, Jul 30, 2025 at 4:18 AM Yury Khrustalev wrote:
>
> This optional header is used to bring in the definition of the
> struct __ifunc_arg_t type. Since it has been added to glibc only
> recently, the previous implementation had to check whether this
> header is present and, if not, it provide
On Wed, Apr 30, 2025 at 6:05 AM Richard Sandiford
wrote:
>
> Wilco Dijkstra writes:
> > Cleanup HWCAP defines - rather than including hwcap.h and then repeating it
> > using
> > #ifndef, just define the HWCAPs we need exactly as in hwcap.h.
> >
> > libgcc:
> > * config/aarch64/cpuinfo.c:
On Wed, 30 Jul 2025, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
>
> -- >8 --
>
> Here the result of A::make(0, 0, 1), (0, 1, 0) and (1, 0, 0) are each
> represented as a single-element CONSTRUCTOR with CONSTRUCTOR_NO_CLEARING
> cleare
Hi!
On Wed, Jul 30, 2025 at 01:12:27PM +0530, Kishan Parmar wrote:
> PR target/118890
> * config/rs6000/rs6000.cc (can_be_rotated_to_negative_lis): Avoid left
> shift of
Line too long, changelog lines are only 80 character positions max.
> negative value and guard shift count.
On 7/25/25 3:59 PM, Marek Polacek wrote:
On Tue, Jul 22, 2025 at 04:52:53PM -0400, Jason Merrill wrote:
On 7/21/25 6:28 PM, Marek Polacek wrote:
On Mon, Jul 21, 2025 at 11:26:08AM -0400, Jason Merrill wrote:
On 7/18/25 5:11 PM, Marek Polacek wrote:
On Thu, Jul 17, 2025 at 06:44:08PM -0400, Ja
1 - 100 of 12486 matches
Mail list logo
