[Bug target/115408] regression between gcc 13.3.0 and 14.1.0 using -mips16 and -minterlink-mips16

["broly at mac dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115408

--- Comment #11 from gagan sidhu (broly) <broly at mac dot com> ---
dear lad(ettes),

i just want to take this opportunity to contrast this scenario, had the
equivalent occurred on the inferior, unjustifiably hyped, ARM architecture's
"thumb" mode, which is arguably a clone of MIPS16.

if such an unthinkable and catastrophic (/s) event occurred, my bet the team
would have pushed a 14.1.1 to resolve it. this is, of course, in spite of ARM's
inferiority.

but i get it, it's like when you have fans you always gotta satisfy the casuals
who don't even know what they're doing (why else would they use an ARM?).

at the same time it upsets me because ARM still doesn't have SMT, and i love
deferring to the embedded legend ralf baechle who never thought ARM would even
get a shot at going multicore because really, SMT can be conflated with SMP
(i'm not trying to start a rabble rabble here, so forgive me if this statement
evokes a passionate disagreement): https://tldp.org/HOWTO/SMP-HOWTO-3.html

and ralf is no fool. 

i will say, and this is of course no fault of the great gcc team, i do get
amused by the "multilib" ARM toolchain that seemingly grows with each
iteration, always (of course) incompatible with the previous one (if we use the
MIPS standard, of course. flipping a bit+resetting isn't the kind of thing i
call compatibility)

just weird how the better processors are being forgotten. i guess that's the
"industry" though and i'm comparatively young to the real maintainers in the
GNU sphere.

thanks for tolerating me, i appreciate it.