Jakub Jelinek <ja...@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 <ja...@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).