Le jeudi 9 janvier 2014, 17:13:41 Michael Matz a écrit : > > Yeah. tcc meanwhile also emits references to other symbols that aren't in > libgcc. E.g. __floatundixf.
Indeed. > > > Or maybe now that arm can uses libtcc1 this option could be just > > removed. If there is some value in keeping it, it could also be nice > > that tcc can work directly with libgcc (and thus have va_* macros > > builtin, see stdarg.h from gcc and gcc's source code). > > You can't without providing the implementation currently residing in > libtcc directly as inline variant in the code generator (as libgcc doesn't > contain any implementation of that stuff). As the x86_64 variant of > stdargs is a bit convoluted (as in, more that three/four instructions) > that doesn't seem like the best solution. So, ... That's what gcc does but indeed, tcc tries to be smaller and faster than gcc so indeed. > > > Dear users, does any of you see value in the --with-libgcc switch of > > configure? > > ... if the possibility of using libgcc should be retained, then yes, > libtcc needs to be linked in additionally. Which seems to make sense as > that lib indeed is supposed to provide the runtime parts that the compiler > (here tcc) specifically wants to rely on. Right, I'm tempted to remove the libgcc switch but I need to look again at the commit that introduced it for the reasons. Best regards, Thomas _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
