X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Subject: Re: different binary output with 32- and 64-bit hosted compilers To: djgpp AT delorie DOT com References: <83d1y2cf7e DOT fsf AT gnu DOT org> From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com]" Message-ID: <55E5DD7E.1040203@iki.fi> Date: Tue, 1 Sep 2015 20:16:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <83d1y2cf7e.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 09/01/2015 06:49 PM, Eli Zaretskii (eliz AT gnu DOT org) [via djgpp AT delorie DOT com] wrote: >> Date: Tue, 1 Sep 2015 18:20:56 +0300 >> From: "Ozkan Sezer (sezeroz AT gmail DOT com) [via djgpp AT delorie DOT com]" >> >> 32-bit (i686-linux fedora-9) and 64-bit (x86_64-linux fedora-20) hosted >> djgpp-targeting compiler generates different output for some sources. >> This happens with djgpp source itself too, and it isn't a nice thing >> and was not an expected thing for me. Did the following with gcc-3.4.6: >> >> Compiled djgpp-cvs with a 32- and 64-bit hosted toolchain (gcc-3.4.6 >> and binutils-2.25.1), then did: >> diff -urp --exclude=*.d --exclude=id_*.o --exclude=stub* \ >> --exclude=*.tex --exclude=*.exe --exclude=djasm.c \ >> 32/src 64/src > 64.diff >> ... which results in this: > Looks like sign extension and register allocation differences. > > GCC 3.4.6 is quite old, could well be a compiler bug. Maybe it's a > good idea to repeat this experiment with a newer version, like 4.9.x? > > Thanks. > Tried to build DJGPP v2.05 rpms both for i686 and x86_64 and compared object files i586-pc-msdosdjgpp --disassemble-all file.o | grep -v file\ format\ coff-go32 >... As result got several similar differences with gcc-4.9.3 cross-compiler (installed from my RPMs). One of affected file is stubify.c Also tried to run cc1.exe from gcc-5.2.0 cross-compiler with mostly same parameters under valgrind after I replaced cc1 installed from RPM with one from build directory (to have debug info). The result was rather large number of valgrind error messages like given below from GCC integrated register allocator (IRA). I only tested this for x86_64 So I suspect that one could potentially get different results if compiling file repeatedly. I have not however checked it. Building cross-compiler do not go through bootstrapping process and comparison of stages 2 and 3 as native build. As the result similar problems are much more likely to noticed when building native compiler. I do not remember having stage 2 and 3 comparison errors when building native compiler for DJGPP in last years Andris Konsole output ==4888== Memcheck, a memory error detector ==4888== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==4888== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==4888== Command: /usr/libexec/gcc/i586-pc-msdosdjgpp/5.2.0/cc1 -quiet -nostdinc -v -I /usr/lib64/gcc/i586-pc-msdosdjgpp/5.2.0/include -MD stubify.d -remap -D GAS_MAJOR=2 -D GAS_MINOR=24 -D GAS_MINORMINOR=0 -iquote . -isystem ./../../include stubify.c -quiet -dumpbase stubify .c -mtune=i586 -march=i386 -auxbase stubify -O2 -Wall -version ==4888== GNU C11 (GCC) version 5.2.0 (i586-pc-msdosdjgpp) compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 #include "..." search starts here: . #include <...> search starts here: /usr/lib64/gcc/i586-pc-msdosdjgpp/5.2.0/include ./../../include End of search list. GNU C11 (GCC) version 5.2.0 (i586-pc-msdosdjgpp) compiled by GNU C version 5.2.0, GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.3 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c4cb9c242d096e93f63c8f0292044b07 ==4888== Conditional jump or move depends on uninitialised value(s) ==4888== at 0x6F9902: sparseset_bit_p (sparseset.h:147) ==4888== by 0x6F9902: mark_pseudo_regno_live(int) (ira-lives.c:301) ==4888== by 0x6FA578: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1281) ==4888== by 0x6E19D6: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) ( ira-build.c:1845) ==4888== by 0x6FB1E1: ira_create_allocno_live_ranges() (ira-lives.c:1582) ==4888== by 0x6E3353: ira_build() (ira-build.c:3461) ==4888== by 0x6DB57D: ira (ira.c:5254) ==4888== by 0x6DB57D: (anonymous namespace)::pass_ira::execute(function*) (ira.c:5546) ==4888== by 0x783AD5: execute_one_pass(opt_pass*) (passes.c:2330) ==4888== by 0x783EF5: execute_pass_list_1(opt_pass*) [clone .constprop.64] (passes.c:2382) ==4888== by 0x783F07: execute_pass_list_1(opt_pass*) [clone .constprop.64] (passes.c:2383) ==4888== by 0x783F48: execute_pass_list(function*, opt_pass*) (passes.c:2393) ==4888== by 0x54063A: cgraph_node::expand() (cgraphunit.c:1895) ==4888== by 0x541923: expand_all_functions (cgraphunit.c:2031) ==4888== by 0x541923: symbol_table::compile() [clone .part.43] (cgraphunit.c:2384) ==4888== ==4888== Conditional jump or move depends on uninitialised value(s) ==4888== at 0x6F9804: sparseset_bit_p (sparseset.h:147) ==4888== by 0x6F9804: sparseset_set_bit (sparseset.h:166) ==4888== by 0x6F9804: make_object_born(ira_object*) (ira-lives.c:132) ==4888== by 0x6F991F: mark_pseudo_regno_live(int) (ira-lives.c:305) ==4888== by 0x6FA578: process_bb_node_lives(ira_loop_tree_node*) (ira-lives.c:1281) ==4888== by 0x6E19D6: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) ( ira-build.c:1845) ==4888== by 0x6FB1E1: ira_create_allocno_live_ranges() (ira-lives.c:1582) ==4888== by 0x6E3353: ira_build() (ira-build.c:3461) ==4888== by 0x6DB57D: ira (ira.c:5254) ==4888== by 0x6DB57D: (anonymous namespace)::pass_ira::execute(function*) (ira.c:5546) ==4888== by 0x783AD5: execute_one_pass(opt_pass*) (passes.c:2330) ==4888== by 0x783EF5: execute_pass_list_1(opt_pass*) [clone .constprop.64] (passes.c:2382) ==4888== by 0x783F07: execute_pass_list_1(opt_pass*) [clone .constprop.64] (passes.c:2383) ==4888== by 0x783F48: execute_pass_list(function*, opt_pass*) (passes.c:2393) ==4888== by 0x54063A: cgraph_node::expand() (cgraphunit.c:1895)