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
> 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:
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
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
> 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.
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
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
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 inline that into get_alias_set
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
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
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 existence of
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
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
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
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
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
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, 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.
Ok, but
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, 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?
I don't think
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 integer to
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?
I
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
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 { int i; } and struct {
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 now.
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
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
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 ptrdiff_t,
30 matches
Mail list logo
