cross compiled output differs

cross compiled output differs

[Milan Ton]

Hi:

I built two versions -- linux/mingw -- of a 32-bit gcc cross compiler
of codebase 7.3.0 on fedora 20 (gcc 4.8). Then I compiled an embedded
project using the both cross compilers in the same build
environment. An assemble code inspection showed that one function out
of about thousand project functions differs in the two builds. Both
run-time tests and visual inspection suggest that both variants of the
compiled function are correct. I looked at the output of the switch
`-fdump-tree-all' and realized that the path `ivopts' makes this difference.
Once `-fno-ivopts' applied, the two compilations are binary equivalent.

Shouldn't I expect in general same output of such cross compilers ?
What could be reasons of such differences ? and options to fix it ?

Milan

Re: cross compiled output differs

[Nathan Sidwell]

On 03/10/2018 06:58 AM, Milan Ton wrote:

> run-time tests and visual inspection suggest that both variants of the
> compiled function are correct. I looked at the output of the switch
> `-fdump-tree-all' and realized that the path `ivopts' makes this difference.
> Once `-fno-ivopts' applied, the two compilations are binary equivalent.
> 
> Shouldn't I expect in general same output of such cross compilers ?
> What could be reasons of such differences ? and options to fix it ?

Yes, that's a reasonable expectation.  The usually discovered cause of 
such differences is the host system's qsort function coupled with a 
comparison function that can return 0.  When that happens things can be 
differently ordered, essentially at the whim of the host.  And that can 
affet code generation.  It sounds like you've tied that down to ivops -- 
great!

If you could find a selfcontained testcase, that'd make a great bug 
report.  (Sadly, 'ivopts can cause code differences' is probably too vague.)


nathan

-- 
Nathan Sidwell

Re: cross compiled output differs

[Richard Biener]

On Sat, Mar 10, 2018 at 12:58 PM, Milan Ton <milan.ton@yandex.ru> wrote:
> Hi:
>
> I built two versions -- linux/mingw -- of a 32-bit gcc cross compiler
> of codebase 7.3.0 on fedora 20 (gcc 4.8). Then I compiled an embedded
> project using the both cross compilers in the same build
> environment. An assemble code inspection showed that one function out
> of about thousand project functions differs in the two builds. Both
> run-time tests and visual inspection suggest that both variants of the
> compiled function are correct. I looked at the output of the switch
> `-fdump-tree-all' and realized that the path `ivopts' makes this difference.
> Once `-fno-ivopts' applied, the two compilations are binary equivalent.
>
> Shouldn't I expect in general same output of such cross compilers ?
> What could be reasons of such differences ? and options to fix it ?

Not sure if I understand but if one cross compiler targets linux-32bit and one
targets mingw-32bit then of course there are differences to be expected.

If I didn't understand please correct the two cross compiler host/target combos
below

 x86_64-fedora -> i586-linux
 x86_64-fedora -> i586-mingw32

> Milan

Re: cross compiled output differs

[Nathan Sidwell]

On 03/12/2018 09:24 AM, Richard Biener wrote:

> 
>   x86_64-fedora -> i586-linux
>   x86_64-fedora -> i586-mingw32

Ah, I'd interpreted it as

host:linux -> some (embedded) system
host:mingw32 -> same (embedded) system

I answered that question.

nathan

-- 
Nathan Sidwell

Re: cross compiled output differs

[Milan Ton]

Nathan, Richard:

sorry if it wasn't clear: my target was a 32-bit embedded system for that
I built two cross compilers to be run on two hosts -- linux32 and mingw32 --,
my build system was Fedora x86_64 (with gcc -m32 and i686-w64-mingw32-gcc
respectively). So Nathan's scheme was what I would have depicted:
> host:linux -> some (embedded) system
> host:mingw32 -> same (embedded) system

>> Shouldn't I expect in general same output of such cross compilers ?
>> What could be reasons of such differences ? and options to fix it ?

> Yes, that's a reasonable expectation. The usually discovered cause of
> such differences is the host system's qsort function coupled with a
> comparison function that can return 0. When that happens things can be
> differently ordered, essentially at the whim of the host. And that can
> affet code generation.

This is really useful. Thanks a lot !

> If you could find a selfcontained testcase, that'd make a great bug
> report.

I'll try to think of a reproducible test-case.

Milan

Re: cross compiled output differs

[Richard Biener]

On Mon, Mar 12, 2018 at 5:11 PM, Milan Ton <milan.ton@yandex.ru> wrote:
>
> Nathan, Richard:
>
> sorry if it wasn't clear: my target was a 32-bit embedded system for that I
> built two cross compilers to be run on two hosts -- linux32 and mingw32, my
> build system was Fedora x86_64 (with gcc -m32 and i686-w64-mingw32-gcc
> respectively). So Nathan's scheme was what I would have depicted:
>> host:linux -> some (embedded) system
>> host:mingw32 -> same (embedded) system

Ok, with the additional fact that you are building canandian crosses
with build == linux-x86_64 in one case, I can't really say how to
categorize the build != host 2nd case of using i686-w64-mingw32-gcc
on x86_64-linux ;)

A first step of the investigation would be to compare the configure results
of both compiles (well, the tests relevant for target support).

Richard.

>> Yes, that's a reasonable expectation. The usually discovered cause of
>> such differences is the host system's qsort function coupled with a
>> comparison function that can return 0. When that happens things can be
>> differently ordered, essentially at the whim of the host. And that can
>> affet code generation.
>
> Thanks a lot for giving your explanation/ideas !
>
>> If you could find a selfcontained testcase, that'd make a great bug
>> report.
>
> I'll try to think of a reproducible test-case.
>
> Milan