Hi Richard,
> Please file a bugreport so this issue doesn't get lost.
I was struggling to reproduce it on a recent toolchain, but I managed to take
one of the gcc test cases and recreate it I think. I submitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117383
Thanks,
Anton
Hi,
I think gcc is relying on undefined behaviour with the vcompress instruction.
Unfortunately my test case isn't reproducing on mainline, but gcc looks to
use the fields between the last mask selected field and vl while setting
tail agnostic.
This thread explains how vcompress is different in t
Hi Joseph,
I hit the following problem when trying to build a ppc64 Linux kernel
from svn today:
# gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wmissing-prototypes
-Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep
scripts/basic/fixdep.c
cc1: error: unrecognized command line o
Hi David,
> My one other concern is developers using the builtins for applications on
> embedded PowerPC processors. lwsync will not order accesses to device
> memory space, AFAICT. I do not know if developers would rely on GCC builtins
> in that context and assume it implements the correct se
Hi Richard,
>> I noticed that sync_lock_release uses lwsync if available but every other
>> sync_* builtin uses a heavyweight sync. eg:
>
> Every other sync builtin has full-barrier semantics. AFAIK, isync is
> correct.
I think we can change the sync to an lwsync and still maintain full
barri
Hi,
I noticed that sync_lock_release uses lwsync if available but every other
sync_* builtin uses a heavyweight sync. eg:
0060 :
60: 7c 00 04 ac sync
64: 7c 69 1b 78 mr r9,r3
68: 7c 60 48 28 lwarx r3,0,r9
6c: 39 63 00 01 addir11,r3,1
70: 7d
Hi,
I was debugging some performance issues with an application that uses
the gcc builtin lock functions on powerpc. A simple test case:
long lock_try(long *value)
{
return __sync_lock_test_and_set(value, 1);
}
long unlock(long *value)
{
__sync_lock_release(value);
}
0010 :
