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

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

[broly at mac dot com]

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

            Bug ID: 115408
           Summary: regression between gcc 13.3.0 and 14.1.0 using -mips16
                    and -minterlink-mips16 with openssl
           Product: gcc
           Version: 14.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: broly at mac dot com
  Target Milestone: ---

Created attachment 58394
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58394&action=edit
mips64el-none-linux-gnu, mabi=32, openssl 1.1.1v, gcc 13.3.0

hi,

i noticed today whilst compiling openssl that there is an issue with the 
-mips16 and -minterlink-mips16 flags.

to be specific, when i use gcc 13.3.0 i have no problem compiling both the
libcrypto/libssl libraries AND the openssl program with these flags (greatly
reducing their size).

i noticed in 14.1.0, the libraries compile fine but the compiler fails to
understand the optimised mips16 symbols when compiling the openssl program,
resulting in a failure.

the log for each build is labelled and provided.

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

[broly at mac dot com]

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

--- Comment #1 from gagan sidhu (broly) <broly at mac dot com> ---
Created attachment 58395
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58395&action=edit
mips64el-none-linux-gnu, openssl 1.1.1v, mabi=32, glibc 2.38

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-06-09

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
How did you configure gcc for both versions of GCC?

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

[broly at mac dot com]

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

--- Comment #3 from gagan sidhu (broly) <broly at mac dot com> ---
that's my secret sauce, dogg.

i can email it to you but don't give it out.

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

[broly at mac dot com]

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

--- Comment #4 from gagan sidhu (broly) <broly at mac dot com> ---


well, i can give the final pass since it's a bit generic:


AR=ar LDFLAGS="-Wl,-rpath,/cross/lib" \
    ../gcc-14.1.0/configure --prefix=/cross \
    --target=mips64el-none-linux-gnu --build=x86_64-apple-darwin17
--host=x86_64-apple-darwin17 --enable-shared \
    --disable-static --enable-frame-pointer
--enable-languages=c,c++,objc,fortran
--with-native-system-header-dir=/tools/include --with-glibc-version=2.38 \
    --with-mpc=/cross --with-mpfr=/cross --with-gmp=/cross  --with-isl=/cross

i highly doubt it's related to mpc, mpfr, gmp or isl.

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

[broly at mac dot com]

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

--- Comment #5 from gagan sidhu (broly) <broly at mac dot com> ---
hi andrew,

i tried compiling another program that wasn't openssl and a similar issue
arose. something is seriously wrong in 14.1.0 in terms of -mips16 and
-minterlink-mips16 mode

this is kinda urgent now:


/Volumes/xtoolshit/hdr3/le/cross/bin/../lib/gcc/mips64el-none-linux-gnu/14.1.0/../../../../mips64el-none-linux-gnu/bin/ld:
/tmp/ccPV2gsV.lto.o: in function `do_upgrade_post':
/Volumes/xtoolshit/misc/dd-wrt/src/router/httpd/modules/upgrade.c:402:(.text.do_upgrade_post+0x498):
warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
/Volumes/xtoolshit/hdr3/le/cross/bin/../lib/gcc/mips64el-none-linux-gnu/14.1.0/../../../../mips64el-none-linux-gnu/bin/ld:
/Volumes/xtoolshit/hdr3/le/cross/bin/../lib/gcc/mips64el-none-linux-gnu/14.1.0/../../../../mips64el-none-linux-gnu/bin/ld:
DWARF error: could not find abbrev number 85
/tmp/ccPV2gsV.lto.o: in function `ej_get_currate':
<artificial>:(.text.ej_get_currate+0x84): undefined reference to
`__mips16_call_stub_df_0'
/Volumes/xtoolshit/hdr3/le/cross/bin/../lib/gcc/mips64el-none-linux-gnu/14.1.0/../../../../mips64el-none-linux-gnu/bin/ld:
<artificial>:(.text.ej_get_currate+0x96): undefined reference to
`__mips16_gtdf2'


something to do with the stubs is screwed up, it seems.

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

[sjames at gcc dot gnu.org]

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

--- Comment #6 from Sam James <sjames at gcc dot gnu.org> ---
If it's "kinda urgent", please provide the full info we need, including "secret
sauce".

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

[broly at mac dot com]

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

gagan sidhu (broly) <broly at mac dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|regression between gcc      |regression between gcc
                   |13.3.0 and 14.1.0 using     |13.3.0 and 14.1.0 using
                   |-mips16 and                 |-mips16 and
                   |-minterlink-mips16 with     |-minterlink-mips16
                   |openssl                     |

--- Comment #7 from gagan sidhu (broly) <broly at mac dot com> ---
there is no secret sauce, as i said i gave the compiler command below. it's
just your typical CLFS stuff.

you should have no problem reproducing this if you use -mips16
-minterlink-mips16 with a glibc-2.3x toolchain and a multilib
mips64el-none-linux-gnu target.

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

[broly at mac dot com]

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

--- Comment #8 from gagan sidhu (broly) <broly at mac dot com> ---
how did you respond so fast? i don't see you on the CC list. that's kind of
cool but eerie. that's usually MY modus operandi, lol

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

[broly at mac dot com]

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

--- Comment #9 from gagan sidhu (broly) <broly at mac dot com> ---
Created attachment 58452
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58452&action=edit
curl failure

this is not gooood guysssssss :((((

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

[broly at mac dot com]

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

--- Comment #10 from gagan sidhu (broly) <broly at mac dot com> ---
Created attachment 58456
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58456&action=edit
findutils 4.10 failure

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

[broly at mac dot com]

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.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to gagan sidhu (broly) from comment #11)
> 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.

Note thumb was released in 1994 while MIPS16 came out in 1996 ...

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

[broly at mac dot com]

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

--- Comment #13 from gagan sidhu (broly) <broly at mac dot com> ---
oh i see, i didn't realise that thumb was pure 16 bit.

my apologies.

so i guess i meant thumb2, which would have the same effect of the
mips16/minterlink-mips16 flags that i use to "collapse" 32 bit executables?*

https://stackoverflow.com/a/71378041

apparently it's all called thumb though? not trying to escape your (very
welcome) correction, but i just wanted to share my surprise at learning this.

--
* often a nice savings in binary size.

of course i concede if you use a sophisticated compression algorithm on the
root file system containing these binaries, there is a significant reduction in
the benefit of the root filesystem compression (possibly even detrimental).