> this comes directly from your system headers (/usr/include/bits/select.h) > and as such doesn't really have anything to do with llvm-gcc:iirc there were some fixincludes hacks for FD_ZERO thing. Maybe are presented presented in one version and does not - in another, thus the difference... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
Hi Anton,>> this comes directly from your system headers (/usr/include/bits/select.h) >> and as such doesn't really have anything to do with llvm-gcc: > iirc there were some fixincludes hacks for FD_ZERO thing. Maybe are > presented presented in one version and does not - in another, thus the > difference...IIRC the fixincludes hack was done so that the asm would not crash the compiler, the problem being that "int" (32 bits) is being passed to the asm even on 64 bit machines; it should be "long". But the asm itself is coming from glibc. Ciao, Duncan.
> IIRC the fixincludes hack was done so that the asm would not crash the > compiler, > the problem being that "int" (32 bits) is being passed to the asm even on 64 > bit machines; it should be "long". But the asm itself is coming from glibc.Yes, however from the original report it's unclear how the versions of llvm-gcc were built. It's possible e.g. that 2.6 one was some pre-packaged one bringing the "fixed" header from other version of glibc. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University