Edgar E. Iglesias wrote: > On Wed, Oct 24, 2007 at 12:33:24PM +0200, J. Mayer wrote: > > On Wed, 2007-10-24 at 09:36 +0900, Hwang YunSong(?????????) wrote: > > > > > > gcc32 -g -o qemu-system-cris vl.o osdep.o readline.o monitor.o pci.o > > > console.o loader.o isa_mmio.o cutils.o block.o block-raw.o block-cow.o > > > block-qcow.o aes.o block-vmdk.o block-cloop.o block-dmg.o > > > block-bochs.o block-vpc.o block-vvfat.o block-qcow2.o > > > block-parallels.o irq.o i2c.o smbus.o scsi-disk.o cdrom.o lsi53c895a.o > > > usb.o usb-hub.o usb-linux.o usb-hid.o usb-ohci.o usb-msd.o usb-wacom.o > > > eeprom93xx.o eepro100.o ne2000.o pcnet.o rtl8139.o etraxfs.o ptimer.o > > > etraxfs_timer.o etraxfs_ser.o gdbstub.o sdl.o x_keymap.o vnc.o d3des.o > > > slirp/cksum.o slirp/if.o slirp/ip_icmp.o slirp/ip_input.o > > > slirp/ip_output.o slirp/slirp.o slirp/mbuf.o slirp/misc.o slirp/sbuf.o > > > slirp/socket.o slirp/tcp_input.o slirp/tcp_output.o slirp/tcp_subr.o > > > slirp/tcp_timer.o slirp/udp.o slirp/bootp.o slirp/debug.o slirp/tftp.o > > > libqemu.a -lm -lz -lgnutls -L/usr/lib -lSDL -lpthread -lrt -lutil > > > libqemu.a(helper.o): In function `do_interrupt': > > > /usr/src/Haansoft/BUILD/qemu/target-cris/helper.c:137: undefined > > > reference to `__builtin_clz' > > > libqemu.a(translate-op.o): In function `dyngen_code': > > > /home/hys545/qemu/cris-softmmu/op.h:1566: undefined reference to > > > `__builtin_clz' > > > libqemu.a(op.o): In function `op_lz_T0_T1': > > > /usr/src/Haansoft/BUILD/qemu/target-cris/op.c:1009: undefined > > > reference to `__builtin_clz' > > > collect2: ld returned 1 exit status > > > > It does not seem to be a good idea, imho, to use gcc builtins directly > > from micro-ops. But your compiler should implement __builtin_clz. As far > > Hi, > > I submitted a patch that at compile-time fallbacks to clz code without > builtins. Do you see any additional issues with using the builtins? > > I think the speed-up with GCC ports implementing fast builtin variants of > operations like clz would be significant enough to justify their use but if > there is disagreement I'll send in a new patch removing the builtin_clz > alltogether.
If the builtin ends up calling into libgcc (this can happen depending on the host / host compiler), then the dynamic code generation breaks. It is safer not to force the compiler to use builtins. Thiemo