There's two new tests that are dependent on logical-op-non-short-circuit
settings. The BZ is reported against ppc64 and ppc64le, but also
applies to a goodly number of the other targets.
The "regression" fix is trivial, just add the appropriate param to force
the behavior we're expecting. I'
On Thu, 2025-01-30 at 00:31 +0800, Gerald Pfeifer wrote:
> On Fri, 24 Jan 2025, David Malcolm wrote:
> > Changed in v2: rather than replacing "mhc", this version runs the
> > output from mhc through the Python script.
>
> Unless I'm missing something that makes sense, yes.
>
> > With this approac
On 29 January 2025 20:43:12 CET, Bernhard Reutner-Fischer
wrote:
>
>>> deduction_guide_p doesn't look like a significant expense to me; I wouldn't
>>> bother trying to optimize it without profile data as evidence.
>>
>>Yep, can confirm that it's insignificant. And DECL_FRIEND_CONTEXT isn't
>>use
Built on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
This unused accessor is just a simple alias of LAMBDA_EXPR_THIS_CAPTURE
and contrary to the documentation doesn't actually use TREE_LANG_FLAG_0.
Might as well remove it.
gcc/cp/ChangeLog:
* cp-tree.h (LAMBDA_EXPR_CAPTUR
>> deduction_guide_p doesn't look like a significant expense to me; I wouldn't
>> bother trying to optimize it without profile data as evidence.
>
>Yep, can confirm that it's insignificant. And DECL_FRIEND_CONTEXT isn't
>used in any particularly hot code so the implied memory barrier of the
>ded
On Wed, Jan 29, 2025 at 06:46:30PM +, Richard Sandiford wrote:
> As Andrew says in the bugzilla comments, this PR is about a case where
> we tried to fuse two stores of x0, one in which x0 was defined and one
> in which it was undefined. merge_access_arrays failed on the conflict,
> but the fa
Tested on x86_64-pc-linux-gnu, I suppose this is stage 1 material?
-- >8 --
As a follow-up to r15-1253 and r15-1254.
libstdc++-v3/ChangeLog:
* include/std/type_traits (__is_invocable): Define in terms of
corresponding builtin if available.
(__is_nothrow_invocable): Likew
As Andrew says in the bugzilla comments, this PR is about a case where
we tried to fuse two stores of x0, one in which x0 was defined and one
in which it was undefined. merge_access_arrays failed on the conflict,
but the failure wasn't caught.
Normally the hazard detection code would fail if the
The test case assumes that alignof(int)=sizeof(int). But for some
targets this is not valid. For example, for PRU target,
alignof(int)=1 but sizeof(int)=4.
Fix the test case to align to twice the size of int, as the expected
dg-error messages suggest.
This patch fixes the test failures for PRU
Christoph Müllner writes:
> The avoid-store-forwarding pass is disabled by default and therefore
> in the risk of bit-rotting. This patch addresses this by enabling
> the pass at O2 or higher.
>
> The assembly patterns in `bitfield-bitint-abi-align16.c` and
> `bitfield-bitint-abi-align8.c` have b
On Wed, Jan 29, 2025 at 04:44:55PM +, Richard Sandiford wrote:
> The PR showed two issues with pair-fusion. The first is that the pass
> treated stack pointer deallocations as ordinary register updates, and so
> might move them earlier than another stack access (through a different
> base regi
I'd like to ping 4 C++ patches:
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662379.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662380.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662381.html
P2552R3 - On the ignorability of standard attributes - se
The PR showed two issues with pair-fusion. The first is that the pass
treated stack pointer deallocations as ordinary register updates, and so
might move them earlier than another stack access (through a different
base register) that doesn't alias the pair candidate.
The simplest fix for that see
On Fri, 24 Jan 2025, David Malcolm wrote:
> Changed in v2: rather than replacing "mhc", this version runs the
> output from mhc through the Python script.
Unless I'm missing something that makes sense, yes.
> With this approach we could gradually move parts of the mhc
> functionality into the pyt
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
Fixed by r11-2412.
PR c++/57533
gcc/testsuite/ChangeLog:
* g++.dg/eh/throw5.C: New test.
---
gcc/testsuite/g++.dg/eh/throw5.C | 23 +++
1 file changed, 23 insertions(+)
create mode 100644 gcc/testsuite
On Wed, Jan 29, 2025 at 03:46:46PM +0100, Richard Biener wrote:
> The following guards the BIT_FIELD_REF expansion fallback for
> MEM_REFs of entities expanded to register (or constant) further,
> avoiding large out-of-bound offsets by, when the access does not
> overlap the base object, expanding
On Wed, Jan 29, 2025 at 10:25:39AM -0500, Siddhesh Poyarekar wrote:
> > > gcc/testsuite/ChangeLog:
> > >
> > > PR testsuite/118127
> > > * lib/target-supports.exp
> > > (check_effective_target_long_double_is_ibm128): New
> > > procedure.
> > > * gfortran.dg/default_format_2.f90: xfail fo
On 2025-01-29 08:24, Jakub Jelinek wrote:
On Wed, Jan 29, 2025 at 08:19:38AM -0500, Siddhesh Poyarekar wrote:
Denormal behaviour is well defined for IEEE128 long doubles, so
XFAIL some gfortran tests only for targets with the IBM128 long double
ABI.
gcc/testsuite/ChangeLog:
PR testsuit
On Wed, 2025-01-29 at 09:16 -0500, David Malcolm wrote:
> On Wed, 2025-01-29 at 13:05 +, Bader, Lucas wrote:
> > Hi,
> >
> > as discussed, I rebased and tested my patch against current master.
> > Additionally, it now has the Signed-off-by tag.
> > Looking forward to your comments.
> >
> > Be
On 1/29/25 3:47 AM, Yoshinori Sato wrote:
When using the "Q" constraint in the inline assembler, the displacement value
could exceed the range specified by the instruction.
To avoid this issue, a displacement range check is added to the "Q" constraint.
Thanks. I've pushed this to the trunk, e
Hello,
On Tue, 28 Jan 2025, Surya Kumari Jangala wrote:
> The following patch has been bootstrapped and regtested on
> powerpc64le-linux, aarch64-linux and x86_64-linux. This patch is a
> proposed fix for PR118533. Request you to please review the patch.
A full insn-scan should not be needed f
The following guards the BIT_FIELD_REF expansion fallback for
MEM_REFs of entities expanded to register (or constant) further,
avoiding large out-of-bound offsets by, when the access does not
overlap the base object, expanding the offset as if it were zero.
Bootstrapped on x86_64-unknown-linux-gnu
On Tue, 28 Jan 2025 at 16:00, Patrick Palka wrote:
>
> On Mon, 27 Jan 2025, Patrick Palka wrote:
>
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14?
> >
> > -- >8 --
> >
> > This case was incorrectly failing in C++23 mode even after P2492R2
> > because the perfect forwarding simpl
On Wed, 2025-01-29 at 13:05 +, Bader, Lucas wrote:
> Hi,
>
> as discussed, I rebased and tested my patch against current master.
> Additionally, it now has the Signed-off-by tag.
> Looking forward to your comments.
>
> Best
> Lucas
Thanks for the updated patch.
Various notes inline througho
When we walk stmts to find always executed stmts with UB in the last
iteration to be able to reduce the iteration count by one we fail
to consider infinite subloops in the last iteration that would make
such stmt not execute. The following adds this.
Third try - bootstrapped and tested on x86_64-
On Wed, Jan 29, 2025 at 08:19:38AM -0500, Siddhesh Poyarekar wrote:
> Denormal behaviour is well defined for IEEE128 long doubles, so
> XFAIL some gfortran tests only for targets with the IBM128 long double
> ABI.
>
> gcc/testsuite/ChangeLog:
>
> PR testsuite/118127
> * lib/target-sup
Denormal behaviour is well defined for IEEE128 long doubles, so
XFAIL some gfortran tests only for targets with the IBM128 long double
ABI.
gcc/testsuite/ChangeLog:
PR testsuite/118127
* lib/target-supports.exp
(check_effective_target_long_double_is_ibm128): New
pr
Hi,
as discussed, I rebased and tested my patch against current master.
Additionally, it now has the Signed-off-by tag.
Looking forward to your comments.
Best
Lucas
Within a compile cluster, only the preprocessed output of GCC is transferred
to remote nodes for compilation. When GCC produ
On Wed, Jan 29, 2025 at 08:01:17AM -0500, Siddhesh Poyarekar wrote:
> On 2025-01-29 07:34, Jakub Jelinek wrote:
> > > Denormal behaviour is well defined for IEEE128 long doubles, so don't
> > > XFAIL some gfortran tests on ppc64le when configured with the IEEE128
> > > long double ABI.
> >
> > If
On 1/27/25 6:19 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
We've had a wrong-code problem since r14-4140, due to which we
forget to initialize a variable.
In consteval39.C, we evaluate
struct QQQ q;
<>>
(const char *) "" >>>
On 2025-01-29 07:34, Jakub Jelinek wrote:
Denormal behaviour is well defined for IEEE128 long doubles, so don't
XFAIL some gfortran tests on ppc64le when configured with the IEEE128
long double ABI.
If long double is just IEEE754 double, then I think denormals
are equally well behaved, it is so
> Denormal behaviour is well defined for IEEE128 long doubles, so don't
> XFAIL some gfortran tests on ppc64le when configured with the IEEE128
> long double ABI.
If long double is just IEEE754 double, then I think denormals
are equally well behaved, it is solely the case of IBM double double.
Of
On 1/29/25 6:18 AM, Siddhesh Poyarekar wrote:
> Denormal behaviour is well defined for IEEE128 long doubles, so don't
> XFAIL some gfortran tests on ppc64le when configured with the IEEE128
> long double ABI.
>
> gcc/testsuite/ChangeLog:
>
> PR testsuite/118127
> * lib/target-supports
Denormal behaviour is well defined for IEEE128 long doubles, so don't
XFAIL some gfortran tests on ppc64le when configured with the IEEE128
long double ABI.
gcc/testsuite/ChangeLog:
PR testsuite/118127
* lib/target-supports.exp
(check_effective_target_ppc_not_well_defined_
*The Journal of Hunan University Natural Sciences *is the leading Chinese
peer-reviewed journal that publishes articles in all areas of natural
sciences. The Journal is meant to serve as a means of communication and
discussion of important issues related to science and scientific
activities. The Jo
When using the "Q" constraint in the inline assembler, the displacement value
could exceed the range specified by the instruction.
To avoid this issue, a displacement range check is added to the "Q" constraint.
Signed-off-by: Yoshinori Sato
---
gcc/config/rx/constraints.md | 3 ++-
1 file change
Tejas Belagod writes:
> diff --git a/gcc/config/aarch64/aarch64-sve-builtins.cc
> b/gcc/config/aarch64/aarch64-sve-builtins.cc
> index e7c703c987e..2c169ea3806 100644
> --- a/gcc/config/aarch64/aarch64-sve-builtins.cc
> +++ b/gcc/config/aarch64/aarch64-sve-builtins.cc
> @@ -4956,12 +4956,35 @@ ha
+JiangNing Liu
On Wed, 29 Jan 2025 at 10:38, Richard Biener wrote:
>
> On Wed, 29 Jan 2025, Christoph Müllner wrote:
>
> > The avoid-store-forwarding pass is disabled by default and therefore
> > in the risk of bit-rotting. This patch addresses this by enabling
> > the pass at O2 or higher.
> >
When we walk stmts to find always executed stmts with UB in the last
iteration to be able to reduce the iteration count by one we fail
to consider infinite subloops in the last iteration that would make
such stmt not execute. The following adds this and also changes
the DFS walk (which could end u
On Wed, 29 Jan 2025, Christoph Müllner wrote:
> The avoid-store-forwarding pass is disabled by default and therefore
> in the risk of bit-rotting. This patch addresses this by enabling
> the pass at O2 or higher.
>
> The assembly patterns in `bitfield-bitint-abi-align16.c` and
> `bitfield-bitint
> I think you meant "the value extended into" rather than "the extended to".
> OK with that fix.
Thanks Jeff, will commit the series with that fix.
Pan
-Original Message-
From: Jeff Law
Sent: Tuesday, January 28, 2025 11:18 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@riva
On Thu, Nov 28, 2024 at 8:37 AM Richard Biener
wrote:
> On Mon, Nov 25, 2024 at 3:28 AM Philipp Tomsich
> wrote:
> >
> > Pushed to master with the following fixups:
> > - new timevar added
> > - nits addressed
> > - whitespace fixes
>
> The pass seems to be disabled by default everywhere -
The avoid-store-forwarding pass is disabled by default and therefore
in the risk of bit-rotting. This patch addresses this by enabling
the pass at O2 or higher.
The assembly patterns in `bitfield-bitint-abi-align16.c` and
`bitfield-bitint-abi-align8.c` have been updated to account for
the ASF tra
When we expand BIT_FIELD_REF we can end up creating
a stack local, running into the fix. But get_object_alignment
will return 8 for any SSA_NAME because that's not an "object" we
handle. Deal with handled components on registers by singling out
SSA_NAME bases, using their type alignment instead
While working on split path, I noticed that poor_ifcvt_candidate_code
would check for CALL_EXPR but that can't show up in gimple_assign
so this removes that check.
This could be a very very small compile time improvement.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* gim
On Wed, Jan 29, 2025 at 8:54 AM Andrew Pinski wrote:
>
> After r15-3436-gb2b20b277988ab, poor_ifcvt_pred returns false for
> the case where the statement could trap but in this case trapping
> instructions cannot be made unconditional so it is a poor ifcvt.
>
> This fixes a small preformance regre
On Wed, Jan 29, 2025 at 8:56 AM Andrew Pinski wrote:
>
> While working on split path, I noticed that poor_ifcvt_candidate_code
> would check for CALL_EXPR but that can't show up in gimple_assign
> so this removes that check.
>
> This could be a very very small compile time improvement.
OK
> Boot
Enabling 'fp' on v8.1-m.main (either via +fp, +fp.dp or +mve.dp)
enables support for fp16 types (and registers _Float16 in C++).
As the g++.dg/cpp23/ext-floating13.C testcase shows, this pulls
typeinfo for _Float16 at link time, but a toolchain built using
t-rmprofile currently relies on v8-m.main
48 matches
Mail list logo
