On Wed, Feb 7, 2018 at 3:32 PM, Jakub Jelinek <ja...@redhat.com> wrote: > 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. Yes, I understand how we got to this point, but having the functions diverge because of this guideline seems like a mistake. And there seem to be two ways to avoid the divergence: make an exception to the guideline, or move the function. Jason
