The AArch64 FEAT_LUT extension is optional from Armv9.2-a and mandatory
from Armv9.5-a. This extension introduces instructions for lookup table
read with 2-bit indices.
This patch adds AdvSIMD LUT intrinsics for LUTI2, supporting table
lookup with 2-bit packed indices. The following intrinsics ar
From: Vladimir Miloserdov
Hi All,
This is a patch series that refactors infrastructure for advsimd
pragma intrinsics and adds LUTI2 AdvSIMD intrinsics.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
The patches need to be committed for me as I don't have commit rights.
Ok for
On Wed, 6 Nov 2024 at 07:20, Torbjörn SVENSSON
wrote:
>
> While the regression was reported on GCC15, I'm sure that same
> regression will be seen on GCC14 when it's tested in the
> arm-linux-gnueabihf configuration.
>
> Ok for trunk and releases/gcc-14?
>
> --
>
> This fixes reported regression a
While the regression was reported on GCC15, I'm sure that same
regression will be seen on GCC14 when it's tested in the
arm-linux-gnueabihf configuration.
Ok for trunk and releases/gcc-14?
--
This fixes reported regression at
https://linaro.atlassian.net/browse/GNU-1407.
gcc/testsuite/ChangeLog
Hi Harald,
Yes indeed about proc_ptr_56.f90 :-( That was a slip that occurred in the
preparation of the patch for the list. I will indeed make proc_ptr_54.f90
compile-only for the time being. The latter was not elided from my platform
for any level of optimization for the simple reason that system
Jan Hubicka writes:
> [...]
> The attached patch adds code to track size of allocated block and
> disable the transformation when the block is not known to be smaller
> then half of the address space by ranger. We can do the runtime check
> discussed on the top of that.
>
> I have bootstrap®ress
From: xuli
This patch adds testcase for form1, as shown below:
T __attribute__((noinline)) \
sat_s_add_imm_##T##_fmt_1##_##INDEX (T x) \
{\
T sum = (UT)x + (UT)IMM; \
return (x ^ IMM) < 0
From: xuli
This patch would like to support .SAT_ADD when one of the op
is singed IMM.
Form1:
T __attribute__((noinline)) \
sat_s_add_imm_##T##_fmt_1##_##INDEX (T x) \
{\
T sum = (UT)x + (UT)IMM; \
r
On Wed, Nov 6, 2024 at 10:35 AM Hu, Lin1 wrote:
>
> Hi, all
>
> This patch aims to add OPTION_MASK_ISA2_EVEX512 for all avx512 512-bits
> builtin functions, raise error when these builtin functions are used with
> -mno-evex512.
>
> Bootstrapped and Regtested on x86-64-pc-linux-gnu, OK for trunk an
Hi, all
This patch aims to add OPTION_MASK_ISA2_EVEX512 for all avx512 512-bits
builtin functions, raise error when these builtin functions are used with
-mno-evex512.
Bootstrapped and Regtested on x86-64-pc-linux-gnu, OK for trunk and backport to
GCC14?
BRs,
Lin
gcc/ChangeLog:
PR targ
On Tue, Nov 5, 2024 at 5:50 PM Mayshao-oc wrote:
>
>
> >
> >
> > On Tue, Nov 5, 2024 at 2:34 PM Liu, Hongtao wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: MayShao-oc
> > > > Sent: Tuesday, November 5, 2024 11:20 AM
> > > > To: gcc-patches@gcc.gnu.org; hubi...@ucw.cz;
On Wed, Nov 6, 2024 at 8:19 AM H.J. Lu wrote:
>
> Since x32 uses (%edi), instead of (%rdi), also scan (%edi).
>
> * gcc.target/i386/apx-ndd.c: Also scan (%edi).
Ok.
>
> --
> H.J.
--
BR,
Hongtao
On Wed, Nov 6, 2024 at 8:21 AM H.J. Lu wrote:
>
> Since x32 uses (%reg32), instead of (%r.x), also scan (%e.x).
>
> * gcc.target/i386/avx10_2-512-movrs-1.c: Also scan (%e.x).
> * gcc.target/i386/avx10_2-movrs-1.c: Likewise.
> * gcc.target/i386/movrs-1.c: Likewise.
Ok.
>
> --
> H.J.
--
BR,
Hong
On Tue, Oct 22, 2024 at 4:39 AM Richard Biener
wrote:
>
> On Mon, Oct 21, 2024 at 6:04 PM Andrew Pinski wrote:
> >
> > On Mon, Oct 21, 2024 at 3:41 AM Richard Biener
> > wrote:
> > >
> > > On Thu, Oct 17, 2024 at 4:43 AM Andrew Pinski
> > > wrote:
> > > >
> > > > After fixing loop-im to do the
Since x32 uses (%reg32), instead of (%r.x), also scan (%e.x).
* gcc.target/i386/avx10_2-512-movrs-1.c: Also scan (%e.x).
* gcc.target/i386/avx10_2-movrs-1.c: Likewise.
* gcc.target/i386/movrs-1.c: Likewise.
--
H.J.
Since x32 uses (%edi), instead of (%rdi), also scan (%edi).
* gcc.target/i386/apx-ndd.c: Also scan (%edi).
--
H.J.
From 318afe290b7f4422fea168214438ca821d87de40 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Wed, 6 Nov 2024 07:44:24 +0800
Subject: [PATCH] gcc.target/i386/apx-ndd.c: Also scan (%
PR fortran/117442 reports a crash on exit of f951 when configured
with --enable-gather-detailed-mem-stats.
The crash happens if any diagnostics were ever buffered into
error_buffer. The root cause is that error_buffer is statically
allocated and thus has a non-trivial destructor called at exit.
I
On Tue, Nov 05, 2024 at 04:26:13PM -0600, Peter Bergner wrote:
> On 11/5/24 1:16 PM, Segher Boessenkool wrote:
> > Would it not have been better to not use -O0 at all here? -O0 is
> > not realistic if you expect any reasonable optimisation!
>
> That's what I first attempted, using -O2, but the te
On 11/5/24 1:16 PM, Segher Boessenkool wrote:
> Would it not have been better to not use -O0 at all here? -O0 is
> not realistic if you expect any reasonable optimisation!
That's what I first attempted, using -O2, but the test case still FAILed
because we optimized the code too much and failed th
This is broken out of predecessor promotion patch so that debugging can
proceed during stage1 restrictions.
Signed-off-by: Vineet Gupta
---
gcc/haifa-sched.cc | 10 +-
gcc/sched-rgn.cc | 14 --
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/gcc/haifa-sched.
On Tue, Nov 5, 2024 at 5:27 PM Richard Biener
wrote:
>
> On Tue, Nov 5, 2024 at 10:09 AM Richard Biener
> wrote:
> >
> > On Tue, Nov 5, 2024 at 5:23 AM Jeff Law wrote:
> > >
> > >
> > >
> > > On 11/4/24 8:13 PM, H.J. Lu wrote:
> > > > On Tue, Nov 5, 2024 at 10:57 AM Jeff Law wrote:
> > > >>
> >
Just a small coment fix, the `(` was in the wrong location,
making it look it was transforming into `(X - X) != 0`
rather than `X - (X != 0)`.
Pushed as obvious after a quick build for x86_64-linux-gnu.
gcc/ChangeLog:
* match.pd (X != 0 ? X + ~0 : 0): Fix comment.
Signed-off-by: Andrew
On 10/17/24 1:10 PM, Patrick Palka wrote:
On Thu, 17 Oct 2024, Patrick Palka wrote:
On Tue, 15 Oct 2024, Patrick Palka wrote:
On Tue, 15 Oct 2024, Patrick Palka wrote:
According to [temp.param]/11, the constraint on an auto NTTP is an
associated constraint and so should be checked as part o
Changes since v1:
- Changed from arm_neon to arm_arch_v7a for the required effective target.
Ok for trunk and releases/gcc-14?
--
Force armv7-a as the tests require a neon compatible architecture.
gcc/testsuite/ChangeLog:
* gcc.target/arm/attr-neon-builtin-fail.c: Use effective-target
On 10/23/24 4:30 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
This tree code was added as part of the initial Concepts TS
implementation to support type-constraints introducing any kind
of template-parameter, not just type tem
On 10/15/24 12:45 AM, Patrick Palka wrote:
This patch further cleans up the concepts code following the removal of
Concepts TS support:
* concept-ids are now the only kind of "concept check", so we can
simplify some code accordingly. In particular resolve_concept_check
seems like a
changes since v1
* Changed target hook to --param
* squash addon patch for RISC-V opting-in, testcase here
* updated changelog with latest perf numbers
---
sched1 computes ECC (Excess Change Cost) for each insn, which represents
the register pressure attributed to the insn.
Currently the pre
Based on how these functions are used in test cases, I think it's correct
to require 16-bit float support in both functions.
Without this change, the checks passes for armv8-m and armv8.1-m, but the
test cases that uses them fails due to the incorrect -mfpu option.
Ok for trunk and releases/gcc-1
Sorry, still haven't found time to look at the patch properly
(hopefully after stage 1 closes, if not before), but:
Jeff Law writes:
> [...]
> On 10/31/24 1:35 PM, Vineet Gupta wrote:
>>> And if it doesn't strictly need to be a valid schedule are we giving an
>>> overly-optimistic view of the bes
On 2024-11-05 20:08, Richard Earnshaw (lists) wrote:
On 05/11/2024 18:26, Torbjörn SVENSSON wrote:
Changes since v1:
- Force arm_arch_v7a as a baseline for pr68620.c.
Ok for trunk and releases/gcc-14?
--
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr68620.c: Use effective-target ar
> On Nov 5, 2024, at 14:29, David Malcolm wrote:
>
> On Tue, 2024-11-05 at 16:31 +, Qing Zhao wrote:
>> During array out-of-bound checking or -Wstringop-* warning checking,
>> the
>> "move_history" that was attached to the gimple statement is used to
>> form
>> a sequence of diagnostic eve
On 11/4/24 16:45, Jeff Law wrote:
> On 10/31/24 1:35 PM, Vineet Gupta wrote:
An INSN can have multiple dependencies/predecessor nodes, some of them
being true dependency REG_DEP_TRUE meaning the predecessor register output
is a must have for the INSN to be scheduled.
e.g.
I
Hi Folks.
> On 5 Nov 2024, at 19:23, Harald Anlauf wrote:
>
> Hi Paul,
>
> Am 05.11.24 um 16:24 schrieb Paul Richard Thomas:
>> Hi All,
>>
>> There is not much to say about the attached patch other than it is minimal
>> :-) The testcases are probably a bit more than is strictly needed since th
On Tue, 2024-11-05 at 16:31 +, Qing Zhao wrote:
> During array out-of-bound checking or -Wstringop-* warning checking,
> the
> "move_history" that was attached to the gimple statement is used to
> form
> a sequence of diagnostic events that are added to the corresponding
> rich
> location to be
On 10/22/24 1:54 PM, Patrick Palka wrote:
On Tue, 9 Jan 2024, Jason Merrill wrote:
On 1/5/24 15:01, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?
-- >8 --
Here during default template argument substitution we wrongly consider
the (substi
Hi Paul,
Am 05.11.24 um 16:24 schrieb Paul Richard Thomas:
Hi All,
There is not much to say about the attached patch other than it is minimal
:-) The testcases are probably a bit more than is strictly needed since the
interface tests (proc_ptr_55.f90) are already tested elsewhere. However, it
i
On 11/5/24 3:59 AM, Jakub Jelinek wrote:
On Tue, Nov 05, 2024 at 09:32:23AM +0100, Richard Biener wrote:
I think there's the possibility to get back the memory on the GIMPLE
side but I wouldn't make
this a requirement for this patch.
Sure. I'll I'm saying is that we should make some effort to
On Tue, Nov 05, 2024 at 10:47:28AM -0600, Peter Bergner wrote:
> The test safe-indirect-jump-3.c FAILs on powerpc64le-linux with the change
> in jump table generation behavior with commit r15-4756-g06bc3a734e8890,
> since it is compiled without optimization and expects jump tables to be
> generated
On 05/11/2024 18:26, Torbjörn SVENSSON wrote:
> Changes since v1:
>
> - Force arm_arch_v7a as a baseline for pr68620.c.
>
> Ok for trunk and releases/gcc-14?
>
> --
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/arm/pr68620.c: Use effective-target arm_neon.
> * gcc.target/arm/pr7804
Hi!
The following patch on top of the PR41045 toplevel extended asm patch
allows marking inline asms (both toplevel and function-local, admittedly
it is less useful for the latter, so if you want, I can add restrictions)
as defining symbols, either functions or variables.
As most remaining constr
On 2024-11-05 14:19, Christophe Lyon wrote:
Hi,
On Sat, 19 Oct 2024 at 19:20, Torbjörn SVENSSON
wrote:
With r15-1618-g9f168b412f4, I get the following asm generated for the test case:
.align 1
.align 2
.global test5
.syntax unified
.thumb
On 05/11/24 17:50 +, Jonathan Wakely wrote:
On 28/10/24 21:51 +0100, François Dumont wrote:
On 24/10/2024 21:49, Jonathan Wakely wrote:
On Thu, 24 Oct 2024 at 19:43, François Dumont wrote:
Committed as trivial the attached patch.
libstdc++: Fix test broken when using COW std::strin
On Tue, Nov 05, 2024 at 07:24:42PM +0100, Uros Bizjak wrote:
> On Tue, Nov 5, 2024 at 7:12 PM Jakub Jelinek wrote:
> >
> > On Tue, Nov 05, 2024 at 06:55:33PM +0100, Uros Bizjak wrote:
> > > The difference between redzoned and non-redzoned code is *two*
> > > instructions that decrease and increase
Changes since v1:
- Force arm_arch_v7a as a baseline for pr68620.c.
Ok for trunk and releases/gcc-14?
--
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr68620.c: Use effective-target arm_neon.
* gcc.target/arm/pr78041.c: Use effective-target arm_arch_v7a.
Signed-off-by: Torbjörn S
On Tue, Nov 5, 2024 at 7:12 PM Jakub Jelinek wrote:
>
> On Tue, Nov 05, 2024 at 06:55:33PM +0100, Uros Bizjak wrote:
> > The difference between redzoned and non-redzoned code is *two*
> > instructions that decrease and increase stack pointer, which I think
> > is an acceptable compromise between c
On 2024-11-05 13:54, Richard Earnshaw (lists) wrote:
On 05/11/2024 07:49, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
The test case assumes that -mfp16-format=alternative is accepted for the
target, but not all targets support this flag. One such target is
Cortex-M85 that
On Tue, Nov 05, 2024 at 06:55:33PM +0100, Uros Bizjak wrote:
> The difference between redzoned and non-redzoned code is *two*
> instructions that decrease and increase stack pointer, which I think
> is an acceptable compromise between correctness and performance. Also
It is not. Because this pric
On Tue, Nov 05, 2024 at 06:41:24PM +0100, Richard Biener wrote:
> I don’t think it will matter in practice?
IMHO it will. Many projects have many inline asms, e.g. glibc several
hundreds of them, none of them need this treatment, many are used in leaf
functions, including really small functions w
On 2024-11-05 16:37, Richard Earnshaw wrote:
On 05/11/2024 15:21, Richard Earnshaw (lists) wrote:
On 04/11/2024 20:34, Torbjorn SVENSSON wrote:
On 2024-11-04 17:03, Richard Earnshaw (lists) wrote:
On 31/10/2024 18:26, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Tests
On Tue, Nov 5, 2024 at 6:08 PM Jakub Jelinek wrote:
>
> On Tue, Nov 05, 2024 at 05:56:09PM +0100, Uros Bizjak wrote:
> > > Maybe never make functions having any volatile asm() "leaf"? Thus
> > > require 'volatile' to be present - aka the asm has side-effects that
> > > are not fully encoded in th
On 28/10/24 21:51 +0100, François Dumont wrote:
On 24/10/2024 21:49, Jonathan Wakely wrote:
On Thu, 24 Oct 2024 at 19:43, François Dumont wrote:
Committed as trivial the attached patch.
libstdc++: Fix test broken when using COW std::string
libstdc++-v3/ChangeLog:
*
> Hi,
>
> I believe that the current function ipa_range_set_and_normalize lacks
> a check that a base of an ADDR_EXPR lacks a test whether the base
> really cannot be NULL, so this patch adds it. Moreover, I never liked
> the name as I do not think it makes the value of ranges any more
> normal b
On Tue, 5 Nov 2024, Jakub Jelinek wrote:
> Anyway, IMHO just checking errno because you rely on malloc must have failed
> in certain case is obscure. You'd better at least that that it actually
> failed.
I know, but obscurity or weirdness should be irrelevant when we are debating
correctness.
> Am 05.11.2024 um 17:39 schrieb Andrew Pinski :
>
> Since r13-707-g68e0063397ba82, COND_EXPR/VEC_COND_EXPR has not
> allowed a comparison as the first operand but the gimple front-end
> was not updated for this change and you would error out later on.
> An assert was added with r15-4791-gb600
> Am 05.11.2024 um 18:08 schrieb Jakub Jelinek :
>
> On Tue, Nov 05, 2024 at 05:56:09PM +0100, Uros Bizjak wrote:
>>> Maybe never make functions having any volatile asm() "leaf"? Thus
>>> require 'volatile' to be present - aka the asm has side-effects that
>>> are not fully encoded in the con
>
>
> On Tue, Nov 05 2024, Jan Hubicka wrote:
> >> 2024-11-04 Martin Jambor
> >>
> >>* ipa-cp.cc (ipa_check_const_jf_vr): New function.
> >>(ipa_value_range_from_jfunc): Call it when checking and when
> >>dealing with a constant jump function.
> >>(propagate_vr_across_jump_fun
> 2024-11-04 Martin Jambor
>
> * ipa-cp.cc (ipa_check_const_jf_vr): New function.
> (ipa_value_range_from_jfunc): Call it when checking and when
> dealing with a constant jump function.
> (propagate_vr_across_jump_function): Likewise.
OK
> + /* TODO: Non-nullness is
On Tue, Nov 05 2024, Jan Hubicka wrote:
>> 2024-11-04 Martin Jambor
>>
>> * ipa-cp.cc (ipa_check_const_jf_vr): New function.
>> (ipa_value_range_from_jfunc): Call it when checking and when
>> dealing with a constant jump function.
>> (propagate_vr_across_jump_function): L
> On Tue, Nov 05, 2024 at 04:47:20PM +0100, Jan Hubicka wrote:
> > > POSIX semantics for malloc involve errno.
> >
> > So if I can check errno to see if malloc failed, I guess even our
> > current behaviour of optimizing away paired malloc+free calls provided
> > that the return value is unused is
On Tue, Nov 05, 2024 at 08:15:04PM +0300, Alexander Monakov wrote:
>
> On Tue, 5 Nov 2024, Jakub Jelinek wrote:
>
> > On Tue, Nov 05, 2024 at 04:47:20PM +0100, Jan Hubicka wrote:
> > > > POSIX semantics for malloc involve errno.
> > >
> > > So if I can check errno to see if malloc failed, I gues
On Tue, 5 Nov 2024, Jakub Jelinek wrote:
> On Tue, Nov 05, 2024 at 04:47:20PM +0100, Jan Hubicka wrote:
> > > POSIX semantics for malloc involve errno.
> >
> > So if I can check errno to see if malloc failed, I guess even our
> > current behaviour of optimizing away paired malloc+free calls pro
We are working on a patch to improve the codegen for the following test case:
uint64x2_t foo (uint64x2_t r) {
uint32x4_t a = vreinterpretq_u32_u64 (r);
uint32_t t;
t = a[0]; a[0] = a[1]; a[1] = t;
t = a[2]; a[2] = a[3]; a[3] = t;
return vreinterpretq_u64_u32 (a);
}
that GCC curr
On Tue, 22 Oct 2024, Patrick Palka wrote:
> On Tue, 9 Jan 2024, Jason Merrill wrote:
>
> > On 1/5/24 15:01, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> > > look OK for trunk?
> > >
> > > -- >8 --
> > >
> > > Here during default template argument sub
On Tue, Nov 05, 2024 at 05:56:09PM +0100, Uros Bizjak wrote:
> > Maybe never make functions having any volatile asm() "leaf"? Thus
> > require 'volatile' to be present - aka the asm has side-effects that
> > are not fully encoded in the constraints.
>
> I think this would work!
>
> Although this
On Tue, Nov 05, 2024 at 09:47:17AM +0100, Richard Biener wrote:
> On Tue, Nov 5, 2024 at 2:02 AM Jason Merrill wrote:
> >
> > On 10/31/24 4:40 PM, Andi Kleen wrote:
> > > From: Andi Kleen
> > >
> > > autofdo looks up inline stacks and tries to match them with the profile
> > > data using their sy
On Fri, 25 Oct 2024, Patrick Palka wrote:
> On Wed, 23 Oct 2024, Patrick Palka wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > This tree code was added as part of the initial Concepts TS
> > implementation to support type
> Hi,
>
> when inlining (during the analysis phase) a call graph edge, we update
> all pass-through jump functions corresponding to edges going out of
> the newly inlined function to be relative to the function into which
> we are inlining or to expose the information originally captured for
> the
On Thu, 17 Oct 2024, Patrick Palka wrote:
> On Thu, 17 Oct 2024, Patrick Palka wrote:
>
> > On Tue, 15 Oct 2024, Patrick Palka wrote:
> >
> > > On Tue, 15 Oct 2024, Patrick Palka wrote:
> > >
> > > > According to [temp.param]/11, the constraint on an auto NTTP is an
> > > > associated constrain
On Tue, 15 Oct 2024, Patrick Palka wrote:
> This patch further cleans up the concepts code following the removal of
> Concepts TS support:
>
> * concept-ids are now the only kind of "concept check", so we can
> simplify some code accordingly. In particular resolve_concept_check
> seems
> gcc/ChangeLog:
>
> 2024-11-01 Martin Jambor
>
> * ipa-prop.cc (skip_a_conversion_op): New function.
> (ipa_compute_jump_functions_for_edge): Use it.
>
> gcc/testsuite/ChangeLog:
>
> 2024-11-01 Martin Jambor
>
> * gcc.dg/ipa/vrp9.c: New test.
> ---
> gcc/ipa-prop.cc
Forwarding to the correct ML...
> Begin forwarded message:
>
> From: Kyrylo Tkachov via Gcc
> Subject: [PATCH] PR target/117449: Restrict vector rotate match and split to
> pre-reload
> Date: 5 November 2024 at 17:57:40 GMT+1
> To: gcc mailing list
> Reply-To: Kyrylo Tkachov
>
> Hi all,
>
> Th
On Tue, Nov 5, 2024 at 3:49 PM Richard Biener
wrote:
>
> On Tue, Nov 5, 2024 at 2:47 PM Uros Bizjak wrote:
> >
> > On Tue, Nov 5, 2024 at 12:19 PM Jakub Jelinek wrote:
> > >
> > > On Tue, Nov 05, 2024 at 12:00:24PM +0100, Uros Bizjak wrote:
> > > > On Tue, Nov 5, 2024 at 11:43 AM Andreas Schwab
The test safe-indirect-jump-3.c FAILs on powerpc64le-linux with the change
in jump table generation behavior with commit r15-4756-g06bc3a734e8890,
since it is compiled without optimization and expects jump tables to be
generated. Add an explicit -fjump-tables to dg-options to get the old
behavior
On Tue, Nov 05, 2024 at 04:47:20PM +0100, Jan Hubicka wrote:
> > POSIX semantics for malloc involve errno.
>
> So if I can check errno to see if malloc failed, I guess even our
> current behaviour of optimizing away paired malloc+free calls provided
> that the return value is unused is problematic
Since r13-707-g68e0063397ba82, COND_EXPR/VEC_COND_EXPR has not
allowed a comparison as the first operand but the gimple front-end
was not updated for this change and you would error out later on.
An assert was added with r15-4791-gb60031e8f9f8fe which meant an ICE
would happen from the gimple FE.
T
During array out-of-bound checking or -Wstringop-* warning checking, the
"move_history" that was attached to the gimple statement is used to form
a sequence of diagnostic events that are added to the corresponding rich
location to be used to report the warning message.
PR tree-optimization
Add debugging for move history.
PR tree-optimization/109071
PR tree-optimization/85788
PR tree-optimization/88771
PR tree-optimization/106762
PR tree-optimization/108770
PR tree-optimization/115274
PR tree-optimization/117179
gcc/ChangeLog:
Control this with a new option -fdiagnostics-details.
$ cat t.c
extern void warn(void);
static inline void assign(int val, int *regs, int *index)
{
if (*index >= 4)
warn();
*regs = val;
}
struct nums {int vals[4];};
void sparx5_set (int *ptr, struct nums *sg, int index)
{
int *val = &sg
Hi,
This is the 4th version of the patch for fixing PR109071.
Compared to the 3nd version:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666870.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666872.html
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666871.html
The
Ping 4
On 10/28/24 4:29 PM, Carl Love wrote:
Ping 3
On 10/17/24 1:31 PM, Carl Love wrote:
Ping 2
On 10/9/24 7:44 AM, Carl Love wrote:
Ping
On 10/1/24 8:12 AM, Carl Love wrote:
GCC maintainers:
The following version 2 of a series of patches for PowerPC removes
some built-ins that a
Ping 4
On 10/28/24 4:28 PM, Carl Love wrote:
Ping 3
On 10/17/24 1:31 PM, Carl Love wrote:
Ping 2
On 10/9/24 7:43 AM, Carl Love wrote:
Ping, FYI this is a fairly simple fix to a testcase.
On 10/3/24 8:11 AM, Carl Love wrote:
GCC maintainers:
The builtins-1-10-runnable.c has the debugg
> > 2024-11-01 Martin Jambor
> >
> > * ipa-prop.cc (ipa_compute_jump_functions_for_edge): When creating
> > value-range jump functions from pointer type constant zero, do so
> > as if it was not a pointer.
> > ---
> > gcc/ipa-prop.cc | 3 ++-
> > 1 file changed, 2 insert
Tested x86_64-pc-linux-gnu, applying to trunk and 14.
-- 8< --
We've accidentally accepted this forever (at least as far back as 4.7), but
it's always been ill-formed; this was PR59465. And we didn't accept it for
scalar types. But rather than switch to a hard error for this code, let's
give a
OK.
On 11/3/24 5:22 PM, Lewis Hyatt wrote:
The modules implementation is necessarily sensitive to the internal workings
of class line_map, and so it needed changes in order to handle a 64-bit
location_t. The changes mostly boil down to supporting that in the debug
dumping routines (which is acco
> Bootstrapped and tested on x86_64-linux, the whole patch series has
> additionally passed LTO and profiled-LTO bootstrap on the same platform
> and a bootstrap and testsuite on ppc64-linux. Aarch64-linux bootstrap
> and testing is in progress. Because we have agreed with Honza this is
> necessa
> Hi,
>
> currently ipa_value_range_from_jfunc and
> propagate_vr_across_jump_function contain similar but not same code
> for dealing with pass-through jump functions. This patch puts these
> common bits into one function which can also handle comparison
> operations.
>
> Bootstrapped and teste
>
> On Sat, 2 Nov 2024, Sam James wrote:
>
> > Some references to feed discussion which I had in my logs from
> > discussing it with someone the other week after that interaction we
> > had with alanc:
> > * https://github.com/llvm/llvm-project/issues/28790 (not very
> > insightful, other than to
On 05/11/2024 15:21, Richard Earnshaw (lists) wrote:
> On 04/11/2024 20:34, Torbjorn SVENSSON wrote:
>>
>>
>> On 2024-11-04 17:03, Richard Earnshaw (lists) wrote:
>>> On 31/10/2024 18:26, Torbjörn SVENSSON wrote:
Ok for trunk and releases/gcc-14?
--
Tests uses neon, so add
On 11/3/24 5:22 PM, Lewis Hyatt wrote:
CODE_CONTAINS_STRUCT () currently reports that a TRAIT_EXPR contains a
TS_EXP struct, but it does not actually start with a TS_EXP as an initial
sequence. In modules.cc, when we stream out a tree, we explicitly check for the
TS_EXP case and call note_locatio
Hi All,
There is not much to say about the attached patch other than it is minimal
:-) The testcases are probably a bit more than is strictly needed since the
interface tests (proc_ptr_55.f90) are already tested elsewhere. However, it
is as well to check in this context.
OK for mainline and 14-br
On 04/11/2024 20:34, Torbjorn SVENSSON wrote:
>
>
> On 2024-11-04 17:03, Richard Earnshaw (lists) wrote:
>> On 31/10/2024 18:26, Torbjörn SVENSSON wrote:
>>> Ok for trunk and releases/gcc-14?
>>>
>>> --
>>>
>>> Tests uses neon, so add effective-target arm_neon.
>>>
>>> gcc/testsuite/ChangeLog:
>
On 04/11/2024 20:14, Torbjorn SVENSSON wrote:
>
>
> On 2024-11-04 16:47, Richard Earnshaw (lists) wrote:
>> On 20/10/2024 16:51, Torbjörn SVENSSON wrote:
>>> Ok for trunk and releases/gcc-14?
>>>
>>> --
>>>
>>> The tests assume that a neon fpu is avialable and fails it not, so
>>> explicitly req
On Tue, Nov 5, 2024 at 2:47 PM Uros Bizjak wrote:
>
> On Tue, Nov 5, 2024 at 12:19 PM Jakub Jelinek wrote:
> >
> > On Tue, Nov 05, 2024 at 12:00:24PM +0100, Uros Bizjak wrote:
> > > On Tue, Nov 5, 2024 at 11:43 AM Andreas Schwab
> > > wrote:
> > > >
> > > > On Nov 05 2024, Uros Bizjak wrote:
>
On Tue, Nov 5, 2024 at 12:12 PM Martin Jambor wrote:
>
> Hi,
>
> the next patch in the series introduces a verifier that prints a
> single jump function when it fails with the function introduced in
> this one. Because it is a verifier, the risk that it would need to e
> reverted are non-zero and
On Tue, Nov 5, 2024 at 12:10 PM Martin Jambor wrote:
>
> Hi,
>
> When looking into cases where we know an actual argument of a call is
> a constant but we don't generate a singleton value-range for the jump
> function, I found out that the special handling of pointer constants
> does not work well
On 11/5/24 03:37, Richard Biener wrote:
On Mon, Nov 4, 2024 at 4:52 PM Andrew MacLeod wrote:
Am 04.11.2024 um 16:32 schrieb Andrew MacLeod :
On 11/4/24 10:27, Richard Biener wrote:
Am 04.11.2024 um 16:01 schrieb Andrew MacLeod :
The invert() range operation is not supported on value
On Tue, Nov 05, 2024 at 02:47:15PM +0100, Uros Bizjak wrote:
> We would have to define a memory clobber that would correspond to
> redzone and attach it to the asm parallel RTX, perhaps:
>
> (clobber (mem:BLK (reg:DI sp)))
That wouldn't represent what is actually clobbered.
That says everything f
Hi all,
Updating this patch to rebase ontop of the new version of the C FMV
patch.
As I mentioned in that series, we are very keen to get ACLE Compliant
FMV support for Aarch64 in for GCC 15. I am aware this is a busy
period for all though.
Regtested on Aarch64, X86
Bootstrapped on aarch64-none-
On Tue, Nov 5, 2024 at 12:19 PM Jakub Jelinek wrote:
>
> On Tue, Nov 05, 2024 at 12:00:24PM +0100, Uros Bizjak wrote:
> > On Tue, Nov 5, 2024 at 11:43 AM Andreas Schwab
> > wrote:
> > >
> > > On Nov 05 2024, Uros Bizjak wrote:
> > >
> > > > But what is the non-deprecated way to communicate the f
The following moves the two virtual operands into the gimple_ops
array, thereby allowing those to be allocated on-demand. In
particular the patch goes the simple route never allocating those
for GIMPLE_UNARY_RHS, GIMPLE_BINARY_RHS or GIMPLE_TERNARY_RHS.
I did not clean up the class hierarchy, I d
1 - 100 of 150 matches
Mail list logo
