search for: thownl

.... It's fine if you guys don't want to change it. It may never be a problem with gcc. This is the definition of pthread_mutex_lock() in glibc. There aren't any magic hints that this invalidates memory: extern int pthread_mutex_lock (pthread_mutex_t *__mutex) __THROWNL __nonnull ((1)); THOWNL is attribute((nothrow)). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/nouveau/attachments/20150225/1d46e029/attachment.html>

...to change > it. It may never be a problem with gcc. > > This is the definition of pthread_mutex_lock() in glibc. There aren't any > magic hints that this invalidates memory: > > extern int pthread_mutex_lock (pthread_mutex_t *__mutex) > __THROWNL __nonnull ((1)); > > THOWNL is attribute((nothrow)). Hm, this is actually a little worrying. Maarten, thoughts? I would have assumed there'd be a __attribute__((some_magic_thing)) in there. -ilia

...be a problem with gcc. >> >> This is the definition of pthread_mutex_lock() in glibc. There aren't any >> magic hints that this invalidates memory: >> >> extern int pthread_mutex_lock (pthread_mutex_t *__mutex) >> __THROWNL __nonnull ((1)); >> >> THOWNL is attribute((nothrow)). > > Hm, this is actually a little worrying. Maarten, thoughts? I would > have assumed there'd be a __attribute__((some_magic_thing)) in there. In general things don't get optimized across function calls, except in case of inlinable functions. And for comp...

So you're saying a compiler can optimize: > > - statement with memory access > - read memory barrier > - statement with memory access > > To drop the second statement? I would worry about your definition of > memory barrier then.. > This is tricky, but I think you're mixing up the general case with the actual code you have. In general, you are pointing to this