Compiler bugs where the compiler generates bad code are definitely real (I've found two), but are very rare (I've found two ever).

95% of the time when I've had a bug that only shows up with specific build settings, it's because I used an uninitialized variable. Something like this:

int myVariable;

if(a < b){
  myVariable = 6;
} else if(a < c){
  myVariable = 12;
}

If a is greater than both b and c, myVariable will just have whatever old leftover value happened to be sitting in the register or stack location given to myVariable. It might be 0, it might be -12000, and it's almost guaranteed to change based on compiler settings as that causes registers to get used for different things. It's harder to notice this happening when myVariable is a float as half of the random sets of bits when used as a floating point number will be between 1 and -1. When this happens to pointers it can cause other confusing bugs.

As CJ said, turn on more warnings and also run the static analyzer. They might be able to find your bug for you.

Also, after years of inflicting bugs on myself caused by this. I decided never ever declare a variable without defining it! There isn't a good reason to do it unless you are supporting 20 year old compilers.

I would start by turning on more compiler warning options and then build with llvm. See what sort of warnings it gives you.

old thread but...

is it possible that xcode 4.2 default compiler llvm 3.0 behaves differently compiling cocos2d than gcc 4.2?

i am having a strange issue (missing batchnodes and cclabelbmfont) with my app on an old ipod touch 2g (ios 4.2.1) compiled with llvm. but using gcc... all is well. to make it worse... the issue is not appearing on my ipod touch g4 and ipad (both ios5) even when compiling with llvm. the issue also only appears in release not debug build!

@riq: any tips for tracking a bug like that? i hoped its withing my code not cocos2d but since it does work on ipod4/ipad i am not so sure anymore.

FWIW, I'm getting a nasty EXC_BAC_ACCESS on line 518 of CCSprite where glBlendFunc is called when LLVM 2.0 is selected. Device is an iPhone 3G with iOS4. It works fine on simulator and on 3GS, or using LLVM GCC 4.2.

I've heard much the same. There was a issue involving iOS4 frame rate dropping related to multitasking (issue #910?).. I was suggest to try compiling with LLVM rather than GCC by a friend. I haven't had the chance to try yet, but I'm going to look into it over the weekend.

Apple is moving in the direction of LLVM. I've used it consistently on the Zwoptex Desktop project as well as some iPad applications without any issues at all granted I was not using cocos2d and coded from the beginning with LLVM.

I find that it's faster, more verbose in warnings & errors and generally just better all around.

With XCode 4 and LLDB I doubt I'll ever even touch GCC or GDB again.

Thanks a lot for your investigation. What does that mean now for the particle issue?

Thanks,
Marco

@crmagicxxx: Yes, your code seems to work OK both with LLVM and GCC.

@riq

Good you found it. I am getting things from dictionary like this:

float x = [dictionary valueForKey:@"some_key"] ? [[dictionary valueForKey:@"some_key"] floatValue] : 0;

So there is never a doubt about the value of 'x'

It seems to be an LLVM bug:
https://devforums.apple.com/message/260616

I found it:

In LLVM 1.5 compiler

// x ==  -nan if the key "doesn't exist" doesn't exist.
float x = [[dictionary valueForKey:@"doesnt_exist"] floatValue];

In GCC 4.2 compiler

// x ==  0 if the key "doesn't exist" doesn't exist.
float x = [[dictionary valueForKey:@"doesnt_exist"] floatValue];

@JonKean does running the build with analyze produce information that would help you track this down?

A developer at Apple (guy working on LLVM) highly suggested moving away from GCC immediately. He says Apple is no longer fixing bugs in GCC, and in XCode 4 GCC-LLVM will be the default option.

I've noticed sometimes LLVM will not compile against really old libraries compiled with GCC (gives errors about built in runtime functions not found). I can fix that by using GCC-LLVM (gcc parser, LLVM code generator).

A few days ago I noticed a bug in my code that only showed up when using LLVM (but not GCC). I tracked it down to a non initialized local variable that was being read from, and GCC would always initialize to zero (even with O3 optimizations). Since the variable value should be undefined, LLVM was giving the correct behavior of using whatever was in that memory already (even though it's clearly not the desired result). I'd speculate something similar is going on with ParticleTests.

I did a quick test, and compiling Cocos2D with GCC-LLVM works correctly with issue 872.

@riq

Today I tried to update to latest develop version (2010-07-16 d73e47927a035927de59) and discovered 12 warnings/errors. I also have default compiler GCC 4.2. If I change to LLVM 1.5 those warning disappear. But I have a doubt if I should change compiler because I am afraid of possible incompatibility issues (like you stated for particles). So, can you please tell me what are the benefits/drawbacks of using LLVM 1.5 and should I really change GCC like you did in latest version?

Best

Sorry to ask, but I have never changed the default compiler settings. Do I have to use a special compiler for special projects or a special OS version or is it okay to just use that GCC compiler and be fine :-)

Thanks,
Marco

weird...

Hey,

Have you experienced any incompatibility between LLVM compiler and GCC compiler ?

I found one strange issue:
If you compile ParticleTests with GCC and if you try sub-test "issue 872", it works as expected: a particle system will emit particles.
But if you compile it with LLVM 1.5, you won't see any particle at all. I'm not sure what's the problem, but I'll investigate it a bit further.

I can only reproduce this bug on the simulator. It seems that this bug can't be reproduced on the devices.

I tested it both in Release & Debug mode using Xcode 3.2.3.