On Thu, Sep 10, 2020 at 04:58:03PM -0500, Peter Bergner via Gcc-patches wrote:
> +unsigned long
> +test0 (void)
> +{
> + return 0x0000UL;
> +}
> +
> +unsigned long
> +test1 (void)
> +{
> + return 0x0000UL;
> +}
> +
> +unsigned long
> +test2 (void)
> +{
> + return
On 2020/9/14 17:47, Richard Biener wrote:
On Mon, Sep 14, 2020 at 10:05 AM luoxhu wrote:
Not sure whether this reflects the issues you discussed above.
I constructed below test cases and tested with and without this patch,
only if "a+c"(which means store only), the performance is getting
>@@ -3426,8 +3426,16 @@ dt_simplify::gen_1 (FILE *f, int indent, bool
>gimple, operand *result)
> /* Re-fold the toplevel result. It's basically an embedded
> gimple_build w/o actually building the stmt. */
> if (!is_predicate)
>- fprintf_indent (f,
> On Sep 14, 2020, at 6:09 PM, Segher Boessenkool
> wrote:
>
> On Fri, Sep 11, 2020 at 05:41:47PM -0500, Qing Zhao wrote:
>>> On Sep 11, 2020, at 4:51 PM, Segher Boessenkool
>>> wrote:
>>> It is definitely *not* effective if there are gadgets that set rax to
>>> a value the attacker wants
Hi:
This patch would avoid spill gprs to mask registers for non-AVX512
micro-architecture and fix regression in PR96744.
Bootstrap is ok, regression test for i386/x86-64 backend is ok.
No big performance impact on SPEC2017.
gcc/ChangeLog:
PR taregt/96744
*
On Mon, Sep 14, 2020 at 08:39:36PM +, Joseph Myers wrote:
> On Mon, 14 Sep 2020, Marek Polacek via Gcc-patches wrote:
>
> > so I followed suit. In the C++ FE this was rather easy, because
> > finish_parenthesized_expr already set TREE_NO_WARNING. In the C FE
> > it was trickier; I've added
These functions do behave a little differently for SImode, so the
mode should be passed.
* config/rs6000/rs6000.c (rs6000_rtx_costs): Pass mode to
reg_or_add_cint_operand and reg_or_sub_cint_operand.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index
The existing "case AND" in this function is not sufficient for
optabs.c:avoid_expensive_constant usage, where the AND is passed in
outer_code.
* config/rs6000/rs6000.c (rs6000_rtx_costs): Move costing for
AND to CONST_INT case.
diff --git a/gcc/config/rs6000/rs6000.c
Prior patches in this series were small bug fixes. This lays out the
ground rules for following patches.
* config/rs6000/rs6000.c (rs6000_rtx_costs): Expand comment.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 523d029800a..5b3c0ee0e8c 100644
---
Also use rs6000_cost only for speed.
* config/rs6000/rs6000.c (rs6000_rtx_costs): Reduce cost for SETs
when insn operation cost handled on recursive call. Only use
rs6000_cost for speed. Tidy break/return. Tidy AND costing.
diff --git a/gcc/config/rs6000/rs6000.c
This small patch to rs6000_rtx_const considerably improves code
generated for large constants in 64-bit code, teaching gcc that it is
better to load a constant from memory than to generate a sequence of
up to five dependent instructions. Note that the rs6000 backend does
generate large constants
Implement more two insn constants.
PR 94393
* config/rs6000/rs6000.c (rotate_and_mask_constant): New function.
(num_insns_constant_multi, rs6000_emit_set_long_const): Use it here.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index
* config/rs6000/rs6000.c (rs6000_rtx_costs): Cost IOR.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 8c300b82b11..fb5fe7969a3 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -21177,6 +21177,7 @@ static bool
rs6000_rtx_costs (rtx x,
This patch series fixes a number of issues in rs6000_rtx_costs, the
aim being to provide costing somewhat closer to reality. Probably the
most important patch of the series is patch 4, which just adds a
comment. Without the analysis that went into that comment, I found
myself making what seemed
rldimi is generated by rs6000_emit_set_long_const when the high and
low 32 bits of a 64-bit constant are equal.
* config/rs6000/rs6000.c (num_insns_constant_gpr): Count rldimi
constants correctly.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index
On Mon, Sep 14, 2020 at 11:13:18AM -0400, Jason Merrill via Gcc-patches wrote:
> On Mon, Jun 29, 2020 at 1:25 PM Martin Liška wrote:
> >
> > On 6/29/20 4:57 PM, Marek Polacek wrote:
> > > On Mon, Jun 29, 2020 at 09:51:57AM +0200, Martin Liška wrote:
> > >> On 6/26/20 9:34 PM, Marek Polacek via
On Linux/x86_64,
e9fdb9a73249f95f3da2d7fde6f268ae12d0d22c is the first bad commit
commit e9fdb9a73249f95f3da2d7fde6f268ae12d0d22c
Author: Nathan Sidwell
Date: Mon Sep 14 09:42:29 2020 -0700
c++: local externs in templates do not get template head
caused
FAIL: libgomp.c++/udr-3.C
On Linux/x86_64,
e9fdb9a73249f95f3da2d7fde6f268ae12d0d22c is the first bad commit
commit e9fdb9a73249f95f3da2d7fde6f268ae12d0d22c
Author: Nathan Sidwell
Date: Mon Sep 14 09:42:29 2020 -0700
c++: local externs in templates do not get template head
caused
FAIL: libgomp.c++/udr-13.C
On Mon, Sep 14, 2020 at 05:33:33PM +0100, Richard Sandiford wrote:
> > However, for the cases on Power as Segher mentioned, there are also some
> > scratch registers used for
> > Other purpose, not sure whether we can correctly generate zeroing in
> > middle-end for Power?
>
> Segher would be
Hi!
On Fri, Sep 11, 2020 at 05:24:58PM -0500, Qing Zhao wrote:
> > So IMO the pass should just search for all the
> > returns in a function and insert the zeroing instructions before
> > each one.
>
> I was considering this approach too for some time, however, there is one
> major issue with
On Fri, Sep 11, 2020 at 05:41:47PM -0500, Qing Zhao wrote:
> > On Sep 11, 2020, at 4:51 PM, Segher Boessenkool
> > wrote:
> > It is definitely *not* effective if there are gadgets that set rax to
> > a value the attacker wants and then do a syscall.
>
> You mean the following gadget:
>
>
>
On Mon, 14 Sep 2020 09:34:08 +0200
Richard Biener wrote:
> On Fri, Sep 11, 2020 at 11:56 PM Sergei Trofimovich via Gcc-patches
> wrote:
> >
> > From: Sergei Trofimovich
> >
> > Before the change option handling did not accept an argument:
> > xgcc: error: unknown profile reproducibility
On 9/14/20 1:03 PM, Jakub Jelinek wrote:
+
+ if (flag_openmp && !(TYPE_QUALS (TREE_TYPE (ptr)) & TYPE_QUAL_RESTRICT))
+always_modifier = true;
I think we don't want to depend on flag_openmp here, ... Guess for now
an openacc flag with (ctx->region_type & ORT_ACC) != 0 passed to it
This patch cause run-time fails for
g++ -fopenmp libgomp/testsuite/libgomp.c++/udr-13.C
The follow-up fix does not help.
Namely, in udr-3.C:115:
115 if (t.s != 11 || v.v != 9 || q != 0 || d != 3.0) abort ();
(gdb) p t.s
$1 = 11
(gdb) p v.v
$2 = 4
(gdb) p q
$3 = 0
(gdb) p d
$4 = 3
On Linux/x86_64,
e9fdb9a73249f95f3da2d7fde6f268ae12d0d22c is the first bad commit
commit e9fdb9a73249f95f3da2d7fde6f268ae12d0d22c
Author: Nathan Sidwell
Date: Mon Sep 14 09:42:29 2020 -0700
c++: local externs in templates do not get template head
caused
FAIL: libgomp.c++/udr-13.C
On Linux/x86_64,
e9fdb9a73249f95f3da2d7fde6f268ae12d0d22c is the first bad commit
commit e9fdb9a73249f95f3da2d7fde6f268ae12d0d22c
Author: Nathan Sidwell
Date: Mon Sep 14 09:42:29 2020 -0700
c++: local externs in templates do not get template head
caused
FAIL: libgomp.c++/udr-3.C
After the previous patch we are left with an unreachable BB. This will
ICE if either we have -fschedule-fusion, or we do not have peephole2.
This fixes it. Okay for trunk?
Segher
2020-09-14 Segher Boessenkool
PR rtl-optimization/96475
* bb-reorder.c
On 9/4/20 11:14 AM, Jason Merrill wrote:
On 9/3/20 2:44 PM, Martin Sebor wrote:
On 9/1/20 1:22 PM, Jason Merrill wrote:
On 8/11/20 12:19 PM, Martin Sebor via Gcc-patches wrote:
-Wplacement-new handles array indices and pointer offsets the same:
by adjusting them by the size of the element.
> On Sep 14, 2020, at 7:30 AM, Ville Voutilainen via Libstdc++
> wrote:
>
> On Mon, 14 Sep 2020 at 15:49, Glen Fernandes wrote:
>>
>> On Mon, Sep 14, 2020 at 5:52 AM Ville Voutilainen wrote:
>>> On Mon, 14 Sep 2020 at 12:51, Ville Voutilainen
>>> wrote:
On Mon, 14 Sep 2020 at 09:18,
This patch to libbacktrace adds support for MiniDebugInfo, as
requested in PR 93608.
MiniDebugInfo stores compressed symbol tables for an executable, where
the executable is otherwise stripped. It is documented at
https://fedoraproject.org/wiki/Features/MiniDebugInfo and
On Mon, Sep 14, 2020 at 11:47:52AM +0100, Richard Sandiford wrote:
> Would it be worth changing the optab so that the input and output are
> separate? Having a single operand would be justified if the operation
> was only supposed to touch the selected bytes, but most targets wouldn't
> guarantee
On Mon, Sep 14, 2020 at 11:47:56AM +0200, Richard Biener wrote:
> this should be
>
>u[n % 4] = i;
>
> I guess. Is the % 4 mandated by the vec_insert semantics btw?
Yes:
VEC_INSERT (ARG1, ARG2, ARG3)
Purpose: Returns a copy of vector ARG2 with element ARG3 replaced by
the value of
On Mon, 14 Sep 2020, Marek Polacek via Gcc-patches wrote:
> so I followed suit. In the C++ FE this was rather easy, because
> finish_parenthesized_expr already set TREE_NO_WARNING. In the C FE
> it was trickier; I've added a NOP_EXPR to discern between the non-()
> and () versions.
This sort
On 10/09/20 5:19 pm, Jonathan Wakely wrote:
On 09/09/20 22:12 +0200, François Dumont via Libstdc++ wrote:
libstdc++: Add std::advance overload for ostreambuf_iterator
Implement std::advance overload for ostreambuf_iterator using
basic_streambuf
pubseekof.
libstdc++-v3/ChangeLog:
    Â
On Mon, Sep 14, 2020 at 10:05 AM Jakub Jelinek wrote:
>
> On Mon, Sep 14, 2020 at 08:57:18AM -0700, H.J. Lu via Gcc-patches wrote:
> > Something like this for GCC 8 and 9.
>
> Guess my preference would be to do this everywhere and then let's discuss if
The same patch also works on master branch.
On Sun, 13 Sep 2020, Uecker, Martin wrote:
> Hi Joseph,
>
> here is the (unfinished) patch to support
> mixing of labels in C2X.
I think there should be explicit tests for old standard versions
(c11-labels-1.c etc.) that these usages are errors with -pedantic-errors
with the old -std option,
> On Sep 14, 2020, at 2:20 PM, Richard Sandiford
> wrote:
>
> Qing Zhao mailto:qing.z...@oracle.com>> writes:
>>> On Sep 14, 2020, at 11:33 AM, Richard Sandiford
>>> wrote:
>>>
>>> Qing Zhao writes:
> Like I mentioned earlier though, passes that run after
>
On Thu, Sep 10, 2020 at 12:08:44PM +0200, Richard Biener wrote:
> On Wed, Sep 9, 2020 at 6:03 PM Segher Boessenkool
> wrote:
> > There often are problems over function calls (where the compiler cannot
> > usually *see* how something is used).
>
> Yep. The best way would be to use small loads
Dear all,
my fix for PR fortran/96711 adds a testcase that failed on powerpc64-*-*
as well as sparc*-sun-solaris2.11. This is a consequence of the, say,
mess, on x86, where we have real kinds 4,8,10,16, with kind=10 being long
double and kind=16 being represented as float128, while on sparc
Qing Zhao writes:
>> On Sep 14, 2020, at 11:33 AM, Richard Sandiford
>> wrote:
>>
>> Qing Zhao writes:
Like I mentioned earlier though, passes that run after
pass_thread_prologue_and_epilogue can use call-clobbered registers that
weren't previously used. For example, on
The BPF ISA doesn't have a no-operation instruction, but in practice
the Linux kernel verifier performs some optimizations that rely on
these instructions to be encoded in a particular way. As it turns
out, we were using the "wrong" instruction in GCC.
This patch makes GCC to generate the
Hi Richard,
>On 14/09/2020 15:19, Wilco Dijkstra wrote:
>> The --with-cpu/--with-arch configure option processing not only checks valid
>> arguments
>> but also sets TARGET_CPU_DEFAULT with a CPU and extension bitmask. This
>> isn't used
>> however since a --with-cpu is translated into a -mcpu
On Mon, Sep 14, 2020 at 12:53:18PM -0400, Nathan Sidwell wrote:
> On 9/14/20 12:49 PM, Marek Polacek wrote:
> > On Mon, Sep 14, 2020 at 12:45:33PM -0400, Nathan Sidwell wrote:
> > > Now we consistently mark local externs with DECL_LOCAL_DECL_P, we can
> > > teach the template machinery not to give
Hi
The tests assume non-PIC for m32 (which means that they fail on default
PIC targets, like Darwin), also on Linux with -fpic, FWIW.
There is also a missing space before the closing '}' on one of the dg-require-
effective-target which means that test fails on machines without avx512f.
Tested
> On Sep 14, 2020, at 11:33 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>>> Like I mentioned earlier though, passes that run after
>>> pass_thread_prologue_and_epilogue can use call-clobbered registers that
>>> weren't previously used. For example, on x86_64, the function might
This patch implements a new warning, -Wsizeof-array-div. It warns about
code like
int arr[10];
sizeof (arr) / sizeof (short);
where we have a division of two sizeof expressions, where the first
argument is an array, and the second sizeof does not equal the size
of the array element. See
Hi!
On Mon, Sep 14, 2020 at 05:53:13PM +0800, Kewen.Lin wrote:
> This patch is to extend the existing function find_alignment_op to
> check all defintions of base_reg are AND operations with mask -16B
> to force the alignment. If all are satifised, it passes all AND
> operations and instructions
On Mon, Sep 14, 2020 at 08:57:18AM -0700, H.J. Lu via Gcc-patches wrote:
> Something like this for GCC 8 and 9.
Guess my preference would be to do this everywhere and then let's discuss if
we change the warning into error there or keep it being deprecated.
Though, let's see what others want to
On 9/14/20 12:49 PM, Marek Polacek wrote:
On Mon, Sep 14, 2020 at 12:45:33PM -0400, Nathan Sidwell wrote:
Now we consistently mark local externs with DECL_LOCAL_DECL_P, we can
teach the template machinery not to give them a TEMPLATE_DECL head,
and the instantiation machinery treat them as the
On Mon, Sep 14, 2020 at 12:45:33PM -0400, Nathan Sidwell wrote:
> Now we consistently mark local externs with DECL_LOCAL_DECL_P, we can
> teach the template machinery not to give them a TEMPLATE_DECL head,
> and the instantiation machinery treat them as the local specialiations
> they are.
Now we consistently mark local externs with DECL_LOCAL_DECL_P, we can
teach the template machinery not to give them a TEMPLATE_DECL head,
and the instantiation machinery treat them as the local specialiations
they are. (openmp UDRs also fall into this category, and are dealt
with similarly.)
Hi all,
I'd like to submit this patch to fix PR96968 and add the corresponding
test.
The fix makes sure the target of these getters is a register so the
insn can be pattern matched correctly.
Regtested and bootsraped on aarch64-linux-gnu.
Okay for trunk?
Thanks
Andrea
>From
On attempting to run the full test suite with -fanalyzer via
make check RUNTESTFLAGS="-v -v --target_board=unix/-fanalyzer"
I saw it get stuck on:
gcc.c-torture/compile/20001226-1.c
It turns out this was on a debug build, rather than a release build;
but a release build with -fanalyzer took:
PR analyzer/96653 reports a CPU-time and memory explosion in -fanalyzer
seen in Linux 5.9-rc1:drivers/media/v4l2-core/v4l2-ctrls.c on a switch
statement with many cases.
The issue is some old code in constraint_manager::get_or_add_equiv_class
for ensuring that comparisons between equivalence
Downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1878600
describes a false positive from -Wanalyzer-file-leak seen with
gcc 10.2, but which has been fixed in gcc 11.
This patch adds the reproducer as a regression test.
Successfully tested on x86_64-pc-linux-gnu.
Pushed to
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-3188-g35e3f0829d8e9cdc7ea19917c9f3a7add3f14847.
gcc/analyzer/ChangeLog:
PR analyzer/97029
* analyzer.cc (is_setjmp_call_p): Require the initial arg to be a
pointer.
*
Qing Zhao writes:
>> Like I mentioned earlier though, passes that run after
>> pass_thread_prologue_and_epilogue can use call-clobbered registers that
>> weren't previously used. For example, on x86_64, the function might
>> not use %r8 when the prologue, epilogue and returns are generated,
>>
On Mon, Sep 14, 2020 at 8:12 AM H.J. Lu wrote:
>
> On Mon, Sep 14, 2020 at 7:35 AM Jakub Jelinek wrote:
> >
> > On Sat, Sep 12, 2020 at 10:11:36AM -0700, H.J. Lu via Gcc-patches wrote:
> > > Clobbering the stack pointer in asm statment has been deprecated. Adding
> > > the stack pointer
On Mon, Sep 14, 2020 at 09:46:11AM +0200, Richard Biener wrote:
> On Fri, Sep 11, 2020 at 4:18 PM Segher Boessenkool
> wrote:
> > Until 2014 (and documented just days ago ;-) ) all bits of a partial
> > integer mode were considered unknown.
>
> All bits or all bits outside of its precision? I
On Mon, Jun 29, 2020 at 1:25 PM Martin Liška wrote:
>
> On 6/29/20 4:57 PM, Marek Polacek wrote:
> > On Mon, Jun 29, 2020 at 09:51:57AM +0200, Martin Liška wrote:
> >> On 6/26/20 9:34 PM, Marek Polacek via Gcc-patches wrote:
> >>> As discussed last month:
> >>>
On Mon, Sep 14, 2020 at 7:35 AM Jakub Jelinek wrote:
>
> On Sat, Sep 12, 2020 at 10:11:36AM -0700, H.J. Lu via Gcc-patches wrote:
> > Clobbering the stack pointer in asm statment has been deprecated. Adding
> > the stack pointer register to the clobber list has traditionally had some
> >
On 14/09/2020 13:01, Wilco Dijkstra wrote:
> Enable the fast shift feature in Neoverse N1 tuning - this means additions
> with
> a shift left by 1-4 are as fast as addition. This improves multiply by
> constant
> expansions, eg. x * 25 is now emitted using shifts rather than a multiply:
>
> add
Hi, Richard,
> On Sep 11, 2020, at 5:56 PM, Richard Sandiford
> wrote:
>
> Qing Zhao mailto:qing.z...@oracle.com>> writes:
>>> On Sep 11, 2020, at 4:44 PM, Richard Sandiford
>>> wrote:
>>>
>>> Qing Zhao writes:
> On Sep 11, 2020, at 12:32 PM, Richard Sandiford
> >> If we go for
Hi,
the attached patch implements pretty printers relevant for iteration
over std::vector, thus handling the TODO
added in commit 36d0dada6773d7fd7c5ace64c90e723930a3b81e
("Have std::vector printer's iterator return bool for vector",
2019-06-19):
TODO add printer for vector's _Bit_iterator
On Sat, Sep 12, 2020 at 10:11:36AM -0700, H.J. Lu via Gcc-patches wrote:
> Clobbering the stack pointer in asm statment has been deprecated. Adding
> the stack pointer register to the clobber list has traditionally had some
> undocumented and somewhat obscure side-effects, including ICE. Issue
>
On Mon, 14 Sep 2020 at 15:49, Glen Fernandes wrote:
>
> On Mon, Sep 14, 2020 at 5:52 AM Ville Voutilainen wrote:
> > On Mon, 14 Sep 2020 at 12:51, Ville Voutilainen
> > wrote:
> > > On Mon, 14 Sep 2020 at 09:18, Glen Fernandes
> > wrote:
> > > > Edit; Correct patch this time.
> > > >
> > > > Fix
On 14/09/2020 15:19, Wilco Dijkstra wrote:
> The --with-cpu/--with-arch configure option processing not only checks valid
> arguments
> but also sets TARGET_CPU_DEFAULT with a CPU and extension bitmask. This
> isn't used
> however since a --with-cpu is translated into a -mcpu option which is
>
Add support for --with-tune. Like --with-cpu and --with-arch, the argument is
validated and transformed into a -mtune option to be processed like any other
command-line option. --with-tune has no effect if a -mcpu or -mtune option
is used. The validating code didn't allow --with-cpu=native, so
The --with-cpu/--with-arch configure option processing not only checks valid
arguments
but also sets TARGET_CPU_DEFAULT with a CPU and extension bitmask. This isn't
used
however since a --with-cpu is translated into a -mcpu option which is processed
as if
written on the command-line (so
On Mon, Sep 14, 2020 at 1:31 PM Eric Botcazou wrote:
>
> > In fact I can probably reuse cfun->tail_call_marked for this purpose.
>
> Like so.
Looks reasonable to me.
Richard.
>
> * cgraphunit.c (cgraph_node::expand_thunk): Make sure to set
> cfun->tail_call_marked when forcing a
On Mon, Sep 14, 2020 at 5:17 AM Feng Xue OS via Gcc-patches
wrote:
>
> Thanks,
@@ -3426,8 +3426,16 @@ dt_simplify::gen_1 (FILE *f, int indent, bool
gimple, operand *result)
/* Re-fold the toplevel result. It's basically an embedded
gimple_build w/o actually building the
Hello Jakub, hi Honza,
On 8/31/20 5:53 PM, Jakub Jelinek wrote:
On Mon, Aug 03, 2020 at 05:37:40PM +0200, Tobias Burnus wrote:
It turned out that the omp_discover_declare_target_tgt_fn_r
discovered all nodes – but as it tagged the C++ alias nodes
and not the streamed-out nodes, no device
On Mon, Sep 14, 2020 at 5:52 AM Ville Voutilainen wrote:
> On Mon, 14 Sep 2020 at 12:51, Ville Voutilainen
> wrote:
> > On Mon, 14 Sep 2020 at 09:18, Glen Fernandes
> wrote:
> > > Edit; Correct patch this time.
> > >
> > > Fix overflow handling in align
> >
> > Should the test verify that space
On 9/14/20 6:10 AM, Hongtao Liu wrote:
On Mon, Sep 14, 2020 at 3:51 PM Richard Biener via Gcc-patches
wrote:
On Fri, Sep 11, 2020 at 11:19 PM Nathan Sidwell wrote:
I noticed a compiler warning about out-of-bound access. Fixed thusly.
gcc/
* config/i386/sse.md (mov):
Enable the fast shift feature in Neoverse N1 tuning - this means additions with
a shift left by 1-4 are as fast as addition. This improves multiply by constant
expansions, eg. x * 25 is now emitted using shifts rather than a multiply:
add w0, w0, w0, lsl 2
add w0, w0, w0, lsl 2
Bootstrap OK,
Richard Biener writes:
> On Mon, Sep 14, 2020 at 12:47 PM Richard Sandiford
> wrote:
>>
>> Richard Biener via Gcc-patches writes:
>> > On gimple the above function (after fixing it) looks like
>> >
>> > VIEW_CONVERT_EXPR(u)[_1] = i_4(D);
>> >
>> > and the IFN idea I had would - for non-global
> In fact I can probably reuse cfun->tail_call_marked for this purpose.
Like so.
* cgraphunit.c (cgraph_node::expand_thunk): Make sure to set
cfun->tail_call_marked when forcing a tail call.
* function.c (assign_parm_setup_reg): Always use a register to
retrieve a
On Mon, Sep 14, 2020 at 12:56 PM Eric Botcazou wrote:
>
> > No, so you're right - validity analysis is split. Still the cause you
> > reference comes from RTL expansion which means RTL expansion should
> > possibly do the disqualification here. The question is what makes the case
> > you run
On Mon, Sep 14, 2020 at 12:47 PM Richard Sandiford
wrote:
>
> Richard Biener via Gcc-patches writes:
> > On gimple the above function (after fixing it) looks like
> >
> > VIEW_CONVERT_EXPR(u)[_1] = i_4(D);
> >
> > and the IFN idea I had would - for non-global memory 'u' only - transform
> >
Hi Kito,
> > Could you provide a test case for that?
>
I add the test case and update the git message.
RISC-V: fix a typo in riscv.h
The missing parentheses would make shorten-memrefs pass give a
wrong base when the offset of load/store is not multiple of 4.
2020-09-14 Yeting
> That being said, I can add another bit to cfun, e.g. is_gimple_thunk, and
> force the use of a register above only in case the bit is true.
In fact I can probably reuse cfun->tail_call_marked for this purpose.
--
Eric Botcazou
On Mon, Sep 14, 2020 at 09:50:08AM +0200, Tobias Burnus wrote:
> --- a/gcc/fortran/trans-openmp.c
> +++ b/gcc/fortran/trans-openmp.c
> @@ -1357,6 +1357,15 @@ gfc_omp_finish_clause (tree c, gimple_seq *pre_p)
>tree type = TREE_TYPE (decl);
>tree ptr = gfc_conv_descriptor_data_get
> No, so you're right - validity analysis is split. Still the cause you
> reference comes from RTL expansion which means RTL expansion should
> possibly do the disqualification here. The question is what makes the case
> you run into at -O0 impossible to trigger with -O1+?
The key test in
Ilya Leoshkevich writes:
> Bootstrapped and regtested on x86_64-redhat-linux. Ok for master?
>
>
>
> The following s390 rtx is errneously considered a no-op:
>
> (set (subreg:DF (reg:TF %f0) 8) (subreg:DF (reg:V1TF %f0) 8))
>
> Here, SET_DEST is a second register in a floating-point register
Richard Biener via Gcc-patches writes:
> On gimple the above function (after fixing it) looks like
>
> VIEW_CONVERT_EXPR(u)[_1] = i_4(D);
>
> and the IFN idea I had would - for non-global memory 'u' only - transform
> this to
>
> vector_register_2 = u;
> vector_register_3 = .IFN_VEC_SET
On Mon, Sep 14, 2020 at 3:51 PM Richard Biener via Gcc-patches
wrote:
>
> On Fri, Sep 11, 2020 at 11:19 PM Nathan Sidwell wrote:
> >
> > I noticed a compiler warning about out-of-bound access. Fixed thusly.
> >
> > gcc/
> > * config/i386/sse.md (mov): Fix operand indices.
> >
On Mon, Sep 14, 2020 at 10:36 AM Eric Botcazou wrote:
>
> > ISTR the tailcall flag is only a hint and RTL expansion can decide to
> > not tailcall based on targets. So to me it looks like a missed
> > disqualification on the RTL expansion side.
>
> That's IMO debatable: the GIMPLE tailcall
Hi,
This patch is to extend the existing function find_alignment_op to
check all defintions of base_reg are AND operations with mask -16B
to force the alignment. If all are satifised, it passes all AND
operations and instructions in one vector to recombine_lvx_pattern
and recombine_stvx_pattern,
On Mon, 14 Sep 2020 at 12:51, Ville Voutilainen
wrote:
>
> On Mon, 14 Sep 2020 at 09:18, Glen Fernandes via Libstdc++
> wrote:
> >
> > Edit; Correct patch this time.
> >
> > Fix overflow handling in align
>
> Should the test verify that space is unmodified when nullptr is returned?
..and same
On Mon, 14 Sep 2020 at 09:18, Glen Fernandes via Libstdc++
wrote:
>
> Edit; Correct patch this time.
>
> Fix overflow handling in align
Should the test verify that space is unmodified when nullptr is returned?
On Mon, Sep 14, 2020 at 11:02:26AM +0200, Jan Hubicka wrote:
> Especially for the new param machinery, most of streamed values are
> probably going to be the default values. Perhaps somehow we could
> stream them more effectively.
Ah, that seems like a good idea, that brings further savings, the
On Mon, Sep 14, 2020 at 10:05 AM luoxhu wrote:
>
>
>
> On 2020/9/10 18:08, Richard Biener wrote:
> > On Wed, Sep 9, 2020 at 6:03 PM Segher Boessenkool
> > wrote:
> >>
> >> On Wed, Sep 09, 2020 at 04:28:19PM +0200, Richard Biener wrote:
> >>> On Wed, Sep 9, 2020 at 3:49 PM Segher Boessenkool
>
When the unrolling decision comes late and would have prevented
eliding a SLP load permutation we can end up generating aligned
loads when the load is in fact unaligned. Most of the time
alignment analysis figures out the load is in fact unaligned
but that cannot be relied upon.
The following
Initializing orig_err avoids a warning: "may be used uninitialized".
2020-09-14 Torbjörn SVENSSON
Christophe Lyon
libiberty/
* pex-win32 (pex_win32_exec_child): Initialize orig_err.
---
libiberty/pex-win32.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Hi all,
here is the update version of the patch implementing suggestions.
The check for 'vect_need_peeling_or_partial_vectors_p' (and its
comment) has also been move just before so we can short-circuit the
partial vector handling if we know we are using full vectors.
Bootstrapped and regtested
On Mon, 14 Sep 2020, Jakub Jelinek wrote:
> On Mon, Sep 14, 2020 at 09:31:52AM +0200, Richard Biener wrote:
> > But does it make any noticable difference in the end? Using
>
> Yes.
>
> > bp_pack_var_len_unsigned just causes us to [u]leb encode half-bytes
> > rather than full bytes. Using
Bootstrapped and regtested on x86_64-redhat-linux. Ok for master?
The following s390 rtx is errneously considered a no-op:
(set (subreg:DF (reg:TF %f0) 8) (subreg:DF (reg:V1TF %f0) 8))
Here, SET_DEST is a second register in a floating-point register pair,
and SET_SRC is the second half of a
> On Mon, Sep 14, 2020 at 09:31:52AM +0200, Richard Biener wrote:
> > But does it make any noticable difference in the end? Using
>
> Yes.
>
> > bp_pack_var_len_unsigned just causes us to [u]leb encode half-bytes
> > rather than full bytes. Using hardcoded 8/16/32/64 makes it still
> >
On Mon, Sep 14, 2020 at 09:31:52AM +0200, Richard Biener wrote:
> But does it make any noticable difference in the end? Using
Yes.
> bp_pack_var_len_unsigned just causes us to [u]leb encode half-bytes
> rather than full bytes. Using hardcoded 8/16/32/64 makes it still
> dependent on what 'int'
Hi Jakub,
> -Original Message-
> From: Jakub Jelinek
> Sent: 13 September 2020 09:39
> To: Richard Earnshaw ; Kyrylo Tkachov
>
> Cc: gcc-patches@gcc.gnu.org
> Subject: [PATCH] arm: Fix up gcc.target/arm/lto/pr96939_* FAIL
>
> Hi!
>
> The following patch on top of the
>
1 - 100 of 120 matches
Mail list logo
