<div dir="auto"><div>That would be fine. The two languages expose roughly the same atomic capability so I would be able to ignore atomic and use stdatomic throughout.</div><div dir="auto"><br></div><div dir="auto">It's a bit sad to have the stable abi requirement ripple through the whole C++ library in the form of using the nastier API but I expect that can be wrapped. I should look into why <atomic> can't be such a wrapper.</div><div dir="auto"><br></div><div dir="auto">Cheers<br><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote">On 7 Mar 2018 17:54, "Volodymyr Sapsai" <<a href="mailto:vsapsai@apple.com">vsapsai@apple.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">With the implementation I have in mind, you won’t be able to use C atomic types from C++ by default. But you should be able to define a macro and use C atomics from C++. It will prevent you from using C++ atomics though. The idea is to prevent mixing <atomic> and <stdatomic.h>, so only one of those should be included.<div><br></div><div>The plan is to allow to use C atomics from C++ but with minor hurdles so we'll guide people towards preferred approach C++ atomics from C++.</div><div><br></div><div>Thanks,</div><div>Volodymyr<div class="elided-text"><br><div><br><blockquote type="cite"><div>On Mar 7, 2018, at 13:38, Jon Chesterfield via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_1737378503054782374Apple-interchange-newline"><div><div dir="auto"><div>It is occasionally necessary to write a C header that uses atomic types then include it in a C++ file. For example, implementing an abi defined in C using C++.</div><div dir="auto"><br></div><div dir="auto">This didn't quite work out of the box - I think I needed to #include <atomic> inside extern "C" or some similar absurdity - but I did get valid asm out of the result without modifying clang. Sadly I can't currently access the source to check the details.</div><div dir="auto"><br></div><div dir="auto">If this change goes ahead, would I no longer be able to use atomic types from a C header in C++?</div><div dir="auto"><br></div><div dir="auto">Cheers!</div><div dir="auto"><br></div><div dir="auto">Jon<br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On 7 Mar 2018 16:15, "via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="m_1737378503054782374quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send cfe-dev mailing list submissions to<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:cfe-dev-request@lists.llvm.org" target="_blank">cfe-dev-request@lists.llvm.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:cfe-dev-owner@lists.llvm.org" target="_blank">cfe-dev-owner@lists.llvm.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cfe-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible<br>
(Volodymyr Sapsai via cfe-dev)<br>
2. Re: [RFC] Make <atomic> and <stdatomic.h> explicitly<br>
incompatible (Shoaib Meenai via cfe-dev)<br>
<br>
<br>
------------------------------<wbr>------------------------------<wbr>----------<br>
<br>
Message: 1<br>
Date: Wed, 07 Mar 2018 12:32:05 -0800<br>
From: Volodymyr Sapsai via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
To: Clang Dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
Subject: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h> explicitly<br>
incompatible<br>
Message-ID: <<a href="mailto:C1343C23-7BE7-43A2-95BC-239F410913D8@apple.com" target="_blank">C1343C23-7BE7-43A2-95BC-239F4<wbr>10913D8@apple.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello all,<br>
<br>
Currently atomics are available in C through <stdatomic.h> and in C++ through <atomic>. These headers have some common names, so using both of them in the same translation unit usually doesn’t work. The downside is that in some cases diagnostic can be overly verbose and overwhelming. For example, compiling just 2 lines<br>
<br>
#include <stdatomic.h><br>
#include <atomic><br>
<br>
results in 68 errors.<br>
<br>
I am proposing to make these headers explicitly incompatible, so we have just a single error telling so instead of multiple errors. What do you think?<br>
<br>
Alternative solution is to make these headers compatible. But the consensus seems to be that it’s not the right solution. See <a href="https://reviews.llvm.org/D26376" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2637<wbr>6</a> <<a href="https://reviews.llvm.org/D26376" rel="noreferrer" target="_blank">https://reviews.llvm.org/D263<wbr>76</a>> for more details. There is also a proposal P0943R0: Support C atomics in C++ <<a href="http://open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0943r0.html" rel="noreferrer" target="_blank">http://open-std.org/jtc1/sc22<wbr>/wg21/docs/papers/2018/p0943r0<wbr>.html</a>>. As far as I can tell, my proposal doesn’t interfere with P0943R0 but will be obsolete if that proposal is accepted. Regardless of the future development I think it is still beneficial to have better diagnostics in the short term.<br>
<br>
I am not providing concrete implementation yet, at first I want to know the opinion of the community on the matter.<br>
<br>
Thanks,<br>
Volodymyr<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20180307/666af01c/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.llvm.org/piperma<wbr>il/cfe-dev/attachments/2018030<wbr>7/666af01c/attachment-0001.<wbr>html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 7 Mar 2018 21:15:02 +0000<br>
From: Shoaib Meenai via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
To: Volodymyr Sapsai <<a href="mailto:vsapsai@apple.com" target="_blank">vsapsai@apple.com</a>>, Clang Dev<br>
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
Subject: Re: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h><br>
explicitly incompatible<br>
Message-ID: <<a href="mailto:43BFBEC0-0C03-4B7A-874F-62F562C9FDB5@fb.com" target="_blank">43BFBEC0-0C03-4B7A-874F-62F56<wbr>2C9FDB5@fb.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
I'd be in favor of making them explicitly incompatible. I ran into this recently, found the incompatibility quite surprising, and had to do a bunch of research (looking at the relevant standards, doing experiments across a bunch of compilers and standard libraries, etc.) to convince myself that it was expected behavior. An explicit error would be super nice.<br>
<br>
From: cfe-dev <<a href="mailto:cfe-dev-bounces@lists.llvm.org" target="_blank">cfe-dev-bounces@lists.llvm.or<wbr>g</a>> on behalf of cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
Reply-To: Volodymyr Sapsai <<a href="mailto:vsapsai@apple.com" target="_blank">vsapsai@apple.com</a>><br>
Date: Wednesday, March 7, 2018 at 12:32 PM<br>
To: cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
Subject: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible<br>
<br>
Hello all,<br>
<br>
Currently atomics are available in C through <stdatomic.h> and in C++ through <atomic>. These headers have some common names, so using both of them in the same translation unit usually doesn’t work. The downside is that in some cases diagnostic can be overly verbose and overwhelming. For example, compiling just 2 lines<br>
<br>
#include <stdatomic.h><br>
#include <atomic><br>
<br>
results in 68 errors.<br>
<br>
I am proposing to make these headers explicitly incompatible, so we have just a single error telling so instead of multiple errors. What do you think?<br>
<br>
Alternative solution is to make these headers compatible. But the consensus seems to be that it’s not the right solution. See <a href="https://reviews.llvm.org/D26376" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2637<wbr>6</a><<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D26376&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=f2XAChgmKGyURiNTGeNTF1t1Fpo5BLSqNdUKyYAZYeM&s=O1AIlpTPrgXe3-fXW3-VqVGTAUhg2qKBozM1iOtQhbE&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoin<wbr>t.com/v2/url?u=https-3A__<wbr>reviews.llvm.org_D26376&d=DwMF<wbr>aQ&c=5VD0RTtNlTh3ycd41b3MUw&r=<wbr>o3kDXzdBUE3ljQXKeTWOMw&m=f2XAC<wbr>hgmKGyURiNTGeNTF1t1Fpo5BLSqNdU<wbr>KyYAZYeM&s=O1AIlpTPrgXe3-fXW3-<wbr>VqVGTAUhg2qKBozM1iOtQhbE&e=</a>> for more details. There is also a proposal P0943R0: Support C atomics in C++<<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__open-2Dstd.org_jtc1_sc22_wg21_docs_papers_2018_p0943r0.html&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=f2XAChgmKGyURiNTGeNTF1t1Fpo5BLSqNdUKyYAZYeM&s=iHKcnTreK84QBWD-j_3_n7ww5ON1-EzKzni3NgSgiaY&e=" rel="noreferrer" target="_blank">https://urldefense.proofpo<wbr>int.com/v2/url?u=http-3A__<wbr>open-2Dstd.org_jtc1_sc22_wg21_<wbr>docs_papers_2018_p0943r0.html&<wbr>d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3<wbr>MUw&r=o3kDXzdBUE3ljQXKeTWOMw&<wbr>m=f2XAChgmKGyURiNTGeNTF1t1Fpo5<wbr>BLSqNdUKyYAZYeM&s=iHKcnTreK84Q<wbr>BWD-j_3_n7ww5ON1-EzKzni3NgSgia<wbr>Y&e=</a>>. As far as I can tell, my proposal doesn’t interfere with P0943R0 but will be obsolete if that proposal is accepted. Regardless of the future development I think it is still beneficial to have better diagnostics in the short term.<br>
<br>
I am not providing concrete implementation yet, at first I want to know the opinion of the community on the matter.<br>
<br>
Thanks,<br>
Volodymyr<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.llvm.org/pipermail/cfe-dev/attachments/20180307/a2ab09a8/attachment.html" rel="noreferrer" target="_blank">http://lists.llvm.org/piperma<wbr>il/cfe-dev/attachments/2018030<wbr>7/a2ab09a8/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of cfe-dev Digest, Vol 129, Issue 36<br>
******************************<wbr>**********<br>
</blockquote></div><br></div></div></div>
______________________________<wbr>_________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div></div>