#75 2.2.3 Build fails on Linux x86_64

[Anonymous]

Hi!
Iv' tryed to build Pixie on Fedora 7/8/9
But the compilation of 2.2.3 fails on x86_64 (went fine on x86 at least).
See: http://koji.fedoraproject.org/koji/getfile?taskID=274762&name=build.log
The previous version 2.2.2 built fine...

Iv' tryed with --enable-openexr-threads or without: same assembler message...

Any advices ?
Should we expect some 64bit regression with this release ? (as there is a note on the DEVNOTES about 64bit compatibilities)...

[LuisB]

Logged In: YES
user_id=1072678
Originator: NO

Hi
I've had the same problem, also on x86-64, the weird thing is that lwarx, etc... aren't x86-64 opcodes, they're ppc opcodes, perhaps some borked #ifdef in some source file w/inline asm? Some configuration problem?
I'm on the same boat as you, waiting for a fix :)

[Nobody/Anonymous]

Logged In: NO

Hi,

i copied the i386 part in src/ri/atomic.h and changed i386 to x86_64. Pixie compiles, but I am not a coder and so I cannot say anything about possible runtime problems.

///////////////////////////////////////////////////////////////
// GCC (i386)
#elif defined(__i386__) && defined(__GNUC__)

inline int atomicIncrement(volatile int *ptr) {

unsigned char ret;

asm volatile("lock\n"

"incl %0\n"

"setne %1"

"=m" (*ptr), "=qm" (ret)

"m" (*ptr)

"memory");
return ret;
}

inline int atomicDecrement(volatile int *ptr) {

unsigned char ret;

asm volatile("lock\n"

"decl %0\n"

"setne %1"

"=m" (*ptr), "=qm" (ret)

"m" (*ptr)

"memory");
return ret;
}

///////////////////////////////////////////////////////////////
// GCC (x86_64) changed by me
#elif defined(__x86_64) && defined(__GNUC__)

inline int atomicIncrement(volatile int *ptr) {

unsigned char ret;

asm volatile("lock\n"

"incl %0\n"

"setne %1"

"=m" (*ptr), "=qm" (ret)

"m" (*ptr)

"memory");
return ret;
}

inline int atomicDecrement(volatile int *ptr) {

unsigned char ret;

asm volatile("lock\n"

"decl %0\n"

"setne %1"

"=m" (*ptr), "=qm" (ret)

"m" (*ptr)

"memory");
return ret;
}

Regards
Konrad Naumann

[Aasimon]

Logged In: YES
user_id=1642849
Originator: NO

This has been fixed from rev 1144