From: Maarten B. <sou...@ds...> - 2004-05-18 14:20:05
|
Developers, please help, I have constructed a fix for bug 954082 and similar bugs, but I don't want to send it to the patch area yet because I had to make several changes. I would prefer to test it first with the regression tests and here's my problem. I'm using MSVC as compiler and WinXP as operating system and am unsure how to run the tests on my machine? Can anyone shed some light on this? Greets, Maarten |
From: Erik P. <epe...@iv...> - 2004-05-18 19:30:59
|
On Tue, 18 May 2004, Maarten Brock wrote: > Developers, please help, > > I have constructed a fix for bug 954082 and similar bugs, but I don't > want to send it to the patch area yet because I had to make several > changes. I would prefer to test it first with the regression tests and > here's my problem. I'm using MSVC as compiler and WinXP as > operating system and am unsure how to run the tests on my machine? > Can anyone shed some light on this? As far as I know, the only way to run the regression tests under Windows is via the Cygwin development environment. The simulators definately need to be built and run under Cygwin (and without using Mingw32); they use some feature of sockets that Windows does not natively support. You may be able to use an MSVC compiled SDCC for the regression tests, but it would probably be less error prone to recompile it as well under Cygwin. Look in the manual at "2.4.5 Building SDCC using Cygwin and Mingw32", and then "2.4.1 Building SDCC on Linux", but ignore the Mingw32 information. Erik |
From: Maarten B. <sou...@ds...> - 2004-05-21 18:36:19
|
<?xml version="1.0" ?><html> <head> <title></title> </head> <body> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> As far as I know, the only way to run the regression tests under</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> Windows is via the Cygwin development environment. The simulators</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> definately need to be built and run under Cygwin (and without using</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> Mingw32); they use some feature of sockets that Windows does not</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> natively support. You may be able to use an MSVC compiled SDCC for the</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> regression tests, but it would probably be less error prone to</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> recompile it as well under Cygwin.</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> </span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> Look in the manual at "2.4.5 Building SDCC using Cygwin and Mingw32",</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> and then "2.4.1 Building SDCC on Linux", but ignore the Mingw32</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> information.</span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">> </span></font></div> <div align="left"><font face="Arial" color="#7f0000"><span style="font-size:10pt">>   Erik</span></font></div> <div align="left"><br/></div> <div align="left"><font face="Arial"><span style="font-size:10pt">Thanks Erik,</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">I considered this to be more cumbersome then telnetting to a linux box I have access to and compile and run sdcc there. That works ok.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Now I need to run the regression tests. This is what I've done.</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">I configured and compiled sdcc</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">I compiled sdcc-extra</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">I tried to get gbdk-lib from cvs but that timed out. So instead I downloaded the gbdk-lib 2.95 released file. When I run make it generates 2 errors and 4 warnings.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">So I just ran make -s in sdcc/support/regression</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">The result is 320 fails for ucz80.</span></font></div> <div align="left"><br/> </div> <div align="left"><font face="Arial"><span style="font-size:10pt">Can you give me some more hints?</span></font></div> <div align="left"><font face="Arial"><span style="font-size:10pt">Maarten</span></font></div> </body> </html> |
From: Erik P. <epe...@iv...> - 2004-05-22 03:35:41
|
On Fri, 21 May 2004, Maarten Brock wrote: > > As far as I know, the only way to run the regression tests under > > Windows is via the Cygwin development environment. The simulators > > definately need to be built and run under Cygwin (and without using > > Mingw32); they use some feature of sockets that Windows does not > > natively support. You may be able to use an MSVC compiled SDCC for the > > regression tests, but it would probably be less error prone to > > recompile it as well under Cygwin. > > Thanks Erik, > I considered this to be more cumbersome then telnetting to a linux box I > have access to and compile and run sdcc there. That works ok. > Now I need to run the regression tests. This is what I've done. > I configured and compiled sdcc > I compiled sdcc-extra > I tried to get gbdk-lib from cvs but that timed out. So instead I > downloaded the gbdk-lib 2.95 released file. When I run make it generates > 2 errors and 4 warnings. > So I just ran make -s in sdcc/support/regression > The result is 320 fails for ucz80. > Can you give me some more hints? I don't recall needing gbdk-lib. There are two z80 simulators that the regression tests can use: make test-z80 uses sdcc-extra/emu/rrz80/rrz80 make test-ucz80 uses sdcc/sim/ucsim/z80.src/sz80 The ucz80 tests will fail by default since sdcc's makefiles don't build sz80 automatically. I really don't see the point in running the regression tests on two simulators, since they both seem to work, so I usually edit the regression test Makefile. Find the line that begins ALL_PORTS and change it to something like: ALL_PORTS = $(filter-out CVS xa51 ucz80 gbz80 hc08,$(notdir $(wildcard $(PORTS_DIR)/*))) This will cause it to skip the xa51, ucz80, gbz80, and hc08 tests and only run mcs51, mcs51-large, mcs51-stack-auto, ds390, and z80. For some reason (and I am definately not a make guru), it doesn't build reentrant libraries for the mcs51-stack-auto tests if it has run some other tests, so it will probably give an error. Just ignore it and run make again (or make test-mcs51-stack-auto by itself) and it should work that time. Erik |
From: Maarten B. <sou...@ds...> - 2004-05-22 15:52:14
|
> I don't recall needing gbdk-lib. > > There are two z80 simulators that the regression tests can use: > > make test-z80 uses sdcc-extra/emu/rrz80/rrz80 > make test-ucz80 uses sdcc/sim/ucsim/z80.src/sz80 > > The ucz80 tests will fail by default since sdcc's makefiles don't > build sz80 automatically. I really don't see the point in running the > regression tests on two simulators, since they both seem to work, so I > usually edit the regression test Makefile. Find the line that begins > ALL_PORTS and change it to something like: > > ALL_PORTS = $(filter-out CVS xa51 ucz80 gbz80 hc08,$(notdir $(wildcard > $(PORTS_DIR)/*))) > > This will cause it to skip the xa51, ucz80, gbz80, and hc08 tests and > only run mcs51, mcs51-large, mcs51-stack-auto, ds390, and z80. For > some reason (and I am definately not a make guru), it doesn't build > reentrant libraries for the mcs51-stack-auto tests if it has run some > other tests, so it will probably give an error. Just ignore it and run > make again (or make test-mcs51-stack-auto by itself) and it should > work that time. > > Erik Thanks again Erik, and I have some more questions. But first some answers. I skipped using gbdk-lib and ucz80 (and hc08 as well). I also found the error on stack-auto and running make again did not solve it. Running make test-mcs51-stack-auto by itself did however. I've updated the zeropad.c test case and it runs ok for ds390, mcs51, mcs51-large and mcs51-stack-auto. But it fails for "host" and z80. What is "host"? Is this my gcc c compiler? Btw: thanks for closing the fixed bug. Greets, Maarten |
From: Erik P. <epe...@iv...> - 2004-05-22 18:51:32
|
On Sat, 22 May 2004, Maarten Brock wrote: > Thanks again Erik, and I have some more questions. > > But first some answers. I skipped using gbdk-lib and ucz80 (and hc08 > as well). I also found the error on stack-auto and running make again > did not solve it. Running make test-mcs51-stack-auto by itself did > however. > > I've updated the zeropad.c test case and it runs ok for ds390, mcs51, > mcs51-large and mcs51-stack-auto. But it fails for "host" and z80. > What is "host"? Is this my gcc c compiler? "host" is gcc, if it is installed, otherwise it is whatever compiler is installed as "cc". Although certainly not foolproof, running the tests on a another compiler in addition to sdcc give some confidence that the assertions made by the tests are actually true. If testing something that is implementation dependent according to the C standard, the test should be enclosed in an appropriate #ifdef/#endif pair (or made compatible some suitable macro substitution, such as replacing data/xdata/idata keywords with whitespace). So if test-host fails, first double check the failing assertion with the C standard. If it is implementation specific, try to take this into account with the preprocessor directives. Otherwise, you may have found a bug in the host compiler. The z80 failure is probably bug #741044, reacting to a change you have made to the initialized struct(s). I haven't looked at the bug since last year; I will take another look and perhaps understand what is going on better now. But don't worry about zeropad.c failing with z80 since it is already a filed bug report. Erik |
From: Maarten B. <sou...@ds...> - 2004-05-29 12:29:52
Attachments:
zeropad.c
|
> Hi again, > > As you may have guessed I'm no gcc guru. The linux machine I have > access to has gcc 2.96 installed and generates these warnings which I > can understand. Maybe later versions of gcc react differently (see C99 > spec 6.7.2.1 17) but I need others to verify that. So please help with > that. Please help... Anyone??? Attached is a new version of zeropad.c. Can anyone please try this one on a newer GCC version? > In the meantime I will try and see if I can find anything in the z80 > port. And so it was bug #741044 which I also was able to fix. But before updating anything I need confirmation on the failing host test. |
From: Frieder F. <fri...@we...> - 2004-05-29 12:46:12
|
Maarten Brock wrote: >>Hi again, >> >>As you may have guessed I'm no gcc guru. The linux machine I have >>access to has gcc 2.96 installed and generates these warnings which I >>can understand. Maybe later versions of gcc react differently (see C99 >>spec 6.7.2.1 17) but I need others to verify that. So please help with >>that. > > > Please help... Anyone??? > > Attached is a new version of zeropad.c. Can anyone please try this one > on a newer GCC version? > > >>In the meantime I will try and see if I can find anything in the z80 >>port. > > > And so it was bug #741044 which I also was able to fix. But before > updating anything I need confirmation on the failing host test. > Hi Maarten, sorry to say, with gcc 3.3.3 (SuSE9.1) the new zeropad.c fails with: echo Processing tests/zeropad.c Processing tests/zeropad.c rm -rf `dirname gen/host/zeropad/iterations.stamp` mkdir -p `dirname gen/host/zeropad/iterations.stamp` python generate-cases.py tests/zeropad.c `dirname gen/host/zeropad/iterations.stamp` > /dev/null touch gen/host/zeropad/iterations.stamp make iterations PORT=host CASES=`dirname gen/host/zeropad/iterations.stamp` make[2]: Entering directory `/home/fe/sdcc/support/regression' gcc -DPORT_HOST=1 -Wall -fsigned-char -fpack-struct -DREENTRANT= -Ifwk/include -Itests -c gen/host/zeropad/zeropad_storage_code.c -o gen/host/zeropad/zeropad_storage_code.o gen/host/zeropad/zeropad_storage_code.c:58: error: initialization of flexible array member in a nested context gen/host/zeropad/zeropad_storage_code.c:58: error: (near initialization for `nestedstruct.s.b') make[2]: *** [gen/host/zeropad/zeropad_storage_code.o] Fehler 1 make[2]: Leaving directory `/home/fe/sdcc/support/regression' make[1]: *** [results/host/zeropad.out] Fehler 2 rm gen/host/const/iterations.stamp gen/host/zeropad/iterations.stamp gen/host/shifts/iterations.stamp gen/host/bug-469671/iterations.stamp gen/host/bp/iterations.stamp gen/host/onebyte/iterations.stamp gen/host/bug-221100/iterations.stamp gen/host/bug-908454/iterations.stamp gen/host/bug-221220/iterations.stamp gen/host/atomic/iterations.stamp gen/host/bug-905492/iterations.stamp gen/host/bug-221168/iterations.stamp make[1]: Leaving directory `/home/fe/sdcc/support/regression' make: *** [test-host] Fehler 2 Greetings, Frieder |
From: Maarten B. <sou...@ds...> - 2004-05-29 19:11:36
|
> > Attached is a new version of zeropad.c. Can anyone please try this > > one on a newer GCC version? > > Hi Maarten, > > sorry to say, with gcc 3.3.3 (SuSE9.1) the new zeropad.c fails with: > > echo Processing tests/zeropad.c > Processing tests/zeropad.c > rm -rf `dirname gen/host/zeropad/iterations.stamp` > mkdir -p `dirname gen/host/zeropad/iterations.stamp` > python generate-cases.py tests/zeropad.c `dirname > gen/host/zeropad/iterations.stamp` > /dev/null touch > gen/host/zeropad/iterations.stamp make iterations PORT=host > CASES=`dirname gen/host/zeropad/iterations.stamp` make[2]: Entering > directory `/home/fe/sdcc/support/regression' gcc -DPORT_HOST=1 -Wall > -fsigned-char -fpack-struct -DREENTRANT= -Ifwk/include -Itests -c > gen/host/zeropad/zeropad_storage_code.c -o > gen/host/zeropad/zeropad_storage_code.o > gen/host/zeropad/zeropad_storage_code.c:58: error: initialization of > flexible array member in a nested context > gen/host/zeropad/zeropad_storage_code.c:58: error: (near > initialization for `nestedstruct.s.b') make[2]: *** > [gen/host/zeropad/zeropad_storage_code.o] Fehler 1 make[2]: Leaving > directory `/home/fe/sdcc/support/regression' make[1]: *** > [results/host/zeropad.out] Fehler 2 rm gen/host/const/iterations.stamp > gen/host/zeropad/iterations.stamp gen/host/shifts/iterations.stamp > gen/host/bug-469671/iterations.stamp gen/host/bp/iterations.stamp > gen/host/onebyte/iterations.stamp gen/host/bug-221100/iterations.stamp > gen/host/bug-908454/iterations.stamp > gen/host/bug-221220/iterations.stamp gen/host/atomic/iterations.stamp > gen/host/bug-905492/iterations.stamp > gen/host/bug-221168/iterations.stamp make[1]: Leaving directory > `/home/fe/sdcc/support/regression' make: *** [test-host] Fehler 2 > > Greetings, > Frieder Thanks a bunch Frieder, this is excellent news. It means gcc accepts what is in the standard only not what I extrapolated from it. I'll remove the nestedstruct from the test (maybe only for host). Now let's see if I can get this cvs thing going. |
From: Maarten B. <sou...@ds...> - 2004-05-22 19:55:07
Attachments:
zeropad.c
|
> > On Sat, 22 May 2004, Maarten Brock wrote: > > > Thanks again Erik, and I have some more questions. > > > > But first some answers. I skipped using gbdk-lib and ucz80 (and hc08 > > as well). I also found the error on stack-auto and running make > > again did not solve it. Running make test-mcs51-stack-auto by itself > > did however. > > > > I've updated the zeropad.c test case and it runs ok for ds390, > > mcs51, mcs51-large and mcs51-stack-auto. But it fails for "host" and > > z80. What is "host"? Is this my gcc c compiler? > > "host" is gcc, if it is installed, otherwise it is whatever compiler > is installed as "cc". Although certainly not foolproof, running the > tests on a another compiler in addition to sdcc give some confidence > that the assertions made by the tests are actually true. If testing > something that is implementation dependent according to the C > standard, the test should be enclosed in an appropriate #ifdef/#endif > pair (or made compatible some suitable macro substitution, such as > replacing data/xdata/idata keywords with whitespace). So if test-host > fails, first double check the failing assertion with the C standard. > If it is implementation specific, try to take this into account with > the preprocessor directives. Otherwise, you may have found a bug in > the host compiler. > > The z80 failure is probably bug #741044, reacting to a change you have > made to the initialized struct(s). I haven't looked at the bug since > last year; I will take another look and perhaps understand what is > going on better now. But don't worry about zeropad.c failing with z80 > since it is already a filed bug report. > > Erik Hi again, Just for your information this is what the test looks like now. Maarten |
From: Maarten B. <sou...@ds...> - 2004-05-23 09:03:12
|
> "host" is gcc, if it is installed, otherwise it is whatever compiler > is installed as "cc". Although certainly not foolproof, running the > tests on a another compiler in addition to sdcc give some confidence > that the assertions made by the tests are actually true. If testing > something that is implementation dependent according to the C > standard, the test should be enclosed in an appropriate #ifdef/#endif > pair (or made compatible some suitable macro substitution, such as > replacing data/xdata/idata keywords with whitespace). So if test-host > fails, first double check the failing assertion with the C standard. > If it is implementation specific, try to take this into account with > the preprocessor directives. Otherwise, you may have found a bug in > the host compiler. > > The z80 failure is probably bug #741044, reacting to a change you have > made to the initialized struct(s). I haven't looked at the bug since > last year; I will take another look and perhaps understand what is > going on better now. But don't worry about zeropad.c failing with z80 > since it is already a filed bug report. > > Erik Hi again, As you may have guessed I'm no gcc guru. The linux machine I have access to has gcc 2.96 installed and generates these warnings which I can understand. Maybe later versions of gcc react differently (see C99 spec 6.7.2.1 17) but I need others to verify that. So please help with that. And then make gives two errors. I'm really at a loss here. gen/host/zeropad/zeropad_storage_code.c:36: array size missing in `b' gen/host/zeropad/zeropad_storage_code.c:51: warning: excess elements in array initializer gen/host/zeropad/zeropad_storage_code.c:51: warning: (near initialization for `incompletestruct.b') gen/host/zeropad/zeropad_storage_code.c:51: warning: excess elements in array initializer gen/host/zeropad/zeropad_storage_code.c:51: warning: (near initialization for `incompletestruct.b') gen/host/zeropad/zeropad_storage_code.c:51: warning: excess elements in array initializer gen/host/zeropad/zeropad_storage_code.c:51: warning: (near initialization for `incompletestruct.b') gen/host/zeropad/zeropad_storage_code.c:51: warning: excess elements in array initializer gen/host/zeropad/zeropad_storage_code.c:51: warning: (near initialization for `incompletestruct.b') gen/host/zeropad/zeropad_storage_code.c:56: warning: excess elements in array initializer gen/host/zeropad/zeropad_storage_code.c:56: warning: (near initialization for `nestedstruct.s.b') gen/host/zeropad/zeropad_storage_code.c:56: warning: excess elements in array initializer gen/host/zeropad/zeropad_storage_code.c:56: warning: (near initialization for `nestedstruct.s.b') make[2]: *** [gen/host/zeropad/zeropad_storage_code.o] Error 1 make[1]: *** [results/host/zeropad.out] Error 2 See my previous post for the used zeropad.c source code. In the meantime I will try and see if I can find anything in the z80 port. Greets, Maarten |