Hi,
here is patch I LTO-bootstrapped and regtested on x86_64-linux and I am going
to commit shortly. Thank you for useful discussion - I did not really realize
before that types may or may not have linkage. This caused surprises indeed ;)
Honza
* ipa-devirt.c (type_with_linkage_p): New f
> Looks good.
Thank you! Testing looks good, too, no false positives on Firefox.
I suppose the next challenge is to make type_with_linkage_p to return false on
types that was not built by C++ FE as discussed in
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01023.html
What would be the preferred so
Looks good.
Jason
> /* Record, union and enumeration type have linkage that allows use
>to check type_in_anonymous_namespace_p. Compound types
>can be always compared structurally.
>To save some work we compare builtin types properties of its main
>variant. A special case are i
> On 05/11/2015 04:39 PM, Jan Hubicka wrote:
> >What happens in LTO is that lto-symtab decide to merge the two declarations
> >of
> >foo. At this time it has chance to output the warning. For that it needs to
> >be able to work out that these declarations are having different types, but
> >becau
On 05/11/2015 04:39 PM, Jan Hubicka wrote:
What happens in LTO is that lto-symtab decide to merge the two declarations of
foo. At this time it has chance to output the warning. For that it needs to
be able to work out that these declarations are having different types, but
because LTO merge can
> On 05/11/2015 01:05 PM, Jan Hubicka wrote:
> >>On 05/11/2015 12:46 PM, Jan Hubicka wrote:
> >>>Well, my main motivatoin to extend from RECORD_OR_UNION_TYPE_P was to
> >>>handle
> >>>enums. But other case I would like to deal with are integer types - i.e.
> >>>preserve
> >>>difference between ch
On 05/11/2015 01:05 PM, Jan Hubicka wrote:
On 05/11/2015 12:46 PM, Jan Hubicka wrote:
Well, my main motivatoin to extend from RECORD_OR_UNION_TYPE_P was to handle
enums. But other case I would like to deal with are integer types - i.e.
preserve
difference between char/signed char/unsigned char/
> On 05/11/2015 12:46 PM, Jan Hubicka wrote:
> >Well, my main motivatoin to extend from RECORD_OR_UNION_TYPE_P was to handle
> >enums. But other case I would like to deal with are integer types - i.e.
> >preserve
> >difference between char/signed char/unsigned char/short/int/long/wchar in
> >case
On 05/11/2015 12:46 PM, Jan Hubicka wrote:
Well, my main motivatoin to extend from RECORD_OR_UNION_TYPE_P was to handle
enums. But other case I would like to deal with are integer types - i.e.
preserve
difference between char/signed char/unsigned char/short/int/long/wchar in cases
where they str
> On 05/11/2015 09:28 AM, Jan Hubicka wrote:
> >We already discussed earlier that type_in_anonymous_namespace_p is not
> >working
> >on compund types, because these do not have TYPE_STUB_DECL. I thought those
> >are
> >!TYPE_NAME types. What is reason for !TYPE_NAME type with no TYPE_STUB_DECL?
On 05/11/2015 09:28 AM, Jan Hubicka wrote:
We already discussed earlier that type_in_anonymous_namespace_p is not working
on compund types, because these do not have TYPE_STUB_DECL. I thought those are
!TYPE_NAME types. What is reason for !TYPE_NAME type with no TYPE_STUB_DECL?
Is it always a c
Jason,
I got my firefox tree building again and noticed that my patch to enable
ODR merging on non-class types caused false positives:
/aux/hubicka/trunk-install/include/c++/6.0.0/ext/new_allocator.h:66:26:
warning: type ‘(anonymous namespace)::ObservationWithStack const&’ violates one
definitio
13 matches
Mail list logo
