On Fri, 13 Jan 2017, Richard Biener wrote:
> On Fri, 13 Jan 2017, Jakub Jelinek wrote:
>
> > On Fri, Jan 13, 2017 at 09:15:22AM +0100, Richard Biener wrote:
> > > > @@ -1710,6 +1716,24 @@ dump_generic_node (pretty_printer *pp, t
> > > > print_hex (val, pp_buffer (pp)->digit_buffer);
> >
On Fri, 13 Jan 2017, Jakub Jelinek wrote:
> On Fri, Jan 13, 2017 at 09:15:22AM +0100, Richard Biener wrote:
> > > @@ -1710,6 +1716,24 @@ dump_generic_node (pretty_printer *pp, t
> > > print_hex (val, pp_buffer (pp)->digit_buffer);
> > > pp_string (pp, pp_buffer (pp)->digit_buffer);
> > >
On Fri, Jan 13, 2017 at 09:15:22AM +0100, Richard Biener wrote:
> > @@ -1710,6 +1716,24 @@ dump_generic_node (pretty_printer *pp, t
> > print_hex (val, pp_buffer (pp)->digit_buffer);
> > pp_string (pp, pp_buffer (pp)->digit_buffer);
> > }
> > + if ((flags & TDF_GIMPLE)
> > +
On Thu, 12 Jan 2017, Richard Biener wrote:
> On Thu, 12 Jan 2017, Jakub Jelinek wrote:
>
> > On Thu, Jan 12, 2017 at 01:35:32PM +0100, Richard Biener wrote:
> > > It also lacks expressiveness when comparing
> > >
> > > short s;
> > > s_1 = (short) 1;
> > > s_2 = short (1);
> > >
> > > IMH
On Thu, 12 Jan 2017, Jakub Jelinek wrote:
> Well, we need some suffix that will not clash with C++ mandated udlits
> very soon, it is already bad that i and Q suffixes are problematic.
> By sN, did you mean s128 or literally sN?
> I've googled around a little bit and only found comments about
> 1u
On January 12, 2017 4:53:54 PM GMT+01:00, Jakub Jelinek
wrote:
>On Thu, Jan 12, 2017 at 04:45:41PM +0100, Marc Glisse wrote:
>> > On Thu, 12 Jan 2017, Jakub Jelinek wrote:
>> >
>> > > On Thu, Jan 12, 2017 at 01:35:32PM +0100, Richard Biener wrote:
>> > > > It also lacks expressiveness when compa
On Thu, Jan 12, 2017 at 04:45:41PM +0100, Marc Glisse wrote:
> > On Thu, 12 Jan 2017, Jakub Jelinek wrote:
> >
> > > On Thu, Jan 12, 2017 at 01:35:32PM +0100, Richard Biener wrote:
> > > > It also lacks expressiveness when comparing
> > > >
> > > > short s;
> > > > s_1 = (short) 1;
> > > >
On Thu, 12 Jan 2017, Richard Biener wrote:
On Thu, 12 Jan 2017, Jakub Jelinek wrote:
On Thu, Jan 12, 2017 at 01:35:32PM +0100, Richard Biener wrote:
It also lacks expressiveness when comparing
short s;
s_1 = (short) 1;
s_2 = short (1);
IMHO having a _Literal somewhere makes it more ob
On Thu, 12 Jan 2017, Jakub Jelinek wrote:
> On Thu, Jan 12, 2017 at 01:35:32PM +0100, Richard Biener wrote:
> > It also lacks expressiveness when comparing
> >
> > short s;
> > s_1 = (short) 1;
> > s_2 = short (1);
> >
> > IMHO having a _Literal somewhere makes it more obvious what is mean
On Thu, Jan 12, 2017 at 01:35:32PM +0100, Richard Biener wrote:
> It also lacks expressiveness when comparing
>
> short s;
> s_1 = (short) 1;
> s_2 = short (1);
>
> IMHO having a _Literal somewhere makes it more obvious what is meant
> (I'm still going to dump 1u or 1l instead of _Literal (
On Thu, 12 Jan 2017, Jakub Jelinek wrote:
> On Thu, Jan 12, 2017 at 04:38:27PM +0530, Prathamesh Kulkarni wrote:
> > On 12 January 2017 at 16:15, Richard Biener wrote:
> > > On Thu, 12 Jan 2017, Jakub Jelinek wrote:
> > >
> > >> On Thu, Jan 12, 2017 at 10:52:23AM +0100, Richard Biener wrote:
> >
On Thu, Jan 12, 2017 at 04:38:27PM +0530, Prathamesh Kulkarni wrote:
> On 12 January 2017 at 16:15, Richard Biener wrote:
> > On Thu, 12 Jan 2017, Jakub Jelinek wrote:
> >
> >> On Thu, Jan 12, 2017 at 10:52:23AM +0100, Richard Biener wrote:
> >> > > I'll give the (short) 1 parsing a try though to
On 12 January 2017 at 16:15, Richard Biener wrote:
> On Thu, 12 Jan 2017, Jakub Jelinek wrote:
>
>> On Thu, Jan 12, 2017 at 10:52:23AM +0100, Richard Biener wrote:
>> > > I'll give the (short) 1 parsing a try though to see how awkward it
>> > > really gets.
>> >
>> > Ok, doesn't look a good way to
On Thu, 12 Jan 2017, Jakub Jelinek wrote:
> On Thu, Jan 12, 2017 at 10:52:23AM +0100, Richard Biener wrote:
> > > I'll give the (short) 1 parsing a try though to see how awkward it
> > > really gets.
> >
> > Ok, doesn't look a good way to go. Apart from making it difficult
> > to handle in the p
On Thu, Jan 12, 2017 at 10:52:23AM +0100, Richard Biener wrote:
> > I'll give the (short) 1 parsing a try though to see how awkward it
> > really gets.
>
> Ok, doesn't look a good way to go. Apart from making it difficult
> to handle in the parser you can't distinguish a conversion from an
> inte
On Thu, 12 Jan 2017, Richard Biener wrote:
> On Wed, 11 Jan 2017, Joseph Myers wrote:
>
> > On Wed, 11 Jan 2017, Richard Biener wrote:
> >
> > > As you can see I adjusted dumping of pointer constants (we can't
> > > parse the B suffix and large unsigned numbers get a warning so
> > > add 'U').
On Wed, 11 Jan 2017, Joseph Myers wrote:
> On Wed, 11 Jan 2017, Richard Biener wrote:
>
> > As you can see I adjusted dumping of pointer constants (we can't
> > parse the B suffix and large unsigned numbers get a warning so
> > add 'U'). There's the general issue that we dump
> >
> > short x;
On Wed, 11 Jan 2017, Richard Biener wrote:
> As you can see I adjusted dumping of pointer constants (we can't
> parse the B suffix and large unsigned numbers get a warning so
> add 'U'). There's the general issue that we dump
>
> short x;
> x = 1;
>
> and then lex the '1' as type int and th
The following fills the gap of missed handling of MEM_REF parsing.
As we want to represent all info that is on a MEM_REF the existing
dumping isn't sufficent so I resorted to
__MEM '<' type-name [ ',' number ] '>'
'(' [ '(' type-name ')' ] unary-expression
[ '+' number ] ')' *
19 matches
Mail list logo
