Hi Thomas: Thank you so much for your response.
I think I made sure that TCC_ARM_HARDFLOAT was #undef'ed. I am not sure it was ever defined, however. Here is the result of configure: pi@raspberrypi ~/tinycc $ ./configure Binary directory /usr/local/bin TinyCC directory /usr/local/lib/tcc Library directory /usr/local/lib Include directory /usr/local/include Manual directory /usr/local/share/man Info directory /usr/local/share/info Doc directory /usr/local/share/doc/tcc Target root prefix Source path /home/pi/tinycc C compiler gcc Target OS Linux CPU armv4l Big Endian no gprof enabled no cross compilers no use libgcc no Creating config.mak and config.h Although I don't see it on the generated command line from Make, I also removed the possible inclusion of -DTCC_ARM_HARDFLOAT in the Makefile, like this: changing NATIVE_DEFINES+=-DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT to NATIVE_DEFINES+=-DTCC_ARM_EABI Here's the result of make after that: pi@raspberrypi ~/tinycc $ make gcc -o tcc.o -c tcc.c -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI -DTCC_ARM_VFP -I. -I/home/pi/tinycc -I /usr/include/arm-linux-gnueabihf -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare gcc -o libtcc.o -c libtcc.c -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI -DTCC_ARM_VFP -I. -I/home/pi/tinycc -I /usr/include/arm-linux-gnueabihf -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare gcc -o tccpp.o -c tccpp.c -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI -DTCC_ARM_VFP -I. -I/home/pi/tinycc -I /usr/include/arm-linux-gnueabihf -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare gcc -o tccgen.o -c tccgen.c -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI -DTCC_ARM_VFP -I. -I/home/pi/tinycc -I /usr/include/arm-linux-gnueabihf -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare gcc -o tccelf.o -c tccelf.c -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI -DTCC_ARM_VFP -I. -I/home/pi/tinycc -I /usr/include/arm-linux-gnueabihf -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare gcc -o tccasm.o -c tccasm.c -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI -DTCC_ARM_VFP -I. -I/home/pi/tinycc -I /usr/include/arm-linux-gnueabihf -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare gcc -o tccrun.o -c tccrun.c -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI -DTCC_ARM_VFP -I. -I/home/pi/tinycc -I /usr/include/arm-linux-gnueabihf -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare gcc -o arm-gen.o -c arm-gen.c -DTCC_TARGET_ARM -DWITHOUT_LIBTCC -DTCC_ARM_EABI -DTCC_ARM_VFP -I. -I/home/pi/tinycc -I /usr/include/arm-linux-gnueabihf -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare ar rcs libtcc.a libtcc.o tccpp.o tccgen.o tccelf.o tccasm.o tccrun.o arm-gen.o gcc -o tcc tcc.o libtcc.a -lm -ldl -I. -I/home/pi/tinycc -I /usr/include/arm-linux-gnueabihf -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare texi2html -monolithic -number tcc-doc.texi make: texi2html: Command not found make: [tcc-doc.html] Error 127 (ignored) makeinfo tcc-doc.texi make: makeinfo: Command not found make: [tcc-doc.info] Error 127 (ignored) (I think that the errors from texi2html are not relevant here.) However, running make test results in the same sorts of intermittent Segmentation faults, and the 40_stdio.c test still hangs forever in the while ! EOF loop. So perhaps the code for hardware floating point is not the only possible cause for these symptoms? The inclusion of the --with-libgcc flag to configure seems to make no difference. Any further suggestions for how I might obtain more information here. Again, thanks. On Sun, Jan 20, 2013 at 6:40 PM, Thomas Preud'homme <[email protected]>wrote: > Le dimanche 20 janvier 2013 04:28:16, Jerry Reed a écrit : > > Built tiny cc from source at: > > > > git clone git://repo.or.cz/tinycc.git > > > > Using the Raspberry Pi with the Raspbian distro as the host and target. > > > > OS is: Linux raspberrypi 3.1.9+ #168 PREEMPT Sat Jul 14 18:56:31 BST 2012 > > armv6l GNU/Linux > > > > gcc is: Using built-in specs. > > COLLECT_GCC=gcc > > COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper > > Target: arm-linux-gnueabihf > > Configured with: ../src/configure -v --with-pkgversion='Debian > > 4.6.3-8+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs > > --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr > > --program-suffix=-4.6 --enable-shared --enable-linker-build-id > > --with-system-zlib --libexecdir=/usr/lib --without-included-gettext > > --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 > > --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu > > --enable-libstdcxx-debug --enable-libstdcxx-time=yes > > --enable-gnu-unique-object --enable-plugin --enable-objc-gc > > --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp > > --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf > > --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf > > Thread model: posix > > gcc version 4.6.3 (Debian 4.6.3-8+rpi1) > > > > tcc builds without apparent error. > > > > I got as far as running the tests with > > > > make test > > > > but there is bad news there. Several things of concern occurred. > > > > First, there were intermittent Segmentation Faults in several of the > tests, > > like this: > > > > pi@raspberrypi ~/tinycc $ make test > > make -C tests2 test > > make[1]: Entering directory `/home/pi/tinycc/tests2' > > Test: 00_assignment... > > Test: 01_comment... > > Test: 02_printf... > > Test: 03_struct... > > Test: 04_for... > > Test: 05_array... > > Test: 06_case... > > Test: 07_function... > > Test: 08_while... > > Test: 09_do_while... > > Test: 10_pointer... > > Test: 11_precedence... > > Test: 12_hashdefine... > > Test: 13_integer_literals... > > Segmentation fault > > > > Sometimes this would happen, and sometimes the test would pass Ok and a > > subsequent test would fail. One math test failed consistently, not with a > > Segmentation fault, although without looking at the source code, I am not > > sure what this actually means. > > Yeah this happened to me as well but I wasn't sure it came from tcc or not > since the computer I was doing it got frozen at some point so I suspected a > hardware fault. I'm not sure now but I think this didn't happen on the > softfloat variant of the calling convention (TCC_ARM_HARDFLOAT not set) so > since the hardfloat variant is new, I consider this not a blocker for the > next > release. > > > > > > The stdio test was really odd. Basically it seems as if the getc and > fgetc > > library routines don't correctly return what tcc expects for EOF, or the > > generated test in the while loop is faulty code. Code of the form: > > > > f = fopen("fred.txt", "r"); > > while ( (InChar = getc(f)) != EOF) > > { > > ShowChar = InChar; > > if (ShowChar < ' ') > > ShowChar = '.'; > > printf("ch: %d '%c'\n", InChar, ShowChar); > > } > > fclose(f); > > > > loops forever. > > Same here, it never worked on the hardfloat variant but it works like a > charm > on the softflate. I should investigate this one as it's fully reproducible. > > Thanks for your report. > > Best regards, > > Thomas Preud'homme > -- Interested in bats? Check out my blog at: http://www.karaokebats.com/
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
