Update my affiliation.
Cheers,
David
diff --git a/htdocs/steering.html b/htdocs/steering.html
index 6039a503..b03ade5a 100644
--- a/htdocs/steering.html
+++ b/htdocs/steering.html
@@ -29,7 +29,7 @@ committee.
place to reach them is the gcc mailing list.
-David Edelsohn (IBM)
+David Edelsohn (
On Mon, Mar 3, 2025 at 3:40 PM Vineet Gupta wrote:
>
> On 3/3/25 15:18, Andrew Waterman wrote:
> >> So in some convoluted way both the above scenarios have callee-saved
> >> semantics
> >> for FRM, except for the leaf function which unconditionally sets FRM where
> >> this
> >> save/restore is n
On 3/3/25 15:18, Andrew Waterman wrote:
>> So in some convoluted way both the above scenarios have callee-saved
>> semantics
>> for FRM, except for the leaf function which unconditionally sets FRM where
>> this
>> save/restore is not done.
> I don't follow the last part about leaf functions. Unl
On Mon, Mar 3, 2025 at 2:37 PM Vineet Gupta wrote:
>
> Hi Pan, Andrew
>
> I'm trying to understand the semantics of FRM as it intersects with calling
> convention.
> psABI is not explicit about it and refers to C standard [1]
>
> > On 2/14/25 03:39, Li, Pan2 wrote:
>
> [snip]
>
>
> > With option "
On Mon, Mar 03, 2025 at 05:21:38PM -0500, James K. Lowden wrote:
> However IMO, the incantation:
>
> make install DESTDIR=/foo
>
> is invalid. The compiler's library search path is fixed when the
> compiler is built, based on configure options. Installing into an
> arbitrary directory canno
Hi Pan, Andrew
I'm trying to understand the semantics of FRM as it intersects with calling
convention.
psABI is not explicit about it and refers to C standard [1]
> On 2/14/25 03:39, Li, Pan2 wrote:
[snip]
> With option "-march=rv64gcv_zvfh -O3"
>
> 10 │ vxrm:
> 11 │ csrwi vxrm,
Hi,
This patch implements STAGE1_GDCFLAGS and others to the configure
machinery, allowing the GDCFLAGS for each bootstrap stage of building
gdc to be overriden, as is the case with CXXFLAGS for other front-ends.
This is limited to just the generation of recipes for the
configure-stage-gcc and all
On Mon, 24 Feb 2025 14:51:27 +0100
Richard Biener wrote:
> > Our repository is
> >
> > https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/
> >
> > using branch
> >
> > cobol-stage
> >
> > I tested these patches using "git apply" to an unpublished branch
> > "cobol-patched".
>
> I h
Hello world,
this patch is a bit more complicated than originally envisioned.
The problem was that we were not handling external dummy arguments
with -fc-prototypes-external. In looking at this, I found that we
were not warning about external procedures with different argument
lists. This can a
On Sat, 1 Mar 2025 at 05:19, XU Kailiang wrote:
>
> Hello libstdc++ maintainers,
>
> I sent a patch in January, but as it was my first patch, my email client
> was not properly configured so the patch format was broken. So I am
> re-sending it now.
>
> https://gcc.gnu.org/pipermail/gcc-patches/202
On Mon, Mar 03, 2025 at 03:58:24PM +0100, Andre Vehreschild wrote:
>
> attached patches fix a 12-regression, when a caf token is requested from an
> abstract class-typed dummy. The token was not looked up in the correct spot.
> Due the class typed object getting an artificial variable for direct d
Hi Andre,
Am 03.03.25 um 10:08 schrieb Andre Vehreschild:
Hi Harald,
in +++ b/gcc/fortran/symbol.cc
@@ -4624,12 +4624,28 @@ verify_bind_c_derived_type (gfc_symbol *derived_sym)
there is
+ else if (!pedantic)
+ gfc_warning (0, "Derive ...
To me the "not pedantic" is counter-intuiti
Feedback from the kernel team suggests that it's best to only use HWCAPs
rather than also use low-level checks as done by has_lse128() and has_rcpc3().
So change these to just use HWCAPs which simplifies the code and speeds up
ifunc selection by avoiding expensive system register accesses.
Passes
Change AArch64 cpuinfo to follow the latest updates to the FMV spec [1]:
Remove FEAT_PREDRES and FEAT_LS64*. Preserve the ordering in enum CPUFeatures.
Passes regress, OK for commit?
[1] https://github.com/ARM-software/acle/pull/382
gcc:
* common/config/aarch64/cpuinfo.h: Remove FEAT_PR
Enable the early scheduler on AArch64 for O3/Ofast. This means GCC15 benefits
from much faster build times with -O2, but avoids the regressions in lbm which
is very sensitive to minor scheduling changes due to long FMA chains. We can
then revisit this for GCC16.
gcc:
PR target/118351
Outline atomics is not designed to be used with -mcmodel=large, so disable
it automatically if the large code model is used.
Passes regress, OK for commit?
gcc:
PR target/112465
* config/aarch64/aarch64.cc (aarch64_override_options_after_change_1):
Turn off outline atomic
Hi,
The current implementation of fussion predicates misses some common
fussion cases on zen and more recent cores. I added knobs for
individual conditionals we test.
1) I split checks for fusing ALU with conditional operands when the ALU
has memory operand. This seems to be supported by zen3+
Compared to v3, this version:
- moves the sve_alignment_switcher in handle_arm_sve_h to function scope (and
fixes an inaccurate changelog message);
- updates affected Makefile dependencies.
The patch was preapproved by Richard with the first change, and the second
change is obvious, so I've comm
The code in gcc.target/unsigned-extend-1.c really should not need an
unsigned extension operations when the optimizers are used. For Arm
and thumb2 that is indeed the case, but for thumb1 code it gets more
complicated as there are too many instructions for combine to look at.
For thumb1 we end up
On 28/02/2025 16:18, Richard Earnshaw wrote:
> On 28/02/2025 16:12, Richard Earnshaw wrote:
>> On 08/11/2024 18:47, Torbjörn SVENSSON wrote:
>>> Ok for trunk and releases/gcc-14?
>>>
>>> --
>>>
>>> A long time ago, this test forced -march=armv6.
>>>
>>> With -marm, the generated assembler is:
>>>
On Mon, Mar 3, 2025 at 5:44 PM Richard Biener
wrote:
>
>
>
> > Am 03.03.2025 um 17:08 schrieb Uros Bizjak :
> >
> > Reverse negative logic in !a ? b : c to become a ? c : b.
> >
> > No functional changes.
> >
> > gcc/ChangeLog:
> >
> >* combine.cc (distribute_notes):
> >Reverse negative l
> Am 03.03.2025 um 17:08 schrieb Uros Bizjak :
>
> Reverse negative logic in !a ? b : c to become a ? c : b.
>
> No functional changes.
>
> gcc/ChangeLog:
>
>* combine.cc (distribute_notes):
>Reverse negative logic in ternary operators.
>
> Bootstrapped and regression tested on x86
Hi!
On 2002-04-17T21:37:50-0400, Phil Edwards wrote:
> If the user decides to build the library with extra compiler options
> via --enable-cxx-flags, the testsuite should (by default) use those same
> options when running.
Hmm, are we sure that's what we actually want?
> Verified by passing str
Reverse negative logic in !a ? b : c to become a ? c : b.
No functional changes.
gcc/ChangeLog:
* combine.cc (distribute_notes):
Reverse negative logic in ternary operators.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed as an obvious patch.
Uros.
diff --git
On Wed, 12 Feb 2025, Sam James wrote:
> Suggested by Andrew Pinski. I think it makes sense to have it in here
> even if perhaps a bit verbose, because we really try to tell bug
> reporters to read the page properly.
Makes sense.
> This could also be a table.
I'm not sure how a table would look
Hi,
We make personalized packaging—tuck boxes, CBD boxes, mailer boxes, rigid
boxes, bakery boxes, retail boxes, shopping bags, label stickers and more.
Simply provide us with the dimensions (L x W x H), quantity, and preferred box
style, and we'll provide you with a competitive quote. Plus, fo
Hi all,
attached patches fix a 12-regression, when a caf token is requested from an
abstract class-typed dummy. The token was not looked up in the correct spot.
Due the class typed object getting an artificial variable for direct derived
type access, the get_caf_decl was looking at the wrong decl.
On Mon, 3 Mar 2025, Tamar Christina wrote:
> > >/* For now assume all conditional loads/stores support unaligned
> > > diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
> > > index
> > 6bbb16beff2c627fca11a7403ba5ee3a5faa21c1..b661dd400e5826fc1c4f70
> > 957b335d1741fa 100644
> >
We can just shift the mask and fill the other bits with 0 (for ior/xor)
or 1 (for and), and use an am*.w instruction to perform the atomic
operation, instead of using a LL-SC loop.
gcc/ChangeLog:
* config/loongarch/sync.md (UNSPEC_COMPARE_AND_SWAP_AND):
Remove.
(UNSPEC_COM
We'll use the sc.q instruction for some 16-byte atomic operations, but
it's only added in LoongArch 1.1 evolution so we need to gate it with
an option.
gcc/ChangeLog:
* config/loongarch/genopts/isa-evolution.in (scq): New evolution
feature.
* config/loongarch/loongarch-evo
On Sat, 1 Mar 2025 at 15:52, Giuseppe D'Angelo
wrote:
>
> Hello,
>
> The attached patch implements the tuple protocol for std::complex (added
> by P2819R2 for C++26).
>
> Tested on x86-64 Linux. Beware that you need the latest GCC trunk,
> otherwise you'll get an ICE (PR 119045).
>
> It's also on
> >/* For now assume all conditional loads/stores support unaligned
> > diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
> > index
> 6bbb16beff2c627fca11a7403ba5ee3a5faa21c1..b661dd400e5826fc1c4f70
> 957b335d1741fa 100644
> > --- a/gcc/tree-vect-stmts.cc
> > +++ b/gcc/tree-vect-
Jakub Jelinek writes:
> On Mon, Mar 03, 2025 at 01:46:20PM +, Richard Sandiford wrote:
>> Jakub Jelinek writes:
>> > On Mon, Mar 03, 2025 at 01:02:07PM +, Richard Sandiford wrote:
>> >> ...how about something like this? Completely untested, and I haven't
>> >> thought about it much. Jus
Hi,
On 14 Feb 2025, at 18:08, Simon Martin wrote:
> We have been miscompiling the following valid code since GCC8, and
> r8-3497-g281e6c1d8f1b4c
>
> === cut here ===
> struct span {
> span (const int (&__first)[1]) : _M_ptr (__first) {}
> int operator[] (long __i) { return _M_ptr[__i]; }
>
Hi,
On 18 Feb 2025, at 11:12, Simon Martin wrote:
> We've been rejecting this valid code since r8-4571:
>
> === cut here ===
> void foo (float);
> int main () {
> constexpr float x = 0;
> (void) [&] () {
> foo (x);
> (void) [] () {
> foo (x);
> };
> };
> }
> === cut here =
Hi,
On 18 Feb 2025, at 14:00, Simon Martin wrote:
> A checking assert triggers upon the following invalid code since
> GCC 11:
>
> === cut here ===
> class { a (struct b;
> } struct b
> === cut here ===
>
> The problem is that during error recovery, we call
> set_identifier_type_value_with_scope
On Mon, Mar 03, 2025 at 01:46:20PM +, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > On Mon, Mar 03, 2025 at 01:02:07PM +, Richard Sandiford wrote:
> >> ...how about something like this? Completely untested, and I haven't
> >> thought about it much. Just didn't want to hold up the
On Fri, 28 Feb 2025, Tamar Christina wrote:
> Hi All,
>
> This fixes two PRs on Early break vectorization by delaying the safety checks
> to
> vectorizable_load when the VF, VMAT and vectype are all known.
>
> This patch does add two new restrictions:
>
> 1. On LOAD_LANES targets, where the bu
Jakub Jelinek writes:
> On Mon, Mar 03, 2025 at 01:02:07PM +, Richard Sandiford wrote:
>> ...how about something like this? Completely untested, and I haven't
>> thought about it much. Just didn't want to hold up the discussion.
>
> Works for me.
>
> Just wonder if there is anything that wil
On Mon, Mar 03, 2025 at 01:02:07PM +, Richard Sandiford wrote:
> ...how about something like this? Completely untested, and I haven't
> thought about it much. Just didn't want to hold up the discussion.
Works for me.
Just wonder if there is anything that will actually verify that XEXP (op0,
When we vectorize a .COND_ADD reduction and apply the single-use-def
cycle optimization we can end up chosing the wrong else value for
subsequent .COND_ADD. The following rectifies this.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimization/119096
* tree
We are detecting a cycle as double reduction where the inner loop
cycle has extra out-of-loop uses. This clashes at least with
assumptions from the SLP discovery code which says the cycle
isn't reachable from another SLP instance. It also was not intended
to support this case, in fact with GCC 14
Hi,
PR 118318 reported an ICE during PGO build of Firefox when IPA-CP, in
the final stages of update_counts_for_self_gen_clones where it
attempts to guess how to distribute profile count among clones created
for recursive edges and the various edges that are created in the
process. If one such ed
Jakub Jelinek writes:
> On Mon, Mar 03, 2025 at 12:20:00PM +, Richard Sandiford wrote:
>> I think we should instead go back to punting on comparisons whose inputs
>> are CC modes, as we did (indirectly, via comparison_code_valid_for_mode)
>> before r15-6777. Sorry, I'd forgotten/hadn't though
On Mon, Mar 03, 2025 at 12:20:00PM +, Richard Sandiford wrote:
> I think we should instead go back to punting on comparisons whose inputs
> are CC modes, as we did (indirectly, via comparison_code_valid_for_mode)
> before r15-6777. Sorry, I'd forgotten/hadn't thought to exclude CC modes
> expl
Christophe Lyon writes:
> On Mon, 3 Mar 2025 at 12:29, Richard Sandiford
> wrote:
>>
>> Tamar Christina writes:
>> >> -Original Message-
>> >> From: Richard Sandiford
>> >> Sent: Monday, March 3, 2025 10:12 AM
>> >> To: Tamar Christina
>> >> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Ea
Jakub Jelinek writes:
> Hi!
>
> The following testcase is miscompiled on powerpc64le-linux starting with
> r15-6777.
> That change has the if (HONOR_NANS (GET_MODE (XEXP (op0, 0 all = 15;
> lines which work fine if the comparisons use MODE_FLOAT or MODE_INT operands
> (or say MODE_VECTOR* etc.
Hi!
I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675704.html
and
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675765.html
patches (both for PR117178, -Wunterminated-string-initialization
regressions and attempts to mitigate it).
Thanks.
Jakub
Tamar Christina writes:
> Hi All,
>
> The last extraction instructions work full both full and partial SVE vectors,
> however we currrently only define them for FULL vectors.
>
> Early break code for VLA now however requires partial vector support, which
> relies on extract_last support.
>
> I hav
Hi!
On Tue, Feb 11, 2025 at 07:04:31PM +0100, Jakub Jelinek wrote:
> The following testcase IMO in violation of the P2552R3 paper doesn't
> pedwarn on alignas applying to dependent types or alignas with dependent
> argument.
>
> tsubst was just ignoring TYPE_ATTRIBUTES.
>
> The following patch f
Andrew Carlotti writes:
> Compared to v2, this splits out the alignment switching into a new class and
> merges the rest of the switching functionality into aarch64_target_switcher,
> as agreed with Richard in the previous review discussion.
>
> Bootstrapped and regression tested on aarch64. Is th
On Mon, 3 Mar 2025 at 12:29, Richard Sandiford
wrote:
>
> Tamar Christina writes:
> >> -Original Message-
> >> From: Richard Sandiford
> >> Sent: Monday, March 3, 2025 10:12 AM
> >> To: Tamar Christina
> >> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> >> ; ktkac...@gcc.gnu.org
>
Tamar Christina writes:
>> -Original Message-
>> From: Richard Sandiford
>> Sent: Monday, March 3, 2025 10:12 AM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
>> ; ktkac...@gcc.gnu.org
>> Subject: Re: [PATCH]AArch64: force operand to fresh register to avoid
From: Yash Shinde
This patch addresses an issue in the C preprocessor where incorrect line number
information is generated when processing
files with a large number of lines. The problem arises from improper handling
of location intervals in the line map,
particularly when locations exceed LINE
On Mon, 3 Mar 2025, Filip Kastl wrote:
> Hi Richard,
>
> I almost forgot that the issue is also present on GCC 14. Can I backport to
> releases/gcc-14 branch?
Sure.
> Thanks,
> Filip Kastl
>
> On Fri 2025-02-28 17:46:42, Richard Biener wrote:
> >
> >
> > > Am 28.02.2025 um 17:02 schrieb Fil
odr_types_equivalent_p can end up using TYPE_PRECISION on vector
types which is a no-go. The following instead uses TYPE_VECTOR_SUBPARTS
for vector types so we also end up comparing the number of vector elements.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR ipa/119067
LGTM.
--
Regards
Robin
Hi Richard,
I almost forgot that the issue is also present on GCC 14. Can I backport to
releases/gcc-14 branch?
Thanks,
Filip Kastl
On Fri 2025-02-28 17:46:42, Richard Biener wrote:
>
>
> > Am 28.02.2025 um 17:02 schrieb Filip Kastl :
> >
> > Hi,
> >
> > bootstrapped and regtested on x86_6
Jonathan Wakely writes:
> This looks more accurate than the current wording, yes.
>
> Specifically, only objects/libraries "built with experimental standard
> support" need to be recompiled.
>
> LGTM, but I'll let Jason give approval.
>
ping (I've found myself citing this section a few times rec
Sam James writes:
> Suggested by Andrew Pinski. I think it makes sense to have it in here even
> if perhaps a bit verbose, because we really try to tell bug reporters to
> read the page properly.
>
> This could also be a table.
Ping on this if I may.
> -Original Message-
> From: Richard Sandiford
> Sent: Monday, March 3, 2025 10:12 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; ktkac...@gcc.gnu.org
> Subject: Re: [PATCH]AArch64: force operand to fresh register to avoid subreg
> issues [PR118892]
>
>
Tamar Christina writes:
> Hi All,
>
> When the input is already a subreg and we try to make a paradoxical
> subreg out of it for copysign this can fail if it violates the sugreg
subreg
> relationship.
>
> Use force_lowpart_subreg instead of lowpart_subreg to then force the
> results to a registe
The pass ext-dce is only activated at O2 and above. Using O2 instead of O1
in testsuites when using -fdump-ext_dce.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/core_list_init.c: Using -O2 instead of -O1.
* gcc.target/riscv/pr111384.c: Ditto.
---
gcc/testsuite/gcc.target/riscv/c
On Mon, Mar 3, 2025 at 12:43 AM Kyrylo Tkachov wrote:
>
>
>
> > On 28 Feb 2025, at 19:06, Andrew Pinski wrote:
> >
> > On Fri, Feb 28, 2025 at 5:25 AM Kyrylo Tkachov wrote:
> >>
> >> Hi all,
> >>
> >> In this PR late-combine was failing to merge:
> >> dup v31.4s, v31.s[3]
> >> fmla v30.4s, v31.4
> On 3 Mar 2025, at 09:49, Andrew Pinski wrote:
>
> On Mon, Mar 3, 2025 at 12:43 AM Kyrylo Tkachov wrote:
>>
>>
>>
>>> On 28 Feb 2025, at 19:06, Andrew Pinski wrote:
>>>
>>> On Fri, Feb 28, 2025 at 5:25 AM Kyrylo Tkachov wrote:
Hi all,
In this PR late-combine was fa
> On 28 Feb 2025, at 19:06, Andrew Pinski wrote:
>
> On Fri, Feb 28, 2025 at 5:25 AM Kyrylo Tkachov wrote:
>>
>> Hi all,
>>
>> In this PR late-combine was failing to merge:
>> dup v31.4s, v31.s[3]
>> fmla v30.4s, v31.4s, v29.4s
>> into the lane-wise fmla form.
>> This is because late-combine
Hi Harald,
in +++ b/gcc/fortran/symbol.cc
@@ -4624,12 +4624,28 @@ verify_bind_c_derived_type (gfc_symbol *derived_sym)
there is
+ else if (!pedantic)
+ gfc_warning (0, "Derive ...
To me the "not pedantic" is counter-intuitive. In pedantic mode I would have
expected this to be at leas
From: Pan Li
The bug-3.c would like to check the slli a[0-9]+, a[0-9]+, 33 for the
big poly int handling. But the underlying insn may change to slli 1
+ slli 32 with sorts of optimization. Thus, update the asm check to
function body check with above slli 1 + slli 32 series.
The below test suit
Hi all,
In this testcase late-combine was failing to merge:
dup v31.4s, v31.s[3]
fmla v30.4s, v31.4s, v29.4s
into the lane-wise fmla form.
This is because late-combine checks may_trap_p under the hood on the dup insn.
This ended up returning true for the insn:
(set (reg:V4SF 152 [ _32 ])
(
Hi Paul,
thanks for the review. Committed as gcc-15-7789-g43c11931acc.
The regression is tagged as 15-regression only and was caused by PR
fortran/90068. At least the change in trans-array.cc:2000-.. is one of
major causes for that regression.
Thanks again,
Andre
On Sat, 1 Mar 2025 08:0
70 matches
Mail list logo
