On Thu, Dec 19, 2019 at 11:52 AM Richard Sandiford < richard.sandif...@arm.com> wrote:
> Jason Merrill <ja...@redhat.com> writes: > > On 12/12/19 10:16 AM, Richard Sandiford wrote: > >> As Jason pointed out in the review of the C++ gnu_vector_type_p patch: > >> > >> https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00173.html > >> > >> the real fix for the XFAILs in acle/general-c++/gnu_vectors_*.C is to > >> make same_type_p return false for two types if one is gnu_vector_type_p > >> and the other isn't. This patch does that and fixes the fallout in the > >> way Jason suggested above. > >> > >> I'd said at the time that some of the tests require: > >> > >> /* If the constructor already has the array type, it's been > through > >> digest_init, so we shouldn't try to do anything more. */ > >> bool digested = same_type_p (atype, TREE_TYPE (init)); > >> > >> (build_vec_init) to be true for gnu vectors built from non-gnu vectors. > >> I can no longer reproduce that, maybe because my original same_type_p > >> change was bogus or because something in the later sizeless type > >> support made it moot (or something else :-)). > >> > >> This means that sve-sizeless-2.C (the length-specific test) now reports > >> some errors for comparisons and pointer differences that > sve-sizeless-1.C > >> (the length-agnostic test) already had. I think requiring a cast is OK > >> for those cases, since there's no reason to mix GNU and non-GNU versions > >> of the same vector in the same object. Even -flax-vector-conversions > >> would require a cast for different vector types here, for both C and > C++. > >> > >> same_type_p had: > >> > >> else if (strict == COMPARE_STRUCTURAL) > >> return structural_comptypes (t1, t2, COMPARE_STRICT); > >> else > >> return structural_comptypes (t1, t2, strict); > >> > >> Since structural_comptypes ignored the COMPARE_STRUCTURAL bit of > "strict" > >> before the patch, the "else if" was harmless but AFAICT unnecessary. > > > > The comment in cp-tree.h has > > > >> #define COMPARE_STRUCTURAL 8 /* The comparison is intended to be > > >> structural. The actual comparison > > >> will be identical to > > >> COMPARE_STRICT. */ > > > > So introducing differences between COMPARE_STRUCTURAL and COMPARE_STRICT > > other than that the first always calls structural_comptypes and the > > second sometimes compares TYPE_CANONICAL instead is to be avoided. > > OK. > > > Do you want to use vector_types_convertible_p in similar_type_p? > > The problem then is that we'll apply -flax-vector-conversion rules too, > which seems to be going too far beyond what [conv.qual] says. > > But that's probably a sign that I was wanting the wrong behaviour here. > The main point is to ensure that similar GNU and non-GNU vectors remain > interconveritble without -flax-vector-conversions, and without any > warnings. There's no specific requirement to extend that to pointers, > it just seemed like the natural thing to do at the time. > > So on reflection, I guess we should just accept the consequences of > making the types !same_type_p. > > Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install? > If so, I'll follow up with a corresponding patch for C. > OK. > >
