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 regression with TSVC s258 at
`-O3 -ftrapping-math` on aarch64 where if
On Tue, Jan 28, 2025 at 7:13 PM Surya Kumari Jangala
wrote:
>
> Hi,
> 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.
>
> Regards
> Surya
>
>
> lra:
Hi Dave,
thanks for having a look. I'll rebase the change and resend it with the DCO
sign-off.
Best
Lucas
-Original Message-
From: David Malcolm
Sent: Tuesday, 28 January 2025 23:36
To: Bader, Lucas ; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] get source line for diagnostic from prep
On 1/27/25 6:23 PM, Jakub Jelinek wrote:
Hi!
This is basically Marek's PR114479 r14-9759 __is_array fix applied to
__is_bounded_array as well. Similarly to that trait, when not using
the builtin it returned false for zero sized arrays but when using
the builtin it returns true.
Fixed thusly, b
On 2025-01-28 21:01, Siddhesh Poyarekar wrote:
However, the previous test XFAILed the test for all PowerPC compiles
and your new one only XFAILs it for IBM128. That allows our two other
long double options to not be XFAILed. IEEE128 which is actually
expected
to PASS and --without-long-double
> From: Richard Biener
> Sent: Tuesday, January 28, 2025 4:41 PM
>
> >On Mon, Jan 27, 2025 at 3:54 PM Jiang, Haochen
> >wrote:
> > -mno-evex512 will do nothing with AVX10 related options. It will only
> > apply on -mavx512xxx options.
> >
> > In GCC currently, take AVX10.2 as example, we have th
On 1/28/25 8:04 PM, Siddhesh Poyarekar wrote:
> ...do you think this would be better off being called
> ppc_not_well_defined_denormals
> or something like that?
It's better than ppc_default_long_double_not_ieee! :-)
Peter
On 2025-01-28 20:57, Peter Bergner wrote:
On 1/28/25 4:51 PM, Siddhesh Poyarekar wrote:
So the reason why I didn't go the __LONG_DOUBLE_IEEE128__ route because
the check would then have to be something like:
powerpc*-*-* && ! ppc_default_long_double_ieee
Ah, that makes sense.
-! { dg-d
On 1/28/25 4:51 PM, Siddhesh Poyarekar wrote:
> So the reason why I didn't go the __LONG_DOUBLE_IEEE128__ route because
> the check would then have to be something like:
>
> powerpc*-*-* && ! ppc_default_long_double_ieee
Ah, that makes sense.
> -! { dg-do run { xfail powerpc*-*-* } }
> +! { dg
On 1/28/25 12:49 PM, Harald Anlauf wrote:
Dear all,
the attached simple and obvious patch fixes an issue found when running
a UBSAN instrumented compiler on a recent testcase, see PR. Also
verified when running f951 under gdb on that testcase.
I intend to commit within the next 24 hours unless
On 1/28/25 1:33 PM, Harald Anlauf wrote:
Jerry,
while I haven't read your actual patch yet, I think the testcase
is slightly incorrect. In fact, Intel, NAG, Nvidia and AMD flang
disagree with it.
I also installed flang and noticed this. I also received a auto patch
test on ARM that causes me
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_default_long_doub
On 2025-01-28 17:12, Peter Bergner wrote:
On 1/28/25 11:43 AM, Siddhesh Poyarekar wrote:
+return [check_runtime_nocache ppc_default_long_double_ibm {
+ ! Fortran
+ program default_long_double_ibm
+integer, parameter :: kl = selected_real_kind (precision (0.0_8) + 1)
+
On Mon, 2019-12-16 at 11:18 +, Bader, Lucas wrote:
> Hello,
Hi Lucas.
Thanks for the patch, and sorry for not seeing this patch before and
thus the long delay in reviewing it.
I started reviewing this and have various comments (mostly about
introducing subroutines to simplify the logic), but
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
cxx_eval_vec_init_1 was doing the wrong thing for an array of
self-referential class type; just evaluating the TARGET_EXPR initializer
creates a new object that refers to the TARGET_EXPR_SLOT, if we want it to
refer properly to the initializ
On 1/28/25 11:43 AM, Siddhesh Poyarekar wrote:
> +return [check_runtime_nocache ppc_default_long_double_ibm {
> + ! Fortran
> + program default_long_double_ibm
> +integer, parameter :: kl = selected_real_kind (precision (0.0_8) + 1)
> +if (precision (0.0_kl) /= 31) the
Jerry,
while I haven't read your actual patch yet, I think the testcase
is slightly incorrect. In fact, Intel, NAG, Nvidia and AMD flang
disagree with it.
Adding the following lines before the check with the STOP statement:
write(*,'(a)') output1
write(*,'(a)') output2
write (*, fmt1) 'RADIX',
Thanks for working on this!
On 1/28/25 12:11 PM, Surya Kumari Jangala wrote:
> + FOR_ALL_BB_FN (bb, cfun) {
{ should be on the next line.
> +FOR_BB_INSNS (bb, insn) {
Likewise.
> + pat_code = GET_CODE (PATTERN (insn));
> + if (pat_code == ASM_INPUT || pat_code == USE || pat
Dear all,
the attached simple and obvious patch fixes an issue found when running
a UBSAN instrumented compiler on a recent testcase, see PR. Also
verified when running f951 under gdb on that testcase.
I intend to commit within the next 24 hours unless there are comments.
Regtested on x86_64-p
Thanks for having a look Jeff. Would be great to hear your thoughts on this
patch David.
Best
Lucas
> On 18. Jan 2025, at 17:41, Jeff Law wrote:
>
>
>
>> On 1/3/25 7:27 AM, Bader, Lucas wrote:
>> Hello and Happy New Year,
>> as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79106 is still open
Hi,
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.
Regards
Surya
lra: initialize allocated_hard_reg_p[] for hard regs referenced in RTL
[PR118533]
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_default_long_doub
Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685
This ensures that gcc uses its own crt objects for static linking.
Otherwise, it could mix the base system's crtbeginT.o with libgcc's
crtend.o, leading to possible segfaults.
Signed-off-by: Dimitry Andric
---
libgcc/config.host | 2 +-
1
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
When fn returns {extension}, the ArrayRef in the initializer_list is
constructed to point to 'extension', the variable with static storage
duration. The optimization was copying extension's value into a temporary
array and constructing the
The arm-none-eabi port provides some alternative implementations of
__sync_synchronize for different implementations of the architecture.
These can be selected using one of -specs=sync-{none,dmb,cp15dmb}.specs.
These specs fragments fail, however, when LTO is used because they
unconditionally add
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 simplification mechanism assumed bound
> arguments are copy-constructibl
I would also like to ping this patch.
On Thu, Jan 09, 2025 at 04:15:24PM +0100, Michael Matz wrote:
> Hello,
>
> On Wed, 13 Nov 2024, Michael Matz wrote:
>
> > Hello,
> >
> > this is essentially
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651025.html
> >
> > from Kewen in fu
On Mon, 2025-01-27 at 15:26 -0500, David Malcolm wrote:
[...snip..]
> >
>
> I spent some time stepping through this to get clear in my mind how
> the
> new algorithm works. FWIW I found the patch below helpful, to
> clarify
> in dumps about the slot index versus the line number of the slot;
>
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Successful run of analyzer integration tests on x86_64-pc-linux-gnu.
Checked selftests under valgrind on x86_64-pc-linux-gnu.
Pushed to trunk as r15-7255-gb4bd06774ced72.
gcc/ChangeLog:
PR other/118675
* diagnostic-for
On Tue, Jan 28, 2025 at 04:26:11PM +0100, Richard Biener wrote:
> The following fixes a not properly aligned stack temporary created
> during RTL expansion of a MEM_REF that we handle as a BIT_FIELD_REF
> whose base was allocated to a register but which was originally
> aligned to allow a larger lo
The following fixes a not properly aligned stack temporary created
during RTL expansion of a MEM_REF that we handle as a BIT_FIELD_REF
whose base was allocated to a register but which was originally
aligned to allow a larger load not trapping. While probably UB
in C the vectorizer creates aligned
On 1/27/25 4:07 AM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to refactor the helper function of the SAT_*
scalar. The helper function will convert the define_pattern ops
to the xmode reg for the underlying code-gen. This patch add
new parameter for ZERO_EXTEND or SIGN_EX
On Mon, 27 Jan 2025, Jason Merrill wrote:
> On 1/27/25 4:17 PM, Patrick Palka wrote:
> > On Mon, 27 Jan 2025, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk/14?
>
> OK.
Thanks, pushed.
>
> > > +&& (cxx_dialect < cxx23 ||
On 1/27/25 4:07 AM, pan2...@intel.com wrote:
From: Pan Li
This patch would like to refactor the helper function of the SAT_*
scalar. The helper function will convert the define_pattern ops
to the xmode reg for the underlying code-gen. This patch add
new parameter for ZERO_EXTEND or SIGN_EX
On Tue, 28 Jan 2025 at 14:10, Jonathan Wakely wrote:
>
> On Fri, 10 Jan 2025 at 21:29, Jonathan Wakely wrote:
> >
> > + template > + typename _Pred, typename _ValFn>
> > +void
> > +__atomic_wait_address(const _Tp* __addr,
> > + _Pred&& __pred, _ValFn&& __vf
On Fri, 10 Jan 2025 at 21:29, Jonathan Wakely wrote:
>
> This represents a major refactoring of the previous atomic::wait
> and atomic::notify implementation detail. The aim of this change
> is to simplify the implementation details and position the resulting
> implementation so that much of the cu
On Tue, Jan 28, 2025 at 10:05 AM Richard Sandiford
wrote:
>
> vectorizable_slp_permutation_1 has two ways of generating the
> permutations: one that looks for repeating patterns and one that
> calculates the permutation index for every output element individually.
> The former works for VLA and VL
This adds a comment before the workaround, indicating flaky
dependence analysis.
Pushed.
PR tree-optimization/112859
* tree-loop-distribution.cc
(loop_distribution::pg_add_dependence_edges): Add comment.
---
gcc/tree-loop-distribution.cc | 4 +++-
1 file changed, 3 insert
On 27/01/2025 18:07, Ian Lance Taylor wrote:
> Richard Earnshaw writes:
>
>> Older versions of the Arm architecture lack support for __sync
>> operations directly in hardware and require calls into appropriate
>> operating-system hooks. But such hooks obviously don't exist in a
>> freestanding e
The patch in the attachment solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118663
The patch was successfully bootstrapped and tested on ppc64le, x86_64,
aarch64.
commit 01339d29b7663d85eea6145eac2b1ad1da428c11
Author: Vladimir N. Makarov
Date: Tue Jan 28 08:37:33 2025 -0500
[PR11
Hey,
On Tue, 28 Jan 2025, Richard Biener wrote:
> > I think as long as that is the case your proposed changes makes sense.
> > But perhaps it's worth a comment to that effect, i.e. that because
> > dependence analysis is wonky (sometime using zero as unknown) we do these
> > "strange" tests.
The following addresses a bug in tree_could_trap_p leading to
hoisting of a possibly trapping, because of out-of-bound, access.
We only ensured the first accessed byte is within a decl there,
the patch makes sure the whole base of the reference is within it.
This is pessimistic if a handled compone
On Mon, 27 Jan 2025, Michael Matz wrote:
> Hello,
>
> On Thu, 23 Jan 2025, Richard Biener wrote:
>
> > When we get a zero distance vector we still have to check for the
> > situation of a common inner loop with zero distance. But we can
> > still allow a zero distance for the loop we distribute
On Tue, 28 Jan 2025, Martin Jambor wrote:
> Hi,
>
> On Tue, Jan 28 2025, Richard Biener wrote:
> > On Mon, 27 Jan 2025, Martin Jambor wrote:
> >
> >> Hi,
> >>
> >> Zhendong Su and Michal Jireš found out that our gimple DSE pass can,
> >> under fairly specific conditions, remove a noreturn call w
Trying to compile libcc1 plugin in native RISC-V GCC build on X86
I bumped into the problem that gcc_cv_objdump variable
was not defined in libcc1/configure, because it has definition
only in gcc/configure.ac.
In my case, it leads to problem that -rdynamic check is failed
and it disables libcc1 bu
Hi!
On 2025-01-14T15:03:20+0100, Tobias Burnus wrote:
> Thomas Schwinge wrote:
>> On 2021-11-06T00:51:59+0800, Chung-Lin Tang wrote:
>>> On 2021/6/24 11:55 PM, Jakub Jelinek wrote:
On Fri, May 14, 2021 at 09:20:25PM +0800, Chung-Lin Tang wrote:
> + OMP_CLAUSE_MAP_IMPLICIT_P (clause
Hi,
On Tue, Jan 28 2025, Richard Biener wrote:
> On Mon, 27 Jan 2025, Martin Jambor wrote:
>
>> Hi,
>>
>> Zhendong Su and Michal Jireš found out that our gimple DSE pass can,
>> under fairly specific conditions, remove a noreturn call which then
>> leaves behind a "normal" BB with no successor ed
Hi!
On 2023-12-20T14:48:29+, Abid Qadeer wrote:
> From: Hafiz Abid Qadeer
>
> The OpenACC reduction clause on compute construct implies a copy clause
> for each reduction variable [1]. This patch adds tests to check if the
> implied copy is being generated. The check covers various types and
vectorizable_slp_permutation_1 has two ways of generating the
permutations: one that looks for repeating patterns and one that
calculates the permutation index for every output element individually.
The former works for VLA and VLS whereas the latter only works for VLS.
There are two justification
Noticed while working PR117270, where it was a distracting
difference for before-after comparisons.
Tested on aarch64-linux-gnu & pushed as obvious.
Richard
gcc/
* tree-vect-slp.cc (vectorizable_slp_permutation_1): Remove
extra newline from dump message.
---
gcc/tree-vect-slp.c
On Tue, 28 Jan 2025, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled at -Os on x86_64-linux.
> The problem is during make_compound_operation of
> (ashiftrt:SI (ashift:SI (mult:SI (reg:SI 107 [ a_5 ])
> (const_int 3 [0x3]))
> (const_int 31 [0x1f]))
> (c
On Mon, Jan 27, 2025 at 9:59 PM David Malcolm wrote:
>
> On Sat, 2025-01-25 at 23:31 -0800, Andi Kleen wrote:
> > From: Andi Kleen
> >
> > This is the hot function in input.cc
> >
> > The vectorizer can vectorize it now, but in a generic cpu O2 x86
> > build it isn't.
> > Add a automatic target c
On Mon, 27 Jan 2025, Martin Jambor wrote:
> Hi,
>
> Zhendong Su and Michal Jireš found out that our gimple DSE pass can,
> under fairly specific conditions, remove a noreturn call which then
> leaves behind a "normal" BB with no successor edges which following
> passes do not expect. This patch
On Mon, Jan 27, 2025 at 3:54 PM Jiang, Haochen wrote:
>
> > From: Richard Biener
> > Sent: Monday, January 27, 2025 5:09 PM
> >
> > On Mon, Jan 27, 2025 at 8:30 AM Haochen Jiang
> > wrote:
> > >
> > > Hi all,
> > >
> > > AVX10 has been published for one and half year and we have got many
> > > f
> Nit, can you move this check in the caller riscv_emit_mode_set () which
> already
> checks similarly for VXRM (unless there's a corner case.
Sure, I will send v2 after gcc-16 open.
Pan
-Original Message-
From: Vineet Gupta
Sent: Tuesday, January 28, 2025 11:01 AM
To: Li, Pan2 ; gcc-
55 matches
Mail list logo
