...
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?
I don't know if exception handling has changed but if it's a bug
(either a code generation bug in GCC or one in the program that's
triggered by optimization), the symptoms can manifest in all sorts
of bizarre ways.
Based on all the debugging you've already done it sounds like
you're on the right track. Unless the symptoms jog someone's
memory of a known bug, the most helpful next step is to marrow
it down to a small test case that's independent of Matlab. Doing
it by hand is time consuming and tedious (as you know) but it
goes much faster using multidelta. See the Wiki for how to use
it:
https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
For this exercise I would suggest using the -OX option that
triggers the problem and leaving the fine-grained optimization
options alone until you have a small test case that indicates
a bug in GCC. With the test case we can then look at the dumps
for the suspect optimization passes to see where it gets
introduced.
Martin
PS If you decide to give Multidelta a try, be sure to use -Wall
and -Werror to prevent Multidelta from introducing new errors
into the test case that mask the bug you are trying to expose.
I also find it useful to add printf statements to the test case
and having the Multidelta script verify their output. That helps
prevent the tool from removing the code that triggers the bug
while injecting a new one that masks it. With a good script,
you can sit back and let Multidelta do all the work for you.
