The problem here was that cp_parser_requires_expression committing to a
tentative parse confused cp_parser_decltype_expr, which needs to still be
tentative. The only reason to commit here is to get syntax errors within
the requires-expression, which we can still do when the commit is firewalled
fr
Hi,
This patch merges the libphobos implementation with the upstream phobos
fb4f6a713.
Improves the versioning of IeeeFlags and FloatingPointControl code and
unit-tests, making it clearer which targets can and cannot support it.
Bootstrapped and regression tested on x86_64-linux-gnu, and committ
When GCC9 is built with an older GCC (4.2.1) on FreeBSD 32-bit on PowerPC
an ICE is generated on stage 1 when selftests are performed.
After an investigation the root cause was traced to an unnecessary and
harmful instantiation of a new dump_context singleton class in order to
get the current acti
Currently an use of get() method of dump_context singleton in optinfo
framework causes a new class to be instantiated and when its dtor
is called it calls delete on uninitialized data, causing an ICE.
It happens when a temporary dump_context is instantiated for the 'm_saved'
initialization in temp
On 04/07/2020 03:24 AM, Jakub Jelinek wrote:
On Mon, Apr 06, 2020 at 09:42:17PM -0400, David Malcolm via Gcc-patches wrote:
2020-04-06 Gustavo Romero
* dumpfile.c:
(selftest::temp_dump_context::temp_dump_context): Fix ctor.
---
gcc/dumpfile.c | 2 +-
1 file changed, 1 inse
Hi David,
On 04/06/2020 10:42 PM, David Malcolm wrote:
On Mon, 2020-04-06 at 19:44 -0400, Gustavo Romero wrote:
Thanks for this patch.
The patch looks correct, but I'm not sure that the description of the
problem is exact in every detail. I think you've run into a bug in
code I wrote; sorry.
On 4/7/20 4:58 PM, Segher Boessenkool wrote:
>> I wonder if it would be helpful to have
>>
>> (uoverflow_plus x y carry)
>> (soverflow_plus x y carry)
>>
>> etc.
>
> Those have three operands, which is nasty to express.
How so? It's a perfectly natural operation.
> On rs6000 we have the car
On Wed, 2020-04-08 at 00:55 +0200, Jakub Jelinek wrote:
> Hi!
>
> The following testcase shows two separate issues caused by the cselib
> changes.
> One is that through the cselib sp tracking improvements on
> ... r12 = rsp; rsp -= 8; push cst1; push cst2; push cst3; call
> rsp += 32; rsp -= 8; pu
On Tue, Apr 07, 2020 at 02:43:36PM -0700, Richard Henderson wrote:
> On 4/7/20 1:27 PM, Segher Boessenkool wrote:
> > On Mon, Apr 06, 2020 at 12:19:42PM +0100, Richard Sandiford wrote:
> >> The reason I'm not keen on using special modes for this case is that
> >> they'd describe one way in which th
Whee, more fallout from the cselib work. This is clearly another backend bug.
The H8 port has this peephole:
;; Turn
;;
;; mov.l er7,er0
;; add.l #10,er0 (takes 8 bytes)
;;
;; into
;;
;; sub.l er0,er0
;; add.b #10,r0l
;; add.l er7,er0 (takes 6 bytes)
(define_peephole2
[(set (match_
Hi!
On Mon, Apr 06, 2020 at 12:52:04PM -0400, Michael Meissner wrote:
> Commit message:
> Enable -mpcrel for -mcpu=future if it is allowed by the ABI.
You can just put this in the mail subject. No dot at the end, but start
with a capital, an put a subsystem label on it:
Subject: rs6000: Enable
Hi!
The following testcase shows two separate issues caused by the cselib
changes.
One is that through the cselib sp tracking improvements on
... r12 = rsp; rsp -= 8; push cst1; push cst2; push cst3; call
rsp += 32; rsp -= 8; push cst4; push cst5; push cst6; call
rsp += 32; rsp -= 8; push cst7; pu
On Tue, 2020-04-07 at 22:35 +, Joseph Myers wrote:
> This introduces an ICE building glibc for m68k (and the same ICE appears
> for microblaze, though I haven't bisected there). See bug 94526.
Yea, I've already forwarded Jakub the microblaze testcase.
jeff
This introduces an ICE building glibc for m68k (and the same ICE appears
for microblaze, though I haven't bisected there). See bug 94526.
--
Joseph S. Myers
jos...@codesourcery.com
Hi!
On Sat, Apr 04, 2020 at 10:21:00AM +1030, Alan Modra wrote:
> I have a series of small patches already, the most significant so far
> being the one that adds the following comment to rs6000_rtx_costs:
>
> "Calls from places like optabs.c:avoid_expensive_constant will come
>here with OUT
On 4/7/20 1:27 PM, Segher Boessenkool wrote:
> On Mon, Apr 06, 2020 at 12:19:42PM +0100, Richard Sandiford wrote:
>> The reason I'm not keen on using special modes for this case is that
>> they'd describe one way in which the result can be used rather than
>> describing what the instruction actuall
On Tue, Apr 07, 2020 at 02:46:52PM -0600, Martin Sebor wrote:
> On 4/7/20 1:50 PM, Marek Polacek wrote:
> > On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches
> > wrote:
> > > Among the numerous regressions introduced by the change committed
> > > to GCC 9 to allow string liter
On 4/7/20 1:40 PM, Patrick Palka wrote:
On Mon, 6 Apr 2020, Jason Merrill wrote:
On 4/6/20 11:45 AM, Patrick Palka wrote:
On Wed, 1 Apr 2020, Jason Merrill wrote:
On 4/1/20 6:29 PM, Jason Merrill wrote:
On 3/31/20 3:50 PM, Patrick Palka wrote:
On Tue, 31 Mar 2020, Jason Merrill wrote:
On
Hi!
On Mon, Mar 30, 2020 at 12:18:59PM +0800, luoxhu wrote:
> >>>If df_regs_ever_live_p(31) is false there is no hard frame pointer
> >>>anywhere in the program. How can it be used then?
> >>
> >>There is a piece of code emit move instruction to r31 even
> >>df_regs_ever_live_p(31) is false
> >>
On Mon, Apr 06, 2020 at 11:46:17AM +0530, kamlesh kumar wrote:
> Segher,
> Please provide your suggestion/thought on the fix.
Why me?
I cannot approve almost all of this patch. It is huge. It is stage 1
so patches like this should not be submitted at all now (you can ask for
people to look at i
Here the 'decltype' is missing '(auto)', so open_paren was NULL, and trying
to get its location is a SEGV. Using matching_parens avoids that problem.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog
2020-04-07 Jason Merrill
PR c++/94481
* parser.c (cp_parser_pl
On 4/7/20 1:50 PM, Marek Polacek wrote:
On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches wrote:
Among the numerous regressions introduced by the change committed
to GCC 9 to allow string literals as template arguments is a failure
to recognize the C++ nullptr and GCC's __nu
The Power processor has the ability to fuse certain pairs of dependent
instructions to improve their performance if they appear back-to-back in
the instruction stream. In looking at the current support for
instruction fusion in GCC I saw the following 2 options.
1) TARGET_SCHED_MACRO_FUSION target
On Tue, 7 Apr 2020, Patrick Palka wrote:
> On Mon, 6 Apr 2020, Jason Merrill wrote:
> > On 4/6/20 11:45 AM, Patrick Palka wrote:
> > > On Wed, 1 Apr 2020, Jason Merrill wrote:
> > >
> > > > On 4/1/20 6:29 PM, Jason Merrill wrote:
> > > > > On 3/31/20 3:50 PM, Patrick Palka wrote:
> > > > > > On Tu
On Mon, Apr 06, 2020 at 12:19:42PM +0100, Richard Sandiford wrote:
> The reason I'm not keen on using special modes for this case is that
> they'd describe one way in which the result can be used rather than
> describing what the instruction actually does. The instruction really
> does set all fou
Hi!
I've backported following 21 commits from trunk to 9.4,
bootstrapped/regtested on x86_64-linux and i686-linux and committed to 9
branch.
Jakub
>From 980a7a0be5a114e285c49ab05ac70881e4f27fc3 Mon Sep 17 00:00:00 2001
From: Jakub Jelinek
Date: Tue, 17 Mar 2020 21:21:16 +0100
Subject: [P
On Tue, Apr 07, 2020 at 12:50:48PM -0600, Martin Sebor via Gcc-patches wrote:
> Among the numerous regressions introduced by the change committed
> to GCC 9 to allow string literals as template arguments is a failure
> to recognize the C++ nullptr and GCC's __null constants as pointers.
> For one,
Hi!
On Tue, Apr 07, 2020 at 10:52:10AM +0100, Richard Earnshaw (lists) wrote:
> On 06/04/2020 12:19, Richard Sandiford wrote:
> > "Richard Earnshaw (lists)" writes:
> >> Yes. It surprised me, when doing the aarch32 version, just how often
> >> the mid-end parts of the compiler were able to reaso
On Tue, 2020-04-07 at 21:31 +0200, Martin Jambor wrote:
> Hi Jeff,
>
> On Tue, Apr 07 2020, Jeff Law wrote:
> > On Tue, 2020-04-07 at 18:25 +0200, Martin Jambor wrote:
> > > Hi,
> > >
> > > On Tue, Apr 07 2020, Richard Biener wrote:
> > > > On Tue, 7 Apr 2020, Martin Jambor wrote:
> > > >
> > >
Hi Jeff,
On Tue, Apr 07 2020, Jeff Law wrote:
> On Tue, 2020-04-07 at 18:25 +0200, Martin Jambor wrote:
>> Hi,
>>
>> On Tue, Apr 07 2020, Richard Biener wrote:
>> > On Tue, 7 Apr 2020, Martin Jambor wrote:
>> >
>> > > Hi,
>> > >
>> > > when sra_modify_expr is invoked on an expression that modif
On Mon, Apr 6, 2020 at 5:51 PM Ian Lance Taylor wrote:
>
> I merged master revision 52fa80f853c0b0f623ea9e4c7198e324ce44ff30 to
> the gccgo branch.
Another merge from master to gccgo branch, of revision
50c7853216e8511971c55b51d7fe29173db4749b.
Ian
Hi!
(I have no idea why this PR is a P1).
On Tue, Mar 31, 2020 at 09:04:18AM +0200, Jakub Jelinek wrote:
> The following testcase ICEs on armv7hl-linux-gnueabi.
Also on default arm-linux-gnueabi. It needs -Og.
> try_combine is called on:
> (gdb) p debug_rtx (i3)
> (insn 20 12 22 2 (set (mem/c:
Here we ICE because early_check_defaulted_comparison passed a null
ctx to same_type_p. The attached test is ill-formed according to
[class.compare.default]/1, so fixed by detecting this case early.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/94478 - ICE with defau
On 07.04.20 18:26, Iain Buclaw wrote:
>
>
> On 07/04/2020 16:33, Stefan Liebler wrote:
>> On 4/1/20 6:20 PM, Stefan Liebler wrote:
>>> On 4/1/20 12:50 PM, Iain Buclaw wrote:
On 01/04/2020 08:28, Stefan Liebler wrote:
> ping
>
Hi Stefan,
As I've already s
On Tue, 2020-04-07 at 18:25 +0200, Martin Jambor wrote:
> Hi,
>
> On Tue, Apr 07 2020, Richard Biener wrote:
> > On Tue, 7 Apr 2020, Martin Jambor wrote:
> >
> > > Hi,
> > >
> > > when sra_modify_expr is invoked on an expression that modifies only
> > > part of the underlying replacement, such a
Among the numerous regressions introduced by the change committed
to GCC 9 to allow string literals as template arguments is a failure
to recognize the C++ nullptr and GCC's __null constants as pointers.
For one, I didn't realize that nullptr, being a null pointer constant,
doesn't have a pointer
On Tue, Apr 7, 2020 at 3:33 AM Jakub Jelinek wrote:
>
> On Tue, Apr 07, 2020 at 12:19:45PM +0200, Richard Biener via Gcc-patches
> wrote:
> > On Fri, Apr 3, 2020 at 11:59 PM Ian Lance Taylor via Gcc-patches
> > wrote:
> > >
> > > The split-stack code invokes mmap and munmap with a limited amount
On Mon, 6 Apr 2020, Jason Merrill wrote:
> On 4/6/20 11:45 AM, Patrick Palka wrote:
> > On Wed, 1 Apr 2020, Jason Merrill wrote:
> >
> > > On 4/1/20 6:29 PM, Jason Merrill wrote:
> > > > On 3/31/20 3:50 PM, Patrick Palka wrote:
> > > > > On Tue, 31 Mar 2020, Jason Merrill wrote:
> > > > >
> > > >
When gimplifying an address operand we may expose an indirect
ref via DECL_VALUE_EXPR for example. This is dealt with in the
code already but it fails to consider that INDIRECT_REFs get
gimplified to MEM_REFs.
Fixed which makes the ICE observed on x86_64-netbsd go away.
Bootstrapped and tested
On 4/7/20 9:32 AM, Richard Sandiford wrote:
> It's not really reversibility that I'm after (at least not for its
> own sake).
>
> If we had a three-input compare_cc rtx_code that described a comparison
> involving a carry input, we'd certainly be using it here, because that's
> what the instructio
This C++17 header is supported in C++14 as a GNU extension, but stopped
working last year because I made it depend on an internal helper which
is only defined for C++17 and up.
PR libstdc++/94520
* include/std/charconv (__integer_to_chars_result_type)
(__integer_from_chars_
"Richard Earnshaw (lists)" writes:
> On 06/04/2020 12:19, Richard Sandiford wrote:
>> "Richard Earnshaw (lists)" writes:
>>> On 03/04/2020 16:03, Richard Sandiford wrote:
"Richard Earnshaw (lists)" writes:
> On 03/04/2020 13:27, Richard Sandiford wrote:
>> "Richard Earnshaw (lists)"
Hi all,
A straight backport of
[AArch64] Fix memmodel index in aarch64_store_exclusive_pair
Found via an rtx checking failure.
2019-09-23 Richard Sandiford
gcc/
* config/aarch64/atomics.md (aarch64_store_exclusive_pair): Fix
memmodel index.
Bootstrap
On April 7, 2020 6:25:26 PM GMT+02:00, Martin Jambor wrote:
>Hi,
>
>On Tue, Apr 07 2020, Richard Biener wrote:
>> On Tue, 7 Apr 2020, Martin Jambor wrote:
>>
>>> Hi,
>>>
>>> when sra_modify_expr is invoked on an expression that modifies only
>>> part of the underlying replacement, such as a BIT_F
On 07/04/2020 16:33, Stefan Liebler wrote:
> On 4/1/20 6:20 PM, Stefan Liebler wrote:
>> On 4/1/20 12:50 PM, Iain Buclaw wrote:
>>>
>>>
>>> On 01/04/2020 08:28, Stefan Liebler wrote:
ping
>>>
>>> Hi Stefan,
>>>
>>> As I've already said, I think that the name should be __ibmz_get_tls_of
Hi,
On Tue, Apr 07 2020, Richard Biener wrote:
> On Tue, 7 Apr 2020, Martin Jambor wrote:
>
>> Hi,
>>
>> when sra_modify_expr is invoked on an expression that modifies only
>> part of the underlying replacement, such as a BIT_FIELD_REF on a LHS
>> of an assignment and the SRA replacement's type i
Bin.Cheng wrote:
> On Mon, Mar 16, 2020 at 5:34 PM Bin.Cheng wrote:
>> On Wed, Mar 11, 2020 at 5:07 PM Iain Sandoe wrote:
>>> Bin.Cheng wrote:
>>>
On Thu, Mar 5, 2020 at 10:18 PM Iain Sandoe wrote:
>>> If it helps, I could push a branch to users/iains/ on the FSF git server
>>> with t
On Mon, Apr 6, 2020 at 5:47 PM Steve Kargl
wrote:
[...]
> BTW, if you haven't committed the degree trig functions,
> then I think you should to get the fixes in for 10.1.
Roger that.
---
Fritz
Hi,
An omission spotted while working on open PRs.
tested on x86_64-linux/darwin, applied to master as obvious.
thanks
Iain
In cases that we need to extended the lifetime of a temporary captured
by reference, we make a replacement var for the temporary. This will
be then used to define a cor
On Tue, 7 Apr 2020 at 12:57, Richard Biener wrote:
>
> On Tue, Apr 7, 2020 at 1:46 PM Jonathan Wakely wrote:
> >
> > On Tue, 7 Apr 2020 at 12:40, Richard Biener
> > wrote:
> > >
> > > On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely
> > > wrote:
> > > >
> > > > On Mon, 6 Apr 2020 at 13:45, Nath
Hi.
The patch allows DCE to remove only replaceable operators new and delete.
That's achieved by proper mark up of all these operators in C++ FE.
The patch also brings all tests we've collected so far for the PR.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 07 April 2020 15:19
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC][Arm]: MVE: Add C++ polymorphism and fix some
> more issues
>
> Hi,
>
> This patch adds C++ polymorphism for the MVE intrinsics, by u
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 07 April 2020 15:18
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC][Arm]: MVE: Fixes for pointers used in intrinsics for c++
>
> Hi,
>
> This patch fixes the passing of some pointers to builtins that
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 07 April 2020 15:16
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC][Arm]MVE: Fix -Wall testisms
>
> Hi,
>
> This patch fixes some testisms I found when testing using -Wall/-Werror.
>
> Is this OK for
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 07 April 2020 15:15
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC][Arm]: MVE: make sure we only use the Arm
> namespace variant of vuninitializedq
>
> Hi,
>
> This patch replaces all uses of 'vuninit
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 07 April 2020 15:14
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC][Arm]: MVE: Fix vec extracts to memory
>
> Hi,
>
> This patch fixes vec extracts to memory that can arise from code as seen
> in the
On 4/1/20 6:20 PM, Stefan Liebler wrote:
On 4/1/20 12:50 PM, Iain Buclaw wrote:
On 01/04/2020 08:28, Stefan Liebler wrote:
ping
Hi Stefan,
As I've already said, I think that the name should be
__ibmz_get_tls_offset to make clear that it is an internal function.
Other than that, looks g
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 07 April 2020 15:12
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC][Arm]: MVE Fix immediate constraints on some vector
> instructions
>
> Hi,
>
> This patch fixes the immediate checks on vcvt and vqsh
Hi,
This patch adds C++ polymorphism for the MVE intrinsics, by using the
native C++ polymorphic functions when C++ is used.
It also moves the PRESERVE name macro definitions to the right place so
that the variants without the '__arm_' prefix are not available if we
define the PRESERVE NAMES
Hi,
This patch fixes the passing of some pointers to builtins that expect
slightly different types of pointers. In C this didn't prove an issue,
but when compiling for C++ gcc complains.
Regression tested on arm-none-eabi.
Is this OK for trunk?
2020-04-07 Andre Vieira
* config/
On 07.04.20 09:59, Iain Buclaw wrote:
> On 01/04/2020 18:20, Stefan Liebler wrote:
>> On 4/1/20 12:54 PM, Iain Buclaw wrote:
>>> On 01/04/2020 08:28, Stefan Liebler wrote:
ping
>>>
>>> Thanks, I'll send the patch upstream, as it's the same there.
>>>
>>> Looks OK to me.
>>>
>>> Regards
>>
Hi,
This patch fixes some testisms I found when testing using -Wall/-Werror.
Is this OK for trunk?
gcc/testsuite/ChangeLog:
2020-04-07 Andre Vieira
* gcc.target/arm/mve/intrinsics/vuninitializedq_float.c: Likewise.
* gcc.target/arm/mve/intrinsics/vuninitializedq_float1.c: Li
Hi,
This patch fixes vec extracts to memory that can arise from code as seen
in the testcase added. The patch fixes this by allowing mem operands in
the set of mve_vec_extract patterns, which given the only '=r'
constraint will lead to the scalar value being written to a register and
then sto
Hi,
This patch fixes the immediate checks on vcvt and vqshr(u)n[bt]
instrucitons. It also removes the 'arm_mve_immediate_check' as the
check was wrong and the error message is not much better than the
constraint one, which albeit isn't great either.
Regression tested on arm-none-eabi.
Is t
On 4/7/20 7:29 AM, Jonathan Wakely wrote:
On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
The both operator new and operator delete are looked up in the same
manner. The std does not require a 'matching pair' be found. but it is
extremely poor form for a class to declare exactly one of oper
Hi Jim:
> When I try this patch, I see an error:
>
> rohan:2132$ ./xgcc -B./ -O -march=rv64imafdc -mabi=lp64d tmp.c
> /tmp/ccULN36f.s: Assembler messages:
> /tmp/ccULN36f.s:3: Fatal error:
> -march=rv64i2p0_m2p0_a2p0_f2p0_f2p0_d2p0_c2p0: ISA string is not in
> canonical order. `f'
> rohan:2133$
>
Hi Dennis,
> -Original Message-
> From: Dennis Zhang
> Sent: 07 April 2020 13:31
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Ramana Radhakrishnan ; Kyrylo
> Tkachov
> Subject: Re: [PATCH][Arm][2/4] Custom Datapath Extension intrinsics:
> instructions using FPU/MVE S/D r
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 07 April 2020 11:43
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC][Arm]: MVE Don't use lsll for 32-bit shifts scalar
>
> Hi,
>
> After fixing the v[id]wdups using the "moving the wrap parameter" into
>
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 07 April 2020 11:41
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH][GCC][Arm]: MVE: Fix v[id]wdup's
>
> Hi,
>
> This patch fixes v[id]wdup intrinsics. They had two issues:
> 1) the predicated versions did no
On 07/04/2020 11:57, Christophe Lyon wrote:
On Tue, 7 Apr 2020 at 12:40, Andre Vieira (lists)
wrote:
Hi,
This patch fixes v[id]wdup intrinsics. They had two issues:
1) the predicated versions did not link the incoming inactive vector
parameter to the output
2) The backend didn't enforce the wr
On 2019/11/26 10:49 PM, Chung-Lin Tang wrote:
Hi Thomas,
this is a reorg of the last non-contiguous arrays patch. You'll notice that:
(1) A large part of the code has been pulled into oacc-parallel.c, with most
of the data structure declarations in oacc-int.h.
(2) target.c only contains relativ
Hi!
We need to set OMP_PARALLEL_COMBINED only if the parsing of omp_master
succeeded, because otherwise there is no nested master construct in the
parallel.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk, queued for backporting to 9.x.
2020-04-07 Jakub J
On Tue, Apr 7, 2020 at 2:29 PM Jakub Jelinek wrote:
>
> Hi!
>
> The following testcases are miscompiled, because expand_vec_perm_pshufb
> incorrectly thinks it can use vpshufb instruction for the permutations
> when it can't.
> The
> if (vmode == V32QImode)
> {
>
415.html
> > ISA has been announced at
> > https://developer.arm.com/architectures/instruction-sets/custom-instructions
> >
> > Regtested and bootstrapped for arm-none-linux-gnueabi-armv8-m.main.
> >
> > Is it OK for commit please?
> >
> > Cheers
> > Dennis
> >
arm-m-cde-vcxsidi-final-20200407-rb12663.patch
Description: arm-m-cde-vcxsidi-final-20200407-rb12663.patch
Hi!
The following testcases are miscompiled, because expand_vec_perm_pshufb
incorrectly thinks it can use vpshufb instruction for the permutations
when it can't.
The
if (vmode == V32QImode)
{
/* vpshufb only works intra lanes, it is not
possible
The diff looks weird, but this only removes the first if
(TARGET_HAVE_MVE... ) block and updates the variable 'addr' which is
only used in the consecutive(TARGET_HAVE_MVE ..) blocks. So it doesn't
change NEON codegen.
It's unfortunate the diff looks so complicated :(
Cheers,
Andre
On 07/04/2
On Tue, Apr 7, 2020 at 1:46 PM Jonathan Wakely wrote:
>
> On Tue, 7 Apr 2020 at 12:40, Richard Biener
> wrote:
> >
> > On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely
> > wrote:
> > >
> > > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> > > > The both operator new and operator delete are
On Tue, 7 Apr 2020 at 12:40, Richard Biener wrote:
>
> On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely wrote:
> >
> > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> > > The both operator new and operator delete are looked up in the same
> > > manner. The std does not require a 'matching pai
On Tue, 7 Apr 2020 at 10:29, Richard Biener wrote:
>
> On Tue, Apr 7, 2020 at 10:26 AM Jonathan Wakely wrote:
> >
> > On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> > >
> > > On 4/6/20 4:34 AM, Martin Liška wrote:
> > >
> > > >
> > > > May I please ping Jason, Nathan and Jonathan who can h
On Tue, Apr 7, 2020 at 1:30 PM Jonathan Wakely wrote:
>
> On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> > The both operator new and operator delete are looked up in the same
> > manner. The std does not require a 'matching pair' be found. but it is
> > extremely poor form for a class to d
On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> The both operator new and operator delete are looked up in the same
> manner. The std does not require a 'matching pair' be found. but it is
> extremely poor form for a class to declare exactly one of operator
> {new,delete}.
There are unfortu
On Tue, 7 Apr 2020 at 12:40, Andre Vieira (lists)
wrote:
>
> Hi,
>
> This patch fixes v[id]wdup intrinsics. They had two issues:
> 1) the predicated versions did not link the incoming inactive vector
> parameter to the output
> 2) The backend didn't enforce the wrap limit operand be in an odd regi
On Tue, 7 Apr 2020 at 12:31, Andre Vieira (lists)
wrote:
>
> On 06/04/2020 16:12, Christophe Lyon via Gcc-patches wrote:
> > Hi,
> >
> > While checking Martin's fix for PR ipa/94445, he made me realize that
> > the cmse-15.c testcase still fails at -Os because ICF means that we
> > generate
> > no
Hi!
I'd like to ping this P1 PR fix:
On Tue, Mar 31, 2020 at 09:04:18AM +0200, Jakub Jelinek via Gcc-patches wrote:
> 2020-03-31 Jakub Jelinek
>
> PR rtl-optimization/94291
> * combine.c (try_combine): For split_i2i3, don't assume SET_DEST
> must be a REG or SUBREG of REG; i
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 07 April 2020 11:35
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov
> Subject: [PATCH][GCC][Arm]: MVE: Fix constant load pattern
>
> Hi,
>
> This patch fixes the constant load pattern for MVE, this was not
> accounting correctly
On 4/6/20 2:45 PM, Nathan Sidwell wrote:
On 4/6/20 4:34 AM, Martin Liška wrote:
May I please ping Jason, Nathan and Jonathan who can help us here?
On IRC Martin clarified the question as essentially 'how do you pair up
operator new and operator delete calls?' (so you may delete them if the
Hi,
After fixing the v[id]wdups using the "moving the wrap parameter" into
the top-end of a DImode operand using a shift, I noticed we were using
lsll for 32-bit shifts in scalars, where we don't need to, as we can
simply do a move, which is much better if we don't need to use the
bottom part
On 4/7/20 12:22 PM, Richard Biener wrote:
On Tue, Apr 7, 2020 at 11:49 AM Jan Hubicka wrote:
Well, the question is how to identify "operator new and operator delete at the
point of the new-expression and delete-expression". Currently we're
just matching up "is this a new/delete operator" an
Hi,
This patch fixes v[id]wdup intrinsics. They had two issues:
1) the predicated versions did not link the incoming inactive vector
parameter to the output
2) The backend didn't enforce the wrap limit operand be in an odd register.
1) was fixed like we did for all other predicated intrinsics
Hi,
This patch fixes the constant load pattern for MVE, this was not
accounting correctly for label + offset cases.
Added test that ICE'd before and removed the scan assemblers for the
mve_vector* tests as they were too fragile.
Bootstrapped on arm-linux-gnueabihf and regression tested on a
On Tue, Apr 07, 2020 at 12:19:45PM +0200, Richard Biener via Gcc-patches wrote:
> On Fri, Apr 3, 2020 at 11:59 PM Ian Lance Taylor via Gcc-patches
> wrote:
> >
> > The split-stack code invokes mmap and munmap with a limited amount of
> > stack space. That is fine when the functions just make a sy
On 06/04/2020 16:12, Christophe Lyon via Gcc-patches wrote:
Hi,
While checking Martin's fix for PR ipa/94445, he made me realize that
the cmse-15.c testcase still fails at -Os because ICF means that we
generate
nonsecure2:
b nonsecure0
which is OK, but does not match the currentl
On Tue, Apr 7, 2020 at 11:49 AM Jan Hubicka wrote:
>
> >
> > Well, the question is how to identify "operator new and operator delete at
> > the
> > point of the new-expression and delete-expression". Currently we're
> > just matching up "is this a new/delete operator" and the dataflow of the
> >
These intrinsics are the predicated version of the intrinsics inroduced
in https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542725.html.
These are not yet public on developer.arm.com but we have reached
internal consensus on them.
The approach follows the same method as for the CDE intrinsics
On Fri, Apr 3, 2020 at 11:59 PM Ian Lance Taylor via Gcc-patches
wrote:
>
> The split-stack code invokes mmap and munmap with a limited amount of
> stack space. That is fine when the functions just make a system call,
> but it's not fine when programs use LD_PRELOAD or linker tricks to add
> hook
On 06/04/2020 12:19, Richard Sandiford wrote:
> "Richard Earnshaw (lists)" writes:
>> On 03/04/2020 16:03, Richard Sandiford wrote:
>>> "Richard Earnshaw (lists)" writes:
On 03/04/2020 13:27, Richard Sandiford wrote:
> "Richard Earnshaw (lists)" writes:
>> On 02/04/2020 19:53, Richa
>
> Well, the question is how to identify "operator new and operator delete at the
> point of the new-expression and delete-expression". Currently we're
> just matching up "is this a new/delete operator" and the dataflow of the
> pointer. In the PR it was suggested the actual called methods shou
On Tue, 7 Apr 2020, Martin Jambor wrote:
> Hi,
>
> when sra_modify_expr is invoked on an expression that modifies only
> part of the underlying replacement, such as a BIT_FIELD_REF on a LHS
> of an assignment and the SRA replacement's type is not compatible with
> what is being replaced (0th oper
On Tue, Apr 7, 2020 at 10:26 AM Jonathan Wakely wrote:
>
> On Mon, 6 Apr 2020 at 13:45, Nathan Sidwell wrote:
> >
> > On 4/6/20 4:34 AM, Martin Liška wrote:
> >
> > >
> > > May I please ping Jason, Nathan and Jonathan who can help us here?
> >
> > On IRC Martin clarified the question as essential
> -Original Message-
> From: Gcc-patches On Behalf Of Andre
> Vieira (lists)
> Sent: 07 April 2020 10:02
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrill Tkachov
> Subject: [PATCH][GCC][Arm]: MVE: Do not use typeof for pointer
> parameters
>
> Hi,
>
> To make sure our inlining of _Generic
1 - 100 of 108 matches
Mail list logo
