On Mon, Mar 12, 2018 at 5:11 PM, Milan Ton 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-
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
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
On Sat, Mar 10, 2018 at 12:58 PM, Milan Ton 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 insp
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 com
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 f
