https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126581
--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> --- (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
