Solaris 8 and 10 producing different assembly with gcc 3.4.4

[J Cook]

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][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

 

[Victor Bazarov]

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.

[..code snipped..]
>
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.

[removed cross-posting - I don't read the other group, nor do I know
their rules]

If the outputs are valid and functional and produce identical results
(as seen by the rest of the program), why does it matter?

V

 

[J Cook]

If the outputs are valid and functional and produce identical results
(as seen by the rest of the program), why does it matter?

If I test the executables generated on one system, and they are binary
equal to an executable generated on another system, I don't need to re-
test that executable. Doing an assembly code analysis of the entire
code base everytime there is a change so I can hand-wave that it
*should* do the same thing is probably a bad idea in my particular
case.

Thanks,
JC

 

[Jonathan Lee]

If I test the executables generated on one system, and they are binary
equal to an executable generated on another system, I don't need to re-
test that executable.

If you expect them to be equal, why would you even bother
compiling the code the second time? Why wouldn't you just
make a copy of the first executable?

And if you don't expect them to be equal... then your
question doesn't make a whole lot of sense:
"Two executables are not equal and I didn't expect
them to be. What happened?"

--Jonathan

 

[Victor Bazarov]

If I test the executables generated on one system, and they are binary
equal to an executable generated on another system, I don't need to re-
test that executable.

I suggest you talk to a knowledgeable QA person about that. See what
they say. And the emphasis on "knowledgeable".

> [..]

V

 

[J Cook]

If you expect them to be equal, why would you even bother
compiling the code the second time? Why wouldn't you just
make a copy of the first executable?

And if you don't expect them to be equal... then your
question doesn't make a whole lot of sense:
"Two executables are not equal and I didn't expect
them to be. What happened?"

I expect them to be equal. If one person is on, say Mars, and another
here on Earth, and I tell someone what code changes to make, and we
make them in parallel; I need to know that both programmers made the
same change by comparing a hash, or whatever. There is no way to
share the executables.

Thanks,
Joe C.

 

[J Cook]

I suggest you talk to a knowledgeable QA person about that.  See what
they say.  And the emphasis on "knowledgeable".

Are you suggesting that if I test executable "A", and that I have
executable "B" which is identical (bit by bit) to "A", that there is
something to be gained by testing "B" as well?

I don't think any QA person would agree with that approach, because it
would imply a full regression test was needed everytime the file
changed directories, machines, etc.

JC

 

[Jonathan Lee]

I expect them to be equal.

From the perspective of the C++ language, then, you're going
to be disappointed. The language makes no such guarantees.
I would bring it up with a GCC mailing list. That's the only
thing I've got in the way of a solution.

--Jonathan

 

[Francesco S. Carta]

Are you suggesting that if I test executable "A", and that I have
executable "B" which is identical (bit by bit) to "A", that there is
something to be gained by testing "B" as well?

I don't think any QA person would agree with that approach, because it
would imply a full regression test was needed everytime the file
changed directories, machines, etc.

I think the point is that, eventually, you could expect two executables
to be bit-by-bit identical only if they are created by the same toolset
running on the same type of machine, using the same options.

If you happen to get the same exact executable changing toolset or type
of machine, then that's a lucky coincidence.

At least, that's my understanding of this issue, just my two cents.

 

[Francesco S. Carta]

I think the point is that, eventually, you could expect two executables
to be bit-by-bit identical only if they are created by the same toolset
running on the same type of machine, using the same options.

If you happen to get the same exact executable changing toolset or type
of machine, then that's a lucky coincidence.

At least, that's my understanding of this issue, just my two cents.

On a side note: reading again the original post I see that you're only
changing version of the OS - that would fall into the things that could
change your final executable... unless... let me ask: what does it mean
"guarantees binary compatibility"?

Does it mean that the produced binaries will be identical regardless of
the version of OS used?

 

[Francesco S. Carta]

[..] let me ask: what does it mean
"guarantees binary compatibility"?

Does it mean that the produced binaries will be identical regardless of
the version of OS used?

"Compatibility" rarely means equality or identity. IME binary
compatibility means that a binary built on one machine will work on the
other and vice versa, when copied.

And this should finally answer the OP.

Unless they really mean to guarantee identical binaries...
....in such case, they would have a bug crawling somewhere

 

[Ian Collins]

[..] let me ask: what does it mean
"guarantees binary compatibility"?

Does it mean that the produced binaries will be identical regardless of
the version of OS used?

"Compatibility" rarely means equality or identity. IME binary
compatibility means that a binary built on one machine will work on the
other and vice versa, when copied.

And this should finally answer the OP.

Unless they really mean to guarantee identical binaries...
....in such case, they would have a bug crawling somewhere

In the case of Solaris, "binary compatibility" means an application that
uses public APIs built on version N will run on version N+M.

 

[Francesco S. Carta]

On 7/14/2010 3:13 PM, Francesco S. Carta wrote:
[..] let me ask: what does it mean
"guarantees binary compatibility"?

Does it mean that the produced binaries will be identical regardless of
the version of OS used?

"Compatibility" rarely means equality or identity. IME binary
compatibility means that a binary built on one machine will work on the
other and vice versa, when copied.

And this should finally answer the OP.

Unless they really mean to guarantee identical binaries...
....in such case, they would have a bug crawling somewhere

In the case of Solaris, "binary compatibility" means an application that
uses public APIs built on version N will run on version N+M.

Then no bug but just normal behavior (identical binaries not guaranteed
but eventually possible).

 

[Vladimir Jovic]

From the perspective of the C++ language, then, you're going
to be disappointed. The language makes no such guarantees.
I would bring it up with a GCC mailing list. That's the only
thing I've got in the way of a solution.

Although I doubt they will do anything, since gcc 3.4.4 is already old

 

[Rainer Orth]

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

 

[James Kanze]

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.)