similar to: [LLVMdev] Is it correct to access non-atomic variables using atomic operations?

On Sat, Aug 4, 2012 at 12:11 AM, Lei Zhao <leizhao833 at gmail.com> wrote: > Hi Everyone, > > This might be more a C/C++11 question than a LLVM question: I wondering if it is semantically correct to access an ordinary variable via atomic operations, like: > > int val; > void foo(){ atomic_store((atomic_int *)(&val), 42); } > > I tried this simple program on

It works. But a follow-up question: why do I have to compile it to thumb mode in order to pass the compilation? Is there a way to make it compile to regular arm mode? Thanks. - Lei On Aug 16, 2012, at 4:00 PM, Eli Friedman wrote: > On Thu, Aug 16, 2012 at 12:55 PM, Lei Zhao <leizhao833 at gmail.com> wrote: >> Hi Everybody, >> >> I recently did a cross-compiling

Hi All, I am reading about LLVM IR atomics (http://llvm.org/docs/Atomics.html) and get confused about the difference between "Unordered" and "Monotonic". In particular, I am not sure I understand the statement of "It essentially guarantees that if you take all the operations affecting a specific address, a consistent ordering exists.". For me, it means that for the

Hi Everybody, I recently did a cross-compiling using clang (built with host=x86, target=arm) with the following command: > clang -march=armv7-a -mfloat-abi=soft -ccc-host-triple arm-none-linux-gnueabi -integrated-as main.c -o main.o -c and get error message: ------------------------------------------------------- main.c:9:9: error: instruction requires: thumb2 "ldrex

Sure. Use legal ARM mode syntax for the instruction. Specifically, there is no offset immediate for the ARM mode LDREX instruction. It's illegal syntax to supply one, even if it's zero. -Jim On Aug 16, 2012, at 2:36 PM, Lei Zhao <leizhao833 at gmail.com> wrote: > It works. But a follow-up question: why do I have to compile it to thumb mode in order to pass the compilation? Is

On Thu, Aug 16, 2012 at 12:55 PM, Lei Zhao <leizhao833 at gmail.com> wrote: > Hi Everybody, > > I recently did a cross-compiling using clang (built with host=x86, target=arm) with the following command: > > > clang -march=armv7-a -mfloat-abi=soft -ccc-host-triple arm-none-linux-gnueabi -integrated-as main.c -o main.o -c > > and get error message: > >

On 26 April 2010 15:59, Jeffrey Yasskin <jyasskin at google.com> wrote: > To be clear, Chandler wasn't suggesting any change to the existing > load and store instructions. Instead, we were wondering if people like > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > atomic_exchange and atomic_add instructions. I see, in that case, I don't have any

On 12/11/2015 01:29 PM, James Y Knight wrote: > > On Fri, Dec 11, 2015 at 3:05 PM, Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> One open question I don't know the answer to: Are there any >> special semantics required from floating point stores which >> aren't met

Hi, Our target only has native support for i32 and f32 types. For data types smaller than these, I have to custom lowering truncating store using two atomic load instruction (which have the same semantics as ISD::ATOMIC_LOAD_AND and ATOMIC_LOAD_OR, respectively). I run into a problem during the legalization process, where the legalizer complains that ISD::STORE and ISD::ATOMIC_LOAD_OR (generated

Hi Lei, Le 31/05/2012 03:44, Lei Mou a écrit : > Problem solved by returning the second result of the ATOMIC_LOAD_OR node... You got the chain instead of the loaded value. IMHO, a better solution would have been to add a Pat<> rule to match truncstores and expand them into target store/load/and/or. Pat : <(truncstore16 GPR:$val, MEM:$mem), (store MEM:$mem, (or

Problem solved by returning the second result of the ATOMIC_LOAD_OR node... On Wed, May 30, 2012 at 9:38 PM, Lei Mou <lei.mou.uu at gmail.com> wrote: > Hi, > > Our target only has native support for i32 and f32 types. For data > types smaller than these, I have to custom lowering truncating store > using two atomic load instruction (which have the same semantics as >

On Mon, Apr 26, 2010 at 3:14 AM, Renato Golin <rengolin at systemcall.org> wrote: > On 26 April 2010 10:49, Chandler Carruth <chandlerc at google.com> wrote: >> Certainly for languages such as Java, they will make up a surprisingly large >> chunk of the loads and stores, and instructions have much mor flexibility in >> terms of syntax. On the flip side, it's a

On Monday 26 April 2010 10:19:06 Renato Golin wrote: > On 26 April 2010 15:59, Jeffrey Yasskin <jyasskin at google.com> wrote: > > To be clear, Chandler wasn't suggesting any change to the existing > > load and store instructions. Instead, we were wondering if people like > > the idea of _new_ atomic_load, atomic_store, atomic_cmpxchg, and maybe > >

I don't have much of substance to add, but I will say that I like the proposal (I too prefer Alternative A). When adding C11 atomic support for hexagon, I found it surprising that support for the __sync_* was implemented completely differently than the C11 atomics. On 1/27/2016 1:55 PM, James Knight via llvm-dev wrote: > Right now, the atomics implementation in clang is a bit of a

Same problem exists, thread A can still be within REAL(call_once), but after it ran user code and set the flag to ~0. Roughly, call_once does: __call_once(flag, arg, func) { mutex_lock(mut); if (flag == BEING_INITIALIZED) { wait } else if (flag == NOT_INITIALIZED_AT_ALL) { flag = BEING_INITIALIZED; mutex_unlock(mut); func(arg); // <=== user code callback

Right now, the atomics implementation in clang is a bit of a mess. It has three basically completely distinct code-paths: There's the legacy __sync_* builtins, which clang lowers directly to atomic IR instructions. Then, the llvm atomic IR instructions themselves can sometimes emit libcalls to __sync_* library functions (which are basically undocumented, and users are often responsible for

Dan Gohman <dan433584 at gmail.com> writes: > But I don't understand why defining this as not being a data race > would complicate things. I'm assuming the mask values are > statically known. Can you explain a bit more? > > It's an interesting question for autovectorization, for example. > > Thread A: > for (i=0;i<n;++i) > if (i&1)

On Thu, May 9, 2013 at 6:04 PM, <dag at cray.com> wrote: > Dan Gohman <dan433584 at gmail.com> writes: > > > But I don't understand why defining this as not being a data race > > would complicate things. I'm assuming the mask values are > > statically known. Can you explain a bit more? > > > > It's an interesting question

Hi there, I have a question on fitting data by coxme. In particular I want to fit a random intercept and random slope cox model. Using the rats dataset as an example, I generated another covariate x2 and want to specify a random slope for x2. Here is my code: x2=matrix(rep(runif(50), 3), 50, 3) x2=as.vector(t(x2)) rats2=cbind(rats, x2) But when I used the coxme function as follows, it gave

Time stamps are correct and my system time is correct. I am now tried to use Sys.setFileTime() to update time stamps as proposed. This does not help. The windows and debian builds give different reports on the time stamp issue. https://win-builder.r-project.org/incoming_pretest/eurostat_3.2.8_20180920_122655/Windows/00check.log