Mail Archives: djgpp/2015/09/01/13:17:01
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]" <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)
- Raw text -