https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88587
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #5) > I think the problem is that while we make TYPE_MODE something dynamic for > vector types (which takes into account whether the current function supports > in hw such vectors or not): > #define TYPE_MODE(NODE) \ > (VECTOR_TYPE_P (TYPE_CHECK (NODE)) \ > ? vector_type_mode (NODE) : (NODE)->type_common.mode) > we don't do the same thing for DECL_MODE: > /* Holds the machine mode corresponding to the declaration of a variable or > field. Always equal to TYPE_MODE (TREE_TYPE (decl)) except for a > FIELD_DECL. */ > #define DECL_MODE(NODE) (DECL_COMMON_CHECK (NODE)->decl_common.mode) > #define SET_DECL_MODE(NODE, MODE) \ > (DECL_COMMON_CHECK (NODE)->decl_common.mode = (MODE)) > We've run into this several times in the past already. See e.g. PR78643. > > It is probably not the right time to change the DECL_MODE macro definition > in stage4, so that leaves us to do some hacks where needed. I thought the same in a similar bug but ended up discarding that (I don't remember enough though to explain why). I think the canonical way of re-computing DECL_MODE would be to re-layout decls since that also updates RTL if that was already set. There's relayout_decl for this which is for example called from omp-simd-clone.c and the vectorizer.
