Why doesn't Matlab support newer gcc versions?

Now that the C++11 standard is out, it would be nice to use its features directly when creating mex-files. However, even the latest Matlab R2012b only supports gcc 4.4, which does not have much of C++11 support in it. What are the principles by which the supported compiler is chosen for each version?

I am aware that I can separate the C++11 code into a dynamically-loaded library, and only use the gcc-4.4 code to redirect calls into that library. What I'm wondering though is why Mathworks did not update their compiler support to gcc-4.7, or at least gcc-4.6, straight-away with the 2012 releases?

Answer 1

[Ken Atwell]

Kaba, MathWorks chooses its MEX compiler support based on a number a factors. Primary among those is platform support. MathWorks has in fact experimented with more modern versions of GCC, but doing so introduces binary incompatibility with older supported Linux distributions, most notable Red Hat Enterprise Linux 5. This distribution is beginning to show its age, but it is an important platform to support. So, MathWorks is sticking with version 4.4. for now.

Your chart above (nice!) show a fairly consistent 1.5-2 year upgrade cycle, and without making any promises, I expect MathWorks to continue with this general pattern.

Answer 2

[Walter Roberson]

Lead time. C++11 was approved by ISO 12 August 2011 which would likely have presented difficulties for Mathworks to test adequately in time for the R2012a release. Likewise, the March 1 2012 release of gcc 4.7 would have been quite late in the development cycle to get gcc 4.7 support ready for R2012b.

gcc 4.6 was released 10 August 2011, two days before C++11 was approved.

I do not know why gcc 4.6 was not supported by the time of R2012b .

[Jan]

Does Matlab still enable the C89 standard as default in 2012b?

[Kaba]

The explanation based on lead time seems acceptable for gcc 4.7. According to

http://gcc.gnu.org/releases.html

though, the release date for gcc 4.6.0 was already in March 2011. Thus the time needed for testing only gives a partial answer to the question.

Could it be that they want to retain binary-compatibility between mex-files over several releases? This requires the same versions of g++ and C++ standard libraries. Listing the supported gcc-versions as a function of releases gives this:

• 2012b / 2012a - gcc 4.4
• 2011b / 2011a / 2010b - gcc 4.3
• 2010a / 2009b / 2009a - gcc 4.2
• 2008b / 2008a / 2007b / 2007a - gcc 4.1
• 2006b - gcc 3.4

which seems like a pattern of using the same gcc-version over at least 3 releases. By this conjecture the next window for gcc-version change would be 2013b :(