Bug 30514 - src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to `___sync_sub_and_fetch_4'
Summary: src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to `___sync_su...
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium blocker
Assignee: Tom Fogal
QA Contact:
Depends on:
Reported: 2010-09-30 13:35 UTC by Vinson Lee
Modified: 2014-11-22 03:13 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Vinson Lee 2010-09-30 13:35:42 UTC
mesa: 5f66b340aa49c6bc8d0acb2d1a6f8e9a7ef2cb2e (master)

$ scons platform=windows toolchain=crossmingw winsys=gdi dri=no
scons: Reading SConscript files ...
Checking for C header file udis86.h... (cached) no
warning: not building i915g
warning: not building i965g
warning: LLVM disabled: not building llvmpipe
scons: done reading SConscript files.
scons: Building targets ...
scons: building associated VariantDir targets: build/windows-x86-debug
  Linking build/windows-x86-debug/gallium/targets/graw-null/graw.dll ...
Creating library file: build/windows-x86-debug/gallium/targets/graw-null/libgraw.a
build/windows-x86-debug/gallium/drivers/softpipe/libsoftpipe.a(sp_context.o): In function `p_atomic_dec_zero':
src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to `___sync_sub_and_fetch_4'
build/windows-x86-debug/gallium/drivers/softpipe/libsoftpipe.a(sp_texture.o): In function `p_atomic_dec_zero':
src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to `___sync_sub_and_fetch_4'
build/windows-x86-debug/gallium/drivers/softpipe/libsoftpipe.a(sp_tex_tile_cache.o): In function `p_atomic_dec_zero':
src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to `___sync_sub_and_fetch_4'
build/windows-x86-debug/gallium/drivers/softpipe/libsoftpipe.a(sp_state_sampler.o): In function `p_atomic_dec_zero':
src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to `___sync_sub_and_fetch_4'
build/windows-x86-debug/gallium/drivers/softpipe/libsoftpipe.a(sp_state_shader.o): In function `p_atomic_dec_zero':
src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to `___sync_sub_and_fetch_4'
build/windows-x86-debug/gallium/drivers/softpipe/libsoftpipe.a(sp_state_surface.o):src/gallium/auxiliary/util/u_atomic.h:151: more undefined references to `___sync_sub_and_fetch_4' follow
collect2: ld returned 1 exit status
scons: *** [build/windows-x86-debug/gallium/targets/graw-null/graw.dll] Error 1
Comment 1 Vinson Lee 2010-09-30 13:40:05 UTC
5f66b340aa49c6bc8d0acb2d1a6f8e9a7ef2cb2e is the first bad commit
commit 5f66b340aa49c6bc8d0acb2d1a6f8e9a7ef2cb2e
Author: Tom Fogal <tfogal@alumni.unh.edu>
Date:   Sun Sep 26 22:32:15 2010 -0600

    Prefer intrinsics to handrolled atomic ops.

:040000 040000 c8bc6dbb4983010591b2a72bd240c62757b0d914 3ed91977308b9039c9db7c9e06561aa4003a1a86 M	src
bisect run success
Comment 2 Tom Fogal 2010-09-30 13:41:15 UTC
bugzilla-daemon@freedesktop.org writes:
> https://bugs.freedesktop.org/show_bug.cgi?id=30514
> mesa: 5f66b340aa49c6bc8d0acb2d1a6f8e9a7ef2cb2e (master)
> $ scons platform=windows toolchain=crossmingw winsys=gdi dri=no
> scons: Reading SConscript files ...
> src/gallium/auxiliary/util/u_atomic.h:151: undefined reference to
> `___sync_sub_and_fetch_4'

Ahh, cross gcc must not support atomics.

Not the best solution, but does the attached patch fix things?
Comment 3 Tom Fogal 2010-09-30 13:45:40 UTC
Heh, my patch didn't come through email for some reason, but it was just a revert of the bisect you found :)

I reverted it for now, since I need to run.  Longer term, I think we should
rely on intrinsics though, and somehow note when we've got a cross compiler
that doesn't support these builtins (autoconf test?)
Comment 4 Vinson Lee 2010-09-30 15:02:26 UTC
mesa: 113f1cdfcedf858e4b426ce2dba9e99d2a1e0286 (master)

Verified fixed. SCons MinGW build passes.
Comment 5 David Heidelberg (okias) 2014-10-19 12:00:51 UTC
As part of Nine patchset we also have this patch.

By reading [1] I think it may still cause problems, maybe we could add glibc check and leave original INTRINSIC at his place

--- a/src/gallium/auxiliary/util/u_atomic.h
+++ b/src/gallium/auxiliary/util/u_atomic.h
@@ -24,12 +24,12 @@
 #elif (defined(PIPE_CC_MSVC) && defined(PIPE_ARCH_X86))
 #define PIPE_ATOMIC_ASM_MSVC_X86                
+#elif (defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION >= 401) && defined( _GLIBCXX_ATOMIC_BUILTINS_4)
 #elif (defined(PIPE_CC_GCC) && defined(PIPE_ARCH_X86))
 #elif (defined(PIPE_CC_GCC) && defined(PIPE_ARCH_X86_64))
 #define PIPE_ATOMIC_ASM_GCC_X86_64
 #elif defined(PIPE_CC_GCC) && (PIPE_CC_GCC_VERSION >= 401)
 #error "Unsupported platform"

I'll send proper patch for testing at evening.

[1] https://gcc.gnu.org/onlinedocs/gcc-4.6.0/libstdc++/manual/manual/bk01pt03ch28s02.html
Comment 6 David Heidelberg (okias) 2014-10-19 16:33:47 UTC
patch is on ML [1]. Please retest and let me know, if it's for Windows builds OK :) Thank you

[1] http://lists.freedesktop.org/archives/mesa-dev/2014-October/069503.html
Comment 7 Tom Fogal 2014-10-20 08:38:36 UTC
What about, say, FreeBSD?  Can't it use Gallium?  Wouldn't this break it, then?

The page you linked to mentions the define _GLIBCXX_ATOMIC_BUILTINS_4 is available when the implementation supports these.  Maybe we should just key into that, instaed?  We could probably delete the check for gcc then, even.
Comment 8 David Heidelberg (okias) 2014-10-20 10:03:20 UTC
For _GLIBCXX_ATOMIC_BUILTINS_4 I tried to find it on my systems, did compile checks and it's nowhere to found (not sure if glibc dropped it or what)

About FreeBSD -> I left original line at end, so it'll work as before.
Comment 9 Matt Turner 2014-11-22 03:13:35 UTC
This didn't fail to compile because of cross compiling. I think this failed to compile because gcc defaulted to -march=i386, which doesn't have the necessary instructions to implement the __sync_* intrinsics.

I've resent a patch that prefers the intrinsics. -march=i386 is not a supported configuration.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.