On Fri, Mar 26, 2021 at 6:24 PM H.J. Lu wrote:
>
> On Fri, Mar 26, 2021 at 5:09 AM Richard Biener
> wrote:
> >
> > On Fri, Mar 26, 2021 at 11:26 AM Jakub Jelinek wrote:
> > >
> > > On Fri, Mar 26, 2021 at 11:13:21AM +0100, Richard Biener wrote:
> > > > On Fri, Mar 26, 2021 at 9:34 AM Jakub Jelin
On Mon, 29 Mar 2021 at 17:09, Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> aarch64 currently doesn't support declare simd where the return value and
> arguments
> have different sizes and warns about that case. This change adds a dg-warning
> for that case like various other tests have alrea
Hi!
The following testcase ICEs (since the addition of inline var support),
because the lambda contains PTRMEM_CST but finish_function is called for the
lambda quite early during parsing it (from finish_lambda_function) when
the containing class is still incomplete. That means that during
generic
Hi!
These test FAIL on s390*:
/builddir/build/BUILD/gcc-11.0.1-20210324/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:
In function 'foo8':
/builddir/build/BUILD/gcc-11.0.1-20210324/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:71:1:
sorry, unimplemented: '-fzero-call-used-regs' not suppo
mihailo.stojano...@typhoon-hil.com writes:
> From: Mihailo Stojanovic
>
> Hi all,
>
> Currently, SF->SI and DF->DI conversions on Aarch64 with the "nosimd"
> flag provided sometimes cause the emitting of a vector variant of the
> fcvtz[su] instruction (e.g. fcvtzu s0, s0).
>
> This modifies the co
This PR is a regression caused by r8-5967, where we replaced
a call to aarch64_internal_mov_immediate in aarch64_add_offset
with a call to aarch64_force_temporary, which in turn uses the
normal emit_move_insn{,_1} routines.
The problem is that aarch64_add_offset can be called while
outputting a th
On Tue, Mar 30, 2021 at 10:14 AM Uros Bizjak wrote:
>
> On Fri, Mar 26, 2021 at 6:24 PM H.J. Lu wrote:
> >
> > On Fri, Mar 26, 2021 at 5:09 AM Richard Biener
> > wrote:
> > >
> > > On Fri, Mar 26, 2021 at 11:26 AM Jakub Jelinek wrote:
> > > >
> > > > On Fri, Mar 26, 2021 at 11:13:21AM +0100, Ri
On Tue, Mar 30, 2021 at 12:59:16PM +0200, Richard Biener wrote:
> > > > So yes, a better solution would be nice but I can't see any since the
> > > > underlying issue is known since a long time and thus the pragmatic
> > > > solution is the best (IMHO), also from a QOI perspective. For
> > > > in
VN sometimes builds new integer types to handle accesss where precision
of the access type does not match the access size. The way
ao_ref_init_from_vn_reference is computing the access size ignores
the access type in case the ref operands have an outermost
COMPONENT_REF which, in case it is an arr
On Tue, Mar 30, 2021 at 12:44 PM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> These test FAIL on s390*:
> /builddir/build/BUILD/gcc-11.0.1-20210324/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:
> In function 'foo8':
> /builddir/build/BUILD/gcc-11.0.1-20210324/gcc/testsuite/c-c++-common/z
On Tue, Mar 30, 2021 at 1:03 PM Jakub Jelinek wrote:
>
> On Tue, Mar 30, 2021 at 12:59:16PM +0200, Richard Biener wrote:
> > > > > So yes, a better solution would be nice but I can't see any since the
> > > > > underlying issue is known since a long time and thus the pragmatic
> > > > > solution i
On Tue, Mar 30, 2021 at 01:28:40PM +0200, Richard Biener wrote:
> > Ok to skip the test on s390* until then?
>
> Can we change the test to do
>
> { dg-skip-if "not implemented" { ! { target x86_64-*-* } } }
>
> instead? IIRC it's nowhere implemented but on x86_64.
I don't know, perhaps.
Seems
On Tue, Mar 30, 2021 at 1:56 PM Jakub Jelinek wrote:
>
> On Tue, Mar 30, 2021 at 01:28:40PM +0200, Richard Biener wrote:
> > > Ok to skip the test on s390* until then?
> >
> > Can we change the test to do
> >
> > { dg-skip-if "not implemented" { ! { target x86_64-*-* } } }
> >
> > instead? IIRC
When compiling with -mfloat-abi=hard -march=armv8.1-m.main+mve, we
want to emit Tag_ABI_VFP_args even though we are not emitting
floating-point instructions (we need "+mve.fp" for that), because we
use MVE registers to pass FP arguments.
This patch removes the condition on (! TARGET_SOFT_FLOAT) be
Hi Richi,
TWO_OPERANDS allows any order or number of combinations of + and - operations
but the pattern matcher only supports pairs of operations.
This patch has the pattern matcher for complex numbers reject SLP trees where
the lanes are not a multiple of 2.
Bootstrapped Regtested on aarch64-no
On Mon, 29 Mar 2021 at 12:56, Kyrylo Tkachov via Gcc-patches
wrote:
>
>
>
> > -Original Message-
> > From: Jakub Jelinek
> > Sent: 29 March 2021 11:45
> > To: Kyrylo Tkachov
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH] aarch64: PR target/99037 Fix RTL represntation in
> > mov
On 30/03/2021 13:37, Christophe Lyon via Gcc-patches wrote:
When compiling with -mfloat-abi=hard -march=armv8.1-m.main+mve, we
want to emit Tag_ABI_VFP_args even though we are not emitting
floating-point instructions (we need "+mve.fp" for that), because we
use MVE registers to pass FP argumen
Hi,
PR 93385 reveals that if the user explicitely disables DCE, IPA-SRA
can leave behind statements which are useless because their results
are eventually not used but can have problematic side effects,
especially since their inputs are now bogus that useless parameters
were removed.
This patch f
Hi,
Whereas the previous patch fixed issues with code left behind after
IPA-SRA removed a parameter but only reset all affected debug bind
statements, this one updates them with expressions which can allow the
debugger to print the removed value - see the added test-case.
Even though I originally
On 3/30/21 12:43 PM, Jakub Jelinek wrote:
> Hi!
>
> These test FAIL on s390*:
> /builddir/build/BUILD/gcc-11.0.1-20210324/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:
> In function 'foo8':
> /builddir/build/BUILD/gcc-11.0.1-20210324/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:71:1:
>
> -Original Message-
> From: Christophe Lyon
> Sent: 30 March 2021 13:57
> To: Kyrylo Tkachov
> Cc: Jakub Jelinek ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] aarch64: PR target/99037 Fix RTL represntation in
> move_lo_quad patterns
>
> On Mon, 29 Mar 2021 at 12:56, Kyrylo Tkachov
On Tue, 30 Mar 2021 at 14:59, Richard Earnshaw
wrote:
>
>
>
> On 30/03/2021 13:37, Christophe Lyon via Gcc-patches wrote:
> > When compiling with -mfloat-abi=hard -march=armv8.1-m.main+mve, we
> > want to emit Tag_ABI_VFP_args even though we are not emitting
> > floating-point instructions (we nee
On Tue, 30 Mar 2021, Tamar Christina wrote:
> Hi Richi,
>
> TWO_OPERANDS allows any order or number of combinations of + and - operations
> but the pattern matcher only supports pairs of operations.
>
> This patch has the pattern matcher for complex numbers reject SLP trees where
> the lanes are
Hi all,
In this PR we end up generating an invalid instruction:
adds x1,xzr,#2
because the pattern accepts zero as an operand in the comparison, but the
instruction doesn't.
Fix it by adjusting the predicate and constraints.
Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to trunk.
T
On Tue, Mar 30, 2021 at 02:33:17PM +0200, Richard Biener via Gcc-patches wrote:
> > I don't know, perhaps.
> > Seems the target hook is only defined on
> > config/i386/i386.c:#undef TARGET_ZERO_CALL_USED_REGS
> > config/i386/i386.c:#define TARGET_ZERO_CALL_USED_REGS
> > ix86_zero_call_used_regs
>
committed with few tweaks.
On Wed, Mar 24, 2021 at 11:21 AM Kito Cheng wrote:
>
> ---
> htdocs/gcc-11/changes.html | 32 +++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
> index 69869309..e
Hi all,
This fixes a simple segfault ICE when using the use_new_vector_costs tunable
with a CPU tuning that it wasn't intended for.
I'm not adding a testcase here as we intend to remove the tunable for GCC 12
anyway (the new costing logic will remain and will benefit
from this extra check, but t
On 3/30/21 5:38 AM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs (since the addition of inline var support),
because the lambda contains PTRMEM_CST but finish_function is called for the
lambda quite early during parsing it (from finish_lambda_function) when
the containing class is still
This is the bug that keeps on giving. Reducing it has been successful
at hitting other defects. In this case, some more specialization hash
table fun, plus an issue with reading in a definition of a duplicated
declaration. At least I discovered a null context check is no longer
needed.
We currently mangle __alignof__ as a vendor extended operator,
but that's problematic for the reasons mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115#c6.
This patch changes the mangling of __alignof__ to instead use the
new "vendor extended expression" syntax that's proposed in
htt
Update prefixed attribute for Power10.
This patch creates a new attribute, "maybe_prefixed", which is used to mark
those instructions that may have a prefixed form. The existing "prefixed"
attribute is now used to mark all instructions that are prefixed form.
This patch differs from the prior ver
Hi,
this patch backports the initial support to gcc10 branch. Since the
trunk and branch diverged there is non-trivial change to cpuinfo
discovery. I do;
--- a/libgcc/config/i386/cpuinfo.c
+++ b/libgcc/config/i386/cpuinfo.c
@@ -111,6 +111,12 @@ get_amd_cpu (unsigned int family, unsigned int mode
Hi!
As mentioned in the PR, Uai constraint stands for
aarch64_sve_scalar_inc_dec_immediate
while Uav for
aarch64_sve_addvl_addpl_immediate.
Both *add3_aarch64 and *add3_poly_1 patterns use
* return aarch64_output_sve_scalar_inc_dec (operands[2]);
* return aarch64_output_sve_addvl_addpl (operan
Hi!
On Tue, Mar 30, 2021 at 02:38:32PM -0500, Pat Haugen wrote:
> Update prefixed attribute for Power10.
>
> This patch creates a new attribute, "maybe_prefixed", which is used to mark
> those instructions that may have a prefixed form. The existing "prefixed"
> attribute is now used to mark all
When checking dependence of a placeholder type constraint, if the first
template argument of the constraint is an argument pack, we need to
expand it so that we properly separate the implicit 'auto' argument from
the rest.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
tr
On 3/12/21 3:20 AM, Jakub Jelinek wrote:
Hi!
For -gdwarf-4 -gsplit-dwarf we used to emit .debug_ranges section
(so in the binaries/shared libraries) with DW_AT_ranges from skeleton
units as well as .debug_info.dwo pointing to it through DW_FORM_sec_offset
(and DW_AT_GNU_ranges_base pointing into
On 3/30/21 3:17 PM, Patrick Palka wrote:
We currently mangle __alignof__ as a vendor extended operator,
but that's problematic for the reasons mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88115#c6.
This patch changes the mangling of __alignof__ to instead use the
new "vendor extende
On 3/30/21 4:35 PM, Patrick Palka wrote:
When checking dependence of a placeholder type constraint, if the first
template argument of the constraint is an argument pack, we need to
expand it so that we properly separate the implicit 'auto' argument from
the rest.
Bootstrapped and regtested on x8
Thank you for your interest in this project.
On 3/27/2021 6:18 PM, Bernhard Reutner-Fischer wrote:
On Fri, 26 Mar 2021 23:14:41 +
Patrick McGehearty via Gcc-patches wrote:
Changes in Version 9 since Version 8:
Revised code to meet gcc coding standards in all files, especially
with r
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/symbolic-1.c: Fix typo.
---
gcc/testsuite/gcc.dg/analyzer/symbolic-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/analyzer/symbolic-1.c
b/gcc/testsuite/gcc.dg/analyzer/symbolic-1.c
index 9d228e6331c..
impl_sm_context::get_diagnostic_tree could be expensive, and
I find myself needing to put a breakpoint on it to debug
PR analyzer/99771, so only call it if we're about to use
the result.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r11-7917-g0f9aa35c79a0fe195d5
This was made redundant in the GCC 11 rewrite of state
(808f4dfeb3a95f50f15e71148e5c1067f90a126d).
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as d0b7c821754e2b16e9e84d877082105799adf238.
gcc/analyzer/ChangeLog:
* region.h (region::dump_to_pp): Remove ol
The mma_assemble_input_operand predicate does not accept reg+reg indexed
addresses which can lead to ICEs. The problem is that the quad_address_p
function only accepts reg+offset addresses that are valid for quad word
accesses, but not reg+reg addresses which are also valid for quad word
accesses
> It looks like the latter - I've seen no attempt by the original authors to
> make the feature work on more targets than they cared for.
On the other hand, if you hide the failures, there is essentially zero chance
that architecture maintainers pick up the pieces (I personally implemented the
S
On Tue, Mar 30, 2021 at 5:01 PM Jakub Jelinek wrote:
>
> On Tue, Mar 30, 2021 at 02:33:17PM +0200, Richard Biener via Gcc-patches
> wrote:
> > > I don't know, perhaps.
> > > Seems the target hook is only defined on
> > > config/i386/i386.c:#undef TARGET_ZERO_CALL_USED_REGS
> > > config/i386/i386.
On Tue, Mar 23, 2021 at 12:59 AM H.J. Lu via Gcc-patches
wrote:
>
> On Mon, Mar 22, 2021 at 7:10 AM Jan Hubicka wrote:
> >
> > >
> > > gcc/
> > >
> > > * config/i386/i386-expand.c (expand_set_or_cpymem_via_rep):
> > > For TARGET_PREFER_KNOWN_REP_MOVSB_STOSB, don't convert QImode
> > >
46 matches
Mail list logo
