Re: libecb patch: fix compile warnings on gcc-llvm 4.2.1 (OS X 10.6 with Xcode 4)
On Fri, Dec 09, 2011 at 08:43:44AM +0100, Hongli Lai wrote: > 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. That is very complicated. > - 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) But we have no indication that apple's llvm (or even the official llvm-gcc version it is based on) actually does support attribute just like gcc. In fact, I am pretty sure it doesn't. Please note that this isn't just about features libecb uses, but also features that users of libecb use, which libecb has no control over. So announcing the availability of gcc's attribute when it's not actually true might work with libebc itself, but not with user code. So, here are I think the killer arguments (sumarised from my previous reply): - apple's llvm-gcc is long obsolete - it does create correct code - it can be configured not to emit any warnings, with improved performance, by switching to c99 mode. So your entire complex patch exists not to improve anything of substance (such as making code work on apples llvm), just to silence a few compiler warnings. I think it's just not worth it for a compiler that has long since been replaced. -- 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 Fri, Dec 9, 2011 at 12:48 PM, Marc Lehmann wrote: > 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. What do you think of my latest patch which only whitelists Apple's llvm-gcc specifically, and only if the advertised version is large enough? -- 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)
On Thu, Dec 08, 2011 at 11:18:44PM +0100, Hongli Lai 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 11:33:01PM +0100, Hongli Lai 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. Which leaves these issues unresolved: - other versions than you happen to use (older/newer) - other "branches" of llvm (apple has it's own antique version of llvm) - current and future libecb use(r)s that rely on other gcc features > you saying that the compiler might have no-op stub implementations for > some of those attributes? as one possibility, yes. > > 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 > > 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. millions of people sounds rather inflated to me, but apple actively fights free software such as ecb, and supporting apple is, imho, detrimental to the well being of ecb and other free software, given that free alternative compilers that work (both gcc and llvm) are easily available and installable. -- 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)
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
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 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)
On Thu, Dec 8, 2011 at 4:18 PM, Hongli Lai 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 9:54 PM, Marc Lehmann 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
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 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
