*PING**2
On 3/24/20 11:18 AM, Tobias Burnus wrote:
On 3/11/20 2:28 PM, Tobias Burnus wrote:
Fortran patch:
https://gcc.gnu.org/pipermail/gcc-patches/current/541774.html
Like for Fortran, it also fixes some other issues – here for C++
related to namespaces. (For class, see PR c++/94140.)
Test
Hi Tobias!
On 2020-04-07T09:21:27+0200, Tobias Burnus wrote:
> *PING**2
<87h7y3ofad.fsf@euler.schwinge.homeip.net">http://mid.mail-archive.com/87h7y3ofad.fsf@euler.schwinge.homeip.net>?
Grüße
Thomas
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / German
Hi,
This patch removes the special treatment of 'asm pure' blocks, as the
need for code correctness outweighs the need for optimization around
these statements.
Bootstrapped and regression tested on x86_64-linux-gnu. Committed to
mainline.
Regards
Iain.
---
gcc/d/ChangeLog:
* toir.cc (
Jakub Jelinek writes:
> Hi!
>
> The following testcase ICEs on aarch64 apparently since the introduction of
> the aarch64 port. The reason is that the {ashl,ashr,lshr}3 expanders
> completely unnecessarily FAIL; if operands[2] is something other than
> a CONST_INT or REG or MEM and the middle-end
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
>> Iain.
>>
>
> Thanks for committing the patch ups
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 essentially 'how do you pair up
> operator new and operator delete calls?' (so you
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 07 April 2020 09:57
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH][GCC][Arm]: MVE: Fix polymorphism for scalars and
> constants
>
> Hi,
>
> I rebased this patch and made some extra fixes.
>
> This patch me
Now with the zipped patch so it reaches the mailing list.
Sorry for that.
On 07/04/2020 09:57, Kyrylo Tkachov wrote:
-Original Message-
From: Andre Vieira (lists)
Sent: 07 April 2020 09:57
To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH][GCC][Arm]: MVE: Fix polymorphis
> -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
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
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
>
> 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 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
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
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 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
> >
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 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
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
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
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,
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/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
> -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
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
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
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 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, 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 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, 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, 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
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
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
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
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)
> {
>
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 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
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
> -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
> -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
>
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
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$
>
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,
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
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 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
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 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/
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
> -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
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: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
> -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: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: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: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
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
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,
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 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
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
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
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
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
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
"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)"
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_
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
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 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 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
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, 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
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
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
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:
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 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 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!
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, 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!
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 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
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
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 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
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 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
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 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
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: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
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
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
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
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
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
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_
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
1 - 100 of 108 matches
Mail list logo
