This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][GIMPLE FE] Add parsing of MEM_REFs
On 12 January 2017 at 16:15, Richard Biener <rguenther@suse.de> 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 go. Apart from making it difficult
>> > to handle in the parser you can't distinguish a conversion from an
>> > integer literal and a short literal for
>> >
>> > short s;
>> > s_1 = (short) 1;
>>
>> As there are tons of types the integer literals can have, wouldn't it be
>> better to just introduce _Literal <type, value> where you could supply
>> the type if it is not one where C provides a suffix for it or int?
>> Then we could avoid adding lots of suffixes for new and newer types.
>> Of course for integer literals with int, unsigned int, {,unsigned} long {,long}
>> one would still use no suffix, U, {,U}L{,L} suffixes.
>
> That's an interesting idea. _Literal (type) value might be alternative
> syntax (a cast to be evaulated as literal). I'll give it a shot.
Um, how about just type(value) ?
s_1 = short (10);
AFAIU this isn't legal C and could be added as an extension ?
Thanks,
Prathamesh
>
>> > It looks like we currently have no way to write __int128 literals in C?
>> >
>> > __int128 x = 0xffffeeeeffffeeeeffffeeeeffffeeee;
>>
>> Yeah, one typically has to use
>> __int128 x = (((unsigned __int128) 0xffffeeeeffffeeeeULL) << 64) | 0xffffeeeeffffeeeeULL;
>> or something similar.
>
> I see.
>
> Thanks,
> Richard.