Le dimanche 27 janvier 2013 02:49:17, vous avez écrit : > Hoping I picked up the latest and greatest version, as I am not very > familiar with git: > > git clone git://repo.or.cz/tinycc.git > git fetch origin -v
The latest version is the mob branch so if you want it, you should do git clone -b mob git://repo.or.cz/tinycc.git Then everytime you want to update to the latest commit just do git pull. > > [hopefully this picks up the version you've been working on so hard > lately. If not, please let me know the proper git incantations to get the > newest stuff] > > Then: > > ./configure > make > make test > > At this point, had to make a number of symlinks/copies into /usr/include of > header files from: > > /usr/include/arm-linux-gnueabihf/ to /usr/include These shouldn't be necessary. Can you try without the symlink and the mob branch? > > [This seems peculiar to the Raspbian distro on the Pi. Never had to do this > on the BeagleBone - Angstrom distro there] > > make test > > The good news is that the tests get a lot farther than before -- and > clearly you fixed the problem with 40_stdio.c. A couple of runs got as far > as: > > ------------ speedtest ------------ > time ./ex2 1238 2 3 4 10 13 4 > make[1]: time: Command not found > make[1]: *** [speedtest] Error 127 > make[1]: Leaving directory `/home/pi/tinycc/tests' > make: *** [test] Error 2 > > There is lots of diff output spewed along the way, but the tests do > complete, which means all the stuff in test2, plus test1, 2 and 3 in > tests. Not sure what is up with the speedtest failure, but it is probably > my environment. > > However the bad news is that other runs still get intermittent Segmentation > faults, like this: > > Test: 45_empty_for... > Test: 47_switch_return... > Test: 48_nested_break... > Segmentation fault > make[1]: *** [48_nested_break.test] Error 139 > make[1]: Leaving directory `/home/pi/tinycc/tests2' > make: *** [test] Error 2 > > different places on different runs, of course. Yeah, I tried to debug this in gdb but of course I can't reproduce it there, even when using the batch mode with 100+ run command in the batch file. I tried catching the SIGSEGV signal in the 28_strings test to display the address of failure but it seems it always fail before the sigaction is put in place so I suspect the sigsegv happens in tcc itself. Also, I'm not sure but it could be there forever but have been exposed by the long suite of tests in tests2. I got the SIGSEGV also in the old testsuite but since there was only 3 programs run and this seems to happens at tcc -run startup, I guess it was just not frequent enough to be noticed. > > So better, but still some problems. Similar results if I configure > --with-libgcc as well. > > Will try BeagleBone tomorrow if the VPN to my office is working, otherwise > will try it Monday AM EST. > > Thanks for all the hard work you and others have put in. I'm really interested in making the arm port work smoothly so your bug report are very valuable. Thanks > > Regards, > > Jerry Best regards, Thomas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
