https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65070
--- Comment #2 from Nadav Har'El <nyh at math dot technion.ac.il> --- Hi, What was the intention behind this "intentionally"? As I mentioned above, I believe the tiny performance saving of not calling the syscall() function are minimal, because if I understand correctly it's only called in rare cases when there is contention, and when the context-switch overhead would be large anyway. And even if it's not rare, isn't the syscall overhead significantly larger than the syscall() function's additional overhead (copying a couple of registers, etc.)? Just using <sys/syscall.h> and syscall() would have made all this code simpler, and avoid repeating code already in glibc. Unless I'm missing something important here... Regarding OSv (see http://osv.io/), the idea there is that it is able to run unmodified Linux dynamically-linked binaries. Our C library is different (not glibc), but other libraries and executables which call libc functions can run unmodified, and libgomp should not be an exception. The plan is to take an unmodified libgomp.so from some Linux distribution and just run it, without recompiling. It's not impossible for us also to support the "syscall" instruction, but I was just wondering why we want to: libgomp is the first library we've seen to call the syscall instruction directly instead of just calling the syscall() libc function, and I was wondering if there is good justification for that.
