On 11/07/2014 04:31 AM, Andrew Haley wrote:
On 06/11/14 19:05, Andrew MacLeod wrote:
1) Given that the compiler *always* provides support via libatomic now
(even if it is via locks), does that mean that VMSupportsCS8_builtin()
should always return true?
or should we map to that a call to __ato
On 06/11/14 19:05, Andrew MacLeod wrote:
>
>
> 1) Given that the compiler *always* provides support via libatomic now
> (even if it is via locks), does that mean that VMSupportsCS8_builtin()
> should always return true?
>
> or should we map to that a call to __atomic_always_lock_free() ? (that
On 11/06/2014 01:23 PM, Andrew Haley wrote:
On 11/06/2014 05:57 PM, Andrew MacLeod wrote:
It looks like java is deciding whether or not GCC can inline atomic
operations or not, and if it can't, doesn't want the atomic
operations... which presumably means there is no dependency on
libatomic at
On 11/06/2014 05:57 PM, Andrew MacLeod wrote:
> It looks like java is deciding whether or not GCC can inline atomic
> operations or not, and if it can't, doesn't want the atomic
> operations... which presumably means there is no dependency on
> libatomic at runtime.
>
> A call to can_compare_
On 11/04/2014 03:13 PM, Andrew MacLeod wrote:
>from targhooks.c:
bool
default_builtin_support_vector_misalignment (machine_mode mode,
const_tree type, <...>)
{
if (optab_handler (movmisalign_optab, mode) != CODE_FOR_nothing)
return true;
return false;
}
the idea is to move all the
On 11/04/2014 02:53 PM, Richard Biener wrote:
On November 4, 2014 7:30:18 PM CET, Andrew MacLeod wrote:
On 11/04/2014 12:57 PM, Richard Henderson wrote:
On 11/04/2014 06:56 PM, Andrew MacLeod wrote:
On 11/04/2014 12:25 PM, Richard Henderson wrote:
On 11/04/2014 05:28 PM, Andrew MacLeod wrote
On November 4, 2014 7:30:18 PM CET, Andrew MacLeod wrote:
>On 11/04/2014 12:57 PM, Richard Henderson wrote:
>> On 11/04/2014 06:56 PM, Andrew MacLeod wrote:
>>> On 11/04/2014 12:25 PM, Richard Henderson wrote:
On 11/04/2014 05:28 PM, Andrew MacLeod wrote:
> + bool
> + default_can_comp
On 11/04/2014 12:57 PM, Richard Henderson wrote:
On 11/04/2014 06:56 PM, Andrew MacLeod wrote:
On 11/04/2014 12:25 PM, Richard Henderson wrote:
On 11/04/2014 05:28 PM, Andrew MacLeod wrote:
+ bool
+ default_can_compare_and_swap_p (machine_mode mode, bool allow_libcall)
+ {
+ return can_compa
On 11/04/2014 06:56 PM, Andrew MacLeod wrote:
> On 11/04/2014 12:25 PM, Richard Henderson wrote:
>> On 11/04/2014 05:28 PM, Andrew MacLeod wrote:
>>> + bool
>>> + default_can_compare_and_swap_p (machine_mode mode, bool allow_libcall)
>>> + {
>>> + return can_compare_and_swap_p (mode, allow_libcal
On 11/04/2014 12:25 PM, Richard Henderson wrote:
On 11/04/2014 05:28 PM, Andrew MacLeod wrote:
+ bool
+ default_can_compare_and_swap_p (machine_mode mode, bool allow_libcall)
+ {
+ return can_compare_and_swap_p (mode, allow_libcall);
+ }
This is silly. I think the problem you point out can b
On 11/04/2014 05:28 PM, Andrew MacLeod wrote:
> + bool
> + default_can_compare_and_swap_p (machine_mode mode, bool allow_libcall)
> + {
> + return can_compare_and_swap_p (mode, allow_libcall);
> + }
This is silly. I think the problem you point out can be better fixed by moving
the can_compare_
java/builtins.c needs to call can_compare_and_swap, which happens to be
provided via optabs.h.
As a result, we see the following in java/builtins.c:
/* FIXME: All these headers are necessary for sync_compare_and_swap.
Front ends should never have to look at that. */
#include "rtl.h"
#include
12 matches
Mail list logo
