On Wed, 16 Dec 2020, Joseph Myers wrote: > On Sun, 13 Dec 2020, Martin Sebor via Gcc-patches wrote: > > > "nonstandard" isn't a very descriptive name. The leading g_ prefix > > also looks a little too terse (is that supposed to stand dor GIMPLE?). > > I would suggest choosing a better name, say, bool_precision. Since > > Indeed, g_ suggests the GLib API to me, so a name not involving g_ or > "nonstandard" seems better. > > The principle of a GIMPLE-front-end-specific attribute for this sort of > thing seems reasonable to me.
OK, does "integral_precision" sound better? (supposed to cover INTEGRAL_TYPE_P types) Or would "precision" be preferred (I used g_ to not conflict with possible future C attributes). Note that GCCs "nonstandard boolean types" are signed as opposed to bool which is unsigned so typedef _Bool bool1 __attribute__((precision(1))); would maybe result in a surprising result. One alternative would be to make the attribute have the signedness specified as well (C doesn't accept 'unsigned _Bool' or 'signed _Bool') or simply name the attribute "signed_bool_precision". I guess the bool case is really special compared to the desire to eventually allow declaring of a 3 bit precision signed/unsigned integer type. Allowing 'signed _Bool' with -fgimple might be another option of course. Thanks, Richard.
