tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] _Generic or __builtin_choose_expr


From: uso ewin
Subject: Re: [Tinycc-devel] _Generic or __builtin_choose_expr
Date: Fri, 30 Jun 2017 14:33:01 +0200

I've clean my commit and merge everything on my my mob which should be
easily mergeable with official mob:
https://github.com/cosmo-ray/tcc/commit/d2659993274e076894e039cc654fc9e1617ed056
On Thu, Jun 29, 2017 at 4:32 PM, Michael Matz <address@hidden> wrote:
> Hi,
>
> On Wed, 28 Jun 2017, uso ewin wrote:
>
>> > Are there any plans for C11's _Generic or at least __builtin_choose_expr?
>> >
>> >
>> > Best regards,
>> > Petr Skocik
>> >
>> > _______________________________________________
>> > Tinycc-devel mailing list
>> > address@hidden
>> > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>>
>> Hello,
>>
>> I was working on _Generic implementation on tcc(as an hobby)
>> Your mail made me want to continue my job, and yesterday I've succeed
>> to make something usable:
>> https://github.com/cosmo-ray/tcc/commits/generic
>
> Thanks for working on this.
>
>> The code as it is actually is pretty crappy, doesn't respect C
>> standard(main difference is I can't make difference between a char*,
>> an int * or any kind of pointer), but should be enough for most use
>> case, and pretty easy to merge on mob
>>
>> should I try to merge it to mob once I've clean my commits ?
>> maybe by adding some option like: "--with-fake-generic" ?
>> So _Generic are not enable by default
>
> Hmm.  I'd dislike an implementation of _Generic that isn't standard
> conforming (at least in most cases and as far as we know).  So try a bit
> harder to implement it fully :)  (I.e. you might need to extend
> compare_types)  A separate option wouldn't be needed then.

I've send my first mail before using compare_types, I was manually
comparing type->t,
(it was at this commit:
https://github.com/cosmo-ray/tcc/commit/ee647ecc9b02b0216c3823e2d4ca3cf51d1038ee)
which was broken.
but with compare_types everything seems to work nicely

>
> I've very briefly looked at your implementation: Don't use your current
> way of parsing the controlling expression/type, you should be able to
> reuse expr_type/parse_expr_type/parse_type (or parts of it).
>

Thanks for your advice, and done on mob branch on my github, expr_type
work great.

As buying the official C11 standard from ISO is a little expensive for
my, I use this draft for the implementation:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
I guess my implementation follow it, but I might have miss some stuff,
or add bug to tcc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]