delorie.com/archives/browse.cgi | search |
X-Authentication-Warning: | delorie.com: mail set sender to djgpp-bounces using -f |
X-Recipient: | djgpp AT delorie DOT com |
Subject: | Re: DJGPP and WIndows 10 32 bit |
To: | djgpp AT delorie DOT com |
References: | <57265177 DOT 1090701 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: | <e241e8b6-b442-446d-7cc9-33c4a265ea27@iki.fi> |
Date: | Sun, 8 May 2016 16:01:49 +0300 |
User-Agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 |
Thunderbird/45.0 | |
MIME-Version: | 1.0 |
In-Reply-To: | <57265177.1090701@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 05/01/2016 09:56 PM, Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com] wrote: > 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: > I'm currently sure that problem is either bug or omission in our DJGPP port of GCC or bug in GCC itself (in some code that is seldom or not at all used for other targets). I suspect bug with garbage collection. There are however still several bootstraps to do to get 'git bisect' to conclusion. Current state is that SVN r163408 is bad, r163323 is good. Andris
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |