This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][optabs.c] Fix PR 61713: ICE when expanding single-threaded version of atomic_test_and_set
- From: Jeff Law <law at redhat dot com>
- To: Kyrill Tkachov <kyrylo dot tkachov at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 04 Aug 2014 11:34:02 -0600
- Subject: Re: [PATCH][optabs.c] Fix PR 61713: ICE when expanding single-threaded version of atomic_test_and_set
- Authentication-results: sourceware.org; auth=none
- References: <53C66253 dot 7030006 at arm dot com> <53CF77F5 dot 4090904 at arm dot com> <53D2D4C1 dot 4050705 at redhat dot com> <53DFBAD6 dot 7070008 at arm dot com>
On 08/04/14 10:54, Kyrill Tkachov wrote:
On 25/07/14 23:05, Jeff Law wrote:
On 07/23/14 02:53, Kyrill Tkachov wrote:
Darn, had forgotten to attach the patch...
On 16/07/14 12:30, Kyrill Tkachov wrote:
This fixes the PR mentioned in the subject. When expanding
atomic_test_and_set we try the corresponding sync optabs and if none
exist, like for pre-SMP ARM architectures (-march=armv6 and earlier)
code in optabs.c reverts to a single-threaded implementation that just
does a load and store.
However, if the result of the operation is to be ignored the code in
builtins.c follows the convention that the target RTX is set to
const0_rtx to signify that the result is ignored and the expand
functions in optabs.c are supposed to check for that and act
The code in the single-threaded codepath in expand_atomic_test_and_set
in optabs.c didn't perform this check and instead tried to emit a move
to a const0_rtx which ICEs further down the line.
This patch fixes that by checking if the result is ignored, and if
omits the load.
I wouldn't dare to remove the load in normal atomic handling code
all the memory ordering subtleties, but this code path occurs only when
we have a trivially single-threaded bare-metal target and the compiler
assumes no races anyway and no dodgy context switches and tries to
implement this with a ldrb+strb, so I think removing the ldrb is valid.
Bootstrapped on arm, aarch64 and x86 and tested as well.
Ok for trunk?
This appears on 4.9 as well, I'll test it on that branch as well
2014-07-16 Kyrylo Tkachov <email@example.com>
* gcc/optabs.c (expand_atomic_test_and_set): Do not try to emit
move to subtarget in serial version if result is ignored.
Is this ok for the 4.9 branch as well if testing comes back ok? (It
applies cleanly there.)