On 25 January 2018 at 11:24, Richard Sandiford
wrote:
> Rainer Orth writes:
>> Jeff Law writes:
>>> On 11/22/2017 11:12 AM, Richard Sandiford wrote:
Richard Sandiford writes:
> This patch adds support for the SVE bitwise reduction instructions
> (ANDV, ORV and EORV). It's a fairly
Christophe Lyon writes:
> On 25 January 2018 at 11:24, Richard Sandiford
> wrote:
>> Rainer Orth writes:
>>> Jeff Law writes:
On 11/22/2017 11:12 AM, Richard Sandiford wrote:
> Richard Sandiford writes:
>> This patch adds support for the SVE bitwise reduction instructions
>> (
On 26 January 2018 at 10:33, Richard Sandiford
wrote:
> Christophe Lyon writes:
>> On 25 January 2018 at 11:24, Richard Sandiford
>> wrote:
>>> Rainer Orth writes:
Jeff Law writes:
> On 11/22/2017 11:12 AM, Richard Sandiford wrote:
>> Richard Sandiford writes:
>>> This patch
On Thu, 25 Jan 2018, Richard Biener wrote:
> On Thu, 25 Jan 2018, Marc Glisse wrote:
>
> > On Thu, 25 Jan 2018, Richard Biener wrote:
> >
> > > --- gcc/match.pd (revision 257047)
> > > +++ gcc/match.pd (working copy)
> > > @@ -1939,6 +1939,37 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> > >
On Thu, Jan 25, 2018 at 12:18:21PM +0100, Richard Biener wrote:
> 2018-01-25 Richard Biener
>
> PR rtl-optimization/84003
> * dse.c (dse_step1): When removing redundant stores make sure
> to adjust the earlier stores alias-set to match semantics of
> the removed one and
On 24/01/18 20:10, Richard Sandiford wrote:
Szabolcs Nagy writes:
Fix test failures with -mcmodel=tiny when adr is generated instead of adrp.
FAIL: gcc.target/aarch64/sve/peel_ind_1.c -march=armv8.2-a+sve
scan-assembler \\tadrp\\tx[0-9]+, x\\n
FAIL: gcc.target/aarch64/sve/peel_ind_2.c -march=a
On Thu, 25 Jan 2018, Richard Sandiford wrote:
> Richard Sandiford writes:
> > Richard Biener writes:
> >> The following patch fixes PR84003 where RTL DSE removes a redundant
> >> store (a store storing the same value as an earlier store) but in
> >> doing this changing program semantics because
On Thu, 25 Jan 2018, Jan Hubicka wrote:
> Hi,
> the testcase triggers invalid warning on type mismatch because array
> of pointers to complete type has different alias set from array of pointers
> to incomplete type. This is valid, because incoplete pointer has alias set
> of void_ptr which alias
On Thu, 25 Jan 2018, Segher Boessenkool wrote:
> On Thu, Jan 25, 2018 at 11:20:33PM +0100, Jakub Jelinek wrote:
> > Hi!
> >
> > The r241060 change added the second hunk in this patch which the patch is
> > reverting. The problem is that not deleting some unmarked insns in
> > delete_unmarked_ins
On Thu, 25 Jan 2018, Jakub Jelinek wrote:
> Hi!
>
> builtin_memref ctor for a SSA_NAME with non-NULL SSA_NAME_VAR returns
> the underlying variable, rather than just the SSA_NAME.
> Later on the code checks if the bases are equal and then compares
> corresponding offsets.
>
> The fact that two d
On Fri, 26 Jan 2018, Jakub Jelinek wrote:
> On Thu, Jan 25, 2018 at 12:18:21PM +0100, Richard Biener wrote:
> > 2018-01-25 Richard Biener
> >
> > PR rtl-optimization/84003
> > * dse.c (dse_step1): When removing redundant stores make sure
> > to adjust the earlier stores alias-set t
Richard Biener writes:
> On Thu, 25 Jan 2018, Richard Sandiford wrote:
>
>> Richard Sandiford writes:
>> > Richard Biener writes:
>> >> The following patch fixes PR84003 where RTL DSE removes a redundant
>> >> store (a store storing the same value as an earlier store) but in
>> >> doing this cha
HI DJ,
Thank you!
>> I wonder if these types of optimizations should be added to the
assembler too?
Thank you for the suggestion, I will take a look into it.
Best Regards,
Sebastian
> -Original Message-
> From: DJ Delorie [mailto:d...@redhat.com]
> Sent: 25 January 2018 19:38
> To: S
Hi,
I would like to commit the following comment about LEON3-FT errata now
available in GCC-7.3.
Thanks,
Daniel
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.98
On Fri, 26 Jan 2018, Richard Sandiford wrote:
> Richard Biener writes:
> > On Thu, 25 Jan 2018, Richard Sandiford wrote:
> >
> >> Richard Sandiford writes:
> >> > Richard Biener writes:
> >> >> The following patch fixes PR84003 where RTL DSE removes a redundant
> >> >> store (a store storing th
Sebastian, thanks for the feedback! I have updated the patch accordingly:
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.98
diff -u -r1.98 changes.html
--- htdocs/gcc
> On Thu, 25 Jan 2018, Jan Hubicka wrote:
>
> > Hi,
> > the testcase triggers invalid warning on type mismatch because array
> > of pointers to complete type has different alias set from array of pointers
> > to incomplete type. This is valid, because incoplete pointer has alias set
> > of void_p
On Thu, Jan 25, 2018 at 3:45 PM, Jakub Jelinek wrote:
> On Fri, Jan 05, 2018 at 09:52:36AM +0100, Richard Biener wrote:
>> On Wed, Jan 3, 2018 at 5:31 PM, Marek Polacek wrote:
>> > Here we are crashing because cxx_fold_indirect_ref got a POINTER_PLUS_EXPR
>> > with offset > signed HOST_WIDE_INT a
This is a backport of r251426 which incidentally fixed PR 81860 and
its dup. The bug was closed as fixed, but as a regression it should be
fixed for 7.x too.
The patch applied cleanly to the branch except for a minor conflict in
get_defaulted_eh_spec because r250994 isn't on the branch.
Tested x
LRA was using a subreg offset of 0 whenever constraints matched
two operands with different modes. That leads to an invalid offset
(and ICE) on big-endian targets if one of the modes is narrower
than a word. E.g. if a (reg:SI X) is matched to a (reg:QI Y),
the big-endian subreg should be (subreg:
sve/extract_[12].c were relying on the target-independent optimisation
that removes a redundant vec_select, so that we don't end up with
things like:
dup v0.4s, v0.4s[0]
...use s0...
But that optimisation rightly doesn't trigger for big-endian targets,
because GCC expects lane 0 to be in
aarch64_secondary_reload enforced a secondary reload via
aarch64_sve_reload_be for memory and pseudo registers, but failed
to do the same for subregs of pseudo registers. To avoid this and
any similar problems, the patch instead tests for things that the move
patterns handle directly; if the opera
I'm applying this backport to the gcc-7 branch. Jonathan was kind
enough to point out it's needed tehre.
nathan
--
Nathan Sidwell
2018-01-26 Nathan Sidwell
PR c++/82878
PR c++/78495
* call.c (build_call_a): Don't set CALL_FROM_THUNK_P for inherited
ctor.
* cp-gimplify.c (cp_genericize_
On Fri, 26 Jan 2018, Jan Hubicka wrote:
> > On Thu, 25 Jan 2018, Jan Hubicka wrote:
> >
> > > Hi,
> > > the testcase triggers invalid warning on type mismatch because array
> > > of pointers to complete type has different alias set from array of
> > > pointers
> > > to incomplete type. This is
The current aarch64_simd_valid_immediate code predates the move
to the new CONST_VECTOR representation, so for variable-length SVE
it only handles duplicates of single elements, rather than duplicates
of repeating patterns.
This patch removes the restriction. It means that the validity
of a dupli
The fallback way of handling a repeated 128-bit constant vector for SVE
is to force the 128 bits to the constant pool and use LD1RQ to load it.
Previously the code always used the byte variant of LD1RQ (LD1RQB),
with a preceding BSWAP for big-endian targets. However, that BSWAP
doesn't handle all
> On Fri, 26 Jan 2018, Jan Hubicka wrote:
>
> > > On Thu, 25 Jan 2018, Jan Hubicka wrote:
> > >
> > > > Hi,
> > > > the testcase triggers invalid warning on type mismatch because array
> > > > of pointers to complete type has different alias set from array of
> > > > pointers
> > > > to incomple
This patch deals with cases in which a CONST_VECTOR contains a
repeating bit pattern that is wider than one element but narrower
than 128 bits. The current code:
* treats the repeating pattern as a single element
* uses the associated LD1R to load and replicate it (such as LD1RD
for 64-bit patt
Subreg reads should be equivalent to storing the inner register to
memory and loading the appropriate memory bytes back, with subreg
writes doing the reverse. For the reasons explained in the comments,
this isn't what happens for big-endian SVE if we simply reinterpret
one vector register as havin
Hi Richard,
On 26/01/18 13:31, Richard Sandiford wrote:
sve/extract_[12].c were relying on the target-independent optimisation
that removes a redundant vec_select, so that we don't end up with
things like:
dup v0.4s, v0.4s[0]
...use s0...
But that optimisation rightly doesn't trigger f
I hadn't realised that on big-endian targets, VEC_UNPACK*HI_EXPR unpacks
the low-numbered lanes and VEC_UNPACK*LO_EXPR unpacks the high-numbered
lanes. This meant that both the SVE patterns and the handling of
fully-masked loops were wrong.
The patch deals with that by making sure that all vec_un
On Sun, Jan 7, 2018 at 7:13 PM, H.J. Lu wrote:
> On Fri, Dec 8, 2017 at 5:02 AM, H.J. Lu wrote:
>> On Tue, Oct 24, 2017 at 5:31 AM, H.J. Lu wrote:
>>> PLT should be avoided with shadow stack in 32-bit mode if more than 2
>>> parameters are passed in registers since only 2 parameters can be passe
On Sun, Jan 7, 2018 at 7:11 PM, H.J. Lu wrote:
> On Tue, Oct 24, 2017 at 10:58 AM, H.J. Lu wrote:
>> On Tue, Oct 24, 2017 at 10:40 AM, Andi Kleen wrote:
>>> "H.J. Lu" writes:
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr82699-4.c
@@ -0,0 +1,11 @@
+/* { dg-do compile {
The SVE tests are split into code-quality compile tests and runtime
tests. A lot of the former are geared towards LP64. It would be
possible (but tedious!) to mark up every line that is expected to work
only for LP64, but I think it would be a constant source of problems.
Since the code has not
Hi all,
I'm committing this to trunk after a discussion with James.
There's really not that much aarch64-specific change, it can be considered
obvious from that perspective.
Thanks,
Kyrill
On 19/01/18 10:58, Kyrill Tkachov wrote:
Ping.
https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00913.html
Ping^2
http://gcc.gnu.org/ml/gcc-patches/2018-01/msg00727.html
On Wed, Jan 17, 2018 at 05:47:12PM +0100, Jakub Jelinek wrote:
> I'd like to ping this patch.
> As I wrote, it isn't a full solution for all the __VA_OPT__ issues,
> but it isn't even clear to me how exactly it should behave, but fixes
On Thu, Jan 25, 2018 at 05:58:37PM -0200, Alexandre Oliva wrote:
> > This looks wrong. The proposal has not been accepted yet, so you
> > really can't know if DW_LLE_view_pair will be like that or whether it
> > will have value of 9. Unfortunately, the DWARF standard doesn't specify a
> > vendor
On 26 January 2018 at 11:25, Richard Biener wrote:
> On Thu, 25 Jan 2018, Richard Biener wrote:
>
>> On Thu, 25 Jan 2018, Marc Glisse wrote:
>>
>> > On Thu, 25 Jan 2018, Richard Biener wrote:
>> >
>> > > --- gcc/match.pd (revision 257047)
>> > > +++ gcc/match.pd (working copy)
>> > > @@ -1939,6
On Fri, Jan 26, 2018 at 3:21 PM, Richard Sandiford
wrote:
> I hadn't realised that on big-endian targets, VEC_UNPACK*HI_EXPR unpacks
> the low-numbered lanes and VEC_UNPACK*LO_EXPR unpacks the high-numbered
> lanes. This meant that both the SVE patterns and the handling of
> fully-masked loops we
Richard Biener writes:
> On Fri, Jan 26, 2018 at 3:21 PM, Richard Sandiford
> wrote:
>> I hadn't realised that on big-endian targets, VEC_UNPACK*HI_EXPR unpacks
>> the low-numbered lanes and VEC_UNPACK*LO_EXPR unpacks the high-numbered
>> lanes. This meant that both the SVE patterns and the hand
On Fri, Jan 26, 2018 at 3:57 PM, Christophe Lyon
wrote:
> On 26 January 2018 at 11:25, Richard Biener wrote:
>> On Thu, 25 Jan 2018, Richard Biener wrote:
>>
>>> On Thu, 25 Jan 2018, Marc Glisse wrote:
>>>
>>> > On Thu, 25 Jan 2018, Richard Biener wrote:
>>> >
>>> > > --- gcc/match.pd (revision
Kyrill Tkachov writes:
> On 26/01/18 13:31, Richard Sandiford wrote:
>> sve/extract_[12].c were relying on the target-independent optimisation
>> that removes a redundant vec_select, so that we don't end up with
>> things like:
>>
>> dup v0.4s, v0.4s[0]
>> ...use s0...
>>
>> But that opti
On Fri, Jan 26, 2018 at 4:04 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Fri, Jan 26, 2018 at 3:21 PM, Richard Sandiford
>> wrote:
>>> I hadn't realised that on big-endian targets, VEC_UNPACK*HI_EXPR unpacks
>>> the low-numbered lanes and VEC_UNPACK*LO_EXPR unpacks the high-numbe
The problem here was that when substituting the local class we first
substitute its context, and we weren't finding the rebuilt function
we're inside of, so we tried to create new instantiations of the
closure and call operator, leading to chaos.
The core of this patch is the change to tsubst_func
On 26 January 2018 at 16:13, Richard Biener wrote:
> On Fri, Jan 26, 2018 at 3:57 PM, Christophe Lyon
> wrote:
>> On 26 January 2018 at 11:25, Richard Biener wrote:
>>> On Thu, 25 Jan 2018, Richard Biener wrote:
>>>
On Thu, 25 Jan 2018, Marc Glisse wrote:
> On Thu, 25 Jan 2018, Ri
Hello!
It turned out that *andndi3_doubleword pattern needs earlyclobber on
the output operand of its (=r,r,rm) alternative to prevent partial
regs of the first split instruction from clobbering input operands of
the second insn.The patch also adds a couple of alternatives with
matching input and
There's another latent bug in loop unrolling edge/region removal code
which doesn't deal with removing edges in already removed regions.
The following fixes this.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2018-01-26 Richard Biener
PR tree-optimization/
I've applied this patch to openacc-gcc-7-branch which privatizes
reduction variables inside independent loops which are guaranteed to be
assigned worker or vector partitioning during oaccdevlow. Without this
patch, the inner-reduction.c test case would generate bogus results.
This patch is an exten
Hi.
This fixes detection of ifunc target capability.
I'm going to install the patch.
Martin
gcc/testsuite/ChangeLog:
2018-01-26 Martin Liska
* lib/target-supports.exp: Return a value, otherwise -Wreturn-type
warning is seen.
---
gcc/testsuite/lib/target-supports.exp | 2 +-
My recent patch for 82249 caused a substitution here to return a
TREE_VEC rather than an EXPR_PACK_EXPANSION; fixed by pulling out the
expansion in that case.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 577e646e8472e6bc226168fb96d0884663b0c2cd
Author: Jason Merrill
Date: Fri Jan 26 10
On Tue, Jan 23, 2018 at 02:49:03PM +, Kyrill Tkachov wrote:
> Hi all,
>
> This patch fixes the testsuite failures gcc.target/aarch64/subs_compare_1.c
> and subs_compare_2.c The tests check that we combine a sequence like:
> sub w2, w0, w1
> cmp w0, w1
>
> into
>
On 01/22/2018 09:33 AM, Jakub Jelinek wrote:
On Tue, Jan 16, 2018 at 03:20:24PM -0700, Martin Sebor wrote:
gcc/ChangeLog:
PR tree-optimization/83896
* tree-ssa-strlen.c (get_string_len): Rename...
(get_string_cst_length): ...to this. Return HOST_WIDE_INT.
Avoid
On Mon, 2017-12-11 at 17:24 -0500, Jason Merrill wrote:
> On Wed, Nov 22, 2017 at 10:36 AM, David Malcolm
> wrote:
Original post:
https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02048.html
> > PR c++/81610 and PR c++/80567 report problems where the C++
> > frontend
> > suggested "if", "for" and
Thist patch merges the safe-indirect-jump-1.c and -8.c testcases,
since they do the same thing. On the 64-bit and AIX ABIs the indirect
call is not a sibcall, since there is code generated after the call
(the restore of r2). On the 32-bit non-AIX ABIs it is a sibcall.
Tested on powerpc64-linux {
Committed revision 257105.
Thanks.
On Wed, Jan 24, 2018 at 3:17 PM, Jakub Jelinek wrote:
> On Wed, Jan 24, 2018 at 08:19:58PM +, Paul Richard Thomas wrote:
>> (Jakub, This is all hidden behind the -fcoarray option. To my mind
>> this is safe for release.)
>
> Ok from RM POV.
>
> Jaku
On Fri, Jan 26, 2018 at 2:27 PM, Segher Boessenkool
wrote:
> Thist patch merges the safe-indirect-jump-1.c and -8.c testcases,
> since they do the same thing. On the 64-bit and AIX ABIs the indirect
> call is not a sibcall, since there is code generated after the call
> (the restore of r2). On t
Here, when we walk the subobjects to determine the exception
specification of a defaulted destructor in order to apply it to a
user-provided destructor, we shouldn't look at variant members dtors,
which aren't called.
We really shouldn't be looking at variant members here at all except
to determin
This makes --specs=nosys.specs work correctly. Without this patch, libnosys
is ignored because libgloss gets pulled in first. We may have to revisit this
in the future when we have some proper BSPs defined for various RISC-V
hardware. Meanwhile, adding libgloss by default makes things easier for
On Thu, 2018-01-25 at 18:53 +, Bernd Edlinger wrote:
> Hi,
>
> as PR diagnostic/84034 shows, source files with
> dos style line endings can cause a glitch in the
> terminal emulation that erases the source line that
> is supposed to be shown.
>
> That happens when the colorizing escape sequen
Hi!
Honza reported today on IRC that we spent (again) significant time
of empty file compilation computing preprocessor *_MAX/*_MIN etc. macros.
In 2010 I've added lazy computation for these, only when they are first used
except for -dD, but reserved just 12 entries for those, as only
FLT/DBL/LDBL
Hi!
On a testcase which has 10 consecutive debug insns sched2 spends
a lot of time calling prev_nonnote_nondebug_insn on each of the debug
insns, even when it is completely useless, because no target wants
to fuse a non-debug insn with some debug insn after it, it makes sense
only for two non-
Hi!
resolve_charlen is going to error on ilp32 target charlens above what
can fit into 32-bit signed int, but add_init_expr_to_sym is done before
resolve_charlen, allocating huge amounts of memory in those cases
when we'll error later is just waste of compile time if running on 64-bit
host with en
On Sat, 27 Jan 2018, Jakub Jelinek wrote:
> Hi!
>
> Honza reported today on IRC that we spent (again) significant time
> of empty file compilation computing preprocessor *_MAX/*_MIN etc. macros.
> In 2010 I've added lazy computation for these, only when they are first used
> except for -dD, but r
On Fri, Jan 26, 2018 at 02:11:19PM +0100, Richard Biener wrote:
> >> POINTER_PLUS_EXPR offets are to be interpreted as signed (ptrdiff_t)
> >> so using uhwi and then performing an unsigned division is wrong code.
> >> See mem_ref_offset how to deal with this (ugh - poly-ints...). Basically
> >> yo
On Fri, Jan 26, 2018 at 11:22:04PM +, Joseph Myers wrote:
> On Sat, 27 Jan 2018, Jakub Jelinek wrote:
> > Honza reported today on IRC that we spent (again) significant time
> > of empty file compilation computing preprocessor *_MAX/*_MIN etc. macros.
> > In 2010 I've added lazy computation for
The attached patch implements a check for F2015:C830.
The wording of the F2008:C531 is nearly identical, but
the restriction on BLOCK is noted in the normative test.
The 3 lines in the new testcase show be sufficient to
see the issue. In regression testing, I needed to
adjust the regex pattern in
On Sat, 27 Jan 2018, Jakub Jelinek wrote:
> Works for me, this tests fine on a couple of tests, ok for trunk if it
> passes bootstrap/regtest?
>
> 2018-01-27 Jakub Jelinek
>
> * c-cppbuiltin.c (c_cpp_builtins): Use ggc_strdup for the fp_suffix
> argument.
> (LAZY_HEX_FP_VALU
On Thu, Jan 18, 2018 at 12:23 AM, Uros Bizjak wrote:
> On Wed, Jan 17, 2018 at 5:00 PM, H.J. Lu wrote:
>> We can use const reference of struct ix86_frame to avoid making a local
>> copy of ix86_frame. ix86_expand_epilogue makes a local copy of struct
>> ix86_frame and uses the reg_save_offset fi
This patch to the Go frontend shows readable names in the messages
printed for escape analysis. This will print names like `x` instead
of `.p.x`. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
==
This was noticed while looking at some 64-bit libgcc code. Some functions
like negti had a stack frame allocated, but did not use the stack. The 32-bit
equivalent negdi did not have a stack frame allocated. This is because a
128-bit local variable got allocated to the stack and then optimized aw
On 01/26/2018 06:15 PM, Jakub Jelinek wrote:
Hi!
On a testcase which has 10 consecutive debug insns sched2 spends
a lot of time calling prev_nonnote_nondebug_insn on each of the debug
insns, even when it is completely useless, because no target wants
to fuse a non-debug insn with some debu
On Fri, 26 Jan 2018, Richard Biener wrote:
> On Fri, 26 Jan 2018, Richard Sandiford wrote:
>
> > Richard Biener writes:
> > > On Thu, 25 Jan 2018, Richard Sandiford wrote:
> > >
> > >> Richard Sandiford writes:
> > >> > Richard Biener writes:
> > >> >> The following patch fixes PR84003 where R
72 matches
Mail list logo
