On Thu, Dec 8, 2011 at 9:54 PM, Marc Lehmann <schm...@schmorp.de> wrote: > hmm, I am curious, what kind of warnings are these?
ecb.h:126: warning: ‘ecb_mf_lock’ defined but not used ecb.h:252: warning: ‘ecb_ctz64’ defined but not used ecb.h:285: warning: ‘ecb_ld64’ defined but not used ecb.h:299: warning: ‘ecb_popcount64’ defined but not used ecb.h:312: warning: ‘ecb_rotl8’ defined but not used ecb.h:313: warning: ‘ecb_rotr8’ defined but not used ecb.h:315: warning: ‘ecb_rotr16’ defined but not used ecb.h:316: warning: ‘ecb_rotl32’ defined but not used ecb.h:317: warning: ‘ecb_rotr32’ defined but not used ecb.h:318: warning: ‘ecb_rotl64’ defined but not used ecb.h:319: warning: ‘ecb_rotr64’ defined but not used ecb.h:343: warning: ‘ecb_bswap64’ defined but not used ecb.h:353: warning: ‘ecb_unreachable’ defined but not used ecb.h:368: warning: ‘ecb_big_endian’ defined but not used ecb.h:370: warning: ‘ecb_little_endian’ defined but not used > they in fact are not - llvm choose to implement only subsets of gcc > extensions while announcing full support, so us poor developers would have > to check every llvm version to see what subset it supports. > > if you think attribute is _fully_ implemented in llvm then we would at > least need to know which version of llvm started to do that, and then we > could enable attribute for that version onward, if it exists. I don't know whether it's fully implemented, but everything that ecb.h uses *is* fully implemented in llvm-gcc 4.2.1. This is pretty huge because Xcode 4 now uses llvm-gcc as the default gcc so all OS X users will get these warnings. > what warning does llvm emit for these, and why? marking all functions as > unused is a bit disingenous, I'd think it would be much better to fix llvm > not to emit the warning in these cases instead. > > if the warning is caused by llvm hitting the "static" definition for > ecb_inline then it will go away automatically as soon as llvm supports c99 > (which has inline). llvm-gcc 4.2.1 on OS X does support C99, but it doesn't advertise that unless you specify -std=c99. In fact it doesn't set __STDC_VERSION__ at all unless you pass that argument. I see that forcing ECB_C99 also gets rid of most of the compilation warnings so the problem was with ecb_inline after all. However this still leaves all the other problems as mentioned above. - Hongli -- Phusion | Ruby & Rails deployment, scaling and tuning solutions Web: http://www.phusion.nl/ E-mail: i...@phusion.nl Chamber of commerce no: 08173483 (The Netherlands) _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
