On 2020-02-24 4:54 a.m., Christophe Lyon wrote:
Hi,
On Sun, 23 Feb 2020 at 22:26, Vladimir Makarov wrote:
The following patch is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564
The patch was successfully bootstrapped on x86-64 and benchmarked on
SPEC2000.
It seems this patch caus
On 2020-02-27 7:33 a.m., Andrew Stubbs wrote:
On 26/02/2020 15:16, Andrew Stubbs wrote:
The problem appears to be that the high-part of a register pair is
not marked as "ever live". I'm trying to figure out whether this is
some kind of target-specific issue that has merely been exposed, but
On 26/02/2020 15:16, Andrew Stubbs wrote:
The problem appears to be that the high-part of a register pair is not
marked as "ever live". I'm trying to figure out whether this is some
kind of target-specific issue that has merely been exposed, but it's
difficult to see what's going on. I'm prett
On 23/02/2020 21:25, Vladimir Makarov wrote:
The following patch is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564
The patch was successfully bootstrapped on x86-64 and benchmarked on
SPEC2000.
Since this patch I get an ICE with checking enabled, for amdgcn-amdhsa:
during RTL pa
On 1/28/20 9:52 PM, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
>
> The patch was successfully tested and bootstrapped on x86_64.
>
> Unfortunately it is hard to create a test case for the patch. So there is no
> test for this PR.
Hi,
On Sun, 23 Feb 2020 at 22:26, Vladimir Makarov wrote:
>
> The following patch is for
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564
>
> The patch was successfully bootstrapped on x86-64 and benchmarked on
> SPEC2000.
>
It seems this patch causes regression on some arm cores (seen on
Hi!
On Thu, Feb 06, 2020 at 05:16:14PM -0500, Vladimir Makarov wrote:
> --- a/gcc/lra-assigns.c
> +++ b/gcc/lra-assigns.c
> @@ -964,6 +964,8 @@ spill_for (int regno, bitmap spilled_pseudo_bitmap, bool
> first_p)
>bitmap_clear (&spill_pseudos_bitmap);
>for (j = hard_regno_nregs (ha
Hello!
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85860
>
> The patch was successfully bootstrapped and tested on x86-64.
>
> Committed as rev. 269662 to trunk and as rev. 269663 to gcc-8-branch.
Index: testsuite/gcc.target/i386/pr85860.c
===
On 01/11/2019 04:58 AM, Richard Sandiford wrote:
Hi Vlad,
I think for !WORDS_BIG_ENDIAN the equivalent problem to:
|| !TEST_HARD_REG_BIT (reg_class_contents[rclass],
hard_regno - nregs_diff)))
would be:
|| !TEST_HARD_RE
Hi Vlad,
Vladimir Makarov writes:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87305
>
> The patch was bootstrapped and tested on x86-64 and ppc64 (be).
>
> Committed as rev. 267823.
>
> Index: ChangeLog
>
On 12/18/18 4:50 PM, Jakub Jelinek wrote:
On Tue, Dec 18, 2018 at 04:23:12PM -0500, Vladimir Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87759
The patch was bootstrapped and tested on x86-64.
Committed as rev. 267244.
The test FAILs on i686-lin
On Tue, Dec 18, 2018 at 04:23:12PM -0500, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87759
>
> The patch was bootstrapped and tested on x86-64.
>
> Committed as rev. 267244.
The test FAILs on i686-linux, fixed thusly, committed as ob
Vladimir Makarov writes:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88282
>
> The patch was successfully bootstrapped and tested on
> x86/x86-64/ppc64/aarch64.
>
> Committed as rev. 266784.
>
> Index: ChangeLog
> =
On 11/24/2018 02:10 AM, Jeff Law wrote:
On 11/23/18 3:04 PM, Vladimir Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88157
The patch was successfully bootstrapped on x86 and x86-64 with GO and D.
Committed as rev. 266422.
pr88157.patch
Index:
On 11/23/18 3:04 PM, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88157
>
> The patch was successfully bootstrapped on x86 and x86-64 with GO and D.
>
> Committed as rev. 266422.
>
>
> pr88157.patch
>
> Index: ChangeLog
> =
On 06/18/2018 02:34 PM, Marek Polacek wrote:
> This patch improves the checks in size_must_be_zero_p so that we don't
> call get_range_info with SIZE of a pointer type.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk and 8?
>
> 2018-06-18 Marek Polacek
>
> PR middle-end/86202
>
On 03/10/2018 09:40 AM, Vladimir Makarov wrote:
> A few people reported that the patch broke i686. I am going to work on
> the patch more. Meanwhile I've reverted the patch.
Just a note, none of my other builds failed. Though i686 probably
stresses the class-likely-spilled bits than any other.
A few people reported that the patch broke i686. I am going to work on
the patch more. Meanwhile I've reverted the patch.
On 03/09/2018 11:16 AM, Vladimir Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
It is another "cannot find a spill reg for r
On Fri, Mar 9, 2018 at 8:16 AM, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
>
> It is another "cannot find a spill reg for reload" problem. LRA has already
> a code splitting hard reg live ranges to avoid such problem. This code is
>
On 03/09/2018 09:16 AM, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
>
> It is another "cannot find a spill reg for reload" problem. LRA has
> already a code splitting hard reg live ranges to avoid such problem.
> This code is in LRA
On 2/22/18 3:19 PM, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81572
>
> The patch was successfully bootstrapped and tested on ppc64.
Vlad approved the backporting of this patch to GCC 7.
I backported his patch and bootstrap & regtest
On 02/09/2018 03:54 AM, Jakub Jelinek wrote:
On Fri, Feb 09, 2018 at 11:40:29AM +0100, Richard Biener wrote:
I.e., having to track all pointers to d between the call to
strncpy and the assignment of the nul and make sure none of
them ends up used in a string function. It didn't seem
the additio
On Fri, Feb 09, 2018 at 11:40:29AM +0100, Richard Biener wrote:
> > I.e., having to track all pointers to d between the call to
> > strncpy and the assignment of the nul and make sure none of
> > them ends up used in a string function. It didn't seem
> > the additional complexity would have been w
On Thu, Feb 8, 2018 at 7:12 PM, Martin Sebor wrote:
> On 02/08/2018 07:39 AM, Richard Biener wrote:
>>
>> On Thu, Feb 8, 2018 at 6:35 AM, Jeff Law wrote:
>>>
>>> On 02/06/2018 05:57 AM, Jakub Jelinek wrote:
On Tue, Feb 06, 2018 at 01:46:21PM +0100, Marek Polacek wrote:
>
> --- g
On 02/08/2018 07:39 AM, Richard Biener wrote:
On Thu, Feb 8, 2018 at 6:35 AM, Jeff Law wrote:
On 02/06/2018 05:57 AM, Jakub Jelinek wrote:
On Tue, Feb 06, 2018 at 01:46:21PM +0100, Marek Polacek wrote:
--- gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
+++ gcc/testsuite/c-c++-common/Wstr
On Tue, Feb 06, 2018 at 05:14:16PM +0100, Marek Polacek wrote:
> Here we ICE because get_range_strlen's result might not be an array of
> two integer constants -- for a VLA the array might contain a non-constant.
> So beef up the check before converting to wide_int.
>
> Bootstrapped/regtested on x
On Thu, Feb 8, 2018 at 6:35 AM, Jeff Law wrote:
> On 02/06/2018 05:57 AM, Jakub Jelinek wrote:
>> On Tue, Feb 06, 2018 at 01:46:21PM +0100, Marek Polacek wrote:
>>> --- gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
>>> +++ gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
>>> @@ -0,0 +1,20
On 02/06/2018 08:59 AM, Martin Sebor wrote:
> On 02/06/2018 06:23 AM, Marek Polacek wrote:
>> On Tue, Feb 06, 2018 at 01:57:36PM +0100, Jakub Jelinek wrote:
>>> On Tue, Feb 06, 2018 at 01:46:21PM +0100, Marek Polacek wrote:
--- gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
+++ gcc/t
On 02/06/2018 05:57 AM, Jakub Jelinek wrote:
> On Tue, Feb 06, 2018 at 01:46:21PM +0100, Marek Polacek wrote:
>> --- gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
>> +++ gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
>> @@ -0,0 +1,20 @@
>> +/* PR tree-optimization/84228 */
>> +/* { dg-do
On 02/06/2018 05:46 AM, Marek Polacek wrote:
> When -Wstringop-truncation sees a strncpy call where the specified bound
> is equal to the size of the destination, it looks at the next statement
> to see if it's dst[i] = '\0';, and if it is, it doesn't warn. But it
> needs to look at the next nonde
Ok for trunk, though generally looking at just next stmt is very
fragile, might be
better to look at the strncpy's vuse immediate uses if they are
within the
same basic block and either don't alias with it, or are the store it is
looking for, or something similar.
I guess some
FOR_EACH_IMM_USE_F
On 02/06/2018 06:23 AM, Marek Polacek wrote:
On Tue, Feb 06, 2018 at 01:57:36PM +0100, Jakub Jelinek wrote:
On Tue, Feb 06, 2018 at 01:46:21PM +0100, Marek Polacek wrote:
--- gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
+++ gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
@@ -0,0 +1,2
On Tue, Feb 06, 2018 at 01:57:36PM +0100, Jakub Jelinek wrote:
> On Tue, Feb 06, 2018 at 01:46:21PM +0100, Marek Polacek wrote:
> > --- gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
> > +++ gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
> > @@ -0,0 +1,20 @@
> > +/* PR tree-optimization/8
On Tue, Feb 06, 2018 at 01:46:21PM +0100, Marek Polacek wrote:
> --- gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
> +++ gcc/testsuite/c-c++-common/Wstringop-truncation-3.c
> @@ -0,0 +1,20 @@
> +/* PR tree-optimization/84228 */
> +/* { dg-do compile } */
> +/* { dg-options "-Wstringop-truncat
On 01/30/2018 03:37 PM, Rainer Orth wrote:
Hi Vladimir,
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84112
The patch was successfully bootstrapped and tested on x86-64 and ppc64.
Committed as rev. 257204.
[...]
Index: testsuite/ChangeLog
=
Hi Vladimir,
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84112
>
> The patch was successfully bootstrapped and tested on x86-64 and ppc64.
>
> Committed as rev. 257204.
[...]
> Index: testsuite/ChangeLog
> =
On Tue, Dec 19, 2017 at 03:50:33PM +0100, Marek Polacek wrote:
> This is an ICE-on-invalid where the code in init_cumulative_args tries to
> determine if it should warn about the empty classes ABI change, but is upset
> when it encounters error_mark_node. Thus fixed.
>
> Bootstrapped/regtested on
On 12/18/2017 05:27 PM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 05:03:22PM -0700, Martin Sebor wrote:
Your warning is about restrict and argument overlap, what does it have to do
with unprototyped calls? Nothing. There is no restrict in that case, and
it isn't handled as builtin if it doe
On Mon, Dec 18, 2017 at 05:03:22PM -0700, Martin Sebor wrote:
> > Your warning is about restrict and argument overlap, what does it have to do
> > with unprototyped calls? Nothing. There is no restrict in that case, and
> > it isn't handled as builtin if it doesn't match the builtin's prototype.
On 12/18/2017 04:41 PM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 04:04:11PM -0700, Martin Sebor wrote:
On 12/18/2017 12:04 PM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote:
It isn't optimized either way. In fact, the only indication
of a problem in the
On Mon, Dec 18, 2017 at 04:04:11PM -0700, Martin Sebor wrote:
> On 12/18/2017 12:04 PM, Jakub Jelinek wrote:
> > On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote:
> > > It isn't optimized either way. In fact, the only indication
> > > of a problem in the code below is the new -Wrestric
On 12/18/2017 12:04 PM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote:
It isn't optimized either way. In fact, the only indication
of a problem in the code below is the new -Wrestrict warning:
So just call it as memcpy (0, 0, (size_t) 0); or memcpy (0, 0, 0
On Mon, Dec 18, 2017 at 11:08:19AM -0700, Martin Sebor wrote:
> It isn't optimized either way. In fact, the only indication
> of a problem in the code below is the new -Wrestrict warning:
So just call it as memcpy (0, 0, (size_t) 0); or memcpy (0, 0, 0UL);
on targets where size_t is unsigned long
On 12/18/2017 11:32 AM, Bernd Edlinger wrote:
Hi Martin,
In all cases all the information necessary to detect and diagnose
or even avoid the problem is available. In fact, one might argue
that optimizing such calls (expanding them inline) would be
preferable to doing nothing and allowing the u
Hi Martin,
> In all cases all the information necessary to detect and diagnose
> or even avoid the problem is available. In fact, one might argue
> that optimizing such calls (expanding them inline) would be
> preferable to doing nothing and allowing the undefined behavior
> to cause a bug at run
On 12/18/2017 10:45 AM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 10:37:19AM -0700, Martin Sebor wrote:
On 12/18/2017 10:07 AM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote:
On 12/18/2017 08:10 AM, Marek Polacek wrote:
I'm not entirely up to speed with
On Mon, Dec 18, 2017 at 10:37:19AM -0700, Martin Sebor wrote:
> On 12/18/2017 10:07 AM, Jakub Jelinek wrote:
> > On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote:
> > > On 12/18/2017 08:10 AM, Marek Polacek wrote:
> > > > I'm not entirely up to speed with this code, but this one seemed
On 12/18/2017 10:07 AM, Jakub Jelinek wrote:
On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote:
On 12/18/2017 08:10 AM, Marek Polacek wrote:
I'm not entirely up to speed with this code, but this one seemed sufficiently
obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max
On Mon, Dec 18, 2017 at 10:00:36AM -0700, Martin Sebor wrote:
> On 12/18/2017 08:10 AM, Marek Polacek wrote:
> > I'm not entirely up to speed with this code, but this one seemed
> > sufficiently
> > obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value.
> > Otherwise, go with max
On 12/18/2017 08:10 AM, Marek Polacek wrote:
I'm not entirely up to speed with this code, but this one seemed sufficiently
obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value.
Otherwise, go with maxobjsize.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
Thanks for th
On Mon, Dec 18, 2017 at 09:36:46AM -0700, Jeff Law wrote:
> On 12/18/2017 08:10 AM, Marek Polacek wrote:
> > I'm not entirely up to speed with this code, but this one seemed
> > sufficiently
> > obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value.
> > Otherwise, go with maxobjs
On 12/18/2017 08:10 AM, Marek Polacek wrote:
> I'm not entirely up to speed with this code, but this one seemed sufficiently
> obvious: check INTEGRAL_TYPE_P before looking at a tree's min/max value.
> Otherwise, go with maxobjsize.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 20
On 12/13/2017 07:34 AM, Tom de Vries wrote:
On 10/16/2017 10:38 PM, Vladimir Makarov wrote:
This is another version of the patch to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82353
The patch was successfully bootstrapped on x86-64 with Go and Ada.
Committed as rev. 253796.
Hi Vl
On 10/16/2017 10:38 PM, Vladimir Makarov wrote:
This is another version of the patch to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82353
The patch was successfully bootstrapped on x86-64 with Go and Ada.
Committed as rev. 253796.
Hi Vladimir,
AFAIU this bit of the patch makes sure
Hi Jakub,
> On Fri, Dec 08, 2017 at 01:47:35PM +0100, Rainer Orth wrote:
>> >> the new testcase FAILs on Solaris/x86 with /bin/as:
>> >>
>> >> +FAIL: g++.dg/opt/pr83252.C -std=gnu++11 execution test
>> >> +FAIL: g++.dg/opt/pr83252.C -std=gnu++14 execution test
>> >> +FAIL: g++.dg/opt/pr83252.C
On Fri, Dec 08, 2017 at 01:47:35PM +0100, Rainer Orth wrote:
> >> the new testcase FAILs on Solaris/x86 with /bin/as:
> >>
> >> +FAIL: g++.dg/opt/pr83252.C -std=gnu++11 execution test
> >> +FAIL: g++.dg/opt/pr83252.C -std=gnu++14 execution test
> >> +FAIL: g++.dg/opt/pr83252.C -std=gnu++98 exec
Hi Jakub,
>> the new testcase FAILs on Solaris/x86 with /bin/as:
>>
>> +FAIL: g++.dg/opt/pr83252.C -std=gnu++11 execution test
>> +FAIL: g++.dg/opt/pr83252.C -std=gnu++14 execution test
>> +FAIL: g++.dg/opt/pr83252.C -std=gnu++98 execution test
>>
>> ld.so.1: pr83252.exe: fatal: pr83252.exe:
On Fri, Dec 08, 2017 at 01:38:36PM +0100, Rainer Orth wrote:
> Hi Jakub,
>
> > On Wed, Nov 29, 2017 at 05:21:22PM -0500, Vladimir Makarov wrote:
> >> The following patch fixes
> >>
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80818
> >>
> >> The patch was successfully tested and bootstr
Hi Jakub,
> On Wed, Nov 29, 2017 at 05:21:22PM -0500, Vladimir Makarov wrote:
>> The following patch fixes
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80818
>>
>> The patch was successfully tested and bootstrapped on x86_64. The patch
>> has no test because it is hard to check the pro
On 12/05/2017 07:49 AM, Jakub Jelinek wrote:
On Mon, Dec 04, 2017 at 11:52:01AM +0100, Jakub Jelinek wrote:
On Wed, Nov 29, 2017 at 05:21:22PM -0500, Vladimir Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80818
The patch was successfully tested
On Mon, Dec 04, 2017 at 11:52:01AM +0100, Jakub Jelinek wrote:
> On Wed, Nov 29, 2017 at 05:21:22PM -0500, Vladimir Makarov wrote:
> > The following patch fixes
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80818
> >
> > The patch was successfully tested and bootstrapped on x86_64. The
On Wed, Nov 29, 2017 at 05:21:22PM -0500, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80818
>
> The patch was successfully tested and bootstrapped on x86_64. The patch
> has no test because it is hard to check the problem. I checked ma
On Nov 29 2017, Vladimir Makarov wrote:
> +2017-11-29 Vladimir Makarov
> +
> + PR rtl-optimization/80818
> + * lra.c (collect_non_operand_hard_regs): New arg insn. Pass it
> + recursively. Use insn code for clobber.
> + (lra_set_insn_recog_data): Pass the new arg to
> + c
HI Quing,
this is a very straightforward fix for an undefined behavior in
fortran/decl.c:
> - sprintf (name, "%s_%d", name, kind_value);
> + sprintf (name + strlen (name), "_%d", kind_value);
OK for trunk. Thanks for the patch!
Regards
Thomas
On 10/12/2017 10:49 AM, Jakub Jelinek wrote:
> Hi!
>
> On Wed, Oct 11, 2017 at 06:41:05PM -0400, Vladimir Makarov wrote:
>>> Tested on x86_64-linux -m32/-m64, and verified with cc1plus before your
>>> change, ok for trunk?
>
> BTW, I think it is quite fragile to scan for the reload messages, so I
On Thu, Oct 12, 2017 at 01:05:21PM -0400, Vladimir Makarov wrote:
>
>
> On 10/12/2017 12:49 PM, Jakub Jelinek wrote:
> > Hi!
> >
> > On Wed, Oct 11, 2017 at 06:41:05PM -0400, Vladimir Makarov wrote:
> > > > Tested on x86_64-linux -m32/-m64, and verified with cc1plus before your
> > > > change, o
On 10/12/2017 12:49 PM, Jakub Jelinek wrote:
Hi!
On Wed, Oct 11, 2017 at 06:41:05PM -0400, Vladimir Makarov wrote:
Tested on x86_64-linux -m32/-m64, and verified with cc1plus before your
change, ok for trunk?
BTW, I think it is quite fragile to scan for the reload messages, so I've
cooked up
Hi!
On Wed, Oct 11, 2017 at 06:41:05PM -0400, Vladimir Makarov wrote:
> > Tested on x86_64-linux -m32/-m64, and verified with cc1plus before your
> > change, ok for trunk?
BTW, I think it is quite fragile to scan for the reload messages, so I've
cooked up a runtime test that fails before your pat
Hello!
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82353
>
> LRA did not update hard reg liveness on bb borders for hard regs which are
> part of insn patterns
> like CFLAGS reg. It was ok for inheritance in EBB which creates only moves
> and they usually
> have
On 10/11/2017 05:11 PM, Jakub Jelinek wrote:
On Wed, Oct 11, 2017 at 03:39:21PM -0400, Vladimir Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82353
LRA did not update hard reg liveness on bb borders for hard regs which are
part of insn patterns like CF
On Wed, Oct 11, 2017 at 03:39:21PM -0400, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82353
>
> LRA did not update hard reg liveness on bb borders for hard regs which are
> part of insn patterns like CFLAGS reg. It was ok for inheritance i
On 09/30/2017 04:15 AM, Richard Sandiford wrote:
Vladimir Makarov writes:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81481
The patch was bootstrapped and tested on x86-64.
Committed as rev. 253300.
Index: ira-costs.c
===
Vladimir Makarov writes:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81481
>
> The patch was bootstrapped and tested on x86-64.
>
> Committed as rev. 253300.
>
>
> Index: ira-costs.c
> ===
> --- ira-co
On 04/07/2017 05:45 PM, Jakub Jelinek wrote:
On Fri, Apr 07, 2017 at 12:04:16PM -0400, Vladimir Makarov wrote:
Index: ChangeLog
===
--- ChangeLog (revision 246763)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2017-04-07 Vla
On Fri, Apr 07, 2017 at 12:04:16PM -0400, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478
>
> The patch was successfully bootstrapped and tested on x86-64/ppc64/arm64.
>
> Committed as rev. 246764.
>
> Index: ChangeLog
>
On 04/06/2017 06:24 AM, Richard Biener wrote:
On Wed, Apr 5, 2017 at 6:18 PM, Vladimir Makarov wrote:
On 04/05/2017 12:07 PM, Vladimir Makarov wrote:
I'll correct the patch.
Here is the patch I've committed.
Note that in such contexts it's better to just use [u]int64_t.
You are righ
On Wed, Apr 5, 2017 at 6:18 PM, Vladimir Makarov wrote:
>
>
> On 04/05/2017 12:07 PM, Vladimir Makarov wrote:
>>
>>
>>
>> I'll correct the patch.
>>
> Here is the patch I've committed.
Note that in such contexts it's better to just use [u]int64_t.
Richard.
> 2017-04-05 Vladimir Makarov
>
>
On 04/05/2017 12:07 PM, Vladimir Makarov wrote:
I'll correct the patch.
Here is the patch I've committed.
2017-04-05 Vladimir Makarov
PR rtl-optimization/70703
* ira-color.c (update_conflict_hard_regno_costs): Use
HOST_WIDE_INT instead of long.
Index: ira-color
On 04/05/2017 11:25 AM, Jakub Jelinek wrote:
On Wed, Apr 05, 2017 at 11:11:54AM -0400, Vladimir Makarov wrote:
--- ira-color.c (revision 246536)
+++ ira-color.c (working copy)
@@ -1367,6 +1367,16 @@ update_costs_from_allocno (ira_allocno_t
|| ALLOCNO_ASSIGNED_P (another_allocno))
On Wed, Apr 05, 2017 at 11:11:54AM -0400, Vladimir Makarov wrote:
> --- ira-color.c (revision 246536)
> +++ ira-color.c (working copy)
> @@ -1367,6 +1367,16 @@ update_costs_from_allocno (ira_allocno_t
> || ALLOCNO_ASSIGNED_P (another_allocno))
> continue;
>
> +
On Mon, Mar 06, 2017 at 09:35:08PM +0100, Jakub Jelinek wrote:
> On Mon, Mar 06, 2017 at 03:31:49PM -0500, Vladimir Makarov wrote:
> >
> > Sorry the ChangeLog entry had typos. Here is the final variant
> >
> > 2017-03-06 Vladimir Makarov
> >
> > PR rtl-optimization/79571
> >
On Mon, Mar 06, 2017 at 03:31:49PM -0500, Vladimir Makarov wrote:
>
> Sorry the ChangeLog entry had typos. Here is the final variant
>
> 2017-03-06 Vladimir Makarov
>
> PR rtl-optimization/79571
> * lra-constraints.c (process_alt_operands): Calculate static
One more: Calcula
Sorry the ChangeLog entry had typos. Here is the final variant
2017-03-06 Vladimir Makarov
PR rtl-optimization/79571
* lra-constraints.c (process_alt_operands): Calculate static
reject and subtract it from overall when only addresses will be
reloaded.
On 31 January 2017 at 10:05, Kyrill Tkachov wrote:
> Hi Christophe,
>
> On 30/01/17 20:59, Christophe Lyon wrote:
>>
>> Hi Vladimir,
>>
>> On 26 January 2017 at 18:09, Vladimir Makarov wrote:
>>>
>>> The following patch fixes
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
>>>
>>> The
Hi Christophe,
On 30/01/17 20:59, Christophe Lyon wrote:
Hi Vladimir,
On 26 January 2017 at 18:09, Vladimir Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
The patch also adapts IP IRA in LRA because without it GCC IP RA tests
become broken (it wa
Hi Vladimir,
On 26 January 2017 at 18:09, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131
>
> The patch also adapts IP IRA in LRA because without it GCC IP RA tests
> become broken (it was just a luck that the tests worked before the patc
On 01/17/2017 04:57 PM, Christophe Lyon wrote:
Hi Vladimir,
On 17 January 2017 at 17:14, Vladimir Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
The patch was successfully bootstrapped and tested on x86-64.
Committed as rev. 244535.
The new
Hi Vladimir,
On 17 January 2017 at 17:14, Vladimir Makarov wrote:
> The following patch fixes
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058
>
> The patch was successfully bootstrapped and tested on x86-64.
>
> Committed as rev. 244535.
>
>
The new testcase fails to compile on arm*-linux
On Fri, Oct 07, 2016 at 10:45:18AM +0200, Marek Polacek wrote:
> Ping.
>
> On Sat, Oct 01, 2016 at 04:17:22PM +0200, Marek Polacek wrote:
> > On Sat, Oct 01, 2016 at 07:17:50AM +0200, Markus Trippelsdorf wrote:
> > > On 2016.09.30 at 23:31 +0200, Marek Polacek wrote:
> > > > This PR reports a bogu
Ping.
On Sat, Oct 01, 2016 at 04:17:22PM +0200, Marek Polacek wrote:
> On Sat, Oct 01, 2016 at 07:17:50AM +0200, Markus Trippelsdorf wrote:
> > On 2016.09.30 at 23:31 +0200, Marek Polacek wrote:
> > > This PR reports a bogus -Wimplicit-fallthrough warning on the attached
> > > test.
> > > The pro
On Sun, Oct 02, 2016 at 02:42:23PM -0400, Jason Merrill wrote:
> On Sat, Oct 1, 2016 at 10:17 AM, Marek Polacek wrote:
> > + && (last_eval == NULL
> > + || !gimple_call_internal_p (last_eval, IFN_FALLTHROUGH))
>
> Isn't this still assuming that non-null last_eval must be a
On Sat, Oct 1, 2016 at 10:17 AM, Marek Polacek wrote:
> + && (last_eval == NULL
> + || !gimple_call_internal_p (last_eval, IFN_FALLTHROUGH))
Isn't this still assuming that non-null last_eval must be a gcall, so
we'll get a checking ICE if it's something else?
Jason
On Sat, Oct 01, 2016 at 07:17:50AM +0200, Markus Trippelsdorf wrote:
> On 2016.09.30 at 23:31 +0200, Marek Polacek wrote:
> > This PR reports a bogus -Wimplicit-fallthrough warning on the attached test.
> > The problem is that last_stmt_in_scope should for GIMPLE_TRY, if the last
> > statement of t
On 2016.09.30 at 23:31 +0200, Marek Polacek wrote:
> This PR reports a bogus -Wimplicit-fallthrough warning on the attached test.
> The problem is that last_stmt_in_scope should for GIMPLE_TRY, if the last
> statement of the eval part can't fallthrough, return this statement and don't
> warn. And
OK.
On Thu, Sep 29, 2016 at 9:26 AM, Marek Polacek wrote:
> On Thu, Sep 29, 2016 at 03:20:26PM +0200, Jakub Jelinek wrote:
>> Shouldn't that be { target c++14_down } instead?
>
> Didn't know about that. Thus:
>
> 2016-09-29 Marek Polacek
>
> * g++.dg/cpp0x/fallthrough2.C: Use the c++1
On Thu, Sep 29, 2016 at 03:20:26PM +0200, Jakub Jelinek wrote:
> Shouldn't that be { target c++14_down } instead?
Didn't know about that. Thus:
2016-09-29 Marek Polacek
* g++.dg/cpp0x/fallthrough2.C: Use the c++14_down target.
diff --git gcc/testsuite/g++.dg/cpp0x/fallthrough2.C
gc
On Thu, Sep 29, 2016 at 03:13:57PM +0200, Marek Polacek wrote:
> This test failed with make check-c++1z because in C++1z we don't get the
> expected message.
>
> Bootstrapped/regtested on x86_64-linux, applying to trunk.
>
> 2016-09-29 Marek Polacek
>
> * g++.dg/cpp0x/fallthrough2.C: On
OK, thanks.
On Thu, Sep 22, 2016 at 10:24 AM, Marek Polacek wrote:
> Jason reported that make check-c++1z reveals some fallout
> because we now reject bool++ in C++1z:
> https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01460.html
>
> I hope this patch fixes all of it.
>
> Bootstrapped/regtested on x
On Tue, Aug 2, 2016 at 9:09 AM, Vladimir Makarov wrote:
> The following patch is for
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69847
>
> The patch implements an invariant inheritance and some hard reg assignment
> improvements in LRA. Actually I tried several approaches to implement th
On 21/04/16 09:45, Jiong Wang wrote:
On 19/04/16 03:54, Vladimir N Makarov wrote:
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70689
The patch was successfully tested and bootstrapped on x86/x86-64.
Committed to the trunk as rev. 235184.
This caused the following
1 - 100 of 435 matches
Mail list logo
