On 04/18/2017 09:14 AM, Jakub Jelinek wrote:

As mentioned in the PR, we now use TYPE_TYPELESS_STORAGE flag on
ARRAY_TYPEs to denote types that need the special C++ alias handling.
The problem is how is that created, we just use build_array_type and
set TYPE_TYPELESS_STORAGE on the result, but build_array_type uses type
caching, so we might modify that way some other array type.
If all the array type creation goes through build_cplus_array_type, that
wouldn't be a problem, as that flag is dependent just on the element
type, but that is not the case, c-family as well as the middle-end has
lots of spots that also create array types.  So in the end whether
one gets TYPE_TYPELESS_STORAGE flag or not is quite random, depends on
GC etc.

The following patch attempts to resolve this, by making the type hashing
take that flag into account.  Bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?

2017-04-18  Jakub Jelinek  <ja...@redhat.com>

        PR middle-end/80423
        * tree.h (build_array_type_1): New prototype.
        * tree.c (type_cache_hasher::equal): Also compare
        (build_array_type_1): No longer static.  Add typeless_storage
        argument, set TYPE_TYPELESS_STORAGE to it, if shared also
        hash it, and pass to recursive call.
        (build_array_type, build_nonshared_array_type): Adjust
        build_array_type_1 callers.
        * c-common.c (complete_array_type): Preserve TYPE_TYPELESS_STORAGE.
        * tree.c (build_cplus_array_type): Call build_array_type_1
        with the intended TYPE_TYPELESS_STORAGE flag value, instead
        of calling build_array_type and modifying TYPE_TYPELESS_STORAGE
        on the shared type.
        * g++.dg/other/pr80423.C: New test.
Rather than exporting build_array_type_1, which seems rather gross, why not add a default argument for typeless storage to build_array_type prototype in tree.h? That way existing users "just work", and in the cases where we may want to specify typeless storage, we can pass it into the build_array_type wrapper.

That seems marginally cleaner to me.


Reply via email to