On Mon, Nov 20, 2023 at 09:18:57AM +0100, Florian Weimer wrote:
> * Richard Biener:
> 
> > Ugh.  First of all I don't like that the exception is applied during
> > folding.  As for the problem of multi evaluation can't consumers use
> > stmt expressions for this, say
> >
> > {( auto __tem = value; __builtin_xyz (__tem, __typeof (__tem)); ... )}
> >
> > ?  Thus use 'auto' to avoid spelling 'value' multiple times?
> 
> {( … )} cannot be used in a constant expression, but the new macros are
> supposed to be usable there.

I'm not sure about that, it would be nice for them to be usable there,
but I think e.g. none of Joseph's implementation of those macros
made them usable there (except inside of sizeof/typeof/typeof_unquall)
and I don't see a requirement in the C23 standard that they must be usable
in constant expressions.
The versions I've posted on Thursday were usable there except for
stdc_has_single_bit (but that actually can be implemented that way too)
and stdc_bit_floor.  And the version I haven't posted that used the 3
patches posted on Saturday would have all functions usable when the
argument to those macros is a constant expression.

BTW, if we go route of implementing all of the stdc_ type-generic macros
as builtins, we could as well not implement that way the following 4
# define stdc_first_leading_one(x) (__builtin_clzg (x, -1) + 1U)
# define stdc_first_trailing_one(x) (__builtin_ctzg (x, -1) + 1U)
# define stdc_count_ones(x) ((unsigned int) __builtin_popcountg (x))
# define stdc_has_single_bit(x) ((_Bool) (__builtin_popcountg (x) == 1))
which are implementable without any new extensions.

        Jakub

Reply via email to