On Mon, 5 Dec 2016, Jakub Jelinek wrote:
> On Mon, Dec 05, 2016 at 10:55:05AM -0700, Jeff Law wrote:
> > On 12/05/2016 09:54 AM, Jakub Jelinek wrote:
> > >The recent changes to move strchr folding from builtins.c to gimple-fold.c
> > >broke constexpr handling with __builtin_strchr etc. (which the libstdc++
> > >folks want to use).
> > >
> > >Fixed by handling it also in fold-const-call.c. Bootstrapped/regtested on
> > >x86_64-linux and i686-linux, ok for trunk?
> > >
> > >2016-12-05 Jakub Jelinek <ja...@redhat.com>
> > >
> > > PR c++/71537
> > > * fold-const-call.c (fold_const_call): Handle
> > > CFN_BUILT_IN_{INDEX,STRCHR,RINDEX,STRRCHR}.
> > >
> > > * g++.dg/cpp0x/constexpr-strchr.C: New test.
> > Thoughts on moving this into match.pd? I don't see any string builtins
> > there, so perhaps leave it in fold-const-call for now, then move them as a
> > group later?
>
> At least my understanding has been that such stuff goes into
> fold-const-call.c in the new world. The GIMPLE optimizers for these functions
> have also been added to gimple-fold.c, not to match.pd.
Yes, constant folding goes to fold-const-call.c and folding to
gimple-fold.c. In theory match.pd would be an option but I need to
sit down and invent a syntax for properly handling virtual operands
(very few special cases would already work automagically but in general
you need to be explicit).
So for now, fold-const-call.c and gimple-fold.c.
Richard.
