Re: Issue 301 in memcached: link fails for GCC atomic functions

[dormando]

If someone else wants to make them work, go for it.

I've already spent too much time making it work on old platforms with
outdated and increasingly rare architectures :/ The fallback isn't so
terrible and making everything portable is painful.

On Tue, 18 Dec 2012, David Walter wrote:

> I thought there are linux kernel headers with inline assembler for that. 
>
> They seemed to work in tests on 32 bit platforms.
>
> Admittedly these aren't the gcc __sync* family but would they work?
>
> http://www.takatan.net/lxr/source/include/asm-i386/atomic.h?v=2.4.21-47.EL
>
>
>
> On Tue, Dec 18, 2012 at 3:01 PM,  wrote:
>
>   Comment #3 on issue 301 by dorma...@rydia.net: link fails for GCC 
> atomic functions
>   http://code.google.com/p/memcached/issues/detail?id=301
>
>   Take a look through the configure script, it's supposed to actually 
> test and use the atomic call, and fail back if it fails.
>
>   The problem is that 32bit x86 doesn't have 16bit atomics, so they have 
> to be detected and disabled. Except some versions of GCC (the one
>   you have) claims to have them anyway, and it'll fail at runtime. 32bit 
> is stuck with the mutex, but given how much memory you're limited
>   to, I doubt you'd ever notice the performance drop. It just won't be 
> hugely faster than .11.
>
>   I have no idea why setting march=i686 makes it work right, and I don't 
> have your OS to test on :/ Since that's all pretty old legacy
>   stuff, we might have to insist you compile with your workaround.
>
>   I'd consider a patch to the autocrap if it doesn't degrade any of our 
> supported platforms.
>
>
>
>

Re: Issue 301 in memcached: link fails for GCC atomic functions

[David Walter]

I thought there are linux kernel headers with inline assembler for that.

They seemed to work in tests on 32 bit platforms.

Admittedly these aren't the gcc __sync* family but would they work?

http://www.takatan.net/lxr/source/include/asm-i386/atomic.h?v=2.4.21-47.EL



On Tue, Dec 18, 2012 at 3:01 PM,  wrote:

>
> Comment #3 on issue 301 by dorma...@rydia.net: link fails for GCC atomic
> functions
> http://code.google.com/p/**memcached/issues/detail?id=301
>
> Take a look through the configure script, it's supposed to actually test
> and use the atomic call, and fail back if it fails.
>
> The problem is that 32bit x86 doesn't have 16bit atomics, so they have to
> be detected and disabled. Except some versions of GCC (the one you have)
> claims to have them anyway, and it'll fail at runtime. 32bit is stuck with
> the mutex, but given how much memory you're limited to, I doubt you'd ever
> notice the performance drop. It just won't be hugely faster than .11.
>
> I have no idea why setting march=i686 makes it work right, and I don't
> have your OS to test on :/ Since that's all pretty old legacy stuff, we
> might have to insist you compile with your workaround.
>
> I'd consider a patch to the autocrap if it doesn't degrade any of our
> supported platforms.
>
>

Re: Issue 301 in memcached: link fails for GCC atomic functions

[memcached]

Comment #5 on issue 301 by dorma...@rydia.net: link fails for GCC atomic  
functions

http://code.google.com/p/memcached/issues/detail?id=301

maybe? It's going to be a pretty rare issue, and you filing this bug  
actually helps the google-ability of the problem quite a lot. I was also  
pretty sure it was fixed last time it was reported, and has stayed fixed on  
32bit centos instances with the affected GCC versions.


Also this is the first time it's been reported as fixable by setting  
march=i686 :P That didn't work when I'd originally fixed the bug.


So it's all novel, at this point. I'll leave this open until someone  
reviews if there's a good place to leave a note (or if it's fixable).

Re: Issue 301 in memcached: link fails for GCC atomic functions

[memcached]

Comment #4 on issue 301 by mirkp...@gmail.com: link fails for GCC atomic  
functions

http://code.google.com/p/memcached/issues/detail?id=301

I'm happy to continue using the workaround of setting -march=i686, I just  
wanted to log this in case it was a bigger problem.  I poked around the  
configure code before logging this ticket but didn't work on it long enough  
to figure out why the test was passing.


Although maybe it would be nice to have mention of this in the README or  
somewhere in regards to building memcached?  I had to hunt around google  
for a while to figure out how to get the build to work, and if it is safe  
to use -march=i686 on 64bit x86 with 32bit Linux to get the atomics, then  
maybe a "If you get this error on 64bit x86, try -march=i686" note?

Re: Issue 301 in memcached: link fails for GCC atomic functions

[memcached]

Comment #3 on issue 301 by dorma...@rydia.net: link fails for GCC atomic  
functions

http://code.google.com/p/memcached/issues/detail?id=301

Take a look through the configure script, it's supposed to actually test  
and use the atomic call, and fail back if it fails.


The problem is that 32bit x86 doesn't have 16bit atomics, so they have to  
be detected and disabled. Except some versions of GCC (the one you have)  
claims to have them anyway, and it'll fail at runtime. 32bit is stuck with  
the mutex, but given how much memory you're limited to, I doubt you'd ever  
notice the performance drop. It just won't be hugely faster than .11.


I have no idea why setting march=i686 makes it work right, and I don't have  
your OS to test on :/ Since that's all pretty old legacy stuff, we might  
have to insist you compile with your workaround.


I'd consider a patch to the autocrap if it doesn't degrade any of our  
supported platforms.

Re: Issue 301 in memcached: link fails for GCC atomic functions

[memcached]

Comment #2 on issue 301 by mirkp...@gmail.com: link fails for GCC atomic  
functions

http://code.google.com/p/memcached/issues/detail?id=301

The Linux distro I'm using is Crux 2.5, very unknown and at this point 2.5  
is well out of date.  We largely use it as a base and then roll our own  
software upgrades on top of it, but we haven't updated libc or gcc.  We're  
using 32-bit on Intel Xeon processors.


Since the atomic calls work with -march=i686, should the configure script  
figure out if it should be using that or whatever appropriate march type  
anyways?


Are the atomic calls significantly better than the mutex?

Re: Issue 301 in memcached: link fails for GCC atomic functions

[memcached]

Comment #1 on issue 301 by dorma...@rydia.net: link fails for GCC atomic  
functions

http://code.google.com/p/memcached/issues/detail?id=301

what OS/distro is this? 32bit or 64bit?

was pretty sure I'd gotten the configure tests to actually *test* the  
atomic call and fall back to the mutex if it breaks. It works under all of  
the OS's I test under at least. what's yours, exactly?

Issue 301 in memcached: link fails for GCC atomic functions

[memcached]

Status: New
Owner: 
Labels: Type-Defect Priority-Medium

New issue 301 by mirkp...@gmail.com: link fails for GCC atomic functions
http://code.google.com/p/memcached/issues/detail?id=301

What steps will reproduce the problem?
1. configure && make

What is the expected output? What do you see instead?
Error:
gcc -std=gnu99  -g -O2 -pthread -pthread -Wall -Werror -pedantic  
-Wmissing-prototypes -Wmissing-declarations -Wredundant-decls   -o  
memcached memcached-memcached.o memcached-hash.o memcached-slabs.o  
memcached-items.o memcached-assoc.o memcached-thread.o memcached-daemon.o  
memcached-stats.o memcached-util.o memcached-cache.o-levent -lrt

memcached-thread.o: In function `refcount_decr':
/root/adam/cache/memcached-1.4.15/thread.c:102: undefined reference to  
`__sync_sub_and_fetch_2'

memcached-thread.o: In function `refcount_incr':
/root/adam/cache/memcached-1.4.15/thread.c:87: undefined reference to  
`__sync_add_and_fetch_2'


What version of the product are you using? On what operating system?
memcached 1.4.15 or 1.4.14
libc 2.8
gcc 4.3.3
Linux 2.6.39.3

Please provide any additional information below.
This was resolved by adding -march=i686 to CFLAGS when running "configure".