On Thu, Feb 08, 2018 at 12:55:10PM +0100, Jakub Jelinek wrote:
> On Wed, Feb 07, 2018 at 04:21:43PM -0500, Jason Merrill wrote:
> > On Wed, Feb 7, 2018 at 4:14 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> > > On Wed, Feb 07, 2018 at 03:52:39PM -0500, Jason Merrill wrote:
> > >> > 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.
> > >
> > > Functionally, I think the following patch should turn fold_indirect_ref_1
> > > to be equivalent to the patched constexpr.c version (with the known
> > > documented differences), so if this is the obstackle for the acceptance
> > > of the patch, I can test this.
> > >
> > > Otherwise, I must say I have no idea how to share the code,
> > > same_type_ignoring_qualifiers is only a C++ FE function, so the middle-end
> > > can't use it even conditionally, and similarly with the TBAA issues.
> >
> > Again, can we make an exception and use poly_int in this function
> > because it's mirroring a middle-end function?
>
> So like this if it passes bootstrap/regtest? It is kind of bidirectional
> merge of changes between the 2 functions, except for intentional differences
> (e.g. the same_type_ignoring_top_level_qualifiers_p vs. ==, in_gimple_form
> stuff in fold-const.c, the C++ specific empty class etc. handling in
> constexpr.c etc.).
Better than my patch, and also has comments. Thanks and sorry for duplicated
effort!
Marek
