Greetings, I have been trying to help diagnose a failure to build in the icu package for Fedora on ARM systems, with gcc 4.7. I should very much like to know the answer to a few questions, so that I can help fix this. I would like to say at the outset that I believe I am a reasonably competent programmer, but I am not (yet perhaps) a gcc hacker, though I certainly enjoy any such opportunity to get to know its internals more. I understand more of the theory than the implementation of compilers :)
The __sync_synchronize "legacy" sync function is intended to be used to perform an expensive data memory barrier operation. It is defined within libgcc in such a way that I *believe* means that, on most architectures, it is replaced with an inline assembly code emitted that performs a sync operation. On ARM, and some other architectures with mixed ISAs wherein there may not be a sync function nor one way to do this, this function (__sync_synchronize) can be a real function call. In that case, it might cause inline assembly generation, or e.g. call a kernel VDSO helper. The icu package contains a direct call to __sync_sychronize, especially in the iotest test cases. I believe that this compiles fine on x86 because there is no function call. However, on ARM, the code fails to link because the __sync_synchronize function is HIDDEN and not exported (or so goes my understanding - is that correct?). I am drawing a blank, though, on how this differs from earlier versions of gcc such as 4.6 (aside from a slight difference in the macro used to make it available), and whether it is indeed the case that this function should be made available within libgcc for direct linking? In other words, I do not know whether there is a bug here in gcc or whether icu needs changing. It seems that there are newer, less expensive sync operations that perhaps ought to be used instead, but I don't have the full context. Please forgive my lack of understanding of gcc intrinsics, and atomics. I would very much like to learn more about the internal implementation and I look forward to whatever information you can share with me. If you would like more information, I can happily provide it in the morning. It is very late here, but I wanted to start this thread asap. We are trying to fix icu so that we can continue to build Fedora 17 for ARM systems. Thanks very much, Jon.