On 11/6/05, Paolo Carlini <[EMAIL PROTECTED]> wrote: > Hi, > > we have this long standing issue which really we should solve, one way > or another: otherwise there are both correctness and performance issues > which we cannot fix, new features which we cannot implement. I have > plenty of examples, just ask, in case, if you want more details and > motivations. > > In a nutshell, the problem is that there is no easy way to use in the > library *headers* the new atomic builtins: we want the builtins in the > headers, because we want inlining, but we cannot know whether the > builtins are actually available. This is of course because of targets > like i686-* (I think old Sparcs is another example), when by default the > generated code is i386 compatible. In such cases, more generally, the > availability or not of the builtins depends on the actual command line > switches (e.g., -march). > > Thus my request: would it be possible to have available the builtins > unconditionally, by way of a slow (locks) fallback replacing the real > implementation when the actual target code doesn't allow for them? I > think it's rather obvious that this is the cleanest solution for the > issue by far. Alternately, something I could probably implement myself > rather quickly, export a preprocessor builtin, which could be exploited > in macros. As I said, I already explored a bit this solution time ago > and seems to me very easy to implement, but really I rather prefer the > first one. However, if you really believe the latter is the only > possible way to go, I can work on it immediately: the issue is on top of > my priorities for the next weeks. > > Other proposals?
We could just provide fallback libcalls in libgcc - though usually you would want a fallback on a higher level to avoid too much overhead. So - can't you work with some preprocessor magic and a define, if the builtins are available? Richard.
