From: J Cook on 14 Jul 2010 12:28 Typically, when compiling c++ programs using the same gcc 3.4.4 (identically the same compiler in a shared directory), the resulting binaries match identically between solaris 5.8 (sparc SUNW) and solaris 5.10 (sparc SUNW). However, there is exactly one section of code (out of hundreds of thousands) that produces different assembly output from identical input. I don't know if this is a bug in Solaris (which guarantees binary compatibility), or something with the compiler gcc for powerpc that incorrectly induces some random element for just this one case. Short Program: class Foo { public: void goo(int a,int b,int c); struct Bar { float m_a; float m_b; float m_c; }; Bar m_bar[50][50][50]; }; Foo::goo(int a,int b, int c) { m_bar[a][b][c].m_b = 0; } Playing around, it really seems to have something to do multidimensional arrays where dim>2. Both assembly outputs are valid (one computes the offset of index "a" first, and the other computes the offset of index "b" first.), but they differ. Any suggestions would be welcome, JC
From: Rainer Orth on 15 Jul 2010 04:32 J Cook <joecook(a)gmail.com> writes: > Typically, when compiling c++ programs using the same gcc 3.4.4 > (identically the same compiler in a shared directory), the resulting > binaries match identically between solaris 5.8 (sparc SUNW) and > solaris 5.10 (sparc SUNW). > > However, there is exactly one section of code (out of hundreds of > thousands) that produces different assembly output from identical > input. > > I don't know if this is a bug in Solaris (which guarantees binary Why would `Solaris' be responsible for a compiler's output, be it g++ or Studio CC? > compatibility), or something with the compiler gcc for powerpc that How is binary compatibility affected if the output is correct, as you state below? The only guarantee Solaris gives here is that the library ABIs stay the same, depending on the stability levels of the respective libraries. > incorrectly induces some random element for just this one case. Are you talking about a native compiler here or about a cross-compiler to some PowerPC target? A native compiler's output may naturally differ between different OS versions if the native assembler (or different versions of GNU as) are used: the GCC configure process probes the assembler features and adjusts its output to its findings. > Both assembly outputs are valid (one computes the offset of index "a" > first, and the other computes the offset of index "b" first.), but > they differ. So why worry? > Any suggestions would be welcome, Another factor that could come into play are compiler heuristics that are influenced by the runtime environment (available memory and some such). Look e.g. at a line like this in the gcc -v output: GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Than run gcc with the same values for those parameters explicitly and see if it changes anything. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University
From: James Kanze on 15 Jul 2010 10:02 On Jul 15, 9:32 am, Rainer Orth <r...(a)CeBiTec.Uni-Bielefeld.DE> wrote: > J Cook <joec...(a)gmail.com> writes: > > Typically, when compiling c++ programs using the same gcc > > 3.4.4 (identically the same compiler in a shared directory), > > the resulting binaries match identically between solaris 5.8 > > (sparc SUNW) and solaris 5.10 (sparc SUNW). > > However, there is exactly one section of code (out of > > hundreds of thousands) that produces different assembly > > output from identical input. > > I don't know if this is a bug in Solaris (which guarantees binary > Why would `Solaris' be responsible for a compiler's output, be > it g++ or Studio CC? Different header files. Also, the compiler could check the version of the system, and change its code generation strategy accordingly. (Most compilers have different options with regards to the architecture they target when optimizing, and will use the architecture the compiler is running on as the default. It wouldn't surprise me that the same thing holds for the OS.) -- James Kanze
|
Pages: 1 Prev: How can I determine if a static library is 32-bit or 64-bit? Next: reconfiguring stripes |