https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126581
--- Comment #10 from Hongtao Liu <liuhongt at gcc dot gnu.org> --- (In reply to H.J. Lu from comment #9) > (In reply to H.J. Lu from comment #8) > > (In reply to Jakub Jelinek from comment #7) > > > (In reply to Hongtao Liu from comment #6) > > > > (In reply to Jakub Jelinek from comment #5) > > > > > Still, I think such a change is unsuitable for a release branch > > > > > (unless you > > > > > add the new intrinsics and keep the old ones as aliases or something > > > > > similar). > > > > > We really don't want to force people to port their code more often > > > > > than when > > > > > they migrate to a newer gcc version, so what compiled with gcc 16.1 > > > > > (unless > > > > > it was UB etc.) should still compile by 16.5. That is why we try not > > > > > to > > > > > backport e.g. accepts-invalid fixes etc. > > > > > > > > I c, we can submit a fix to keep the original "typo" intrinsic as an > > > > alias > > > > to the new one. > > > > > > Yes, that would be appreciated. For 16.x only (unless it has been > > > backported to 15 as well), it can stay as is on the trunk obviously. > > > > I think the aliases should be controlled by a macro. For GCC 16, they > > should be enabled by default. > > Something like > > #ifndef __AVX10_2_COMPATIBLE_INTRINSICS__ > #define __AVX10_2_COMPATIBLE_INTRINSICS__ 0/1 > #endif > > #if __AVX10_2_COMPATIBLE_INTRINSICS__ > # define compatible aliases > #endif I prefer just add the alias version for 16.x and 15.x, not for trunk and no macro for the control of those aliases.
