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: 80 2014-11-10_18-01-23
	260f8afb9361da3c7edfd3a8e3a4ca908191ad29
RazorGate-KAS:	Lua profiles 69136 [Nov 12 2014]
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 Win10 32-bit
To:	"DJGPP List (E-mail)" <djgpp AT delorie DOT com>
Message-ID:	<56BF484D.4080200@iki.fi>
Date:	Sat, 13 Feb 2016 17:14:21 +0200
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.5.0
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com

Installed Win10 Home 32 (201511) bit in VirtualBox VM to try some testing.

The GCC stability problems are the same as in earlier tests on Win10 Enterprise trial (random data 
corruption in pre-processor, as far as I noticed single byte gets corrupted which often leads to 
following compiler error, retrying usually succeeds without failure). There is in average 1 compile 
failure per several hunderds of compiles.

Summary of earlier tests:
- gcc-3.4.6 and gcc-4.4.7 are OK (earlier installed gcc-3.4.6 rebuilt it on W10, bootstrapped 
gcc-4.4.7 with 3.4.6 and all worked without problems)
- trying to bootstrap 4.6.4 with gcc-4.4.7 run into similar trouble in bootstrap stage 3 (there 
were no problems in stage 1 and 2)
- all later versions 4.7.4 and newer have the same problem
- failed to reproduce similar problems with different programs

Some thoughts:
- increase of size of executable (cc1.exe about 8.5MB for 4.4.7 and 21MB for 5.3.0)
- I got corruption in pre-procesed output. So that should be easy in comparison with compiling 
itself as compiling require noticeably more resources. That points that the actual problem could 
also be on our side
- It came into mind that the problems began in the same versions in which we had to handle 
relocation counter overflow in 2011. I used then some tricks of changing compiler options to avoid 
overflow then with gcc-4.6 (support in binutils were implemented after that). I guess I could try 
to build gcc-4.6.4 both with changed compiler options and without changes and see whether there is 
any change and perhaps also test with old binutils version (2.21).

New unrelated problem:
- this time I created 2 partitions in VM
- all works as earlier on C:
- there are LFN related problems with drive D: - if directory names are SFN only, all is OK, 
otherwise attempt to open file in such directory fails with EACCES ('cat d:/foo/example.txt' is OK, 
'cat d:/foo.example/bar/example.txt' fails with EACCES, assuming that files exist). I did not have 
drive D: in earlier tests so I do not know whether the problem is Win10 Home specific.

Andris

- Raw text -