C++ PATCH to fix ICE with vector expr folding (PR c++/83659)

[Richard Sandiford]

Jakub Jelinek <jakub@redhat.com> writes:
> On Wed, Feb 07, 2018 at 03:23:25PM -0500, Jason Merrill wrote:
>> On Wed, Feb 7, 2018 at 2:48 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> > On Wed, Feb 07, 2018 at 08:36:31PM +0100, Marek Polacek wrote:
>> >> > > That was my first patch, but it was rejected:
>> >> > > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00271.html
>> >> >
>> >> > Then should we update fold_indirect_ref_1 to use the new code?  Is
>> >> > there a reason for them to stay out of sync?
>> >>
>> >> One of the reasons is that middle end uses poly_uint64 type but the
>> >> front ends
>> >> shouldn't use them.  So some of these functions will unfortunately differ.
>> >
>> > Yeah.  Part of the patch makes the two implementations slightly more
>> > similar, but I have e.g. no idea how to test for poly_uint64 that fits
>> > also in poly_int64 and the poly_int* stuff makes the two substantially
>> > different in any case.
>> 
>> Hmm.  Well, that seems rather unfortunate.  Why shouldn't the front
>> ends use them?  Can we make an exception for this function because
>> it's supposed to mirror a middle-end function?
>> Should we try to push this function back into the middle end?
>
> The function comment seems to explain the reasons:
> /* A less strict version of fold_indirect_ref_1, which requires cv-quals to
>    match.  We want to be less strict for simple *& folding; if we have a
>    non-const temporary that we access through a const pointer, that should
>    work.  We handle this here rather than change fold_indirect_ref_1
>    because we're dealing with things like ADDR_EXPR of INTEGER_CST which
>    don't really make sense outside of constant expression evaluation.  Also
>    we want to allow folding to COMPONENT_REF, which could cause trouble
>    with TBAA in fold_indirect_ref_1.
>    
>    Try to keep this function synced with fold_indirect_ref_1.  */
>
> E.g. the constexpr function uses same_type_ignoring_top_level_qualifiers_p
> instead of == type comparisons, the COMPONENT_REF stuff, ...
>
> For poly_* stuff, I think Richard S. wants to introduce it into the FEs at
> some point, but I could be wrong; certainly it hasn't been done yet and
> generally, poly*int seems to be a nightmare to deal with.

There's no problem with FEs using poly_int now if they want to,
or if it happens to be more convenient in a particular context
(which seems to be the case here to avoid divergence).  It's more
that FEs don't need to go out of their way to handle poly_int,
since the FE can't yet introduce any cases in which the poly_ints
would be nonconstant.

In practice FEs do already use poly_int directly (and indirectly
via support routines).

Thanks,
Richard