X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient:	djgpp AT delorie DOT com
Subject:	Re: Random compile errors under WIndows (32 bit Windows Vista and
	Windows 10)
To:	djgpp AT delorie DOT com
References:	<5611566C DOT 4020507 AT iki DOT fi>
From:	"Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Message-ID:	<561A4BCE.7050606@iki.fi>
Date:	Sun, 11 Oct 2015 14:45:18 +0300
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.3.0
MIME-Version:	1.0
In-Reply-To:	<5611566C.4020507@iki.fi>
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

On 10/04/2015 07:40 PM, Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com] wrote:
> I have earlier noticed random stray compile errors when building
> DJGPP port of gcc under Windows Vista Business. Running make again
> compiled some file without problems. Such errors where
> extremely rare for DJGPP CVS from CVS (also 2.04 before bumping version
> to 2.05). I usually did not get them at all for 2.04 or 2.05. The situation
> was noticeably worse for 2.03p2. Building GCC was still possible but I had to
> restart build often enough.
>
> I have 64-bit Windows 10 (earlier Windows 7) on desktop computer and dual boot
> with Linux (currently Fedora 22 x86_64). So there no DJGPP testing possible in this
> Windows installation for understandable reasons.
>
> Today downloaded 32 bit Windows 10 Enterprise 90 days trial from Microsoft and
> installed it in VirtualBox VM under Linux. I needed slightly more steps to get DJGPP
> working rather than on Windows Vista (for VIsta only registry hack was needed to
> workaround 32MB DMPI memory limit)
>
> Trying to build gcc-5.2.0 on this Windows 10 installation (DJGPP v2.05 only) showed
> that I'm getting stray compiler errors much more often (once per several minutes)
>
> These errors look like:
> gpp -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC -fno-exceptions -fno-rtti 
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
> -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros 
> -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -Ic-family -I/gcc-5.20/gcc 
> -I/gcc-5.20/gcc/c-family -I/gcc-5.20/gcc/../include -I/gcc-5.20/gcc/../libcpp/include  
> -I/gcc-5.20/gcc/../libdecnumber -I/gcc-5.20/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I/gcc-5.20/gcc/../libbacktrace  -I/dev/env/DJDIR/include -o c-family/c-gimplify.o -MT 
> c-family/c-gimplify.o -MMD -MP -MF c-family/.deps/c-gimplify.TPo /gcc-5.20/gcc/c-family/c-gimplify.c
> In file included from /gcc-5.20/gcc/flags.h:24:0,
>                  from /gcc-5.20/gcc/c-family/c-common.h:36,
>                  from /gcc-5.20/gcc/c-family/c-gimplify.c:41:
> ./options.h:10:0: error: unterminated #if
>  #if !defined(IN_LIBGCC2) && !defined(IN_TARGET_LIBS) && !defined(IN_RTS)
>  ^
> ./options.h:3:0: error: unterminated #ifndef
>  #ifndef OPTIONS_H
>  ^
> Makefile:1066: recipe for target 'c-family/c-gimplify.o' failed
> make.exe[3]: *** [c-family/c-gimplify.o] Error 1
> make.exe[3]: Leaving directory 'c:/build.gcc/gcc'
> Makefile:4376: recipe for target 'all-stage1-gcc' failed
> make.exe[2]: *** [all-stage1-gcc] Error 2
> make.exe[2]: Leaving directory 'c:/build.gcc'
> Makefile:17534: recipe for target 'stage1-bubble' failed
> make.exe[1]: *** [stage1-bubble] Error 2
> make.exe[1]: Leaving directory 'c:/build.gcc'
> Makefile:17838: recipe for target 'bootstrap' failed
> make.exe: *** [bootstrap] Error 2
>
> Same error do not repeat when I try to run 'sh ./djmake.sh bootstrap' again.
>
> Most likely explanation is that reading file (opened in binary mode) is unreliable
> and one randomly gets corrupted data. Total data size is correct as libcpp compares
> data size with one from response of stat() and reports an error in case of size discrepancy
> (we needed to handle DOS end of file mark ^Z specially for that reason)
>
> It could be a bug in NTVDM. It could also be some problem on our side.
> More testing is needed. Such test could repeatedly read some set of files into memory
> and calculate MD5 sum or something similar to detect random corruptions. It would
> be possible to investigate further and see what is getting corrupted
>
>
> How to get DJGPP programs running on Windows 10 32 bit (please comment
> if one has possibility to check on different edition)

On of suspect is change to nmalloc. I have used it for a long time for GCC and there has been
some instability related to it on Windows (different versions).

My ancient test program written to test perfomance of memory allocation/freeing

http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp-workers/2007/12/05/17:54:46

also randomly crashed on Windows when linked with nmalloc. I did not found them why it happens.
Also WIndows 10 is not an exception as I have found in my test VM (Windows 10 Enterprise trial)

Changed only one thing (added int _crt0_startup_flags = _CRT0_DISABLE_SBRK_ADDRESS_WRAP;

And it seems to help in case of Windows 10 as the test program has run for several hours more
than 2000 times without any crash (command line parameter value 20000000). Rebuild of
gcc-5.2.0 with this flag set is ongoing on another system, so I'll be able to see whether it fixes 
the problem.

Also: trying to set _CRT0_FLAG_UNIX_SBRK caused test program to crash immediately on Windows 10.
I have not tried to investigate it further yet.

Andris

- Raw text -