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_GC
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 ha
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.
>
>
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_popcou
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 f
ecb.h currently generates tons of warnings on gcc-llvm 4.2.1 (OS X
10.6 with Xcode 4) because the ECB_GCC_VERSION macro blacklists llvm.
This causes ecb.h to think that __attribute__ and other gcc extension
keywords are not supported when they in fact are. The attached patch
fixes this problem and
