On Sat, Oct 31, 2020 at 6:35 PM Jan Hubicka wrote:
> > On 10/29/20 1:40 PM, Richard Biener wrote:
> > > On Thu, 29 Oct 2020, Jakub Jelinek wrote:
> > >
> > > > On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote:
> > > > > >
> > > > > > That's ugly and will for sure defeat warning / acces
On October 31, 2020 11:35:01 PM GMT+01:00, Jan Hubicka wrote:
>> On 10/29/20 1:40 PM, Richard Biener wrote:
>> > On Thu, 29 Oct 2020, Jakub Jelinek wrote:
>> >
>> > > On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote:
>> > > > >
>> > > > > That's ugly and will for sure defeat warning /
> On 10/29/20 1:40 PM, Richard Biener wrote:
> > On Thu, 29 Oct 2020, Jakub Jelinek wrote:
> >
> > > On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote:
> > > > >
> > > > > That's ugly and will for sure defeat warning / access code
> > > > > when we access this as char[], no? I mean, we
On 10/29/20 1:40 PM, Richard Biener wrote:
On Thu, 29 Oct 2020, Jakub Jelinek wrote:
On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote:
That's ugly and will for sure defeat warning / access code
when we access this as char[], no? I mean, we could
as well use 'int str[1];' here?
W
On Thu, 29 Oct 2020, Jakub Jelinek wrote:
> On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote:
> > >
> > > That's ugly and will for sure defeat warning / access code
> > > when we access this as char[], no? I mean, we could
> > > as well use 'int str[1];' here?
> >
> > Well, we always
> On Thu, 29 Oct 2020, Jan Hubicka wrote:
>
> > >
> > > That's ugly and will for sure defeat warning / access code
> > > when we access this as char[], no? I mean, we could
> > > as well use 'int str[1];' here?
> >
> > Well, we always get char pointer via macro that is IMO OK, but I am also
> >
> On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote:
> > >
> > > That's ugly and will for sure defeat warning / access code
> > > when we access this as char[], no? I mean, we could
> > > as well use 'int str[1];' here?
> >
> > Well, we always get char pointer via macro that is IMO OK,
On Thu, Oct 29, 2020 at 05:00:40PM +0100, Jan Hubicka wrote:
> >
> > That's ugly and will for sure defeat warning / access code
> > when we access this as char[], no? I mean, we could
> > as well use 'int str[1];' here?
>
> Well, we always get char pointer via macro that is IMO OK, but I am also
On Thu, 29 Oct 2020, Jan Hubicka wrote:
> >
> > That's ugly and will for sure defeat warning / access code
> > when we access this as char[], no? I mean, we could
> > as well use 'int str[1];' here?
>
> Well, we always get char pointer via macro that is IMO OK, but I am also
> not very much in
>
> That's ugly and will for sure defeat warning / access code
> when we access this as char[], no? I mean, we could
> as well use 'int str[1];' here?
Well, we always get char pointer via macro that is IMO OK, but I am also
not very much in love with this.
>
> Maybe we can invent some C++ attri
> On Thu, Oct 29, 2020 at 04:50:54PM +0100, Jan Hubicka wrote:
> > * tree.c (build_string): Update.
> > * tree-core.h (tree_fixed_cst): Avoid typeless storage.
>
> Is it valid then to
> #define TREE_STRING_POINTER(NODE) \
> ((const char *)(STRING_CST_CHECK (NODE)->string.str))
> and strc
On Thu, 29 Oct 2020, Jan Hubicka wrote:
> Hi,
> this patch removes second char array from tree_def union and makes it
> !TYPELESS_STORAGE. Now all accesses to anything in tree no longer have alias
> set 0, but they all have alias set 1 :)
> This is because the way we handle unions. However it sti
On Thu, Oct 29, 2020 at 04:50:54PM +0100, Jan Hubicka wrote:
> * tree.c (build_string): Update.
> * tree-core.h (tree_fixed_cst): Avoid typeless storage.
Is it valid then to
#define TREE_STRING_POINTER(NODE) \
((const char *)(STRING_CST_CHECK (NODE)->string.str))
and strcpy etc. it a
13 matches
Mail list logo
