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

Question

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?

Answer 1

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.