Hi,
since r15-9062-g70391e3958db79 we perform vector bitmask initialization
via the vec_duplicate expander directly. This triggered a latent bug in
ours where we missed to mask out the single bit which resulted in an
execution FAIL of pr119114.c
The attached patch adds the 1-masking of the broa
Assuming we have the following variables:
unsigned long long a0, a1;
unsigned int a2;
For the expression:
a0 = (a0 << 50) >> 49; // slli a0, a0, 50 + srli a0, a0, 49
a2 = a1 + a0; // addw a2, a1, a0 + slli a2, a2, 32 + srli a2, a2, 32
In the optimization process of ZBA (combine pass)
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2025-04-02 15:02
To: gcc-patches
CC: pal...@dabbelt.com; kito.ch...@gmail.com; juzhe.zh...@rivai.ai;
jeffreya...@gmail.com; pan2...@intel.com; rdapp@gmail.com
Subject: [PATCH] RISC-V: Fix vec_duplicate[bimode] expander [PR119572].
Hi,
sin
On Mon, 17 Mar 2025, Aleksandar Rakic wrote:
> * config/mips/mips.h:
> (TARGET_MICROMIPS_R6): Define.
Umm, this change can't go forward I'm afraid without microMIPSr6 support
landing in binutils first. Otherwise we have no consumer for compiled
code available. Also is there a way
builtin_unreachable_bb_p exacts empty basic blocks to have only one successor
edge but
in the case after inliing a noreturn function that actually returns, we end up
with an
empty basic block with no successor edge. fixup_cfg fixes this up by placing a
call to
__builtin_unreachable but we don't
Jakub,
Thank you for the comments.
> On Apr 2, 2025, at 02:48, Jakub Jelinek wrote:
>
> On Tue, Apr 01, 2025 at 05:13:46PM -0700, Bill Wendling wrote:
>> On Tue, Apr 1, 2025 at 8:29 AM Martin Uecker wrote:
>>> Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zhao:
> On Apr 1, 2025,
在 2025/4/3 上午11:12, Xi Ruoyao 写道:
On Thu, 2025-04-03 at 10:13 +0800, Lulu Cheng wrote:
在 2025/4/2 上午11:19, Xi Ruoyao 写道:
Avoid using gensub that FreeBSD awk lacks, use gsub and split those
each
of gawk, mawk, and FreeBSD awk provides.
Reported-by: mp...@vip.163.com
Link: https://man.freebsd.
On Tue, 1 Apr 2025, Richard Sandiford wrote:
> The problem in PR101523 was that, after each successful 2->2
> combination attempt, distribute_links would search further and
> further for the next combinable use of the i2 destination.
> The original patch for the PR dealt with that by disallowing s
Hi!
I'd like to ping the following PowerPC patches:
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679312.html
rs6000: Ignore OPTION_MASK_SAVE_TOC_INDIRECT differences in inlining decisions
[PR119327]
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/676989.html
target: Adjust gcc.targ
On Fri, 29 Nov 2024, LIU Hao wrote:
在 2024-11-29 23:50, Jonathan Wakely 写道:
It looks like your patch is against gcc-14 not trunk, the
GLIBCXX_15.1.0 version is already there.
Sorry, I mean GLIBCXX_3.4.34 for 15.1.0
Oops that's what I used to test the patch. Reapplied to master now.
Ping -
On Wed, Apr 02, 2025 at 06:38:12PM +0200, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs because c_fully_fold isn't performed on the
> arguments of __sanitizer_ptr_{sub,cmp} builtins and so e.g.
> C_MAYBE_CONST_EXPR can leak into the gimplifier where it ICEs.
>
> Fixed thusly, bootstr
Bootstrapped and regtested on x86_64-pc-linux, does this look
OK for trunk/14?
-- >8 --
The testcase in this PR uses 2.5x more memory and 6x more compile
time ever since r14-5979 which implements P2280R4. This is because
our speculative constexpr folding now does a lot more work trying to
fold
Committed to trunk. Tested on hppa64-hp-hpux11.11.
Dave
___
hpux: Only use long long when __cplusplus >= 201103L
Fixes some test failures.
2025-04-02 John David Anglin
libstdc++-v3/ChangeLog:
* config/os/hpux/os_defines.h: Only use long long when
__cplusplus >= 201103L.
di
On Wed, 2 Apr 2025 at 20:15, John David Anglin wrote:
>
> Committed to trunk. Tested on hppa64-hp-hpux11.11.
>
> Dave
> ___
>
> hpux: Only use long long when __cplusplus >= 201103L
>
> Fixes some test failures.
>
> 2025-04-02 John David Anglin
>
> libstdc++-v3/ChangeLog:
> * config/os/
> On 30 Mar 2025, at 15:07, Robert Dubner wrote:
>
> Follow-up. I risked wrath from my family and grabbed a minute. Tried
> the -L thing and eliminated all the SED statements on the .h files.
>
> It worked.
>
> Are there reasons not to use it?
There were coments about having explicit pat
On Wed, Apr 2, 2025 at 2:58 PM Hongyu Wang wrote:
>
> > Can we just change the output in original pattern, I think combine
> > will still match the pattern even w/ clobber flags.
>
> Yes, adjusted and updated the patch in attachment.
Ok.
>
> Liu, Hongtao 于2025年4月2日周三 08:57写道：
> >
> >
> >
> > > --
On Wed, Apr 02, 2025 at 09:22:54PM +0100, Richard Sandiford wrote:
> I'm not sure the _1 template is worth it. wi::to_widest ->
> const wide_int_ref & should be very cheap (it doesn't for example
> construct a widest_int), so I think native_encode_int could call
> native_encode_wide_int.
You're r
Looking over the recently-committed change to the musttail attribute
documentation, it appears the comment in the last example was a paste-o,
as it does not agree with either what the similar example in the
-Wmaybe-musttail-local-addr documentation says, or the actual behavior
observed when running
XThreadVector does not support the vsext/vzext instructions; however,
due to the reuse of RVV optimizations, it may generate these instructions
in certain cases. To prevent the error "Unknown opcode 'th.vsext.vf2',"
we should disable these patterns.
gcc/ChangeLog:
* config/riscv/vector.md
This patch series adds compile and execute tests to test SVE types with various
OpenMP constructs and clauses. This is a follow-up series that applies on
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/678086.html
posted earlier last month and tests the changes proposed in that series.
I
Add compile-only OpenMP error tests for target clause used with SVE types.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/gomp/gomp.exp: Test driver.
* gcc.target/aarch64/sve/gomp/target-device.c: New test.
* gcc.target/aarch64/sve/gomp/target-link.c: Likewise.
On Thu, Apr 3, 2025 at 7:10 AM Andrew Pinski wrote:
>
> builtin_unreachable_bb_p exacts empty basic blocks to have only one successor
> edge but
> in the case after inliing a noreturn function that actually returns, we end
> up with an
> empty basic block with no successor edge. fixup_cfg fixes
Using specific SSA names in pattern matching in `dg-final' makes tests
"unstable", in that changes in passes prior to the pass whose dump is
analyzed in the particular test may change the numbering of the SSA
variables, causing the test to start failing spuriously.
We thus switch from specific SSA
Tested on x86_64-darwin24 with Xcode 16.2. OK for trunk?
thanks
Iain
--- 8< ---
Darwin's linker now warns when duplicate rpaths are presented - which
happens when we emit duplicate '-B' paths. In principle, we should avoid
this in the test- suite, however at present we tend to have duplicates
be
On Wed, 2 Apr 2025, 14:53 Iain Sandoe, wrote:
> Tested on x86_64-darwin24 with Xcode 16.2. OK for trunk?
>
OK, thanks
thanks
> Iain
>
> --- 8< ---
>
> Darwin's linker now warns when duplicate rpaths are presented - which
> happens when we emit duplicate '-B' paths. In principle, we should avoi
The following reverts parts of r15-8047 which assesses alignment
analysis for VMAT_STRIDED_SLP is correct by using aligned accesses
where allowed by it. As the PR shows this analysis is still incorrect,
so revert back to assuming we got it wrong.
Bootstrapped and tested on x86_64-unknown-linux-gn
Hi!
Below is an attempt to fix up RTX costing P1 caused by r15-775
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/thread.html#652446
@@ -21562,7 +21562,8 @@ ix86_rtx_costs (rtx x, machine_mode mode, int
outer_code_i, int opno,
if (x86_64_immediate_operand (x, VOIDmode))
*total
Hi!
The following testcase ICEs because c_fully_fold isn't performed on the
arguments of __sanitizer_ptr_{sub,cmp} builtins and so e.g.
C_MAYBE_CONST_EXPR can leak into the gimplifier where it ICEs.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2025-04-02 Ja
On 4/2/25 8:53 AM, Victor Do Nascimento wrote:
Using specific SSA names in pattern matching in `dg-final' makes tests
"unstable", in that changes in passes prior to the pass whose dump is
analyzed in the particular test may change the numbering of the SSA
variables, causing the test to start f
On Wed, Apr 2, 2025 at 11:02 AM Rainer Orth
wrote:
>
> Ping? It's been a week:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2025-March/679330.html
>
> > Three tests FAIL on Solaris/x86 in similar ways:
> >
> > FAIL: gcc.target/i386/pr111673.c check-function-bodies advance
> > FAIL: gcc.
On 2025-04-02 3:19 p.m., Jonathan Wakely wrote:
> On Wed, 2 Apr 2025 at 20:15, John David Anglin wrote:
>>
>> Committed to trunk. Tested on hppa64-hp-hpux11.11.
>>
>> Dave
>> ___
>>
>> hpux: Only use long long when __cplusplus >= 201103L
>>
>> Fixes some test failures.
>>
>> 2025-04-02 John Davi
On 4/2/25 1:01 AM, Jin Ma wrote:
Assuming we have the following variables:
unsigned long long a0, a1;
unsigned int a2;
For the expression:
a0 = (a0 << 50) >> 49; // slli a0, a0, 50 + srli a0, a0, 49
a2 = a1 + a0; // addw a2, a1, a0 + slli a2, a2, 32 + srli a2, a2, 32
In the opti
The AIX traceback table documentation states the tbtab "lang" field for
Cobol should be set to 7.
Tested on powerpc64le-linux. There are "new" FAILs with the patch (see below)
on the Cobol test cases, but that is a good thing, because without the
patch, the compiler ICEs and none of the tests are
Hi,
This patch merges the D front-end with upstream dmd ed17b3e95d.
Reverts a change in the upstream D implementation of the compiler,
as it is no longer necessary since another fix for opDispatch got
applied in the same area (merged in r12-6003-gfd43568cc54e17).
Bootstrapped and regression test
Hi, Bill,
Thanks for the summary.
I think that this is good.
Two more questions:
1. Shall we keep the same name of the attribute counted_by for the 2nd new
syntax?
Or use a new name, such as, “counted_by_exp"?
I don’t have strong preference here. As mentioned by Jacub in a
prev
On Fri, Mar 28, 2025 at 10:02:28PM -0400, Patrick Palka wrote:
> On Fri, 28 Mar 2025, Jason Merrill wrote:
>
> > Tested x86_64-pc-linux-gnu, initially with extra checking to make sure that
> > indeed nothing got saved from a namespace level.
> >
> > This isn't a regression, but a 20% speedup for
On 3/30/25 2:52 AM, Jonathan Yong wrote:
Patch OK for master branch?
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/torture/switch-3.c: fix llp64 warnings
diff --git a/gcc/testsuite/gcc.dg/analyzer/torture/switch-3.c b/gcc/
testsuite/gcc.dg/analyzer/torture/switch-3.c
index 57b8acdb292..b40be6
On Wed, 2 Apr 2025, Jakub Jelinek wrote:
> On Wed, Apr 02, 2025 at 10:32:20AM +0200, Richard Biener wrote:
> > I wonder if we can amend the documentation to suggest to end lifetime
> > of variables explicitly by proper scoping?
>
> In the -Wmaybe-musttail-local-addr attribute description I've alr
Since r15-7878-ge1c49f413c8, these tests appear as XPASS on aarch64,
so we can remove the xfails introduced by r12-102-gf31ddad8ac8f11.
gcc/testsuite/ChangeLog:
* gcc.dg/guality/pr90074.c: Remove xfail for aarch64.
* gcc.dg/guality/pr90716.c: Likewise.
---
gcc/testsuite/gcc.dg/gu
Hi folks,
it would be great to reduce the in-flight patch stack a bit :)
> On 25 Mar 2025, at 16:40, Iain Sandoe wrote:
>
> This is on top of the C++-ify configure and random_r patches.
> Tested on x86_64,aarch64-Linux and x86_64-darwin, OK for trunk?
> thanks
> Iain
>
> --- 8< ---
>
> strfro
On Tue, Apr 1, 2025 at 11:49 PM Jakub Jelinek wrote:
> On Tue, Apr 01, 2025 at 05:13:46PM -0700, Bill Wendling wrote:
> > On Tue, Apr 1, 2025 at 8:29 AM Martin Uecker wrote:
> > > Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zhao:
> > > > > On Apr 1, 2025, at 10:04, Martin Uecker wrot
>From ce33db9c7c440be3988d4ad90f2ec41fea9c Mon Sep 17 00:00:00 2001
From: Bob Dubner mailto:rdub...@symas.com
Date: Wed, 2 Apr 2025 12:18:08 -0400
Subject: [PATCH] cobol: Plug memory leak caused by intermediate_e
stack-frame
variables. [PR119521]
COBOL variables with attribute intermediate_e
> On 2 Apr 2025, at 20:02, Robert Dubner wrote:
>
> Since you say it tests okay, I say it's "Okay for trunk".
thanks.
>
> I am new to this, as you know, and I am still trying to figure out how to
> make all of this work. Nor have Jim and I figured out how to handle our
> joint responsibilit
> -Original Message-
> From: Iain Sandoe
> Sent: Wednesday, April 2, 2025 15:05
> To: Robert Dubner
> Cc: GCC Patches ; James K. Lowden
>
> Subject: Re: [ping][PATCH] libgcobol: Provide fallbacks for C32
> strfromf32/64 [PR119296].
>
>
>
> > On 2 Apr 2025, at 20:02, Robert Dubner wrote:
On Tue, 1 Apr 2025, Jakub Jelinek wrote:
> Hi!
>
> On Tue, Mar 25, 2025 at 08:34:10AM +0100, Jakub Jelinek wrote:
> > As discussed here and in bugzilla, [[clang::musttail]] attribute in clang
> > not just strongly asks for tail call or error, but changes behavior.
> > To quote:
> > https://clang.
On Wed, Apr 02, 2025 at 10:32:20AM +0200, Richard Biener wrote:
> I wonder if we can amend the documentation to suggest to end lifetime
> of variables explicitly by proper scoping?
In the -Wmaybe-musttail-local-addr attribute description I've already
tried to show that in the example, but if you t
Sandra Loosemore wrote:
As noted in PR 118965, the initial interop implementation overlooked
the requirement in the OpenMP spec that at least one of the "target"
and "targetsync" modifiers is required in both the interop construct
init clause and the declare variant append_args clause.
... whic
On Tue, Apr 1, 2025 at 8:29 AM Martin Uecker wrote:
> Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zhao:
> > > On Apr 1, 2025, at 10:04, Martin Uecker wrote:
> > > Am Montag, dem 31.03.2025 um 13:59 -0700 schrieb Bill Wendling:
> > > > > I'd like to offer up this to solve the issues we
Since you say it tests okay, I say it's "Okay for trunk".
I am new to this, as you know, and I am still trying to figure out how to
make all of this work. Nor have Jim and I figured out how to handle our
joint responsibility.
Hence delays.
> -Original Message-
> From: Iain Sandoe
> Se
Jakub Jelinek writes:
> Hi!
>
> As has been mentioned earlier, various parts of the COBOL FE and the library
> aren't endian clean. In the library that means that for now we have to
> live with no support for big endian targets, but in the FE that means
> that as well as not being able to build c
50 matches
Mail list logo
