This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][AArch64] Testcase fix for __ATOMIC_CONSUME
- From: Mike Stump <mikestump at comcast dot net>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Alex Velenko <Alex dot Velenko at arm dot com>, Marcus Shawcroft <marcus dot shawcroft at gmail dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Marcus Shawcroft <marcus dot shawcroft at arm dot com>
- Date: Thu, 12 Feb 2015 10:38:10 -0800
- Subject: Re: [PATCH][AArch64] Testcase fix for __ATOMIC_CONSUME
- Authentication-results: sourceware.org; auth=none
- References: <1422375847-18680-1-git-send-email-alex dot velenko at arm dot com> <A97E3995-549C-4A0B-B6A3-1207917FCC8F at comcast dot net> <CAFqB+PyB_qHHLmzzmx9QVsRkaS8JKYOzYwiZP2D0qxrXDa=uDw at mail dot gmail dot com> <58101C4C-374A-43E5-B255-C97CE3046A2C at comcast dot net> <54D8CE31 dot 6090503 at arm dot com> <5E4FFEE7-1846-4915-A613-DD8926252C12 at comcast dot net> <1423685805 dot 9778 dot 304 dot camel at triegel dot csb>
On Feb 11, 2015, at 12:16 PM, Torvald Riegel <triegel@redhat.com> wrote:
> On Mon, 2015-02-09 at 09:10 -0800, Mike Stump wrote:
>> On Feb 9, 2015, at 7:11 AM, Alex Velenko <Alex.Velenko@arm.com> wrote:
>>> The following patch makes atomic-op-consume.c XFAIL
>>>
>>> Is this patch ok?
>>
>> Ok.
>>
>> I’d shorten the comment above the xfail to be exceedingly short:
>>
>> /* PR59448 consume not implemented yet */
>>
>> The reason is the brain can process this about 8x faster. Also, one can cut and paste the PR part into a web browser directly, or, if you have an electric bugzilla mode for emacs, it will pop right up. */
>
> Given the discussions we had in ISO C++ SG1, it seems the only way to
> fix memory_order_consume is to deprecate it (or let it rot forever), and
> add something else to the standard. See
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4321.pdf
Nice paper, thanks.
> IOW, I believe the promotion is here to stay. I'm not aware of any
> other implementation doing something else.
>
> Thus, XFAIL doesn't seem right to me.
Since Jakub in PR64930 updated to the now expected output instead of xfail, and given the paper above, easy to agree with this. The changes to remove the xfail and expect the now expected codegen are pre-approved.