> Yeah, as said such optimistic merging would need to happen during canoncial
> type merging for example by completely ignoring TYPE_DOMAIN or
> DECL_FIELD_OFFSET ... (a non-constant in one unit may be the same as a
> constant in another...).
OK, that's really optimistic, and we can probably get a
On Wed, Jul 13, 2016 at 3:16 PM, Eric Botcazou wrote:
>> As tree merging really replaces trees it has to error on the side of not
>> merging while canonical type merging has to error on the side of "merging"
>> to make types alias.
>
> OK, then the former won't be sufficient for Ada, there are kno
> As tree merging really replaces trees it has to error on the side of not
> merging while canonical type merging has to error on the side of "merging"
> to make types alias.
OK, then the former won't be sufficient for Ada, there are known cases where
producers and clients of a package cannot see
On Mon, Jul 11, 2016 at 5:14 PM, Jan Hubicka wrote:
> Hi,
> Sorry for jumping in late, only now I had chance to read through the whole
> discussion.
> I was looking into similar problem some time ago.
>
>> Index: lto-streamer-out.c
>> ==
On Mon, Jul 11, 2016 at 3:28 PM, Eric Botcazou wrote:
>> So sth like
>>
>> Index: gcc/lto-streamer-out.c
>> ===
>> --- gcc/lto-streamer-out.c (revision 238039)
>> +++ gcc/lto-streamer-out.c (working copy)
>> @@ -996,7 +996,7
> I see that gimple_canonical_types_compatible_p winds up using
> operand_equal_p on expressions which represent the array size and that is
> why you need walk_simple_constant_arithmetic and operand_equal_p change.
Not just array size, but also offsets via gimple_compare_field_offset.
> I wonder
>
> So something akin to what I initially proposed?
> https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00182.html
I have similar patch to add_expr. I don't think it should have flag_wpa guard:
other FEs are keeping umberged decls, too, just not as often as LTO.
I am not sure about operand_equal_p
> It is fine to merge decls across static and external flags, but I am not
> sure this is a safe solution to the problem. In C it is perfectly normal to
> have one decl more specified or with different attributes. Like:
>
> extern int a __attribute__ ((warning("bar"));
>
> int a=7 __attribute__
Hi,
Sorry for jumping in late, only now I had chance to read through the whole
discussion.
I was looking into similar problem some time ago.
> Index: lto-streamer-out.c
> ===
> --- lto-streamer-out.c(revision 238156)
> +++ lt
> So sth like
>
> Index: gcc/lto-streamer-out.c
> ===
> --- gcc/lto-streamer-out.c (revision 238039)
> +++ gcc/lto-streamer-out.c (working copy)
> @@ -996,7 +996,7 @@ hash_tree (struct streamer_tree_cache_d
>else
>
On Wed, Jul 6, 2016 at 12:44 PM, Richard Biener
wrote:
> On Wed, Jul 6, 2016 at 12:21 PM, Richard Biener
> wrote:
>> On Wed, Jul 6, 2016 at 11:33 AM, Eric Botcazou wrote:
I see. I think the solution is to perform cgraph/varpool merging
before attempting to read in
the global decl
On Wed, Jul 6, 2016 at 12:21 PM, Richard Biener
wrote:
> On Wed, Jul 6, 2016 at 11:33 AM, Eric Botcazou wrote:
>>> I see. I think the solution is to perform cgraph/varpool merging
>>> before attempting to read in
>>> the global decl stream. IIRC Micha had (old) patches for this.
>>
>> How can y
On Wed, Jul 6, 2016 at 11:33 AM, Eric Botcazou wrote:
>> I see. I think the solution is to perform cgraph/varpool merging
>> before attempting to read in
>> the global decl stream. IIRC Micha had (old) patches for this.
>
> How can you merge varpool nodes if you haven't merged types?
>
>> But I
> I see. I think the solution is to perform cgraph/varpool merging
> before attempting to read in
> the global decl stream. IIRC Micha had (old) patches for this.
How can you merge varpool nodes if you haven't merged types?
> But I wonder why we don't tree-merge 'n' here (from my C example) and
On Wed, Jul 6, 2016 at 9:56 AM, Eric Botcazou wrote:
>> So this is sth like (invalid C)
>>
>> t.h
>> ---
>> int n;
>> struct X { int x[n]; };
>>
>> t1.c
>> --
>> #include "t.h"
>> struct X x;
>> t2.c
>> --
>> #include "t.h"
>> struct X x;
>>
>> ?
>
> Essentially yes, but with a single definition f
> So this is sth like (invalid C)
>
> t.h
> ---
> int n;
> struct X { int x[n]; };
>
> t1.c
> --
> #include "t.h"
> struct X x;
> t2.c
> --
> #include "t.h"
> struct X x;
>
> ?
Essentially yes, but with a single definition for 'n' and references to it.
> It's not obvious from the fix (which I
On Tue, Jul 5, 2016 at 12:57 PM, Eric Botcazou wrote:
> Hi,
>
> the deficiency comes from a chicken-and-egg problem during WPA: DECL nodes
> merging depends on type merging, but type merging also depends on DECL nodes
> merging for dynamic types declared at file scope, which easily occurs in Ada.
Hi,
the deficiency comes from a chicken-and-egg problem during WPA: DECL nodes
merging depends on type merging, but type merging also depends on DECL nodes
merging for dynamic types declared at file scope, which easily occurs in Ada.
For the attached trivial testcase, the compiler issues:
/hom
18 matches
Mail list logo
