On January 12, 2017 4:53:54 PM GMT+01:00, Jakub Jelinek <ja...@redhat.com> 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 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.
Indeed i64 and ui64 it was, found referenced on some stack overflow post. There was i16 and ui16 as well, can't see i128 mentioned there though. Richard. > > Jakub
