What Is The Linux Equivalent to Msvc++'s Option /D1Reportsingleclasslayout

Is there any g++ option to dump class layout and vtables?

g++ -fdump-class-hierarchy -c source_file.cpp

memory layout of inherited class

One way is to print out the offsets of all the members:

class Parent{
public:
    int a;
    int b;

    virtual void foo(){
        cout << "parent" << endl;
    }
};

class Child : public Parent{
public:
    int c;
    int d;

    virtual void foo(){
        cout << "child" << endl;
    }
};

int main(){

    Parent p;
    Child c;

    p.foo();
    c.foo();

    cout << "Parent Offset a = " << (size_t)&p.a - (size_t)&p << endl;
    cout << "Parent Offset b = " << (size_t)&p.b - (size_t)&p << endl;

    cout << "Child Offset a = " << (size_t)&c.a - (size_t)&c << endl;
    cout << "Child Offset b = " << (size_t)&c.b - (size_t)&c << endl;
    cout << "Child Offset c = " << (size_t)&c.c - (size_t)&c << endl;
    cout << "Child Offset d = " << (size_t)&c.d - (size_t)&c << endl;

    system("pause");
}

Output:

parent
child
Parent Offset a = 8
Parent Offset b = 12
Child Offset a = 8
Child Offset b = 12
Child Offset c = 16
Child Offset d = 20

So you can see all the offsets here. You'll notice that there's nothing at offset 0, as that is presumably where the pointer to the vtable goes.

Also notice that the inherited members have the same offsets in both Child and Parent.

GCC equivalent of /GS, /GL, /Gy, /Oi, /MD in MSVC

Here we go:

/GS is roughly equivalent to -fstack-protector-strong -fstack-clash-protection -D_FORTIFY_SOURCE=2. It also requires optimization (e.g., -O2 or -O3), which is disabled by default in GCC. -fstack-clash-protection requires target support to work properly, which may still be lacking on Arm. For such targets, it's best to avoid using it.
/GL is more or less equivalent to -flto, although the required tuning is vastly different. When using link-time optimization (LTO), you should repeat all compiler flags in the linker invocation.
/Gy is comparable to -ffunction-sections -Wl,--gc-sections.
/Oi is implied by -O2 and most optimization options.
/MD is meaningless on contemporary GNU/Linux; there are no compiler optimizations which assume that the process is not multi-threaded. Multi-threaded applications need to be linked with -lpthread.

It may make sense to check your Linux distribution for additional build flags and mirror them (e.g., -Wl,-z,now for additional security hardening).

What is the equivalent switch to /MT (VC++) for g++ in linux (CentOS)?

The /MT flag in the Microsoft C++ compiler causes the linker to link against the static versions of the C and C++ run-time libraries. Microsoft ships static and dynamic versions of the run-time libraries, so this option effectively selects which set of libs to link against. This flag does not affect linking against third party libraries.

On the Linux side you have the -static option to tell the linker to use static libraries. this option is not library specific like on Windows, it affects all libraries. But if you use this option you have to provide static versions of all the libraries that you need, the linker will not convert dynamic libraries automatically. This includes system and run-time libraries, which are not always available as static libs. It also includes the Intel TBB, which you will probably need to compile yourself as a static lib if Intel doesn't provide it in that form.

Is there a (Linux) g++ equivalent to the /fp:precise and /fp:fast flags used in Visual Studio?

Excess register precision is an issue only on FPU registers, which compilers (with the right enabling switches) tend to avoid anyway. When floating point computations are carried out in SSE registers, the register precision equals the memory one.

In my experience most of the /fp:fast impact (and potential discrepancy) comes from the compiler taking the liberty to perform algebraic transforms. This can be as simple as changing summands order:

( a + b ) + c --> a + ( b + c)

can be - distributing multiplications like a*(b+c) at will, and can get to some rather complex transforms - all intended to reuse previous calculations.
In infinite precision such transforms are benign, of course - but in finite precision they actually change the result. As a toy example, try the summand-order-example with a=b=2^(-23), c = 1. MS's Eric Fleegal describes it in much more detail.

In this respect, the gcc switch nearest to /fp:precise is -fno-unsafe-math-optimizations. I think it's on by default - perhaps you can try setting it explicitly and see if it makes a difference. Similarly, you can try explicitly turning off all -ffast-math optimizations: -fno-finite-math-only, -fmath-errno, -ftrapping-math, -frounding-math and -fsignaling-nans (the last 2 options are non default!)