Updated packages, now Mex files compiled with -O0 are "invalid mex file"?

I had a (previously working and compiling for months) set of MEX files. I updated my 3-month-old packages (which worked fine before with GCC/G++) with a pacman -Syu, and now here are my results:

For GCC/G++:

• O0 - MEX file is "invalid"
• O1-O2 - works
• O3 - "optimizes" away the entire program. A simple mexPrintf() in the right spot fixes this by forcing it not to optimize it away

For Clang:

• Nothing works, all optimization levels result in invalid mexfile

For TDM-GCC:

• Works flawlessly regardless of the optimization level

OS: Win 10, latest updates

Language: C++03

MATLAB Version: R2016B (without Update 7, though tested with, didn't help)

(Changing C++ or MATLAB versions is not an option, it's a client requirement)

MINGW64 GCC version: 9.2.0

TDM GCC version: 5.1.0-2

Compiling with mex isn't an option at the moment. (I made a new post about it here)

Here's what it looks like when the c++ object files are made:

g++ -c -IC:/Progra~1/MATLAB/R2016b/extern/include -I(some library we made) -g3 -O0 -m64 -DFLIP_MEX_DEBUG=1 -DFLIP_C -ansi -Wshadow -Wall -DMX_COMPAT_32 -DMATLAB_MEX_FILE -fexceptions -fno-omit-frame-pointer -D__WIN32__ myFile.cpp -o myFile.o

Here's what the C object files look like:

gcc -c -IC:/Progra~1/MATLAB/R2016b/extern/include -I(some library we made) -g3 -O0 -m64 -DFLIP_MEX_DEBUG=1 -DFLIP_C -ansi -Wshadow -Wall -DMX_COMPAT_32 -DMATLAB_MEX_FILE -fexceptions -fno-omit-frame-pointer -D__WIN32__ myFile2.c -o myFile2.o

Here's what it looks like when the MEX files are made from that object file:

g++ -m64 -shared -Wl,-Bsymbolic -Wl,--no-undefined -Wl,C:/Progra~1/MATLAB/R2016b/extern/lib/win64/mingw64/exportsmexfileversion.def -o myFile.mexw64 myFile.o (various .o files linked in here) -pthread -LC:/Progra~1/MATLAB/R2016b/bin/win64 -LC:/Progra~1/MATLAB/R2016b/extern/lib/win64/mingw64 -lmex -lmx

I noticed the following differences in what the mex command attempts and what we do:

Differences for the object file:

• We're using mingw G++ compiler, they use TDM (swapping didn't fix it)
• They include simulink/include, we do not. (adding didn't fix it)
• They use -O. Does that mean -O1? -O2? -O3? Unclear.

Differences for the mex file:

• We're using mingw G++ compiler, they use TDM (swapping didn't fix it)
• They had -s, we did not (Tried adding it, didn't fix anything)
• They had -llibmx -llibmex -llibmat -lm -llibmwlapack -llibmwblas, we did not. (Tried adding them, did not fix anything)
• They did NOT have -lmex -lmx (removing didn't fix it)
• We have -Wl,-Bsymbolic they do not (removing it didn't fix anything)

Obscure compiler issue is not my specialty. Anyone have any suggestions as to what might be the issue here?

Switching to TDM-GCC fixed the issue with mex files being invalid when compiled with -O0. Nothing else (despite the other differences I noticed) apparently mattered.

My mistake (I think) is that I swapped out G++ for TDM-G++, but did not also do so for GCC, and there are several C files in the repo.

As for compiling with MEX, that issue is also solved in the linked question, so it's an option as well.

EDIT: The issue seems to lie with GCC being updated over time. In any case, with -o0 it still creates an invalid mex file. With -o1-2 it's fine, with -o3 it omits important parts of the code unless a dummy print statement is added. I've found that the best balance is to set it to compile DEBUG with TDM-GCC/G++, and use GCC's latest for all else.