On Thu, Feb 8, 2018 at 6:55 AM, Jakub Jelinek <ja...@redhat.com> 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.).
Looks good, thanks. Jason
