[MIPS] Use nacl_atomic_is_lock_free instead of c11_atomic_is_lock_free

[MIPS] Use nacl_atomic_is_lock_free instead of c11_atomic_is_lock_free

Use nacl_atomic_is_lock_free instead of c11_atomic_is_lock_free, as MIPS
does not have (yet) implementations of these c11 functions for 64-bit types.

BUG= https://code.google.com/p/nativeclient/issues/detail?id=4205
R=dschuff@chromium.org

Committed: https://gerrit.chromium.org/gerrit/gitweb?p=native_client/pnacl-libcxx.git;a=commit;h=c627a310c8986c42c828adab52f3826fceba802e

[petarj, 2015-08-11 17:55:36]

petarj@mips.com changed reviewers:
+ dschuff@chromium.org

[petarj, 2015-08-11 17:55:59]

PTAL.

[Derek Schuff, 2015-08-11 18:47:44]

On 2015/08/11 17:55:59, petarj wrote:
> PTAL.

I don't really see why this is necessary? i.e. "translation time" in the context
of nacl-clang is the same as compile time. I guess you actually just want to use
the logic of nacl_atomic_is_lock_free instead of c11_atomic_is_lock_free? does
c11_atomic_is_lock_free not work?

[petarj, 2015-08-11 19:10:18]

On 2015/08/11 18:47:44, Derek Schuff wrote:
> On 2015/08/11 17:55:59, petarj wrote:
> > PTAL.
> 
> I don't really see why this is necessary? i.e. "translation time" in the
context
> of nacl-clang is the same as compile time. 

True, wording may have not been perfect in this case.

> I guess you actually just want to use
> the logic of nacl_atomic_is_lock_free instead of c11_atomic_is_lock_free?

Yes.

> does
> c11_atomic_is_lock_free not work?

It will not work for 64-bit values for which a library call (to functions
that do not exist) will be generated and that will fail at link time.

[Derek Schuff, 2015-08-11 21:58:39]

On 2015/08/11 19:10:18, petarj wrote:
> On 2015/08/11 18:47:44, Derek Schuff wrote:
> > On 2015/08/11 17:55:59, petarj wrote:
> > > PTAL.
> > 
> > I don't really see why this is necessary? i.e. "translation time" in the
> context
> > of nacl-clang is the same as compile time. 
> 
> True, wording may have not been perfect in this case.
> 
> > I guess you actually just want to use
> > the logic of nacl_atomic_is_lock_free instead of c11_atomic_is_lock_free?
> 
> Yes.
> 
> > does
> > c11_atomic_is_lock_free not work?
> 
> It will not work for 64-bit values for which a library call (to functions
> that do not exist) will be generated and that will fail at link time.

ah... so we have the nacl-specific atomic functions already, and you want to use
those instead of the C11 ones.

I guess this is ok. it would probably be better to eventually implement the C11
library calls (would those go into libc? or compiler-rt?) and use those instead.
Making the toolchain less pnacl-flavored and more native-flavored is still
better where possible (and it does seem like it would be possible in this case?)

LGTM

[Derek Schuff, 2015-08-11 21:59:11]

oh, also please fix the wording of the CL description to be more clear about
what this is actually for.

[petarj, 2015-08-11 22:04:02]

On 2015/08/11 21:58:39, Derek Schuff wrote:
> On 2015/08/11 19:10:18, petarj wrote:
> > On 2015/08/11 18:47:44, Derek Schuff wrote:
> I guess this is ok. it would probably be better to eventually implement the
C11
> library calls (would those go into libc? or compiler-rt?) and use those
instead.

I agree, this is a separate LLVM issue and not related to Native Client. Once
that
gets resolved in a separate track, we can revert this.

> Making the toolchain less pnacl-flavored and more native-flavored is still
> better where possible (and it does seem like it would be possible in this
case?)

Yes, I agree.

[petarj, 2015-08-11 22:16:01]

Committed patchset #1 (id:1) manually as
c627a310c8986c42c828adab52f3826fceba802e (presubmit successful).