[RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

Hans Wennborg via cfe-dev
Hello all,

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

#include <stdatomic.h>
#include <atomic>

results in 68 errors.

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?

Alternative solution is to make these headers compatible. But the consensus seems to be that it’s not the right solution. See https://reviews.llvm.org/D26376 for more details. There is also a proposal P0943R0: Support C atomics in C++.  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.

I am not providing concrete implementation yet, at first I want to know the opinion of the community on the matter.

Thanks,
Volodymyr

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

Hans Wennborg via cfe-dev

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.

 

From: cfe-dev <[hidden email]> on behalf of cfe-dev <[hidden email]>
Reply-To: Volodymyr Sapsai <[hidden email]>
Date: Wednesday, March 7, 2018 at 12:32 PM
To: cfe-dev <[hidden email]>
Subject: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

 

 

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

 

#include <stdatomic.h>

#include <atomic>

 

results in 68 errors.

 

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?

 

Alternative solution is to make these headers compatible. But the consensus seems to be that it’s not the right solution. See https://reviews.llvm.org/D26376 for more details. There is also a proposal P0943R0: Support C atomics in C++.  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.

 

I am not providing concrete implementation yet, at first I want to know the opinion of the community on the matter.

 

Thanks,

Volodymyr


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

Hans Wennborg via cfe-dev
In reply to this post by Hans Wennborg via cfe-dev
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++.

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.

If this change goes ahead, would I no longer be able to use atomic types from a C header in C++?

Cheers!

Jon

On 7 Mar 2018 16:15, "via cfe-dev" <[hidden email]> wrote:
Send cfe-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cfe-dev digest..."


Today's Topics:

   1. [RFC] Make <atomic> and <stdatomic.h> explicitly  incompatible
      (Volodymyr Sapsai via cfe-dev)
   2. Re: [RFC] Make <atomic> and <stdatomic.h> explicitly
      incompatible (Shoaib Meenai via cfe-dev)


----------------------------------------------------------------------

Message: 1
Date: Wed, 07 Mar 2018 12:32:05 -0800
From: Volodymyr Sapsai via cfe-dev <[hidden email]>
To: Clang Dev <[hidden email]>
Subject: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h> explicitly
        incompatible
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hello all,

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

#include <stdatomic.h>
#include <atomic>

results in 68 errors.

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?

Alternative solution is to make these headers compatible. But the consensus seems to be that it’s not the right solution. See https://reviews.llvm.org/D26376 <https://reviews.llvm.org/D26376> for more details. There is also a proposal P0943R0: Support C atomics in C++ <http://open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0943r0.html>.  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.

I am not providing concrete implementation yet, at first I want to know the opinion of the community on the matter.

Thanks,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180307/666af01c/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 7 Mar 2018 21:15:02 +0000
From: Shoaib Meenai via cfe-dev <[hidden email]>
To: Volodymyr Sapsai <[hidden email]>, Clang Dev
        <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h>
        explicitly incompatible
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

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.

From: cfe-dev <[hidden email]> on behalf of cfe-dev <[hidden email]>
Reply-To: Volodymyr Sapsai <[hidden email]>
Date: Wednesday, March 7, 2018 at 12:32 PM
To: cfe-dev <[hidden email]>
Subject: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

Hello all,

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

#include <stdatomic.h>
#include <atomic>

results in 68 errors.

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?

Alternative solution is to make these headers compatible. But the consensus seems to be that it’s not the right solution. See https://reviews.llvm.org/D26376<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=> for more details. There is also a proposal P0943R0: Support C atomics in C++<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=>.  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.

I am not providing concrete implementation yet, at first I want to know the opinion of the community on the matter.

Thanks,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180307/a2ab09a8/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


------------------------------

End of cfe-dev Digest, Vol 129, Issue 36
****************************************


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

Hans Wennborg via cfe-dev
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.

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++.

Thanks,
Volodymyr

On Mar 7, 2018, at 13:38, Jon Chesterfield via cfe-dev <[hidden email]> wrote:

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++.

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.

If this change goes ahead, would I no longer be able to use atomic types from a C header in C++?

Cheers!

Jon

On 7 Mar 2018 16:15, "via cfe-dev" <[hidden email]> wrote:
Send cfe-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cfe-dev digest..."


Today's Topics:

   1. [RFC] Make <atomic> and <stdatomic.h> explicitly  incompatible
      (Volodymyr Sapsai via cfe-dev)
   2. Re: [RFC] Make <atomic> and <stdatomic.h> explicitly
      incompatible (Shoaib Meenai via cfe-dev)


----------------------------------------------------------------------

Message: 1
Date: Wed, 07 Mar 2018 12:32:05 -0800
From: Volodymyr Sapsai via cfe-dev <[hidden email]>
To: Clang Dev <[hidden email]>
Subject: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h> explicitly
        incompatible
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hello all,

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

#include <stdatomic.h>
#include <atomic>

results in 68 errors.

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?

Alternative solution is to make these headers compatible. But the consensus seems to be that it’s not the right solution. See https://reviews.llvm.org/D26376 <https://reviews.llvm.org/D26376> for more details. There is also a proposal P0943R0: Support C atomics in C++ <http://open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0943r0.html>.  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.

I am not providing concrete implementation yet, at first I want to know the opinion of the community on the matter.

Thanks,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180307/666af01c/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 7 Mar 2018 21:15:02 +0000
From: Shoaib Meenai via cfe-dev <[hidden email]>
To: Volodymyr Sapsai <[hidden email]>, Clang Dev
        <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h>
        explicitly incompatible
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

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.

From: cfe-dev <[hidden email]> on behalf of cfe-dev <[hidden email]>
Reply-To: Volodymyr Sapsai <[hidden email]>
Date: Wednesday, March 7, 2018 at 12:32 PM
To: cfe-dev <[hidden email]>
Subject: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

Hello all,

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

#include <stdatomic.h>
#include <atomic>

results in 68 errors.

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?

Alternative solution is to make these headers compatible. But the consensus seems to be that it’s not the right solution. See https://reviews.llvm.org/D26376<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=> for more details. There is also a proposal P0943R0: Support C atomics in C++<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=>.  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.

I am not providing concrete implementation yet, at first I want to know the opinion of the community on the matter.

Thanks,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180307/a2ab09a8/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


------------------------------

End of cfe-dev Digest, Vol 129, Issue 36
****************************************

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

Hans Wennborg via cfe-dev
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.

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.

Cheers

On 7 Mar 2018 17:54, "Volodymyr Sapsai" <[hidden email]> wrote:
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.

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++.

Thanks,
Volodymyr


On Mar 7, 2018, at 13:38, Jon Chesterfield via cfe-dev <[hidden email]> wrote:

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++.

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.

If this change goes ahead, would I no longer be able to use atomic types from a C header in C++?

Cheers!

Jon

On 7 Mar 2018 16:15, "via cfe-dev" <[hidden email]> wrote:
Send cfe-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cfe-dev digest..."


Today's Topics:

   1. [RFC] Make <atomic> and <stdatomic.h> explicitly  incompatible
      (Volodymyr Sapsai via cfe-dev)
   2. Re: [RFC] Make <atomic> and <stdatomic.h> explicitly
      incompatible (Shoaib Meenai via cfe-dev)


----------------------------------------------------------------------

Message: 1
Date: Wed, 07 Mar 2018 12:32:05 -0800
From: Volodymyr Sapsai via cfe-dev <[hidden email]>
To: Clang Dev <[hidden email]>
Subject: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h> explicitly
        incompatible
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hello all,

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

#include <stdatomic.h>
#include <atomic>

results in 68 errors.

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?

Alternative solution is to make these headers compatible. But the consensus seems to be that it’s not the right solution. See https://reviews.llvm.org/D26376 <https://reviews.llvm.org/D26376> for more details. There is also a proposal P0943R0: Support C atomics in C++ <http://open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0943r0.html>.  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.

I am not providing concrete implementation yet, at first I want to know the opinion of the community on the matter.

Thanks,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180307/666af01c/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 7 Mar 2018 21:15:02 +0000
From: Shoaib Meenai via cfe-dev <[hidden email]>
To: Volodymyr Sapsai <[hidden email]>, Clang Dev
        <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h>
        explicitly incompatible
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

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.

From: cfe-dev <[hidden email]> on behalf of cfe-dev <[hidden email]>
Reply-To: Volodymyr Sapsai <[hidden email]>
Date: Wednesday, March 7, 2018 at 12:32 PM
To: cfe-dev <[hidden email]>
Subject: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

Hello all,

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

#include <stdatomic.h>
#include <atomic>

results in 68 errors.

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?

Alternative solution is to make these headers compatible. But the consensus seems to be that it’s not the right solution. See https://reviews.llvm.org/D26376<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=> for more details. There is also a proposal P0943R0: Support C atomics in C++<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=>.  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.

I am not providing concrete implementation yet, at first I want to know the opinion of the community on the matter.

Thanks,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180307/a2ab09a8/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


------------------------------

End of cfe-dev Digest, Vol 129, Issue 36
****************************************

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

Hans Wennborg via cfe-dev
+Marshall and Eric to get their thoughts from the perspective of libc++

On Mar 7, 2018, at 15:35, Jon Chesterfield <[hidden email]> wrote:

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.

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.

Cheers

On 7 Mar 2018 17:54, "Volodymyr Sapsai" <[hidden email]> wrote:
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.

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++.

Thanks,
Volodymyr


On Mar 7, 2018, at 13:38, Jon Chesterfield via cfe-dev <[hidden email]> wrote:

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++.

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.

If this change goes ahead, would I no longer be able to use atomic types from a C header in C++?

Cheers!

Jon

On 7 Mar 2018 16:15, "via cfe-dev" <[hidden email]> wrote:
Send cfe-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cfe-dev digest..."


Today's Topics:

   1. [RFC] Make <atomic> and <stdatomic.h> explicitly  incompatible
      (Volodymyr Sapsai via cfe-dev)
   2. Re: [RFC] Make <atomic> and <stdatomic.h> explicitly
      incompatible (Shoaib Meenai via cfe-dev)


----------------------------------------------------------------------

Message: 1
Date: Wed, 07 Mar 2018 12:32:05 -0800
From: Volodymyr Sapsai via cfe-dev <[hidden email]>
To: Clang Dev <[hidden email]>
Subject: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h> explicitly
        incompatible
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hello all,

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

#include <stdatomic.h>
#include <atomic>

results in 68 errors.

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?

Alternative solution is to make these headers compatible. But the consensus seems to be that it’s not the right solution. See https://reviews.llvm.org/D26376 <https://reviews.llvm.org/D26376> for more details. There is also a proposal P0943R0: Support C atomics in C++ <http://open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0943r0.html>.  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.

I am not providing concrete implementation yet, at first I want to know the opinion of the community on the matter.

Thanks,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180307/666af01c/attachment-0001.html>

------------------------------

Message: 2
Date: Wed, 7 Mar 2018 21:15:02 +0000
From: Shoaib Meenai via cfe-dev <[hidden email]>
To: Volodymyr Sapsai <[hidden email]>, Clang Dev
        <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h>
        explicitly incompatible
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

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.

From: cfe-dev <[hidden email]> on behalf of cfe-dev <[hidden email]>
Reply-To: Volodymyr Sapsai <[hidden email]>
Date: Wednesday, March 7, 2018 at 12:32 PM
To: cfe-dev <[hidden email]>
Subject: [cfe-dev] [RFC] Make <atomic> and <stdatomic.h> explicitly incompatible

Hello all,

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

#include <stdatomic.h>
#include <atomic>

results in 68 errors.

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?

Alternative solution is to make these headers compatible. But the consensus seems to be that it’s not the right solution. See https://reviews.llvm.org/D26376<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=> for more details. There is also a proposal P0943R0: Support C atomics in C++<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=>.  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.

I am not providing concrete implementation yet, at first I want to know the opinion of the community on the matter.

Thanks,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180307/a2ab09a8/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


------------------------------

End of cfe-dev Digest, Vol 129, Issue 36
****************************************

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev




_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev