[Bug] gcc bug affecting OCC fundamentals

It sounds as brutal as unbelievable but I can only attribute this to a gcc bug. If anyone has other explanation/recommendation that would be interesting and valuable.
Here is the simplest test case:

#include

void TestMat()
{
gp_Mat M0;
cerr }

Default constructor of gp_Mat initializes the internal 3x3 matrix with 0 (see gp_Mat.lxx), so is expected output. This is really the case on all configurations:
- Visual Studio 2005, 2008 on Windows
- gcc 4.0.1 -m32 with both -O2 and -O0 on MacOS 10.5 64bit
- gcc 4.1.2 -m32 with -O0 on Linux 64bit

However, gcc 4.1.2 with -O2 -m32 produces weird results leaving 2 of 3 matrix rows (i.e. elements (2,1)-(3,3)) uninitialized. I came to this observation during digging test cases in CAD Exchanger failing on Linux in release mode (-O2).

Looking at gp_Mat.lxx we see the following:

#define Mat00 ((Standard_Real*)M)[0]
#define Mat01 ((Standard_Real*)M)[1]
[…]
#define Mat22 ((Standard_Real*)M)[8]

inline gp_Mat::gp_Mat () {
const Standard_Address M = (Standard_Address)&(matrix[0][0]);
Mat00 =
Mat01 =
Mat02 =
Mat10 =
Mat11 =
Mat12 =
Mat20 =
Mat21 =
Mat22 = 0.0;
}

However during compilation of the above test here is what gcc tells:
../src/CadExTestLib/CadExTestLib_OCC.cxx:84: warning: M.gp_Mat::matrix[1][0] is used uninitialized in this function
../src/CadExTestLib/CadExTestLib_OCC.cxx:84: warning: M.gp_Mat::matrix[1][1] is used uninitialized in this function
../src/CadExTestLib/CadExTestLib_OCC.cxx:84: warning: M.gp_Mat::matrix[1][2] is used uninitialized in this function
../src/CadExTestLib/CadExTestLib_OCC.cxx:84: warning: M.gp_Mat::matrix[2][0] is used uninitialized in this function
../src/CadExTestLib/CadExTestLib_OCC.cxx:84: warning: M.gp_Mat::matrix[2][1] is used uninitialized in this function
../src/CadExTestLib/CadExTestLib_OCC.cxx:84: warning: M.gp_Mat::matrix[2][2] is used uninitialized in this function

Thus, gcc has inlined the constructor body into the test case and now complains that some memory left uninitialized ! Weird, isn’t it ?
It looks like it could not resolve indirect references to memory via &matrix[0][0] and then access M[3]…M[8] and just ignored them. This looks more than dangerous (as compiler’s optimization must not result in wrong memory contents), so I am not fully certain if this is really the case, so any hints would be appreciated. However due to this flaw several valid test cases failed on Linux, built with -O2 mode. So I would recommend that OCC team ensures that they have similar test cases in the regression test suite.

So, I ended up fixing this by using direct references to memory.
#define Mat00 matrix[0][0]
...
#define Mat22 matrix[2][2]

The fix is attached.

Hope this helps.
Roman