Hi Benjamin,
Several people (including me) are hitting this bug on ARM:
http://llvm.org/bugs/show_bug.cgi?id=15429
I see this error when self-hosting Clang on Ubuntu 12.10 on ARM but hadn’t had time to investigate with the release process running on Ubuntu 12.04. We can certainly help you debug this, or if you point me to the right place I can do some tests and send a patch as soon as possible.
cheers,
–renato
I think this is two bugs in one:
* In ABIs that don't use external functions for atomics (linux hard
float at least), we incorrectly decide to use function calls.
* In ABIs that do use external function calls (non hard float linux?),
we don't have code to actually generate the calls.
See the thread in
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130415/078021.html.
The hard float case has been in my personal todo list for some time,
but I never got to it 
* In ABIs that don't use external functions for atomics (linux hard
float at least), we incorrectly decide to use function calls.
This seems to be the problem in my box, and Benjamin's hint did solve the
problem (setting MaxAtomicInlineWidth). However, I'm not sure what relation
that variable has to do with choosing library calls or not. If it's just a
matter of variable sizes (allowing direct atomic calls on 64-bit VFP
instructions), that it's possible that the fix is correct.
I have applied it and Clang compiles code that it wouldn't previously, but
I'm waiting for the build to finish to self-host Clang itself, which is the
ultimate test. I'll keep you posted.
* In ABIs that do use external function calls (non hard float linux?),
we don't have code to actually generate the calls.
You mean in Clang? Or a library?
See the thread in
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130415/078021.html
.From this discussion, seems that compiler-rt is the wrong fix. Shouldn't
this be provided by libstdc++?
cheers,
--renato
This seems to be the problem in my box, and Benjamin's hint did solve the
problem (setting MaxAtomicInlineWidth). However, I'm not sure what relation
that variable has to do with choosing library calls or not. If it's just a
matter of variable sizes (allowing direct atomic calls on 64-bit VFP
instructions), that it's possible that the fix is correct.
For the hard float ABI I think that is the correct fix. At least on
fedora 18 for ARM gcc doesn't use function calls and in fact there
doesn't seem to be any library support present in the installed
libgcc.
* In ABIs that do use external function calls (non hard float linux?),
we don't have code to actually generate the calls.You mean in Clang? Or a library?
In clang. In an ABI where some atomic operations are done by calling
functions in libgcc, it is clang's responsibility to to produce these
calls.
See the thread in
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130415/078021.html.
From this discussion, seems that compiler-rt is the wrong fix. Shouldn't
this be provided by libstdc++?
In the ABIs where we need to use library calls I think the
implementation itself should be in compiler-rt. I don't have a system
with such an ABI to check, but I am almost sure that they would be
implemented in libgcc.
Cheers,
Rafael
For the hard float ABI I think that is the correct fix. At least on
fedora 18 for ARM gcc doesn't use function calls and in fact there
doesn't seem to be any library support present in the installed
libgcc.
Same on Ubuntu 12.04 and 12.10. But this is the hard-float version, maybe
the soft-float does have.
but I am almost sure that they would be implemented in libgcc.
Yes, ignore that.
cheers,
--renato