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
