In bug 516858 we've been looking at a compiler hang in ufn.c. This has been realised by our trunk builders being switched to gcc 4.2 and the Mac OS X 10.5 SDK (previously they were on gcc 4.0 and 10.4 SDK). From bug 516858 comment 30: > I believe I narrowed it down to a single line of code, but it's certainly very > strange. > > in ldap_ufn_expand > > if (( msgid = ldap_search( ld, dn, scope, filter, attrs, > aonly )) == -1 ) { > ldap_msgfree( tmpcand ); > *err = ldap_get_lderrno( ld, ((void *)0), ((void *)0) ); > return( ((void *)0) ); /* XXX */ > > that last return is causing the gcc hang for me. Commenting it out makes the > bug dissapear. Changing it is more interesting. return 1; works just fine, gcc > is happy. Anything else that the optimizer can resolve to 0 seems to cause > problems, variants I've tried > > return 1; //WORKS > return 2; //WORKS > return 0; //HANGS > return i; //WORKS > return i-i; //HANGS > return 2-2; //HANGS > > Absolutely not sure *why* the compiler is doing this, but definitely something > tripping up the optimizer somehow. As this is currently keeping our trees red, and I think we are unlikely to get everything patched (if we can get a patch) I think we should at least work around it for now. From my local experimentations, I believe the attached patch should fix the issue. gozer can you get this onto a mac box and check it please?

(In reply to comment #0) > Created an attachment (id=404452) [details] > Possible fix > > In bug 516858 we've been looking at a compiler hang in ufn.c. This has been > realised by our trunk builders being switched to gcc 4.2 and the Mac OS X 10.5 > SDK (previously they were on gcc 4.0 and 10.4 SDK). > > [...] > From my local experimentations, I believe the attached patch should fix the > issue. > > gozer can you get this onto a mac box and check it please? Crazy, but it works. This needs a *big* comment in the code as to why it's there, that's for sure.

Previous patch with added comments. If we take this I'll arrange appropriate ways to get this included in comm-central.

Please make sure to file a bug with Apple describing the compiler issue as best you can and cite the Apple bug # here.

Comment on attachment 404521 [details] [diff] [review] Proposed fix Very strange indeed. This patch looks OK; I assume other compilers will accept return 0 even though the return type is a pointer.

(In reply to comment #4) > (From update of attachment 404521 [details] [diff] [review]) > Very strange indeed. This patch looks OK; I assume other compilers will accept > return 0 even though the return type is a pointer. I realised in testing on a preprocessed version I had used the equivalent of NULL. So I changed the patch to use NULL when I checked it in. Checked in: Checking in ldap/libraries/libldap/ufn.c; /cvsroot/mozilla/directory/c-sdk/ldap/libraries/libldap/ufn.c,v <-- ufn.c new revision: 5.3; previous revision: 5.2 done Leaving this bug open whilst I get this into the builds and do the necessary follow-ups.

(In reply to comment #3) > Please make sure to file a bug with Apple describing the compiler issue as best > you can and cite the Apple bug # here. Apple Bug ID# 7284187.

This is now incorporated into the comm-central builds and apple bug raised as per comment 6.

Update from Apple today: This is a follow-up to Bug ID# 7284187. Engineering has provided the following feedback on your reported issue: The issue doesn't appear to arise in the x86 targets. We're unlikely to address this issue for the ppc target. We consider this issue closed. If you have any questions or concern regarding this issue, please update your report directly (http://bugreport.apple.com). Thank you for taking the time to notify us of this issue. Best Regards, Kit Miller Developer Bug Reporting Team Apple Worldwide Developer Relations