On 12/19/18 6:14 PM, Jakub Jelinek wrote:
On Tue, Dec 18, 2018 at 10:27:56PM -0500, Jason Merrill wrote:
On 12/18/18 6:19 PM, Jakub Jelinek wrote:
On Tue, Dec 18, 2018 at 05:40:03PM -0500, Jason Merrill wrote:
On 12/18/18 3:45 PM, Jakub Jelinek wrote:
The following testcase FAILs, because parsing creates a TREE_CONSTANT
CONSTRUCTOR that contains CONST_DECL elts. cp_fold_r can handle that,
but constexpr evaluation doesn't touch those CONSTRUCTORs.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
OK. I also wonder if store_init_value should use cp_fold_r rather than just
cp_fully_fold.
I've been thinking about that already when working on the PR88410 bug.
Do you mean something like following completely untested patch?
Perhaps I could add a helper inline so that there is no code repetition
between cp_fully_fold and this new function.
Something like that, yes.
The following does the job too (even the PR88410 ICE is gone with the
cp-gimplify.c change from that patch reverted) and is shorter.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK, thanks.
Jason
