Re: libecb patch: fix compile warnings on gcc-llvm 4.2.1 (OS X 10.6 with Xcode 4)
On Thu, Dec 08, 2011 at 11:18:44PM +0100, Hongli Lai hon...@phusion.nl wrote: hmm, I am curious, what kind of warnings are these? hmm, these are harmless and can be ignored, and possibly switched off if they are a nuisance. 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. well, warnings do not influence correctness, so it's not really a big deal. 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. then thats an easy workaround, just compile libecb in c99 mode, for improved performance even :) 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. none of which seem to influence correctness in a bad way, unlike your proposed changes. you see, we have basically these choices: a) possibly break code in unexpected ways on some far away box, but have fewer warnings on an obsoleted proprietary platform that is known to be buggy beyond repair. b) possibly have a few warnings by an overzealous compiler (or compiler user specifying extra warnings) but correct code and execution maybe a bit slower on some obsolete proprietary box. without your patch, b) is implemented, with your patch we move to a). I don't think a few warnings are reason enough to risk it. Especially as the root cause is the dubious decision of (some) llvm (-based compilers) to implement subsets of gcc extensions but announcing full support for gcc extensions. I am just surprised they didn't do that with c99. Or maybe they didn't, but we don't know yet. Now, if you want to track which version of llvm-gcc announces which version of gcc and actually implements ALL the extensions by that version of gcc that is fine, and might lead to ecb changing. However, llvm-gcc is long obsolete - clang would be more relevant, and much more relevant would be dragonegg, which will without doubt eventually replace it even on outdated os x boxes, so supporting it for fewer warnings and slightly faster code in some corner cases is just not worth your time, imho. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: libecb patch: fix compile warnings on gcc-llvm 4.2.1 (OS X 10.6 with Xcode 4)
On Thu, Dec 08, 2011 at 09:46:24PM +0100, Hongli Lai hon...@phusion.nl wrote: ecb.h currently generates tons of warnings on gcc-llvm 4.2.1 (OS X hmm, I am curious, what kind of warnings are these? This causes ecb.h to think that __attribute__ and other gcc extension keywords are not supported when they in fact are. 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. fixes this problem and also fixes a few more compilation warnings by replacing the 'ecb_inline' in front of some function definitions with 'ecb_function_'. 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). -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: libecb patch: fix compile warnings on gcc-llvm 4.2.1 (OS X 10.6 with Xcode 4)
On Thu, Dec 8, 2011 at 4:18 PM, Hongli Lai hon...@phusion.nl wrote: 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. I doubt they're actually fully implemented in OSX's llvm-gcc 4.2.1. Do you have any supporting documentation or research on that? Also the llvm-gcc 4.2.1 that OSX shipped with 4.2.1 was a pretty tragic mistake on their part, IMHO. It's a branch of code that upstream considers deprecated and unsupported, and has known bugs. See this bug link upstream: http://llvm.org/bugs/show_bug.cgi?id=9891 . ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
Re: libecb patch: fix compile warnings on gcc-llvm 4.2.1 (OS X 10.6 with Xcode 4)
On Thu, Dec 8, 2011 at 11:26 PM, Brandon Black blbl...@gmail.com wrote: I doubt they're actually fully implemented in OSX's llvm-gcc 4.2.1. Do you have any supporting documentation or research on that? All I know is that they compile and that they seem to have effect. Are you saying that the compiler might have no-op stub implementations for some of those attributes? Also the llvm-gcc 4.2.1 that OSX shipped with 4.2.1 was a pretty tragic mistake on their part, IMHO. It's a branch of code that upstream considers deprecated and unsupported, and has known bugs. See this bug link upstream: http://llvm.org/bugs/show_bug.cgi?id=9891 . That's pretty bad. Still, this broken compiler is now in the hands of millions of people who are extremely unlikely to be able to change their compiler any time soon. -- 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
Re: libecb patch: fix compile warnings on gcc-llvm 4.2.1 (OS X 10.6 with Xcode 4)
Here's a new patch should be less invasive than the last one. The new approach is as follows: - Introduced an ECB_REAL_GCC macro which tells us whether the GCC is the real one or another implementation just claiming to be GCC. llvm-gcc is not considered to be real. - Introduced an ECB_APPLE_LLVM_GCC macro which tells us whether this is Apple's llvm-gcc as shipped with OS X. - Introduced an ECB_ADVERTISED_GCC_VERSION macro which is like ECB_GCC_VERSION, but does not blacklist non-real GCC compilers. - Various features such as __inline__ and __attribute__ support are explicitly whitelisted, e.g. like this: ECB_APPLE_LLVM_GCC ECB_ADVERTISED_GCC_VERSION(3,1) - The entire memory barrier section has been moved to the bottom so that I can mark ecb_mf_lock with ecb_unused. -- 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) 0001-Fix-ecb.h-compatibility-with-llvm-gcc-4.2.1-on-OS-X-.patch Description: Binary data ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
