Hello,
This one is quite curious ... almost like a twilight zone episode.... I have an old version of matlab, probably was compiled with gcc-4.1.1 and it ships with libgcc_s.so and libstdc++.so that were part of gcc-4.1.1 (or at least that what it says in a README). Matlab really insists in using
these libraries, and breaks if I try to use newer ones in Red Hat 6 distro.
Matlab also allows people to write their own C code as a shared library - all it needs is the person to implement a function with the name mexFunction, which matlab calls with a specific set of parameters. All cool, until one uses C++ behind that function. I got a rather large chunk of code
written in C++ hiding behind that 'mexFunction', but we only have one exception class - we can toss only one type of exception, and of course, just below mexFunction, we have a catch to avoid the exception to propagate into the C code and matlab. At certain point I was so desperate that I even added
a catch all ( with the ... ).
Here is the thing ... compiling with gcc 4.9.2 in debug mode everything is good, and very complex things work very well, throwing all kinds of exceptions in thousands of different runs. I try to compile with -O3 and I get a nasty core dump "terminate called after throwing an instance of
'bcException*' "... I have to admit I was quite aggressive in terms of stripping the code, and keeping hidden symbols - the only exported symbol is 'mexFunction'. With google's help, I went into a wild goose chase thru debugging the stuff with gdb, playing with symbol visibility, exporting multiple
symbols - 'How to write shared libraries' by Ulrich Drepper scared me senseless, with the whole story about typeinfo, the visibility of typeinfo, and lots of other stuff that seem to make a lot of sense, but did not work at all. I spent days playing with that stuff, looking at different outputs from
nm and objdump ... Simply nothing worked.
This morning, I pulled a little 'Sherlock' moment ... if all the exported symbols are identical between debug and optimize, then the issue has nothing to do with symbol visibility - though does not make any sense, it has to do with optimization options ... (no matter how improbable it is) ...
I found out that if I used -O1 everything works as if it was some kind of magic. I even came up with a strange workaround to build some of my libraries with -O1 flag and others that I really need the deep inlining to use the -O3. Eventually it would always go back to the infamous terminate, if not
in the first example, in some example along the way.
I was determined to find out what was going on. Using the -Q --help=optimizers I first identified the differences between -O3 and -O1 levels, and then recompiled about a 100x my entire code using a recursive binary by hand approach to test the different -f options like -ftree-pre, etc... Then
matlab crashes, modify, recompile, try again ... I am not giving up on this. Eventually I found 3 culprits 'beyond any reasonable doubt' - if I turn any of these on:
-fexpensive-optimizations
-freorder-blocks
-freorder-blocks-and-partition
the first test I try I get the pesky terminate. If I use the -O3 -fno... with the 3 of them explicitly removed, I was able to actually run my automated tests - about a 1000 of them - without any issues.
At this point, I am more curious, and hopefully providing good feedback than looking for another way to fix the problem. I am very happy with 4.9.2, it provides a substantial boost in speed compared with 4.1.1 .... Does this strange relationship of exception handling + optimizations ring any bell?
Did the handling of exceptions change between 4.1.1 and 4.9.2 ? Why would optimization options interfere with exception handling?
Thanks very much, both for an outstanding job with gcc - it is way better than just a few years ago - and for any insight you might have on this issue.
Best,
Ricardo
