Re: [C++ PATCH RFC] PR c++/80265 - constexpr __builtin_mem*.

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Jan 13, 2020 at 06:38:23PM +0000, Jonathan Wakely wrote:
> > > On 11/01/20 00:03 -0500, Jason Merrill wrote:
> > > >The library has already worked around this issue, but I was curious about
> > > >why it wasn't working.  The answer: because we were passing &var to fold,
> > > >which doesn't know about the constexpr values hash table.  Fixed by
> > > passing
> > > >&"str" instead.
> > > >
> > > >Tested x86_64-pc-linux-gnu.  Does this seem useful even though it isn't
> > > >necessary anymore?
> > > 
> > > I'd still like to be able to use memcpy and memmove in constexpr
> > > evaluation. We've added our own "std::__memmove" for use at compile
> > > time, but it doesn't really have the same semantics. We could fix
> > > that, but it would be better to just use the real thing.
> > > 
> > 
> > Ah, supporting memcpy/memmove would be more work than the cmp/chr
> > functions, I'd have to reimplement them entirely in constexpr.c.
> 
> Ah, OK, nevermind then. We'll reimplement just what we need in the
> library.

Guess the hardest part is write helper functions that reads or stores a
single byte at specific address, the builtins then could be easily
implemented by just calling those in a way simplest C implementation of
those functions would do.  But if we have those, we could handle easily many
of the str/mem* functions that way.

	Jakub