On Mon, 12 Oct 2015, Jan Hubicka wrote:
> > Honza,
> > > this is a variant of patch I commited (adding the suggested predicate)
> >
> > This caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67923
>
> Hmm, strange, I do not seem to be able to reproduce this locally. Is it x86?
Can't reproduce
> Honza,
> > this is a variant of patch I commited (adding the suggested predicate)
>
> This caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67923
Hmm, strange, I do not seem to be able to reproduce this locally. Is it x86?
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/pr56015.f90:12:0: error: t
Honza,
> this is a variant of patch I commited (adding the suggested predicate)
This caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67923
Probably related pr66238 and pr66762.
TIA
Dominique
Hi,
this is a variant of patch I commited (adding the suggested predicate)
Honza
* tree.c (type_with_interoperable_signedness): New.
(gimple_canonical_types_compatible_p): Use it.
* tree.h (type_with_interoperable_signedness): Declare
* lto.c (hash_canonical_type)
> On Thu, 8 Oct 2015, Jan Hubicka wrote:
>
> > Hello,
> > here is updated version of the patch, this time without need to modify
> > useless_type_conversion. Just to recall the issue, Fortran C
> > interoperability
> > requires size_t to interoperate with signed version produced by Fortran FE.
>
On Thu, 8 Oct 2015, Jan Hubicka wrote:
> Hello,
> here is updated version of the patch, this time without need to modify
> useless_type_conversion. Just to recall the issue, Fortran C interoperability
> requires size_t to interoperate with signed version produced by Fortran FE.
> Unlike the exist
Hello,
here is updated version of the patch, this time without need to modify
useless_type_conversion. Just to recall the issue, Fortran C interoperability
requires size_t to interoperate with signed version produced by Fortran FE.
Unlike the existing logic in aliasing that makes signed and unsign
> > Hi,
> > I would like to ping this. There are still few things to fix to make our
> > merging compliant at least for C/C++/Fortran rules (the array bounds for
> > Fortran and union ordering for C I believe) and I would like to progress
> > on this.
>
> I don't like the changes to useless_type_
On Mon, 22 Jun 2015, Jan Hubicka wrote:
> > > On Mon, 8 Jun 2015, Jan Hubicka wrote:
> > >
> > > > >
> > > > > I think we should instead work towards eliminating the get_alias_set
> > > > > langhook first. The LTO langhook variant contains the same handling,
> > > > > btw,
> > > > > so just in
> > On Mon, 8 Jun 2015, Jan Hubicka wrote:
> >
> > > >
> > > > I think we should instead work towards eliminating the get_alias_set
> > > > langhook first. The LTO langhook variant contains the same handling,
> > > > btw,
> > > > so just inline that into get_alias_set and see what remains?
> >
> > On Mon, 8 Jun 2015, Jan Hubicka wrote:
> >
> > > >
> > > > I think we should instead work towards eliminating the get_alias_set
> > > > langhook first. The LTO langhook variant contains the same handling,
> > > > btw,
> > > > so just inline that into get_alias_set and see what remains?
> >
> On Mon, 8 Jun 2015, Jan Hubicka wrote:
>
> > >
> > > I think we should instead work towards eliminating the get_alias_set
> > > langhook first. The LTO langhook variant contains the same handling, btw,
> > > so just inline that into get_alias_set and see what remains?
> >
> > I see, i complet
On Mon, 8 Jun 2015, Jan Hubicka wrote:
> >
> > I think we should instead work towards eliminating the get_alias_set
> > langhook first. The LTO langhook variant contains the same handling, btw,
> > so just inline that into get_alias_set and see what remains?
>
> I see, i completely missed exist
> On Mon, 8 Jun 2015, Jan Hubicka wrote:
>
> > Hi,
> > this is a variant of patch that globs also the rest of integer types.
> > Note that we will still get false warnings out of lto-symtab when the
> > values are not wrapped up in structures. This is because lto-symtab
> > uses types_compatible_
> On Mon, 8 Jun 2015, Jan Hubicka wrote:
>
> > Thank you. It is interesting that the DR exists. We do have comments about
> > possibly completing the types by equiality established by the symbol table
> > but I tought it is strictly invalid. Not sure how much that buy us though.
> > As for speci
On Mon, 8 Jun 2015, Jan Hubicka wrote:
> Thank you. It is interesting that the DR exists. We do have comments about
> possibly completing the types by equiality established by the symbol table
> but I tought it is strictly invalid. Not sure how much that buy us though.
> As for specific examples
> On Mon, 8 Jun 2015, Jan Hubicka wrote:
>
> > Joseph, I may be wrong, but I believe that the cross-compilation-unit
> > representation compatibility (in C standard sense) is however not an
> > equivalence class, so it can't be fully represented by TYPE_CANOINICAL
>
> Indeed, type compatibility i
On Mon, 8 Jun 2015, Jan Hubicka wrote:
> Joseph, I may be wrong, but I believe that the cross-compilation-unit
> representation compatibility (in C standard sense) is however not an
> equivalence class, so it can't be fully represented by TYPE_CANOINICAL
Indeed, type compatibility is not transiti
>
> I think we should instead work towards eliminating the get_alias_set
> langhook first. The LTO langhook variant contains the same handling, btw,
> so just inline that into get_alias_set and see what remains?
I see, i completely missed existence of gimple_get_alias_set. It makes more
sense no
> On Mon, 8 Jun 2015, Jan Hubicka wrote:
>
> > Hi,
> > this is a variant of patch that globs also the rest of integer types.
> > Note that we will still get false warnings out of lto-symtab when the
> > values are not wrapped up in structures. This is because lto-symtab
> > uses types_compatible_
On Mon, 8 Jun 2015, Jan Hubicka wrote:
> > On Mon, 8 Jun 2015, Richard Biener wrote:
> >
> > > On Mon, 8 Jun 2015, Joseph Myers wrote:
> > >
> > > > On Mon, 8 Jun 2015, Richard Biener wrote:
> > > >
> > > > > I'm not sure the C standard mandates compatibility between
> > > > >
> > > > > struct
> On Mon, 8 Jun 2015, Richard Biener wrote:
>
> > On Mon, 8 Jun 2015, Joseph Myers wrote:
> >
> > > On Mon, 8 Jun 2015, Richard Biener wrote:
> > >
> > > > I'm not sure the C standard mandates compatibility between
> > > >
> > > > struct { int i; } and struct { unsigned i; } for purposes of TBA
On Mon, 8 Jun 2015, Richard Biener wrote:
> On Mon, 8 Jun 2015, Joseph Myers wrote:
>
> > On Mon, 8 Jun 2015, Richard Biener wrote:
> >
> > > I'm not sure the C standard mandates compatibility between
> > >
> > > struct { int i; } and struct { unsigned i; } for purposes of TBAA.
> > > Joseph?
>
On Mon, 8 Jun 2015, Joseph Myers wrote:
> On Mon, 8 Jun 2015, Richard Biener wrote:
>
> > I'm not sure the C standard mandates compatibility between
> >
> > struct { int i; } and struct { unsigned i; } for purposes of TBAA.
> > Joseph?
>
> I don't think they are necessarily compatible for TBAA.
On Mon, 8 Jun 2015, Richard Biener wrote:
> I'm not sure the C standard mandates compatibility between
>
> struct { int i; } and struct { unsigned i; } for purposes of TBAA.
> Joseph?
I don't think they are necessarily compatible for TBAA.
--
Joseph S. Myers
jos...@codesourcery.com
On Mon, 8 Jun 2015, Jan Hubicka wrote:
> Hi,
> this is a variant of patch that globs also the rest of integer types.
> Note that we will still get false warnings out of lto-symtab when the
> values are not wrapped up in structures. This is because lto-symtab
> uses types_compatible_p that in turn
On Mon, 8 Jun 2015, Jan Hubicka wrote:
> > Hi,
> > this patchs makes fortran's C_SIGNED_CHAR and C_SIZE_T interoperable with
> > signed char and size_t as standard require. There are two issues here.
> >
> > First Fortran integers are always signed, but the standard insist on the
> > signed int
Hi,
this is a variant of patch that globs also the rest of integer types.
Note that we will still get false warnings out of lto-symtab when the
values are not wrapped up in structures. This is because lto-symtab
uses types_compatible_p that in turn uses useless_type_conversion and
that one needs t
> Hi,
> this patchs makes fortran's C_SIGNED_CHAR and C_SIZE_T interoperable with
> signed char and size_t as standard require. There are two issues here.
>
> First Fortran integers are always signed, but the standard insist on the
> signed integer to match C size_t that is unsigned (if it was p
29 matches
Mail list logo
