Mail Archives: djgpp/2015/10/12/14:19:42
On 10/12/2015 09:04 PM, Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp AT delorie DOT com] wrote:
> Am 11.10.2015 13:45, schrieb Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp 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
>>
>
>
> That is a very serious show-stopper for 2.05 IMHO. If we cannot trust our
> memory system we cannot release. IIRC Charles Sandman told in some mail
> some weeks or months ago that the same fast allocation/deallocation speed
> can be achieved with the old code by deactivating some DOS specific feature
> that is of limited usefullness nowadays. May be it is worth to think
> about some switch to change between boths? But I have no preferences.
>
> I have observed a lot of times that bash crashes when running very large
> configure scripts. The only way to get the package configured is to run
> the script again and again until the configuration process succeeds. I do
> not know if this has any relation to what you have described.
>
> Have you already tested on Windows 10 home 32-bit? Makes it sense that I try it?
>
> Another question is should all the information required to install DJGPP on Windows 7
> and Windows 10 be added in a detailed maner to the FAQ?
>
Rebulding gcc-5.2.0 with _CRT0_DISABLE_SBRK_ADDRESS_WRAP did not help.
I wrote simple script that only preprocessed same source file from GCC sources
many time and compared output of preprocessor and got random differences in
preprocessor output (after several hunderds iof thousends of retries)
Also there were similar problem on Windows Vista Business where I'm normally built
DJGPP packages but for DJGPP v2.03p2 only. DJGPP v2.05 seems to be much more stable
there.
Andris
- Raw text -