[Bug target/126581] [16/17 Regression] -mavx10.2 no longer works by r16-9456-gca889982b6f259

"hjl.tools at gmail dot com via Gcc-bugs" <[email protected]> Mon, 03 Aug 2026 01:09:02 +0000
Newsgroups gmane.comp.gcc.bugs
Message-ID <[email protected]/bugzilla/>
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