X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
RazorGate-KAS: Status: not_detected
RazorGate-KAS: Rate: 0
RazorGate-KAS: Envelope from: 
RazorGate-KAS: Version: 5.5.3
RazorGate-KAS: LuaCore: 215 2015-05-29_17-31-22
 60ae4a1b4d01d14f868b20a55aced8d7df7b2e28
RazorGate-KAS: Lua profiles 78662 [Jun 02 2015]
RazorGate-KAS: Method: none
From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
Subject: DJGPP and WIndows 10 32 bit
To: "DJGPP List (E-mail)" <djgpp AT delorie DOT com>
Message-ID: <57265177.1090701@iki.fi>
Date: Sun, 1 May 2016 21:56:55 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

I found earlier that recent gcc DJGPP port versions get random preprocessor failures
when run under Windows 10 (32 bit). The same does not seem to happen under
Windows Vista Business SP2 (I remember having something similar when building
for DJGPP v2.03 also under Vista, but it was rather long time ago).

It is easy to blame Windows 10, but I'm almost sure that the problem is on our
side. DJGPP v2.05 were used for all recent tests.

gcc-3.4.6 and gcc-4.4.7 built with DJGPP is OK. One can bootstrap these version
without any problems under Windows 10

later versions installed from binaries are not OK. Try compiling "Hello World" style program
which uses <iostream> repeatedly under WIn10 to get random failures. I'm getting them
in average once per hundred or several hundreds of compiles. In other test I only repeatedly
run preprocessor and compared it outputs.

So for further test gcc-4.4.7 were used as start version:

Trying to bootstrap GCC:

Tried earlier gcc-4.6.3 is I remember correctly and got failures in stage 3

Today tried gcc-7.0.0 20160427 (build it at first under Windows Vista without any problems).
The results were very similar as what I remember from 4.6.3:
- gcc-4.4.7 builds stage 1 without any problems
- stage 1 compiler built with gcc-4.4.7 also works OK: no random failures detected
- stage 2 compiler is getting random failures while per-processing sources (building stage2
libgcc, libstdc++ or in stage 3 depending on luck)

That all points to one of following:
- something with initialization in our startup code could be no more OK for recent GCC
versions
- something with binutils linker script (for example gcc.o has section .text.startup which is 
handled separately in Linux
(I could try modify linker script, rebuild binutils and retry bootstrapping gcc).
- something with new libgcc or libstdc++ (stage 1 compiler used one from gcc-4.4.7)

I tried earlier to reproduce problems with stand-alone test programs with success. Now it seems
that trying to reproduce them outside GCC is unlikely to succeed.

One can of course ask why that happens under Win 10 not Vista. Maybe there are some slight
differences that causes different behavior when there is some problem with undefined behavior.

Andris