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

Reply via email to