This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C/C++ PATCH to add __typeof_noqual (PR c/65455, c/39985)


On Mon, Jun 26, 2017 at 10:37:03AM -0600, Martin Sebor wrote:
> On 06/23/2017 08:46 AM, Marek Polacek wrote:
> > This patch adds a variant of __typeof, called __typeof_noqual.  As the name
> > suggests, this variant always drops all qualifiers, not just when the type
> > is atomic.  This was discussed several times in the past, see e.g.
> > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985>
> > or
> > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455>
> > It's been brought to my attention again here:
> > <https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01955.html>
> > 
> > One approach would be to just modify the current __typeof, but that could
> > cause some incompatibilities, I'm afraid.  This is based on rth's earlier
> > patch: <https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00268.html> but I
> > didn't do the address space-stripping variant __typeof_noas.  I also added
> > a couple of missing things.
> 
> I haven't reviewed all the discussions super carefully so I wonder
> what alternatives have been considered.  For instance, it seems to
> me that it should be possible to emulate __typeof_noqual__ by relying
> on the atomic built-ins' type-genericity.  E.g., like this:
> 
>   #define __typeof_noqual__(x) \
>     __typeof__ (__atomic_load_n ((__typeof__ (x)*)0, 0))

This doesn't seem to work with structs/arrays/VLA, so wouldn't help.
(typeof can't handle bit-fields, so no need to worry about those.)

Another thing, with the current patch, __typeof_noqual__(const int)
would still produce "const int".  With the __atomic_load_n proposal
it'd return "int".  I don't know what we want to do for typenames,
but __typeof__(_Atomic int) produces "atomic int".

> Alternatively, adding support for lower-level C-only primitives like
> __remove_const and __remove_volatile, to parallel the C++ library
> traits, might provide a more general solution and avoid introducing
> yet another mechanism for determining the type of an expression to
> the languages (C++ already has a few).

I don't know if that wouldn't be overkill.  Qualifiers on rvalues are
meaningless in C and that's why my __typeof_noqual strips them all.
We'd then need even e.g. __remove_restrict, not sure if there's need for
these.  Maybe it is.

> > +@code{typeof_noqual} behaves the same except that it strips type qualifiers
> > +such as @code{const} and @code{volatile}, if given an expression.  This can
> > +be useful for certain macros when passed const arguments:
> > +
> > +@smallexample
> > +#define MAX(__x, __y)			\
> > +  (@{					\
> > +  __typeof_noqual(__x) __ret = __x;	\
> > +  if (__y > __ret) __ret = __y;		\
> > +    __ret;				\
> > +  @})
> 
> The example should probably avoid using reserved names (with
> leading/double underscores).

No, because "typeof_noqual" isn't supported (but was in the first version
of the patch).

	Marek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]