2015-04-02 20:01 GMT+03:00 Jan Hubicka :
>> 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 cod
2015-04-02 20:04 GMT+03:00 Jan Hubicka :
>> 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
>> referen
2015-04-02 21:48 GMT+03:00 Jan Hubicka :
>> 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
2015-04-02 22:42 GMT+03:00 Jeff Law :
> 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
2015-04-02 23:55 GMT+03:00 Jan Hubicka :
>> 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
Hello.
Following patch fixes a new issue, ICE has disappeared on aarch64-linux machine
and I was able to boostrap on
the machine. Moreover, no new regression seen on x86_64-linux-pc.
Ready for trunk?
Thanks,
Martin
>From b8463b8a7b2f6b652d6d9c3a2ece814ec5554619 Mon Sep 17 00:00:00 2001
From: ml
2015-04-03 0:13 GMT+03:00 Jan Hubicka :
>> 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/cgrap
On Thu, 2 Apr 2015, Hans-Peter Nilsson wrote:
> Why then use __alignof(_M_i) (the object-alignment)
> instead of _S_alignment (the deduced alas insufficiently
> increased type-alignment)?
(The immediate reason is that _S_alignment wasn't there until a
later revision, but the gist of the question r
Hi,
I've looked into avx* tests and many of them (even those that don't fail
in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63211) use invalid type
punning. Properly fixing them looks like a lot of work, so I propose
just adding -fno-strict-aliasing to them.
This patch was obtained by running
se
On Fri, Apr 3, 2015 at 1:02 PM, Ilya Tocar wrote:
> I've looked into avx* tests and many of them (even those that don't fail
> in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63211) use invalid type
> punning. Properly fixing them looks like a lot of work, so I propose
> just adding -fno-strict-
OK.
Jason
On 27-03-15 15:10, Tom de Vries wrote:
Hi,
this patch fixes PR65443, a todo in the parloops pass for function
transform_to_exit_first_loop:
...
TODO: the common case is that latch of the loop is empty and immediately
follows the loop exit. In this case, it would be better not to copy th
On Thu, Apr 02, 2015 at 08:02:57PM -0400, David Edelsohn wrote:
> If the final alternative cannot occur, it should be removed as well.
> Alan, would you please test that change also?
Tested powerpc64-linux and powerpc-linux no regressions.
* config/rs6000/rs6000.md (extenddftf2_internal):
On Mar 31, 2015, Jeff Law wrote:
>> - if (var1 != var2)
>> + if (var1 != var2 && !optimize)
>> return false;
> So when when the base variables are different and we are optimizing,
> this allows coalescing, right?
Yeah.
> What I don't see is a corresponding change to var_map_base_init to
> ens
On Mar 31, 2015, Richard Biener wrote:
>> + || !(SSA_NAME_IS_DEFAULT_DEF (var)
>> + || (param_defaults
>> + && bitmap_bit_p (param_defaults, part
> This looks somewhat awkward to me ;) Is it really important to allow
On Fri, Apr 3, 2015 at 8:51 AM, Alan Modra wrote:
> On Thu, Apr 02, 2015 at 08:02:57PM -0400, David Edelsohn wrote:
>> If the final alternative cannot occur, it should be removed as well.
>> Alan, would you please test that change also?
>
> Tested powerpc64-linux and powerpc-linux no regressions.
On Thu, Apr 02, 2015 at 09:05:53PM +0200, Jakub Jelinek wrote:
> 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 t
On 03/04/15 05:24 -0400, Hans-Peter Nilsson wrote:
On Thu, 2 Apr 2015, Hans-Peter Nilsson wrote:
Why then use __alignof(_M_i) (the object-alignment)
instead of _S_alignment (the deduced alas insufficiently
increased type-alignment)?
Isn't the object aligned to _S_alignment?
(The immediate r
On 03/18/2015 11:51 AM, Aldy Hernandez wrote:
On 03/17/2015 07:12 PM, Jason Merrill wrote:
Why are we outlining a DECL_EXTERNAL function?
SRA has no restrictions on whether a function is DECL_EXTERNAL.
Aha.
So it seems that DECL_EXTERNAL is the wrong gate for
equate_decl_number_to_die here
On 03/20/2015 08:11 PM, Aldy Hernandez wrote:
+ /* For class scoped static functions, the dumped early
+ version was the declaration, whereas the next time
+ around with a different context should be the
+ specification. In this case, avoid reusing th
On 03 Apr 13:39, Uros Bizjak wrote:
> On Fri, Apr 3, 2015 at 1:02 PM, Ilya Tocar wrote:
>
> > I've looked into avx* tests and many of them (even those that don't fail
> > in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63211) use invalid type
> > punning. Properly fixing them looks like a lot of
On Thu, Apr 02, 2015 at 10:35:35AM +0200, Marek Polacek wrote:
> 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
On 02 Apr 22:21, Jan Hubicka wrote:
> > 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
>
OK.
Jason
On 02 Apr 22:45, Jan Hubicka wrote:
> > 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
Hi,
On Thu, Apr 2, 2015 at 5:51 PM, James Greenhalgh
wrote:
> Trunk is currently in Stage 4 development, these patches are fairly
> low-risk, but they are certainly not regression fixes. I'll defer
> to port maintainers and release managers for the final say, but in my
> opinion it would not be a
2015-03-31 15:32 GMT+03:00 Ilya Enkovich :
> 2015-03-29 18:43 GMT+03:00 Jan Hubicka :
>> +static bool
>> +set_single_call_flag (cgraph_node *node, void *)
>> +{
>> + cgraph_edge *cs = node->callers;
>> + /* Local thunks can be handled transparently, skip them. */
>> + while (cs && cs->caller->t
> 2015-03-31 15:32 GMT+03:00 Ilya Enkovich :
> > 2015-03-29 18:43 GMT+03:00 Jan Hubicka :
> >> +static bool
> >> +set_single_call_flag (cgraph_node *node, void *)
> >> +{
> >> + cgraph_edge *cs = node->callers;
> >> + /* Local thunks can be handled transparently, skip them. */
> >> + while (cs
>
> Thanks a lot for looking into it! Seems originally I mostly got problems due
> to no DECL_WEAK for generated var, make_decl_one_only seems to work for my
> tests. Will run more testing to make sure it's OK. Here is a new patch
> version. Is it OK?
Good ;)
> diff --git a/gcc/tree-chkp.c
> On 02 Apr 22:21, Jan Hubicka wrote:
> > > 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?
> > >
> > > Tha
> 2015-04-03 0:13 GMT+03:00 Jan Hubicka :
> >> 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/cgraph
>
> Yep, there is such code in place. It is done by
> insert_bndret_call_after. You are right, I should use the same
> interface for both these cases.
That would be nice indeed. We should separate out and unify the code for
porducing
a wrapper call next stage1 (as Jeff mentions too).
>
> >> >
> > I think this will lead to wrong code. At this time, we may have multple
> > declarations sharing single assembler name (and thus
> > IDENTIFIER_TRANSPARENT_ALIAS link). Think of case where one unit defines
> > static
> > function and other global function of the same name. We may end up renami
> 2015-04-02 20:04 GMT+03:00 Jan Hubicka :
> >> 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
> >> thu
> Hello.
>
> Following patch fixes a new issue, ICE has disappeared on aarch64-linux
> machine and I was able to boostrap on
> the machine. Moreover, no new regression seen on x86_64-linux-pc.
>
> Ready for trunk?
> Thanks,
> Martin
> >From b8463b8a7b2f6b652d6d9c3a2ece814ec5554619 Mon Sep 17 00
Hi,
this patch fixes ordering issue where we try to resolve speculation while
we are mid of its duplication.
Bootstrapped/regtested x86_64-liinux, will commit it shortly.
Honza
PR ipa/65655
* ipa-inline-analysis.c (edge_set_predicate): Do not redirect
speculative indirect
> Assembler name of instrumented function is a transparent alias of
> original function's name. Alias chains are not taken into account by
> analysis. Thus we see no conflict between instrumented function's name
> and a variable name but emit them with the same assembler name. To
> detect name con
On Fri, Apr 3, 2015 at 5:17 PM, Sebastian Pop wrote:
> Hi,
>
> On Thu, Apr 2, 2015 at 5:51 PM, James Greenhalgh
> wrote:
>> Trunk is currently in Stage 4 development, these patches are fairly
>> low-risk, but they are certainly not regression fixes. I'll defer
>> to port maintainers and release m
In my fix for PR target/65240, I removed the special -ffast-math code that
delayed dealing with constants until reload time. In this patch, constants are
now pushed to memory earlier, and the compiler uses LFS (load floating point
single) to load double precision constants. When you use the LRA r
On 04/02/2015 11:59 PM, Yangfei (Felix) wrote:
Patch ping: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01148.html
This patch needs documentation for the new attributes and pragmas before
it can be committed. (Since this is a new feature I think it has to
wait until stage 1, too, but that's
On 04/03/2015 07:13 AM, Jonathan Wakely wrote:
> +++ b/libstdc++-v3/include/std/atomic
> @@ -165,9 +165,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> struct atomic
> {
> private:
> - // Align 1/2/4/8/16-byte types the same as integer types of that size.
> + // Align 1/2/4/8/16-by
On Fri, Apr 3, 2015 at 3:07 PM, Michael Meissner
wrote:
> In my fix for PR target/65240, I removed the special -ffast-math code that
> delayed dealing with constants until reload time. In this patch, constants
> are
> now pushed to memory earlier, and the compiler uses LFS (load floating point
>
On Tue, 31 Mar 2015, Ilya Enkovich wrote:
> +library. It also passes '-z bndplt' to a linker in case it supports this
> +option (which is checked on libmpx configuration). Note that old versions
> +of linker may ignore option. Gold linker doesn't support '-z bndplt'
> +option. With no '-z bndp
Hi,
this patch adds combined_size (i.e. size of caller after inlining) to the
denominator of the badness metric. This is based on observations in PR 65076.
Old metric did use relative time speedup to get into sane range with fixed
point math. I removed this after switching to sreals and this caus
Hi,
the dealII compilation ICEs on check that verifies that projected size match
the size after inlining. This check suffers from roundoff errors in corner
cases and I believe it is what triggers here.
Given that I have a reorg of this code to sreals scheduled for next stage1,
I think we can just
On Fri, Apr 03, 2015 at 07:53:12PM +0100, Ramana Radhakrishnan wrote:
> On Fri, Apr 3, 2015 at 5:17 PM, Sebastian Pop wrote:
> > Hi,
> >
> > On Thu, Apr 2, 2015 at 5:51 PM, James Greenhalgh
> > wrote:
> >> Trunk is currently in Stage 4 development, these patches are fairly
> >> low-risk, but they
On Fri, Apr 3, 2015 at 4:09 PM, James Greenhalgh
wrote:
> On Fri, Apr 03, 2015 at 07:53:12PM +0100, Ramana Radhakrishnan wrote:
>> On Fri, Apr 3, 2015 at 5:17 PM, Sebastian Pop wrote:
>> > Hi,
>> >
>> > On Thu, Apr 2, 2015 at 5:51 PM, James Greenhalgh
>> > wrote:
>> >> Trunk is currently in Stag
On April 4, 2015 5:03:14 AM GMT+02:00, Sebastian Pop wrote:
>On Fri, Apr 3, 2015 at 4:09 PM, James Greenhalgh
> wrote:
>> On Fri, Apr 03, 2015 at 07:53:12PM +0100, Ramana Radhakrishnan wrote:
>>> On Fri, Apr 3, 2015 at 5:17 PM, Sebastian Pop
>wrote:
>>> > Hi,
>>> >
>>> > On Thu, Apr 2, 2015 at 5:
48 matches
Mail list logo
