[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays

["redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471

--- Comment #25 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Matt Bentley from comment #23)
> > Actually, don't quote me on that - I may be thinking of the
> > 'reinterpret_cast<_Tp>(0)' - one of the two.
> 
> Just to confirm, "reinterpret_cast<void *>(__first)" not required in this
> context,  either "reinterpret_cast<_Tp>(0)" or "static_cast<_Tp>(0)" *are*
> required to avoid warnings in clang when _Tp is a pointer. Either works fine.

What warning? Why can't you just pass 0 to __builtin_memset? It's a null
pointer constant. I don't see any warning from clang when using -Weverything.

In C++11 we'd just use nullptr of course, but that can't be used here as the
code must compile as C++98.

> I understand that reinterpret_cast isn't allowed inside constexpr, but not
> why, and can't find any resources explicitly stating the reasoning.

reinterpet_cast is forbidden in constexpr functions because it's purpose is to
break the type system and say "trust me, I know what I'm doing", and such
tricks are not allowed in constant expressions.

Using reinterpert_cast to convert 0 (a null pointer constant) into a pointer
type is just silly and poor style. That conversion can be done implicitly, it
doesn't need a sledgehammer to be used.

> But __builtin_constant_p allows it, so it's use is a matter of programmer
> choice, at least in this context.

It really isn't if the standard requires the algorithm to be 'constexpr' (which
we don't implement yet, but there's no point adding constructs which will just
make life harder in the future).