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;
> > > > 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 (unsigned) 1
> > > > of course as that's even more easy to recognize).
> > >
> > > So, with the _Literal (type) constant syntax, what are we going to emit
> > > and parse for __int128 constants?
> > > _Literal (__int128) (0x123456ULL << 64 || 0x123456ULL), something else?
> >
> > Yes, unless we teach libcpp about larger than 64bit literals.
>
> Teaching libcpp about 128bit literals sounds like a much nicer idea
> indeed...
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
1ui64 and 1i64 suffixes, so that would mean accepting instead of l/L
i128 or I128.
Jakub
