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 does support FP16, but not the alternative fo
This test started failing on aarch64 after 0cfc9c95 in 2023 ("Phi
analyzer - Initialize with range instead of a tree.").
The only change visible in the pass dumps prior to thread2 is the upper
bounds of some ranges are reduced from +INF to 7, consistent with the
bitamsk information. After thread2
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 for constant zero pointer values. However, the
code for other typ
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 but rather just
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 fact that SP
> > > changes, and possibly clobbers stack in the asm to the
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 edge that is
Hi,
originally, we did not stream any formal parameter types into WPA and
were generally very conservative when it came to type mismatches in
IPA-CP. Over the time, mismatches that happen in code and blew up in
WPA made us be much more resilient and also stream the types of the
parameters which w
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 because the function can be useful on its
own, this is a special p
Hi,
Because the simplified way of extracting value ranges from functions
does not look at scalar constants (as one of the versions had been
doing before) but instead rely on the value range within the jump
function already capturing the constant, I have added a verifier that
it is indeed so. Afte
Martin Jambor writes:
> +/* If T is an SSA_NAME that is a result of a simple type conversion
> statement,
I think "the result" sounds better than "a result", assuming there is
just one result.
> + return the operand of that conversion, otherwise treturn T. */
s/treturn/return/
Aldy
Hi!
On 11/5/24 12:06, Martin Jambor wrote:
+/* Copy information from SRC_JF to DST_JF which correstpond to call graph edges
+ SRC and DST. */
+
+static void
+ipa_duplicate_jump_function (cgraph_edge *src, cgraph_edge *dst,
+ipa_jump_func *src_jf, ipa_jump_func *dst
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
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 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 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 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
> 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
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
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 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
> 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
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
> > 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
On Tue, Oct 29, 2024 at 07:19:38PM -0700, liuhongt wrote:
> Generate native instruction whenever possible, otherwise use vector
> permutation with odd indices.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ready push to trunk.
>
> gcc/ChangeLog:
>
> * config/i386/i386-exp
From: Pan Li
The phiopt2 pass will also try the gimple_simplify for the form 16
of unsigned integer SAT_ADD. Thus add the testcase to make sure
it will be performed in phiopt2 pass.
The below test suites are passed for this patch:
1. The rv64gcv fully regression tests.
2. The x86 bootstrap test
From: Pan Li
The phiopt2 pass will also try the gimple_simplify for the form 14
of unsigned integer SAT_ADD. Thus add the testcase to make sure
it will be performed in phiopt2 pass.
The below test suites are passed for this patch:
1. The rv64gcv fully regression tests.
2. The x86 bootstrap test
From: Pan Li
The phiopt2 pass will also try the gimple_simplify for the form 12
of unsigned integer SAT_ADD. Thus add the testcase to make sure
it will be performed in phiopt2 pass.
The below test suites are passed for this patch:
1. The rv64gcv fully regression tests.
2. The x86 bootstrap test
From: Pan Li
There are sorts of forms for the unsigned SAT_ADD. Some of them are
complicated while others are cheap. This patch would like to simplify
the complicated form into the cheap ones. For example as below:
>From the form 6 (branch):
SUM = ADD_OVERFLOW (X, Y)
SAT_U_ADD = IMAGPART_
From: Pan Li
The phiopt2 pass will also try the gimple_simplify for the form 15
of unsigned integer SAT_ADD. Thus add the testcase to make sure
it will be performed in phiopt2 pass.
The below test suites are passed for this patch:
1. The rv64gcv fully regression tests.
2. The x86 bootstrap test
On Mon, Nov 4, 2024 at 11:19 PM Jakub Jelinek wrote:
>
> On Mon, Nov 04, 2024 at 10:58:14AM +0100, Richard Biener wrote:
> > > Regarding memory usage implications of this change. It does make a lot of
> > > data structures larger. Here is what it does on x86-64. The base sizes of
> > > some
> > >
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 values
> -Original Message-
> From: Hu, Lin1
> Sent: Tuesday, November 5, 2024 1:34 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: [PATCH v2] i386: Handling exception input of
> __builtin_ia32_prefetch. [PR117416]
>
> Add handler for op3, and the previously st
Committed to trunk.
Thanks,
Di Zhao
> -Original Message-
> From: Jeff Law
> Sent: Monday, September 30, 2024 6:28 AM
> To: Di Zhao OS
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] [tree-optimization/110279] fix testcase pr110279-1.c
>
>
>
> On 5/23/24 3:55 AM, Di Zhao OS wrote
Hi Jason,
On 5 Nov 2024, at 3:30, Jason Merrill wrote:
> On 10/30/24 12:34 PM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 22 Oct 2024, at 17:07, Jason Merrill wrote:
>>
>>> On 10/17/24 10:30 AM, Simon Martin wrote:
Hi,
The issue reported in PR117129 is pretty similar to the one in
>
On Tue, Nov 05, 2024 at 10:42:10AM +0100, Richard Biener wrote:
> > Actually, I think cpp_token isn't that big deal, that should be short-lived
> > unless using huge macros.
> > cp_token in the C++ FE is more important, the FE uses a vector of those
> > and there is one cp_token per token read from
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
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 Nov 05 2024, Uros Bizjak wrote:
> asm volatile ("pushfq; popfq %0" : "=r"(x));
>
> doesn't change SP at any sequence point, doesn't clobber the function
> frame, but the function using it shouldn't create redzone. How to
> communicate this to the compiler?
Saying that SP is changed (when it is
Martin Jambor writes:
> 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.
>
>
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
> .thumb_func
> .type
On 11/5/24 4:13 AM, Simon Martin wrote:
Hi Jason,
On 5 Nov 2024, at 1:23, Jason Merrill wrote:
On 11/4/24 10:19 AM, Simon Martin wrote:
Hi Jason,
On 1 Nov 2024, at 16:31, Jason Merrill wrote:
On 11/1/24 5:07 AM, Simon Martin wrote:
Since r10-3793-g1a37b6d9a7e57c, we ICE upon the following
On Tue, Nov 05, 2024 at 01:43:53PM +0100, Richard Biener wrote:
> 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
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
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:
>
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 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,
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
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
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
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
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
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
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:
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
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
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
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
> 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
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
> 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 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
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
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 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, 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
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, 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
> 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, 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
> 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
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 does support FP16, but not the alternative format.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr
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 avoid the
growth, not just even withou
ping
> -Original Message-
> From: Tamar Christina
> Sent: Monday, October 14, 2024 4:08 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de; j...@ventanamicro.com
> Subject: RE: [PATCH 1/2]middle-end: refactor type to be explicit in
> operand_equal_p [PR114932]
ping
> -Original Message-
> From: Tamar Christina
> Sent: Monday, October 14, 2024 4:08 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de; j...@ventanamicro.com
> Subject: RE: [PATCH 2/2]middle-end: use two's complement equality when
> comparing IVs during ca
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:
> >>
> >>
> >>
> >> On 11/4/24 7:52 PM, H.J. Lu wrote:
> >>> On Tue, Nov 5, 2024 at 8:48 AM Jeff Law wrote:
>
>
>
> On 11/4/24 5:42 PM
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 symbol name. Make sure all decls that can be in a inline
> > stack
> > have a v
On Tue, Nov 5, 2024 at 4:46 PM Jakub Jelinek wrote:
>
> On Tue, Oct 29, 2024 at 07:19:38PM -0700, liuhongt wrote:
> > Generate native instruction whenever possible, otherwise use vector
> > permutation with odd indices.
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Ready pu
On Tue, Nov 05, 2024 at 05:12:56PM +0800, Hongtao Liu wrote:
> Yes, there's a mismatch between scalar and vector code, I assume users
> may not care much about precision/NAN/INF/denormal behaviors for
> vector code.
> Just like we support
> #define RECIP_MASK_DEFAULT (RECIP_MASK_VEC_DIV | RECIP_MAS
Hi Jason,
On 5 Nov 2024, at 1:23, Jason Merrill wrote:
> On 11/4/24 10:19 AM, Simon Martin wrote:
>> Hi Jason,
>>
>> On 1 Nov 2024, at 16:31, Jason Merrill wrote:
>>
>>> On 11/1/24 5:07 AM, Simon Martin wrote:
Since r10-3793-g1a37b6d9a7e57c, we ICE upon the following valid
code
wi
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:
> > >>
> > >>
> > >>
> > >> On 11/4/24 7:52 PM, H.J. Lu wrote:
> > >>> On Tue, Nov 5,
On Tue, Nov 5, 2024 at 8:12 AM Hongtao Liu 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; Liu, Hongtao
> > > ; ubiz
On Tue, Nov 5, 2024 at 5:33 PM Richard Biener
wrote:
>
> On Tue, Nov 5, 2024 at 8:12 AM Hongtao Liu 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
>
On Tue, Nov 5, 2024 at 8:54 AM Uros Bizjak wrote:
>
> On Tue, Nov 5, 2024 at 1:08 AM Jeff Law wrote:
> >
> >
> >
> > On 11/1/24 10:44 AM, Uros Bizjak wrote:
> > > On Fri, Nov 1, 2024 at 3:51 PM Jeff Law wrote:
> > >>
> > >> On 11/1/24 8:45 AM, Uros Bizjak wrote:
> > >>> On Fri, Nov 1, 2024 at 2:
On Tue, Nov 5, 2024 at 9: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
On Nov 05 2024, Uros Bizjak wrote:
> But what is the non-deprecated way to communicate the fact that SP
> changes, and possibly clobbers stack in the asm to the compiler?
Since an asm statement is not allowed to change SP there is no need for
that.
--
Andreas Schwab, sch...@linux-m68k.org
GPG K
Hi,
We are an importer and distributor of gravy and related products, etc, serving
HK and Macau. We would like to know more about your company's brands and
prices, and hope to have the opportunity to cooperate with you.
Best regards,
Justin
> On 29 Oct 2024, at 7:16 PM, Richard Biener wrote:
>
> External email: Use caution opening links or attachments
>
>
> On Mon, 28 Oct 2024, Soumya AR wrote:
>
>> This patch transforms the following POW calls to equivalent LDEXP calls, as
>> discussed in PR57492:
>>
>> powi (2.0, i) -> ldexp (1.0
On Tue, Nov 5, 2024 at 10:38 AM Richard Biener
wrote:
> > > >> So I think we need to conclude whether or not the testcase is valid or
> > > >> not first.
> > > >
> > > > This is what x86 linux kernel uses (arch/x86/include/asm/asm.h) as a
> > > > scheduling barrier to prevent asm from being sched
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 fact that SP
> > changes, and possibly clobbers stack in the asm to the compiler?
>
> Since an asm statement is not allowed to change SP there is
On Tue, Nov 5, 2024 at 12:00 PM 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 fact that SP
> > > changes, and possibly clobbers stack in the asm to the compile
Hi,
when reviewing various IPA bits and pieces I have discovered two
embarrassing problems with jump function duplication.
First, aggregate jump function vector copying contained a pasto where
the source is the (empty) destination vector and so no aggregate jump
functions ever got copied to jump
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 tested on x86_64-linux,
> 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 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 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 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
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
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
1 - 100 of 150 matches
Mail list logo
