Mail Archives: djgpp/2015/10/16/14:20:35
On 10/11/2015 02:45 PM, Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com] wrote:
> 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)
>
Tried to investigate on same Win 10 Enterprise trial VM but no success up to this time:
modified gcc/libcpp/files.c to calculate and dump to stderr MD5 sums of just read files.
Did not notice any problems reading files when repeated it may times (sort | uniq) even
when I had stray preprocessor output differences and errors (like missing #endif). So
reading files do not seem to be reason of problems
Suspected use of -remap (DJGPP is perhaps only target for which it is used, had to fix a
related error rather long time ago). No influence
Some more thoughts:
1) random DPMI memory corruption (for example from interrupts) in Windows (especially WIndows 10).
One would need a program that uses much memory and runs long enough and for which result can
be easily verified. https://gmplib.org/pi-with-gmp.html could be good candidate
2) some problem on our side (for example use os uninitialized data)
In case of (1) we may be out of luck.
There was however similar problems with DJGPP v2.03p2 on Windows Vista, which I have not
any more noticed with 2.05.
Andris
- Raw text -