This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Call for compiler help/advice: atomic builtins for v3


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?

I'm going to link this message to a new enhancement PR, anyway.

Thanks in advance,

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]