committed :)
On Mon, Apr 14, 2025 at 6:01 PM Kito Cheng wrote:
>
> This patch will be committed this week if CI passes and not strong
> objections since it's bug to large code model, also change is small
>
> On Mon, Apr 14, 2025 at 6:00 PM Kito Cheng wrote:
> >
> > Large code model assume the da
On Apr 14, 2025, Peter Bergner wrote:
> diff --git a/gcc/testsuite/g++.dg/pr112822.C b/gcc/testsuite/g++.dg/pr112822.C
> -typedef __attribute__((altivec(vector__))) double co;
> +typedef double co __attribute__ ((vector_size (16)));
FWIW, I've tested this change on gcc-14 powerpc-elf and I confi
Thanks, committed to trunk :)
On Fri, Apr 11, 2025 at 12:27 PM Jesse Huang wrote:
>
> Codegen is incorrectly emitting a ".p2align 3" that coerces the
> alignment of the .note.gnu.property section from 4 to 8 on rv32.
>
> 2025-04-11 Jesse Huang
>
> gcc/ChangeLog
>
> * config/riscv/riscv
Hi!
This testcase got fixed with r15-9397 PR119722 fix.
Tested on x86_64-linux -m32/-m64 with vanilla trunk as well
as with r15-9397 fix reverted (where it FAILs), committed
to trunk as obvious.
2025-04-16 Jakub Jelinek
PR tree-optimization/116093
* gcc.dg/bitint-122.c: New t
Hi!
The following testcase is miscompiled, because we emit a CLOBBER in a place
where it shouldn't be emitted.
Before lowering we have:
b_5 = 0;
b.0_6 = b_5;
b.1_1 = (unsigned _BitInt(129)) b.0_6;
...
= b_5;
The bitint coalescing assigns the same partition/underlying variable
for both b_5
On 4/15/25 1:56 PM, Richard Sandiford wrote:
Tejas Belagod writes:
The operand order to gen_vcond_mask call in the vec_extract pattern is wrong.
Fix the order where predicate is operand 3.
Tested and bootstrapped on aarch64-linux-gnu. OK for trunk?
gcc/ChangeLog
* config/aarch64/aarc
On Apr 14, 2025, Peter Bergner wrote:
> On 4/11/25 1:03 PM, Alexandre Oliva wrote:
>> gcc.dg/pr87600.h and gcc.dg/pr89313.c test for __powerpc__ and
>> __POWERPC__ to choose ppc register names, but ppc-elf defines neither;
>> it defines __PPC__, so test for that as well.
> Is there a reason why
On Apr 15, 2025, Peter Bergner wrote:
> On 4/14/25 11:35 PM, Alexandre Oliva wrote:
>>> That said, that should be done in a separate patch.
>>
>> *nod*. Do you mean you're going to make that change, that I should, or
>> that you hope someone else will? I'd rather avoid duplication, and this
>>
On Apr 15, 2025, Peter Bergner wrote:
> On 4/15/25 9:36 AM, Peter Bergner wrote:
>> So what ABI does powerpc-elf use and what does it mandate?
That's not for me to decide, but to me the patch that introduced
OS_MISSING_POWERPC64 and the PR106680 coversation suggests that enabling
-mpowerpc64 wit
On Apr 15, 2025, Peter Bergner wrote:
> On 4/14/25 11:30 PM, Alexandre Oliva wrote:
>> On Apr 14, 2025, Peter Bergner wrote:
>>
>>> This is an architecture independent test case, so I'm surprised this
>>> doesn't FAIL on non-powerpc targets since they don't know anything
>>> about altivec.
>>
The set of {dg-do-what-default} to 'run' may lead some test hang
during make check.
gcc/testsuite
*gcc.target/loongarch/vector/loongarch-vector.exp: Change
{dg-do-what-default} save and restore logical
---
.../gcc.target/loongarch/vector/loongarch-vector.exp|
On Tue, Apr 15, 2025 at 5:50 AM Michael Matz wrote:
>
> Hello,
>
> On Mon, 14 Apr 2025, Bill Wendling wrote:
>
> > Now, I don't think this will be necessarily confusing to the
> > programmer, but it's inconsistent. In other words, either 'counted_by'
> > *must* forward declare the in-structure ide
On Tue, 8 Apr 2025, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14?
It's not mentioned very often, but is a general rule:
Pretty please, add new files for new tests, don't just edit
existing files. (For one: if they start failing, they look like
regressio
On 4/15/25 19:11, Alex wrote:
Here is a follow up patch for documentation of the omp.h allocators,
I'm not super happy with it but I wanted to get eyes on it before I go
to sleep tonight.
> From c8cef447baf16743f7bf0d887d3fd09108d3a607 Mon Sep 17 00:00:00 2001
From: waffl3x
Date: Tue, 15 Apr 20
Here is a follow up patch for documentation of the omp.h allocators,
I'm not super happy with it but I wanted to get eyes on it before I go
to sleep tonight.
I want the table in there somewhere but I'm not confident that where I
put it was the right place.
Alex
From c8cef447baf16743f7bf0d887d3fd0
Hi,
This patch fixes the ICE in PR119826.
Forward referenced enum types were never fixed up after the main
ENUMERAL_TYPE was finished. All flags set are now propagated to all
variants after its mode, size, and alignment has been calculated.
Bootstrapped and regression tested on x86_64-linux-gnu
On 4/15/25 12:01 PM, Harald Anlauf wrote:
Dear all,
the testcase in the PR shows a case where the pureness of a function
is not properly determined, even though the function is resolved, and
its attributes clearly show that it is pure, because gfc_pure_function
relies on isym or esym being set.
After the conversion for phiopt's conditional operand
to use maybe_push_res_to_seq, it was found that gimple_extract
will extract out from REALPART_EXPR/IMAGPART_EXPR/VCE and BIT_FIELD_REF,
a memory load. But that extraction was not needed as memory loads are not
simplified in match and simplify. S
On 4/14/25 11:30 PM, Alexandre Oliva wrote:
> On Apr 14, 2025, Peter Bergner wrote:
>
>> This is an architecture independent test case, so I'm surprised this
>> doesn't FAIL on non-powerpc targets since they don't know anything
>> about altivec.
>
> AFAICT we ignore attributes we don't know abou
This includes the one which needed some changes to the function (gimple_extract)
being split out from gimple-match-head.cc in GCC 14.
Andrew Pinski (3):
discriminators: Fix assigning discriminators on edge [PR113546]
match: Reject non-ssa name/min invariants in gimple_extract [PR116412]
test
This testcase was fixed by r15-3052-gc7b76a076cb2c6ded but is
a testcase that failed in a different fashion and a much older
failure than the one added with r15-3052.
Pushed as obvious after a quick test.
PR tree-optimization/118476
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr11
The problem here is there was a compare debug since the discriminators
would still take into account debug statements. For the edge we would look
at the first statement after the labels and that might have been a debug
statement.
So we need to skip over debug statements otherwise we could get diff
On Tue, Apr 15, 2025 at 02:38:19PM +, Kyrylo Tkachov wrote:
> Thanks! As discussed on IRC we’ll work on addressing these. I’ve pushed the
> patch with 6d9fdf4bf57 after one more bootstrap on aarch64-none-linux-gnu.
This broke
+FAIL: gcc.dg/completion-2.c (test for excess errors)
+FAIL: gcc.dg
Update the OpenMP entry in the GCC 15 release notes and the status at the
OpenMP project
page.
* https://gcc.gnu.org/gcc-15/changes.html
* https://gcc.gnu.org/projects/gomp/
Tobias
commit 5937699869cfc15d57d8ba5913109701dcf7a64b
Author: Tobias Burnus
Date: Tue Apr 15 23:50:57 2025 +0200
On Tue, Apr 15, 2025 at 09:05:20PM +, Qing Zhao wrote:
> > On Apr 15, 2025, at 16:35, Kees Cook wrote:
> > 1) When applying counted_by to pointer members, are out-of-order member
> > declarations expected to be handled? As in, is this expected to be valid?
> >
> > struct foo {
> > struct bar
I noticed the other day that the USM bullet point only talked about
the 'unified_shared_memory' clause and not about the newer 'self_maps'
clause. That's now fixed by the attached patch.
-> https://gcc.gnu.org/onlinedocs/libgomp/Offload-Target-Specifics.html
Committed asr15-9506-g1ff4a22103767c
> On Apr 15, 2025, at 16:35, Kees Cook wrote:
>
> On Tue, Apr 15, 2025 at 09:07:44PM +0200, Martin Uecker wrote:
>> Am Dienstag, dem 15.04.2025 um 14:50 +0200 schrieb Michael Matz:
>>> Hello,
>> ...
>>
struct A {
int *buf __counted_by(len); // 'len' *must* be in the struct.
in
On Linux/x86_64,
6d9fdf4bf57353f9260a2e0c8774854fb50f5128 is the first bad commit
commit 6d9fdf4bf57353f9260a2e0c8774854fb50f5128
Author: Kyrylo Tkachov
Date: Thu Feb 27 09:24:10 2025 -0800
Locality cloning pass: -fipa-reorder-for-locality
caused
FAIL: gcc.dg/completion-2.c expected mult
Thanks.
Pushed to trunk.
Qing
> On Apr 15, 2025, at 14:56, Marek Polacek wrote:
>
> On Tue, Apr 15, 2025 at 06:46:26PM +, Qing Zhao wrote:
>> This is the 2nd version of the patch, the change is to replace "FALSE" with
>> "false" per Marek's comments.
>>
>> C_MAYBE_CONST_EXPR is a C FE ope
On Tue, Apr 15, 2025 at 09:07:44PM +0200, Martin Uecker wrote:
> Am Dienstag, dem 15.04.2025 um 14:50 +0200 schrieb Michael Matz:
> > Hello,
> ...
>
> > > struct A {
> > > int *buf __counted_by(len); // 'len' *must* be in the struct.
> > > int len;
> > > };
> >
> > ... means that we would hav
Hi,
I'd like to backport this testsuite enhancement to GCC 14 so that
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680896.html
can be backported to GCC 14 with testcases unchanged.
H.J.
---
As PR target/116174 shown, we may need to verify labels and the directive
order. Extend check-f
On Sun, Mar 16, 2025 at 11:43 AM Jeff Law wrote:
>
>
>
> On 3/15/25 9:01 PM, Andrew Pinski wrote:
> > The problem here is there was a compare debug since the discriminators
> > would still take into account debug statements. For the edge we would look
> > at the first statement after the labels an
There's a blurb at the top of the "Optimize Options" node telling
people that most optimization options are completely disabled at -O0
and a similar blurb in the entry for -Og, but nothing at the entry for
-O0. Since this is a continuing point of confusion it seems wise to
duplicate the informatio
On Tue, Apr 15, 2025 at 2:23 PM H.J. Lu wrote:
>
> On Tue, Apr 15, 2025 at 12:45 AM Uros Bizjak wrote:
> >
> > On Tue, Apr 15, 2025 at 1:06 AM H.J. Lu wrote:
> > >
> > > ix86_add_cfa_restore_note omits the REG_CFA_RESTORE REG note for registers
> > > pushed in red-zone. Since
> > >
> > > commit
Tested the testcase fix with a Darwin cross-compiler.
Regression tested x86_64-pc-linux-gnu.
Applying to trunk.
-- 8< --
On Darwin and other targets with !can_alias_cdtor, we instead go to
maybe_thunk_ctor, which builds a thunk function that calls the general
constructor. And then cp_fold tries
On Tue, Apr 15, 2025 at 5:02 AM LIU Hao wrote:
>
> 在 2025-4-14 04:10, Peter Damianov 写道:
> > diff --git a/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
> > b/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
> > index 9b2cd7e7b49..827215be3e2 100644
> > --- a/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
>
Am Dienstag, dem 15.04.2025 um 14:50 +0200 schrieb Michael Matz:
> Hello,
...
> > struct A {
> > int *buf __counted_by(len); // 'len' *must* be in the struct.
> > int len;
> > };
>
> ... means that we would have to implement general delayed parsing for
> expressions in C parsers.
I have to
Indu Bhagat writes:
> Using post-index stg is a faster way of memory tagging/untagging.
>
> TBD:
> - Currently generated by in the aarch64 backend. Not sure if this
> is the right way to do it.
> - Also not clear how to weave in the generation of stzg.
Similarly to patch 4, I think we sh
Dear all,
the testcase in the PR shows a case where the pureness of a function
is not properly determined, even though the function is resolved, and
its attributes clearly show that it is pure, because gfc_pure_function
relies on isym or esym being set. This does not happen here, probably
becaus
On Tue, Apr 15, 2025 at 06:46:26PM +, Qing Zhao wrote:
> This is the 2nd version of the patch, the change is to replace "FALSE" with
> "false" per Marek's comments.
>
> C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold.
> In c_fully_fold, it assumes that operands of fu
Hi Jason,
On Thu Apr 10, 2025 at 10:42 PM CEST, Jason Merrill wrote:
> On 9/6/24 7:15 AM, Simon Martin wrote:
>> We ICE upon the following *valid* code when mangling the requires
>> clause
>>
>> === cut here ===
>> template struct s1 {
>>enum { e1 = 1 };
>> };
>> template struct s2 {
>>
Indu Bhagat writes:
> Using post-index st2g is a faster way of memory tagging/untagging.
> Because a post-index 'st2g tag, [addr], #32' is equivalent to:
>stg tag, addr, #0
>stg tag, addr, #16
>add addr, addr, #32
>
> TBD:
> - Currently generated by in the aarch64 backend. Not sure
This is the 2nd version of the patch, the change is to replace "FALSE" with
"false" per Marek's comments.
C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold.
In c_fully_fold, it assumes that operands of function calls have already
been folded. However, when we build call to
Alice Carlotti writes:
> This applies to the sysreg read/write intrinsics __arm_[wr]sr*. It does
> not depend on changes to Binutils, because GCC converts recognised
> sysreg names to an encoding based form, which is already ungated in Binutils.
>
> We have, however, agreed to make an equivalent
Tested on i686, x86_64 and aarch64 Darwin, plus x86_64, aarch64 and
powerpc64le Linux, pushed to trunk, thanks
Iain
--- 8 ---
The latest editions of XCode have altered the identify reported by 'ld -v'
(again). This means that GCC configure no longer detects the version.
Fixed by adding the new
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, April 15, 2025 13:54
> To: Robert Dubner
> Cc: 'Jeff Law' ; gcc-patches@gcc.gnu.org; 'James
K.
> Lowden'
> Subject: Re: COBOL: Is anything stalled because of me?
>
> On Tue, Apr 15, 2025 at 10:47:13AM -0500, Robert Dubner wr
Alex wrote:
Tested on x86_64-pc-linux-gnu, this is only a library addition (and a
few tests) so it shouldn't cause any major impacts. I also tested
libgomp C to ensure the conditional compile was working.
Namely, the change is only to omp.h(.in) - effective for
__cplusplus >= 201103L.
Note th
This applies to the sysreg read/write intrinsics __arm_[wr]sr*. It does
not depend on changes to Binutils, because GCC converts recognised
sysreg names to an encoding based form, which is already ungated in Binutils.
We have, however, agreed to make an equivalent change in Binutils (which
would t
Pushing as obvious.
Thanks,
Kyrill
Signed-off-by: Kyrylo Tkachov
* common.opt.urls: Regenerate.
0001-Regenerate-common.opt.urls.patch
Description: 0001-Regenerate-common.opt.urls.patch
Tested on x86_64-pc-linux-gnu, this is only a library addition (and a
few tests) so it shouldn't cause any major impacts. I also tested
libgomp C to ensure the conditional compile was working.
Okay for trunk?
From 1ef3fe0a1f026689e64963ec9ab0b04b7e6b1bde Mon Sep 17 00:00:00 2001
From: waffl3x
Da
On Tue, Apr 15, 2025 at 10:47:13AM -0500, Robert Dubner wrote:
> Speaking purely casually: I thought that that COBOL would be released with
> documented limited capability. "Yeah, it works on x86_64-linux and
> aarch64-linux. More to come.". We knew that we didn't know how to
> cross-compile
Hi,
> gcc/ChangeLog:
>
> PR tree-optimization/117790
> * tree-vect-loop.cc (scale_profile_for_vect_loop): Use
> scale_loop_profile_hold_exit_counts instead of scale_loop_profile. Drop
> the exit edge parameter, since the code now handles multiple exits.
> Adjust the
Hi!
Here is my attempt at the PR119614 LTO fix.
Of course, if Martin can come up with something cleaner, let's go with that
instead.
This patch just remembers when ipa_record_return_value_range was set
to a singleton range with CONSTANT_CLASS_P value and propagates that value
through LTO to ltran
> Hi,
> > gcc/ChangeLog:
> >
> > PR tree-optimization/117790
> > * cfgloopmanip.cc (can_flow_scale_loop_freqs_p): New.
> > (flow_scale_loop_freqs): New.
> > (scale_loop_freqs_with_exit_counts): New.
> > (scale_loop_freqs_hold_exit_counts): New.
> > (scale_loop_profile): Ref
Hi,
> gcc/ChangeLog:
>
> PR tree-optimization/117790
> * cfgloopmanip.cc (can_flow_scale_loop_freqs_p): New.
> (flow_scale_loop_freqs): New.
> (scale_loop_freqs_with_exit_counts): New.
> (scale_loop_freqs_hold_exit_counts): New.
> (scale_loop_profile): Refactor
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, April 15, 2025 13:10
> To: gcc-patches@gcc.gnu.org
> Cc: Jakub Jelinek ; rdub...@symas.com
> Subject: [PATCH] cobol/119302 - transform gcobol.3 name during install,
> install as gcobol-io.3
>
> The following installs gcobol.3 as
The following installs gcobol.3 as gcobol-io.3 and applies
program-transform-name to the gcobol-io part. This follows
naming of the pdf and the html variants.
It also uses $(man1ext) and $(man3ext) consistently.
Built and installed on x86_64-unknown-linux-gnu.
OK?
Thanks,
Richard.
PR c
This is a reimplementation of get_target_clone_attr_len,
get_attr_str, and separate_attrs using string_slice and auto_vec to make
memory management and use simpler.
Adds get_target_version helper function to get the target_version string
from a decl.
gcc/c-family/ChangeLog:
* c-attribs.c
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, April 15, 2025 12:50 PM
> To: Tamar Christina
> Cc: Richard Sandiford ; gcc-patches@gcc.gnu.org;
> nd
> Subject: RE: [PATCH]middle-end: Fix incorrect codegen with PFA and VLS
> [PR119351]
>
> On Tue, 15 Apr 2025, Tamar Christi
Move namespace ranges inside the feature test macro guard, because
'ranges' is not a reserved name before C++20.
libstdc++-v3/ChangeLog:
* include/std/numeric (ranges): Only declare namespace for C++23
and later.
(ranges::iota_result): Fix indentation.
* testsuite/
In r14-7153-gadbc46942aee75 we removed a duplicate definition of
__glibcxx_want_range_iota from , but __cpp_lib_ranges_iota
should be defined in at all.
libstdc++-v3/ChangeLog:
* include/std/ranges (__glibcxx_want_ranges_iota): Do not
define.
---
Tested x86_64-linux. Pushed to t
From: beamandala
gcc/rust/ChangeLog:
* expand/rust-macro-builtins.cc (MacroBuiltin::builtin_transcribers):
Add entry for track_caller.
* util/rust-attribute-values.h: add `TRACK_CALLER` attribute.
* util/rust-attributes.cc: add `track_caller` attribute definition.
This patch will be committed this week if CI passes and not strong
objections since it's bug to large code model, also change is small
On Mon, Apr 14, 2025 at 6:00 PM Kito Cheng wrote:
>
> Large code model assume the data or rodata may put far away from
> text section. So we need to put jump tab
A few spelling and grammar fixes, and whitespace tweaks, but the only
significant thing is to qualify some calls to prevent ADL ...
On 14/04/25 16:13 +0200, Tomasz Kamiński wrote:
This patch implements formatter specialization for input_ranges and
range_formatter class form P2286R8, as adjusted
This testcase was fixed by r15-3052-gc7b76a076cb2c6ded but is
a testcase that failed in a different fashion and a much older
failure than the one added with r15-3052.
Pushed as obvious after a quick test.
PR tree-optimization/118476
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr11
vsetvl phase4 uses LCM guided info to insert VSETVL insns, including a
straggler loop for "mising vsetvls" on certain edges. Currently it
asserts on encountering EDGE_ABNORMAL.
When enabling go frontend with V enabled, libgo build hits the assert.
The solution is to prevent abnormal edges from ge
On Tue, Apr 15, 2025 at 09:16:46AM -0400, Jason Merrill wrote:
> On 4/15/25 2:56 AM, Nathaniel Shead wrote:
> > On Mon, Apr 14, 2025 at 05:33:05PM -0400, Jason Merrill wrote:
> > > On 4/13/25 6:32 AM, Nathaniel Shead wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
On Tue, Apr 15, 2025 at 10:48 AM Luc Grosheintz
wrote:
> Uses the FTM infrastructure to create an internal feature testing macro
> for partial availability of mdspan; which is then used to hide the
> contents of the header mdspan when compiling against a standard prior to
> C++23.
>
> libstdc++-v
This change refactors FMV handling in the frontend to allows greater
reasoning about versions in shared code.
This is needed for allowing target_clones and target_versions to be used
together in a function set, as there is then two distinct concerns when
encountering two declarations that previous
* configure.tgt: Set LIBGCOBOL_SUPPORTED for riscv64-*-linux* with
64-bit multilib.
---
libgcobol/configure.tgt | 5 +
1 file changed, 5 insertions(+)
diff --git a/libgcobol/configure.tgt b/libgcobol/configure.tgt
index ebf044e98f1..a23925295b6 100644
--- a/libgcobol/configure
Add logic for the case of two FMV annotated functions with identical
signature other than the return type.
Previously this was ignored, this changes the behavior to emit a diagnostic.
gcc/cp/ChangeLog:
PR c++/119498
* decl.cc (duplicate_decls): Change logic to not always exclude F
On 4/15/25 2:56 AM, Nathaniel Shead wrote:
On Mon, Apr 14, 2025 at 05:33:05PM -0400, Jason Merrill wrote:
On 4/13/25 6:32 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Currently, pruned lambda captures are still leftover in the function's
This implements std::extents from according to N4950 and
contains partial progress towards PR107761.
If an extent changes its type, there's a precondition in the standard,
that the value is representable in the target integer type. This commit
uses direct initialization to perform the conversion,
在 2025-4-14 04:10, Peter Damianov 写道:
diff --git a/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
b/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
index 9b2cd7e7b49..827215be3e2 100644
--- a/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
+++ b/gcc/testsuite/gcc.target/i386/amd64-abi-9.c
@@ -1,18 +1,46 @@
Indu Bhagat writes:
> Store Allocation Tags (st2g) is an Armv8.5-A memory tagging (MTE)
> instruction. It stores an allocation tag to two tag granules of memory.
>
> TBD:
> - Not too sure what is the best way to generate the st2g yet; A
> subsequent patch will emit them in one of the target
The solution is to filter out abnormal edges from getting into LCM at
all. Existing invalid_opt_bb_p () has such checks for BB predecessors
but not for successors which is what the patch adds.
OK.
--
Regards
Robin
Hi,
Indu Bhagat writes:
> subg (Subtract with Tag) is an Armv8.5-A memory tagging (MTE)
> instruction. It can be used to subtract an immediate value scaled by
> the tag granule from the address in the source register.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64.md (subg): New definitio
On 4/15/25 12:24 AM, Eikansh Gupta wrote:
The patterns can be simplified as shown below:
(a != b) & ((a|b) != 0) -> (a != b)
(a != b) | ((a|b) != 0) -> ((a|b) != 0)
The similar simplification can be there for (a == b). This patch adds
simplification for above patterns. The forwprop pass wa
On Mon, Apr 14, 2025 at 3:11 PM Kyrylo Tkachov wrote:
>
> Hi Honza,
>
> > On 13 Apr 2025, at 23:19, Jan Hubicka wrote:
> >
> >> +@opindex fipa-reorder-for-locality
> >> +@item -fipa-reorder-for-locality
> >> +Group call chains close together in the binary layout to improve code code
> >> +localit
This patch implements formatter specialization for input_ranges and
range_formatter class from P2286R8, as adjusted by P2585R1. The formatter
for pair/tuple is not yet provided, making maps not formattable.
This introduces an new _M_format_range member to internal __formatter_str,
that formats ran
ix86_add_cfa_restore_note omits the REG_CFA_RESTORE REG note for registers
pushed in red-zone. Since
commit 0a074b8c7e79f9d9359d044f1499b0a9ce9d2801
Author: H.J. Lu
Date: Sun Apr 13 12:20:42 2025 -0700
APX: Don't use red-zone with 32 GPRs and no caller-saved registers
disabled red-zone,
On Mon, Apr 14, 2025 at 08:28:55PM +, Qing Zhao wrote:
> C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold.
> In c_fully_fold, it assumes that operands of function calls have already
> been folded. However, when we build call to .ACCESS_WITH_SIZE, all its
> operands are
On 3/30/25 6:12 PM, Jan Hubicka wrote:
Hi,
I noticed that this patch got forgotten and I think it may be useful to
solve this next stage 1.
cp_apply_type_quals_to_decl drops 'const' if the type has mutable members.
Unfortunately TREE_READONLY on the PARM_DECL isn't helpful in the case of an
inv
> On Apr 14, 2025, at 16:35, Marek Polacek wrote:
>
> On Mon, Apr 14, 2025 at 08:28:55PM +, Qing Zhao wrote:
>> C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold.
>> In c_fully_fold, it assumes that operands of function calls have already
>> been folded. However, wh
On 4/13/25 1:56 PM, Patrick Palka wrote:
Alternatively, rather than passing the most general template + args to
push_tinst_level, we can pass the partially instantiated template +
innermost args via just:
gcc/cp/ChangeLog:
* constraint.cc (satisfy_declaration_constraints): Pass the
> On 15 Apr 2025, at 15:42, Richard Biener wrote:
>
> On Mon, Apr 14, 2025 at 3:11 PM Kyrylo Tkachov wrote:
>>
>> Hi Honza,
>>
>>> On 13 Apr 2025, at 23:19, Jan Hubicka wrote:
>>>
+@opindex fipa-reorder-for-locality
+@item -fipa-reorder-for-locality
+Group call chains close
Speaking purely casually: I thought that that COBOL would be released with
documented limited capability. "Yeah, it works on x86_64-linux and
aarch64-linux. More to come.". We knew that we didn't know how to
cross-compile, and we knew that other platforms would have to come, in time.
It nev
On 4/9/25 6:08 AM, Robin Dapp wrote:
Hi,
when lifting up a vsetvl into a block we currently don't consider the
block's transparency with respect to the vsetvl as in other parts of the
pass. This patch does not perform the lift when transparency is not
guaranteed.
This condition is more rest
On 4/15/25 9:36 AM, Peter Bergner wrote:
> On 4/15/25 12:01 AM, Alexandre Oliva wrote:
>> On Apr 14, 2025, Peter Bergner wrote:
>>
>>> But -mcpu= should not enable -mpowerpc64 by default for -m32 compiles.
>>
>> Oh, is that so? It seems to have been the case for quite a long time.
>> I can trivia
On 4/9/25 2:53 PM, Vineet Gupta wrote:
Changes since v2
- Elide abnormal edges before LCM not after LCM
---
vsetvl phase4 uses LCM guided info to insert VSETVL insns, including a
straggler loop for "mising vsetvls" on certain edges. Currently it
asserts on encountering EDGE_ABNORMAL.
When
This patch implements formatter specialization for input_ranges and
range_formatter class from P2286R8, as adjusted by P2585R1. The formatter
for pair/tuple is not yet provided, making maps not formattable.
This introduces an new _M_format_range member to internal __formatter_str,
that formats ran
On 4/15/25 9:39 AM, Nathaniel Shead wrote:
On Tue, Apr 15, 2025 at 09:16:46AM -0400, Jason Merrill wrote:
On 4/15/25 2:56 AM, Nathaniel Shead wrote:
On Mon, Apr 14, 2025 at 05:33:05PM -0400, Jason Merrill wrote:
On 4/13/25 6:32 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-p
Attached patch OK for master branch?
Will push soon if there are no objections.
From b329d899d07cda78bc44d88f81bdf10d5e2db302 Mon Sep 17 00:00:00 2001
From: Jonathan Yong <10wa...@gmail.com>
Date: Tue, 15 Apr 2025 11:41:36 +
Subject: [PATCH] ref-temp1.C: Enable some tests for PE targets
Test
On 4/15/25 7:57 AM, Andreas Schwab wrote:
* configure.tgt: Set LIBGCOBOL_SUPPORTED for riscv64-*-linux* with
64-bit multilib.
Can't say I'm happy with the amount of Cobol related churn at this phase
in our cycle. But this should be exceedingly safe. So OK.
jeff
On 4/15/25 12:01 AM, Alexandre Oliva wrote:
> On Apr 14, 2025, Peter Bergner wrote:
>
>> But -mcpu= should not enable -mpowerpc64 by default for -m32 compiles.
>
> Oh, is that so? It seems to have been the case for quite a long time.
> I can trivially see that GCC 9 already did that, but it may
> -Original Message-
> From: Richard Biener
> Sent: Tuesday, April 15, 2025 12:49 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH]middle-end: Fix incorrect codegen with PFA and VLS
> [PR119351]
>
> On Tue, 15 Apr 2025, Tamar Christina wrote:
>
> > Hi Al
On 15/04/25 15:05 +0100, Jonathan Wakely wrote:
A few spelling and grammar fixes, and whitespace tweaks, but the only
significant thing is to qualify some calls to prevent ADL ...
Doh, as pointed out in chat the ADL thing is irrelevant because that's
not std::format.
So I think everything else
On Tue, Apr 15, 2025 at 03:14:49PM +0200, Martin Jambor wrote:
> In my fix for PR 119318 I put mask calculation in
> ipcp_bits_lattice::meet_with_1 above a final fix to value so that all
> the bits in the value which are meaningless according to mask have
> value zero, which has tripped a validator
Hi,
On Tue, Apr 15 2025, Jakub Jelinek wrote:
> On Tue, Apr 15, 2025 at 02:17:46PM +0200, Martin Jambor wrote:
>> Hi,
>>
>> On Tue, Apr 15 2025, Jakub Jelinek wrote:
>> > On Mon, Mar 31, 2025 at 03:34:07PM +0200, Martin Jambor wrote:
>> >> This patch just introduces a form of dumping of widest in
On Tue, Apr 15, 2025 at 11:39:21PM +1000, Nathaniel Shead wrote:
> On Tue, Apr 15, 2025 at 09:16:46AM -0400, Jason Merrill wrote:
> > On 4/15/25 2:56 AM, Nathaniel Shead wrote:
> > > On Mon, Apr 14, 2025 at 05:33:05PM -0400, Jason Merrill wrote:
> > > > On 4/13/25 6:32 AM, Nathaniel Shead wrote:
>
1 - 100 of 165 matches
Mail list logo
