Hello!
Trivial patch to make insn dumps more informative.
2015-04-02 Uros Bizjak
* config/i386/sync.md (UNSPEC_FILD_ATOMIC, UNSPEC_FIST_ATOMIC): New.
(loaddi_via_fpu): Use UNSPEC_FILD_ATOMIC.
(storedi_via_fpu): Use UNSPEC_FIST_ATOMIC.
* reg-stack.c (get_true_reg): Change UNSPE
On Wed, Apr 01, 2015 at 03:37:19PM -0700, H.J. Lu wrote:
> This caused:
>
> FAIL: g++.dg/cpp0x/pr57101.C -std=gnu++11 (test for excess errors)
> FAIL: g++.dg/cpp0x/pr57101.C -std=gnu++14 (test for excess errors)
>
> on 32 bit system.
Thanks, I'll fix it momentarily.
We are now more strict when accepting user-defined initializer_lists; in
particular, we now require sizetype, not just any integral type. The
following test failed with -m32, because it had a bogus type of size_t,
with -m32 it usually should be unsigned int, not unsigned long.
Test passes now wit
Hi all,
during debugging of a larger fortran source I figured that my previous patch on
44672 had still some issues, when it comes to adding a gfc_code into the chain
of codes and with a symbol. Adding a new gfc_code object before the current one
is now solved be creating a new gfc_code object, co
The following makes CCP track copies which avoids pass ordering
issues between CCP and copyprop as seen from the testcase.
Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for stage1.
For stage1 I'd like to get rid of copyprop completely, a 2nd patch
in the series will remove the copy
Hi all,
I've committed this as per https://gcc.gnu.org/ml/gcc/2015-04/msg00012.html
with r221833.
Thanks,
Kyrill
2015-04-02 Kyrylo Tkachov
* MAINTAINERS: Add myself as an arm port reviewer.
Index: MAINTAINERS
===
--- MAI
Ping!
This should be in 5.1. Dominique and I feel like this patch is nearly obvious.
Regards,
Andre
On Wed, 25 Mar 2015 14:35:54 +0100
Andre Vehreschild wrote:
> Hi all,
>
> please find attached a fix for the recently introduced regression when
> allocating arrays with an intrinsic f
On Thu, Apr 02, 2015 at 06:39:57AM +0100, Jeff Law wrote:
> I'm pleased to announce that James Greenhalgh has been appointed as a
> reviewer for the AArch64 port and that Kyrylo Tkachov has been appointed
> as a reviewer for the ARM port.
>
> James & Kyrylo, if you could add yourself to the MAIN
On Wed, Apr 1, 2015 at 9:34 PM, Jeff Law wrote:
> On 03/31/2015 03:47 AM, Ilya Enkovich wrote:
>>
>> On 23 Mar 13:19, Ilya Enkovich wrote:
>>>
>>> Hi,
>>>
>>> May this patch go into trunk at this point? It is very important for
>>> dynamic MPX codes.
>>>
>>> Thanks,
>>> Ilya
>>>
>>
>> I additiona
When I fixed PR64909 I knew it wasn't a 100% precise fix. This bites
us now in PR65660 (which also shows other issues). Thus the following
precise fix for PR64909 (which didn't turn out as too involved) - compute
a cost vector for the scalar iteration cost and apply it for peeled
iterations.
Bo
The attached change fixes an old bug. In debugging the segmentation fault of
cc76narrowing1 in the
ppl-1.1 test suite, I found that we incorrectly handle register indexed memory
operands in double word
loads on 32-bit targets. In particular, when there is an overlap between the
source register
Hello!
Attached patch reverts unwanted part of r216820 [1] movqi_internal
change to restore correct type calculation.
2015-04-02 Uros Bizjak
Revert parts of r216820.
* config/i386/i386.md (movqi_internal): Correct type calculation
for alternatives 3 and 5.
Bootstrapped and regres
On Wed, Apr 01, 2015 at 11:42:28PM +0100, H.J. Lu wrote:
> On Mon, Mar 30, 2015 at 3:19 PM, Martin Liška wrote:
> > You are right, there's one more occurrence of the usage.
> > I'm going to install the patch I've attached.
> >
>
> This caused:
>
> FAIL: g++.dg/torture/pr64378.C -O2 -flto -fno-
Ping
2015-03-10 13:12 GMT+03:00 Ilya Enkovich :
> Hi,
>
> Currentl we loose returned bounds when functions are merged. This patch
> fixes it by adding returne bounds support for cgraph_node::expand_thunk.
> Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk?
>
> Thanks,
> Ilya
Ping. Patch doesn't affect not instrumented code.
Thanks,
Ilya
2015-03-18 15:19 GMT+03:00 Ilya Enkovich :
> Hi,
>
> This patch disables attempts to expand instrumentation thunks which appear
> when we create specialized function versions. Problem was found during
> SPEC2006 insatrumentation wi
Ping
2015-03-19 11:34 GMT+03:00 Ilya Enkovich :
> On 12 Mar 13:27, Ilya Enkovich wrote:
>> Hi,
>>
>> Currently cgraph merge has several issues with instrumented code:
>> - original function node may be removed => no assembler name conflict is
>> detected between function and variable
>> - only
Ping. This patch doesn't affect not instrumented code.
Thanks,
Ilya
2015-03-20 11:20 GMT+03:00 Ilya Enkovich :
> Hi,
>
> Identifiers read with input_identifier miss IDENTIFIER_TRANSPARENT_ALIAS bit.
> We always expect it for instrumentation clones, thus restore it
> input_cgraph_1. Bootstrapp
Richard Biener wrote:
> > On Tue, 31 Mar 2015, Alan Lawrence wrote:
> >
>> >> (1) If we wish to keep the AAPCS principle that varargs are passed just as
>> >> named args, we should use TYPE_MAIN_VARIANT inside
>> >> arm_needs_doubleword_alignment, which will then ignore overalignment on
both
>> >
Hi,
This patch fixes nested PARALLEL in retval for isntrumented calls. Current
possible call:
(call_insn:TI 6 30 17 2 (set (parallel [
(expr_list:REG_DEP_TRUE (parallel:TI [
(expr_list:REG_DEP_TRUE (reg:DF 21 xmm0)
(cons
Hi,
This patch doesn't allow instrumentation thunks calls while merging
constructors and destructors. Not isntrumented code is not affeceted.
Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk?
Thanks,
Ilya
--
gcc/
2015-04-02 Ilya Enkovich
* ipa.c (ipa_cdtor_merge
Hi,
Current in LTO static const bounds are created as external symbol. It doesn't
work in case original symbols were removed and privatized. This patch
introduces a separate comdat symbol to be used in LTO. Bootstrapped and
tested on x86_64-unknown-linux-gnu. Does this approach look OK?
T
We were specifically handling misuse of a function template, but we also
need to handle variable templates now.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d743a07ee6b19b3fec59c81ae2cbedbf38d91c4b
Author: Jason Merrill
Date: Wed Apr 1 19:02:03 2015 -0400
PR c++/65625
* de
Hi,
I guess I can as well ping this - still in my tree, no issues so far...
On 03/04/2015 07:29 PM, Paolo Carlini wrote:
Hi,
today while working a bit on Bugzilla I found this issue which should
be easy to fix, not a regression, therefore possibly post 5.0. At
parsing time, cp_parser_lambda_
Hi,
With r221574 (https://gcc.gnu.org/ml/gcc-cvs/2015-03/msg00495.html) thunks
don't get comdat groups assigned and this causes a failure in cgraph checker
for instrumentation thunks. It happens because instrumentation thunk may
reference local symbol in comdat not being in comdat by itself.
This fixes the regression part of c++/65642. Some history behind this:
up until r214941 we were able to fold "&A[i] + j" into "&A[i + j]", but
in this revision richi removed this transformation. Since we need this
transformation when dealing with constexprs, I added it back into
cxx_fold_indirect
On 24 Mar 15:06, Jakub Jelinek wrote:
> On Tue, Mar 24, 2015 at 12:22:27PM +0300, Ilya Enkovich wrote:
> > 2015-03-24 11:33 GMT+03:00 Jakub Jelinek :
> > > On Thu, Mar 19, 2015 at 11:29:44AM +0300, Ilya Enkovich wrote:
> > >> + /* We might propagate instrumented function pointer into
> > >> +
OK.
Jason
> Ping
It would help if you add hubi...@ucw.cz to CC for IPA related patches.
>
> 2015-03-19 11:34 GMT+03:00 Ilya Enkovich :
> > On 12 Mar 13:27, Ilya Enkovich wrote:
> >> Hi,
> >>
> >> Currently cgraph merge has several issues with instrumented code:
> >> - original function node may be removed
> Hi,
>
> With r221574 (https://gcc.gnu.org/ml/gcc-cvs/2015-03/msg00495.html) thunks
> don't get comdat groups assigned and this causes a failure in cgraph checker
> for instrumentation thunks. It happens because instrumentation thunk may
> reference local symbol in comdat not being in comdat
On Thu, Apr 2, 2015 at 1:22 AM, Alan Modra wrote:
> This cures an unrecognizable insn ICE by modifying a predicate of
> extenddftf2_internal (the only place this predicate is used) to ensure
> that rtl optimization passes do not substitute 0.0 for a register with
> known 0.0 value, except when VSX
On Thu, Apr 2, 2015 at 5:07 PM, Ilya Enkovich wrote:
> Hi,
>
> This patch fixes nested PARALLEL in retval for isntrumented calls. Current
> possible call:
>
> (call_insn:TI 6 30 17 2 (set (parallel [
> (expr_list:REG_DEP_TRUE (parallel:TI [
> (expr_list
On Tue, Mar 31, 2015 at 09:51:21 +0200, Jan Hubicka wrote:
> this patch adds the ARTIFICIAL flag check to avoid ODR merging to these.
> I oriignally tested DECL_ARTIFICIAL (decl) (that is TYPE_NAME) that randomly
> dropped type names on some classes but not all.
>
> Jason, please do you know what
On 03/20/2015 02:20 AM, Ilya Enkovich wrote:
Hi,
Identifiers read with input_identifier miss IDENTIFIER_TRANSPARENT_ALIAS bit.
We always expect it for instrumentation clones, thus restore it input_cgraph_1.
Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk?
Thanks,
Ilya
--
> On Tue, Mar 31, 2015 at 09:51:21 +0200, Jan Hubicka wrote:
> > this patch adds the ARTIFICIAL flag check to avoid ODR merging to these.
> > I oriignally tested DECL_ARTIFICIAL (decl) (that is TYPE_NAME) that randomly
> > dropped type names on some classes but not all.
> >
> > Jason, please do yo
> On 03/20/2015 02:20 AM, Ilya Enkovich wrote:
> >Hi,
> >
> >Identifiers read with input_identifier miss IDENTIFIER_TRANSPARENT_ALIAS
> >bit. We always expect it for instrumentation clones, thus restore it
> >input_cgraph_1. Bootstrapped and tested on x86_64-unknown-linux-gnu. OK
> >for trunk
On 04/02/2015 12:48 PM, Jan Hubicka wrote:
On 03/20/2015 02:20 AM, Ilya Enkovich wrote:
Hi,
Identifiers read with input_identifier miss IDENTIFIER_TRANSPARENT_ALIAS bit.
We always expect it for instrumentation clones, thus restore it input_cgraph_1.
Bootstrapped and tested on x86_64-unknown
On Thu, Apr 02, 2015 at 09:23:03PM +0300, Ilya Verbin wrote:
> Hmm, libgomp.c++/target-3.C still fails.
> Here is what I see in need_assembler_name_p:
Guess we should make the .omp_data_s.* types TYPE_ARTIFICIAL too.
Will take care of that tomorrow.
Jakub
On 04/02/2015 08:49 AM, Ilya Enkovich wrote:
Ping
2015-03-10 13:12 GMT+03:00 Ilya Enkovich :
Hi,
Currentl we loose returned bounds when functions are merged. This patch fixes
it by adding returne bounds support for cgraph_node::expand_thunk.
Bootstrapped and tested on x86_64-unknown-linux-
On 04/02/2015 08:51 AM, Ilya Enkovich wrote:
Ping. Patch doesn't affect not instrumented code.
Thanks,
Ilya
2015-03-18 15:19 GMT+03:00 Ilya Enkovich :
Hi,
This patch disables attempts to expand instrumentation thunks which appear when
we create specialized function versions. Problem was fou
> > 2015-03-18 Ilya Enkovich
> >
> > * cgraphunit.c (cgraph_node::expand_thunk): Don't expand
> > instrumentation thunks.
> >
> >
> > diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
> > index e640907..abc9cfe 100644
> > --- a/gcc/cgraphunit.c
> > +++ b/gcc/cgraphunit.c
> > @@ -1
> Hi,
>
> This patch fixes nested PARALLEL in retval for isntrumented calls. Current
> possible call:
>
> (call_insn:TI 6 30 17 2 (set (parallel [
> (expr_list:REG_DEP_TRUE (parallel:TI [
> (expr_list:REG_DEP_TRUE (reg:DF 21 xmm0)
>
> Hi,
>
> This patch doesn't allow instrumentation thunks calls while merging
> constructors and destructors. Not isntrumented code is not affeceted.
> Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk?
>
> Thanks,
> Ilya
> --
> gcc/
>
> 2015-04-02 Ilya Enkovich
>
>
On 04/02/2015 02:11 PM, Jan Hubicka wrote:
2015-03-18 Ilya Enkovich
* cgraphunit.c (cgraph_node::expand_thunk): Don't expand
instrumentation thunks.
diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index e640907..abc9cfe 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
On Thu, Apr 2, 2015 at 10:17 PM, Jan Hubicka wrote:
>> rtx b0 = gen_rtx_REG (BND64mode, FIRST_BND_REG);
>> rtx b1 = gen_rtx_REG (BND64mode, FIRST_BND_REG + 1);
>> - retval = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (3, retval, b0, b1));
>> - chkp_put_regs_to_expr_list (re
> Hi,
>
> Current in LTO static const bounds are created as external symbol. It
> doesn't work in case original symbols were removed and privatized. This
> patch introduces a separate comdat symbol to be used in LTO. Bootstrapped
> and tested on x86_64-unknown-linux-gnu. Does this approach
On Wed, Apr 01, 2015 at 11:37:41PM +0200, Bernhard Reutner-Fischer wrote:
>Bernd,
>
>same for c6x for unk_isa, fwiw.
Attached.
Ok for trunk for the c6x bits?
Ok for trunk for the bfin bits?
thanks,
>
>thanks,
>
>On 1 April 2015 at 23:34, Bernhard Reutner-Fischer
> wrote:
>> Hi,
>>
>> gcc/c-famil
> Ping
>
> 2015-03-10 13:12 GMT+03:00 Ilya Enkovich :
> > Hi,
> >
> > Currentl we loose returned bounds when functions are merged. This patch
> > fixes it by adding returne bounds support for cgraph_node::expand_thunk.
> > Bootstrapped and tested on x86_64-unknown-linux-gnu. OK for trunk?
> >
> On 04/02/2015 02:11 PM, Jan Hubicka wrote:
> >>>2015-03-18 Ilya Enkovich
> >>>
> >>> * cgraphunit.c (cgraph_node::expand_thunk): Don't expand
> >>> instrumentation thunks.
> >>>
> >>>
> >>>diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
> >>>index e640907..abc9cfe 100644
> >>>
On 03/30/2015 10:37 PM, Mikhail Maltsev wrote:
Hi!
I'm currently working on the proposed task of replacing rtx objects
(i.e. struct rtx_def) with derived classes. I would like to get some
feedback on this work (it's far from being finished, but basically I
would like to know, whether my modifica
> On Thu, Apr 2, 2015 at 10:17 PM, Jan Hubicka wrote:
>
> >> rtx b0 = gen_rtx_REG (BND64mode, FIRST_BND_REG);
> >> rtx b1 = gen_rtx_REG (BND64mode, FIRST_BND_REG + 1);
> >> - retval = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (3, retval, b0,
> >> b1));
> >> - chkp_put_reg
On 04/02/2015 03:13 PM, Jan Hubicka wrote:
I think it is really the transparent alias issue. The comment seems pretty
clear about it.
What is confusing is that instrumentation thunks are called thunks when they are
really not - thunk is a small hunk of code, while instrumentation thunk is a
t
Hi,
from what I understand, Evandro has addressed the comments from Kyrill.
Are there other problems to be addressed before the patches can go in?
Thanks,
Sebastian
On Tue, Mar 31, 2015 at 7:30 PM, Evandro Menezes wrote:
> Hi, Kyrill.
>
> At this moment, it suffices to use the same scheduling a
On Thu, Apr 02, 2015 at 11:19:14PM +0100, Sebastian Pop wrote:
> Hi,
>
> from what I understand, Evandro has addressed the comments from Kyrill.
> Are there other problems to be addressed before the patches can go in?
Trunk is currently in Stage 4 development, these patches are fairly
low-risk, b
On Thu, Apr 02, 2015 at 01:03:19PM -0400, David Edelsohn wrote:
> On Thu, Apr 2, 2015 at 1:22 AM, Alan Modra wrote:
> > This cures an unrecognizable insn ICE by modifying a predicate of
> > extenddftf2_internal (the only place this predicate is used) to ensure
> > that rtl optimization passes do n
On Thu, Apr 02, 2015 at 03:52:35PM +1030, Alan Modra wrote:
> This cures an unrecognizable insn ICE by modifying a predicate of
> extenddftf2_internal (the only place this predicate is used) to ensure
> that rtl optimization passes do not substitute 0.0 for a register with
> known 0.0 value, except
On Thu, Apr 2, 2015 at 7:41 PM, Michael Meissner
wrote:
> On Thu, Apr 02, 2015 at 03:52:35PM +1030, Alan Modra wrote:
>> This cures an unrecognizable insn ICE by modifying a predicate of
>> extenddftf2_internal (the only place this predicate is used) to ensure
>> that rtl optimization passes do no
On 04/02/2015 03:28 AM, Andre Vehreschild wrote:
Ping!
This should be in 5.1. Dominique and I feel like this patch is nearly obvious.
Regards,
Andre
On Wed, 25 Mar 2015 14:35:54 +0100
Andre Vehreschild wrote:
Hi all,
please find attached a fix for the recently introduced regression
On Wed, 25 Mar 2015, Jonathan Wakely wrote:
> I've convinced myself that Richard's patch is correct in all cases,
> but I think we also want this patch, to fix PR62259 and PR65147.
>
> For the generic std::atomic (i.e. not the integral or pointer
> specializations) we should increase the alignment
On Thu, 12 Feb 2015, Richard Henderson wrote:
> When we fixed PR54005,
Hm, there's confusion. When was this fixed? (Not fixed
AFAICT.) Maybe you mean PR54004, but there was no note there
either. Or maybe there's a typo and you meant some other PR and
that PR54005 is supposedly fixed by this pa
Patch ping: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01148.html
Thanks.
60 matches
Mail list logo
