From: J Cook on
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
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
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