|
»
»
[ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
by Paolo Carlini-3
::
Rate this Message:
Matthias Klose wrote:
> ping on reapplying r147076 again to fix PR40133 Did somebody fully address Joseph' comments here http://gcc.gnu.org/ml/gcc/2009-05/msg00039.html ??? I don't think so. In other terms, I don't think the compiler now links the static libgcc, there is a serious target-independent part, isn't just about arm-linux... Paolo. |
|
|
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
by Matthias Klose-6
::
Rate this Message:
On 30.10.2009 01:28, Paolo Carlini wrote:
> Matthias Klose wrote: >> ping on reapplying r147076 again to fix PR40133 > Did somebody fully address Joseph' comments here > > http://gcc.gnu.org/ml/gcc/2009-05/msg00039.html > > ??? > > I don't think so. In other terms, I don't think the compiler now links > the static libgcc, there is a serious target-independent part, isn't > just about arm-linux... I checked that it does (at least on arm-linux-genueabi). IIUC the schema to do so implemented by Jakub and Alexandre can be extendend to targets that need to link with libgcc as well. Currently it is used for powerpc-linux and arm-linux-gnueabi (and linux-sh using it's own variant). I would have to look up hppa again. Matthias |
|
|
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
by Paolo Carlini-3
::
Rate this Message:
Matthias Klose wrote:
> I checked that it does (at least on arm-linux-genueabi). IIUC the > schema to do so implemented by Jakub and Alexandre can be extendend to > targets that need to link with libgcc as well. Currently it is used > for powerpc-linux and arm-linux-gnueabi (and linux-sh using it's own > variant). I would have to look up hppa again. Yes, my point is exactly that that kind of scheme ( http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00324.html, or equivalent) must be really adopted, fixing only arm-linux isn't enough. In other terms, 40134 still blocks 40133, and we cannot fix the latter until the former is really fully fixed for *all* the affected targets. By the way, that's why, sorry, I disregarded your ping in the first place, I was pretty sure it wasn't time yet... Paolo. |
|
|
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
by Matthias Klose-6
::
Rate this Message:
On 02.11.2009 17:28, Paolo Carlini wrote:
> Matthias Klose wrote: >> I checked that it does (at least on arm-linux-genueabi). IIUC the >> schema to do so implemented by Jakub and Alexandre can be extendend to >> targets that need to link with libgcc as well. Currently it is used >> for powerpc-linux and arm-linux-gnueabi (and linux-sh using it's own >> variant). I would have to look up hppa again. > Yes, my point is exactly that that kind of scheme ( > http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00324.html, or equivalent) > must be really adopted, fixing only arm-linux isn't enough. In http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00733.html I wrote that this scheme requires fixing libtool; I never got feedback from the libtool maintainers. In http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00592.html Jakub and Alexandre did "agree that the linker script for targets that need it is probably easier". > In other > terms, 40134 still blocks 40133, and we cannot fix the latter until the > former is really fully fixed for *all* the affected targets. By the way, > that's why, sorry, I disregarded your ping in the first place, I was > pretty sure it wasn't time yet... So it looks like 40134 is fixed at least for all *-linux targets (I accidentally dropped the patch for parisc, now testing again). How to proceed with this for linux targets? Matthias |
|
|
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
by Paolo Carlini-3
::
Rate this Message:
Matthias Klose wrote:
> In http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00733.html I wrote > that this scheme requires fixing libtool; I never got feedback from > the libtool maintainers. In > http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00592.html Jakub and > Alexandre did "agree that the linker script for targets that need it > is probably easier". I'm still not convinced that all the targets possibly affected have been dealt with. But, I don't consider myself knowledgeable enough in this area, I'd like to see some comments from, eg, Jakub and Joseph, before going ahead with the libstdc++ changes for 40133. >> In other >> terms, 40134 still blocks 40133, and we cannot fix the latter until the >> former is really fully fixed for *all* the affected targets. By the way, >> that's why, sorry, I disregarded your ping in the first place, I was >> pretty sure it wasn't time yet... > So it looks like 40134 is fixed at least for all *-linux targets (I > accidentally dropped the patch for parisc, now testing again). How to > proceed with this for linux targets? In your original message you mentioned sparc too. Is it now fine? Anyway, the configure changes I prepared for 40133 aren't linux-specific would run anywhere, as I said above I'd like to be reassured by Joseph and/or Jakub that such kind of test is now safe to use everywhere as far as the compiler proper bits are concerned. Paolo. |
|
|
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
by Ralf Wildenhues
::
Rate this Message:
* Matthias Klose wrote on Thu, Nov 12, 2009 at 07:18:47PM CET:
> On 02.11.2009 17:28, Paolo Carlini wrote: > >Matthias Klose wrote: > >>I checked that it does (at least on arm-linux-genueabi). IIUC the > >>schema to do so implemented by Jakub and Alexandre can be extendend to > >>targets that need to link with libgcc as well. Currently it is used > >>for powerpc-linux and arm-linux-gnueabi (and linux-sh using it's own > >>variant). I would have to look up hppa again. > >Yes, my point is exactly that that kind of scheme ( > >http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00324.html, or equivalent) > >must be really adopted, fixing only arm-linux isn't enough. > > In http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00733.html I wrote > that this scheme requires fixing libtool; I never got feedback from > the libtool maintainers. What would you suggest as the algorithm to fix it in libtool? Mind you, I've probably forgotten parts of this, so please bear with me: Should libtool always reorder -lgcc_s before -lgcc if it sees (or is to emit) both? On all systems? If not, on which? Which of the two should it reorder, and where, if the two do not occur successively? What if another library dependency drags in one but not the other, and we already have seen one or both? FWIW, I never saw a workable approach fixing libtool only, nor understood how libtool could be fixed consistently. Thanks, Ralf |
|
|
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
by Paolo Carlini-3
::
Rate this Message:
Ralf Wildenhues wrote:
> What would you suggest as the algorithm to fix it in libtool? > Mind you, I've probably forgotten parts of this, so please bear > with me: > > Should libtool always reorder -lgcc_s before -lgcc if it sees > (or is to emit) both? On all systems? If not, on which? > Which of the two should it reorder, and where, if the two do > not occur successively? What if another library dependency > drags in one but not the other, and we already have seen one > or both? > > FWIW, I never saw a workable approach fixing libtool only, > nor understood how libtool could be fixed consistently. > fine, you can as well hardcode in the library configure that knowledge and skip running the configure test for those. However, if you want to put in place the looser configure check, you must be 100% sure that it also works correctly on anything != linux, and that means, per Joseph' comments, making sure those generic compiler bits about linking the static libgcc are properly implemented. Either of those is fine with me. Paolo |
|
|
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
by Matthias Klose-6
::
Rate this Message:
On 12.11.2009 19:32, Paolo Carlini wrote:
> Matthias Klose wrote: >> In http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00733.html I wrote >> that this scheme requires fixing libtool; I never got feedback from >> the libtool maintainers. In >> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg00592.html Jakub and >> Alexandre did "agree that the linker script for targets that need it >> is probably easier". > I'm still not convinced that all the targets possibly affected have been > dealt with. I addressed linux targets having a Debian port is available. sh/sh4 should be fine as it did link with -lgcc_s -lgcc before. Didn't check m68k-linux. > But, I don't consider myself knowledgeable enough in this > area, I'd like to see some comments from, eg, Jakub and Joseph, before > going ahead with the libstdc++ changes for 40133. >>> In other >>> terms, 40134 still blocks 40133, and we cannot fix the latter until the >>> former is really fully fixed for *all* the affected targets. By the way, >>> that's why, sorry, I disregarded your ping in the first place, I was >>> pretty sure it wasn't time yet... >> So it looks like 40134 is fixed at least for all *-linux targets (I >> accidentally dropped the patch for parisc, now testing again). How to >> proceed with this for linux targets? > In your original message you mentioned sparc too. Is it now fine? no, sparc-linux was not affected, parisc was, which is now fixed on trunk. > Anyway, the configure changes I prepared for 40133 aren't linux-specific > would run anywhere, as I said above I'd like to be reassured by Joseph > and/or Jakub that such kind of test is now safe to use everywhere as far > as the compiler proper bits are concerned. would a patch acceptable to run these link tests on linux only? Matthias |
|
|
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
by Paolo Carlini-3
::
Rate this Message:
On 12/09/2009 11:42 AM, Matthias Klose wrote:
> would a patch acceptable to run these link tests on linux only? Sure. If you can cook up something (e.g, a version of the configure code I wrote at the time) running only where it's safe to run it (I think linux targets are all safe), fine with me! Paolo. |
|
|
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
by Matthias Klose-6
::
Rate this Message:
On 09.12.2009 11:50, Paolo Carlini wrote:
> On 12/09/2009 11:42 AM, Matthias Klose wrote: >> would a patch acceptable to run these link tests on linux only? > > Sure. If you can cook up something (e.g, a version of the configure code > I wrote at the time) running only where it's safe to run it (I think > linux targets are all safe), fine with me! the attached patch enables the link tests on linux, kfreebsd, and hurd targets. checked with the (Debian) kfreebsd and hurd maintainers that this is the right thing to do (although there doesn't exist an active port of these on arm or hppa. tested on i486-linux-gnu, arm-linux-gnueabi and hppa-linux-gnu. ok for the trunk? Matthias libstdc++-v3/ 2009-12-09 Paolo Carlini <paolo.carlini@...> Matthias Klose <doko@...> PR libstdc++/40133 * acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): On *-*-linux*, *-*-kfreebsd*-gnu | *-*-gnu* targets do link tests when possible. * configure: Regenerate. Index: libstdc++-v3/acinclude.m4 =================================================================== --- a/src/libstdc++-v3/acinclude.m4 (revision 155104) +++ b/src/libstdc++-v3/acinclude.m4 (working copy) @@ -2438,8 +2438,7 @@ dnl that are used should be checked. dnl dnl Note: -dnl libgomp and libgfortran do this with a link test, instead of an asm test. -dnl see: CHECK_SYNC_FETCH_AND_ADD +dnl libgomp and libgfortran use a link test, see CHECK_SYNC_FETCH_AND_ADD. dnl dnl Defines: dnl _GLIBCXX_ATOMIC_BUILTINS_1 @@ -2451,12 +2450,120 @@ AC_LANG_SAVE AC_LANG_CPLUSPLUS old_CXXFLAGS="$CXXFLAGS" - + + # Do link tests if possible, instead asm tests, limited to some platforms + atomic_builtins_link_tests=no + if test x$gcc_no_link != xyes; then + # Can do link tests. Limit to some tested platforms + case "$host" in + *-*-linux* | *-*-kfreebsd*-gnu | *-*-gnu*) + atomic_builtins_link_tests=yes + ;; + esac + fi + + if test x$atomic_builtins_link_tests = xyes; then + + # Do link tests. + + CXXFLAGS="$CXXFLAGS -fno-exceptions" + + AC_MSG_CHECKING([for atomic builtins for bool]) + AC_CACHE_VAL(glibcxx_cv_atomic_bool, [ + AC_TRY_LINK( + [ ], + [typedef bool atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(&c1, c2); + __sync_val_compare_and_swap(&c1, c3, c2); + __sync_lock_test_and_set(&c1, c3); + __sync_lock_release(&c1); + __sync_synchronize();], + [glibcxx_cv_atomic_bool=yes], + [glibcxx_cv_atomic_bool=no]) + ]) + if test $glibcxx_cv_atomic_bool = yes; then + AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1, + [Define if builtin atomic operations for bool are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_bool) + + AC_MSG_CHECKING([for atomic builtins for short]) + AC_CACHE_VAL(glibcxx_cv_atomic_short, [ + AC_TRY_LINK( + [ ], + [typedef short atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(&c1, c2); + __sync_val_compare_and_swap(&c1, c3, c2); + __sync_lock_test_and_set(&c1, c3); + __sync_lock_release(&c1); + __sync_synchronize();], + [glibcxx_cv_atomic_short=yes], + [glibcxx_cv_atomic_short=no]) + ]) + if test $glibcxx_cv_atomic_short = yes; then + AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1, + [Define if builtin atomic operations for short are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_short) + + AC_MSG_CHECKING([for atomic builtins for int]) + AC_CACHE_VAL(glibcxx_cv_atomic_int, [ + AC_TRY_LINK( + [ ], + [typedef int atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(&c1, c2); + __sync_val_compare_and_swap(&c1, c3, c2); + __sync_lock_test_and_set(&c1, c3); + __sync_lock_release(&c1); + __sync_synchronize();], + [glibcxx_cv_atomic_int=yes], + [glibcxx_cv_atomic_int=no]) + ]) + if test $glibcxx_cv_atomic_int = yes; then + AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1, + [Define if builtin atomic operations for int are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_int) + + AC_MSG_CHECKING([for atomic builtins for long long]) + AC_CACHE_VAL(glibcxx_cv_atomic_long_long, [ + AC_TRY_LINK( + [ ], + [typedef long long atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(&c1, c2); + __sync_val_compare_and_swap(&c1, c3, c2); + __sync_lock_test_and_set(&c1, c3); + __sync_lock_release(&c1); + __sync_synchronize();], + [glibcxx_cv_atomic_long_long=yes], + [glibcxx_cv_atomic_long_long=no]) + ]) + if test $glibcxx_cv_atomic_long_long = yes; then + AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1, + [Define if builtin atomic operations for long long are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_long_long) + + else + + # Do asm tests. + # Compile unoptimized. CXXFLAGS='-O0 -S' - # Fake what AC_TRY_COMPILE does, without linking as this is - # unnecessary for a builtins test. + # Fake what AC_TRY_COMPILE does. cat > conftest.$ac_ext << EOF [#]line __oline__ "configure" @@ -2478,14 +2585,14 @@ AC_MSG_CHECKING([for atomic builtins for bool]) if AC_TRY_EVAL(ac_compile); then if grep __sync_ conftest.s >/dev/null 2>&1 ; then - enable_atomic_builtinsb=no + glibcxx_cv_atomic_bool=no else AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1, [Define if builtin atomic operations for bool are supported on this host.]) - enable_atomic_builtinsb=yes + glibcxx_cv_atomic_bool=yes fi fi - AC_MSG_RESULT($enable_atomic_builtinsb) + AC_MSG_RESULT($glibcxx_cv_atomic_bool) rm -f conftest* cat > conftest.$ac_ext << EOF @@ -2508,14 +2615,14 @@ AC_MSG_CHECKING([for atomic builtins for short]) if AC_TRY_EVAL(ac_compile); then if grep __sync_ conftest.s >/dev/null 2>&1 ; then - enable_atomic_builtinss=no + glibcxx_cv_atomic_short=no else AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1, [Define if builtin atomic operations for short are supported on this host.]) - enable_atomic_builtinss=yes + glibcxx_cv_atomic_short=yes fi fi - AC_MSG_RESULT($enable_atomic_builtinss) + AC_MSG_RESULT($glibcxx_cv_atomic_short) rm -f conftest* cat > conftest.$ac_ext << EOF @@ -2539,14 +2646,14 @@ AC_MSG_CHECKING([for atomic builtins for int]) if AC_TRY_EVAL(ac_compile); then if grep __sync_ conftest.s >/dev/null 2>&1 ; then - enable_atomic_builtinsi=no + glibcxx_cv_atomic_int=no else AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1, [Define if builtin atomic operations for int are supported on this host.]) - enable_atomic_builtinsi=yes + glibcxx_cv_atomic_int=yes fi fi - AC_MSG_RESULT($enable_atomic_builtinsi) + AC_MSG_RESULT($glibcxx_cv_atomic_int) rm -f conftest* cat > conftest.$ac_ext << EOF @@ -2569,22 +2676,23 @@ AC_MSG_CHECKING([for atomic builtins for long long]) if AC_TRY_EVAL(ac_compile); then if grep __sync_ conftest.s >/dev/null 2>&1 ; then - enable_atomic_builtinsll=no + glibcxx_cv_atomic_long_long=no else AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1, [Define if builtin atomic operations for long long are supported on this host.]) - enable_atomic_builtinsll=yes + glibcxx_cv_atomic_long_long=yes fi fi - AC_MSG_RESULT($enable_atomic_builtinsll) + AC_MSG_RESULT($glibcxx_cv_atomic_long_long) rm -f conftest* + fi CXXFLAGS="$old_CXXFLAGS" AC_LANG_RESTORE # Set atomicity_dir to builtins if either of above tests pass. - if test $enable_atomic_builtinsi = yes || test $enable_atomic_builtinsb = yes ; then + if test $glibcxx_cv_atomic_int = yes || test $glibcxx_cv_atomic_bool = yes ; then atomicity_dir=cpu/generic/atomicity_builtins fi |
|
|
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
by Paolo Carlini-3
::
Rate this Message:
On 12/11/2009 05:19 AM, Matthias Klose wrote:
> the attached patch enables the link tests on linux, kfreebsd, and hurd > targets. checked with the (Debian) kfreebsd and hurd maintainers that > this is the right thing to do (although there doesn't exist an active > port of these on arm or hppa. tested on i486-linux-gnu, > arm-linux-gnueabi and hppa-linux-gnu. ok for the trunk? First, thanks Matthias for your patience on this issue. The patch looks very nice to me, just wait one day or so for comments and then go ahead, patch is approved for mainline. If you want, I would suggest adding a one-line comment in the code, say, after " # Do link tests if possible, instead asm tests, limited to some platforms", mentioning the PRs, these thorny issues about libgcc... Thanks again, Paolo. |
|
|
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
by Joseph S. Myers
::
Rate this Message:
On Fri, 11 Dec 2009, Matthias Klose wrote:
> On 09.12.2009 11:50, Paolo Carlini wrote: > > On 12/09/2009 11:42 AM, Matthias Klose wrote: > > > would a patch acceptable to run these link tests on linux only? > > > > Sure. If you can cook up something (e.g, a version of the configure code > > I wrote at the time) running only where it's safe to run it (I think > > linux targets are all safe), fine with me! > > the attached patch enables the link tests on linux, kfreebsd, and hurd > targets. checked with the (Debian) kfreebsd and hurd maintainers that this is Link tests are also safe for libstdc++ to use for uclinux targets. -- Joseph S. Myers joseph@... |
|
|
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
by Matthias Klose-6
::
Rate this Message:
On 11.12.2009 10:57, Paolo Carlini wrote:
> On 12/11/2009 05:19 AM, Matthias Klose wrote: >> the attached patch enables the link tests on linux, kfreebsd, and hurd >> targets. checked with the (Debian) kfreebsd and hurd maintainers that >> this is the right thing to do (although there doesn't exist an active >> port of these on arm or hppa. tested on i486-linux-gnu, >> arm-linux-gnueabi and hppa-linux-gnu. ok for the trunk? > First, thanks Matthias for your patience on this issue. > > The patch looks very nice to me, just wait one day or so for comments > and then go ahead, patch is approved for mainline. > > If you want, I would suggest adding a one-line comment in the code, say, > after " # Do link tests if possible, instead asm tests, limited to some > platforms", mentioning the PRs, these thorny issues about libgcc... committed to trunk. Matthias libstdc++-v3/ 2009-12-11 Paolo Carlini <paolo.carlini@...> Matthias Klose <doko@...> PR libstdc++/40133 * acinclude.m4 ([GLIBCXX_ENABLE_ATOMIC_BUILTINS]): On *-*-linux*, *-*-uclinux*, *-*-kfreebsd*-gnu | *-*-gnu* targets do link tests when possible. * configure: Regenerate. Index: libstdc++-v3/acinclude.m4 =================================================================== --- libstdc++-v3/acinclude.m4 (revision 155196) +++ libstdc++-v3/acinclude.m4 (working copy) @@ -2438,8 +2438,7 @@ dnl that are used should be checked. dnl dnl Note: -dnl libgomp and libgfortran do this with a link test, instead of an asm test. -dnl see: CHECK_SYNC_FETCH_AND_ADD +dnl libgomp and libgfortran use a link test, see CHECK_SYNC_FETCH_AND_ADD. dnl dnl Defines: dnl _GLIBCXX_ATOMIC_BUILTINS_1 @@ -2451,12 +2450,122 @@ AC_LANG_SAVE AC_LANG_CPLUSPLUS old_CXXFLAGS="$CXXFLAGS" - + + # Do link tests if possible, instead asm tests, limited to some platforms + # see discussion in PR target/40134, PR libstdc++/40133 and the thread + # starting at http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00322.html + atomic_builtins_link_tests=no + if test x$gcc_no_link != xyes; then + # Can do link tests. Limit to some tested platforms + case "$host" in + *-*-linux* | *-*-uclinux* | *-*-kfreebsd*-gnu | *-*-gnu*) + atomic_builtins_link_tests=yes + ;; + esac + fi + + if test x$atomic_builtins_link_tests = xyes; then + + # Do link tests. + + CXXFLAGS="$CXXFLAGS -fno-exceptions" + + AC_MSG_CHECKING([for atomic builtins for bool]) + AC_CACHE_VAL(glibcxx_cv_atomic_bool, [ + AC_TRY_LINK( + [ ], + [typedef bool atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(&c1, c2); + __sync_val_compare_and_swap(&c1, c3, c2); + __sync_lock_test_and_set(&c1, c3); + __sync_lock_release(&c1); + __sync_synchronize();], + [glibcxx_cv_atomic_bool=yes], + [glibcxx_cv_atomic_bool=no]) + ]) + if test $glibcxx_cv_atomic_bool = yes; then + AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1, + [Define if builtin atomic operations for bool are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_bool) + + AC_MSG_CHECKING([for atomic builtins for short]) + AC_CACHE_VAL(glibcxx_cv_atomic_short, [ + AC_TRY_LINK( + [ ], + [typedef short atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(&c1, c2); + __sync_val_compare_and_swap(&c1, c3, c2); + __sync_lock_test_and_set(&c1, c3); + __sync_lock_release(&c1); + __sync_synchronize();], + [glibcxx_cv_atomic_short=yes], + [glibcxx_cv_atomic_short=no]) + ]) + if test $glibcxx_cv_atomic_short = yes; then + AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1, + [Define if builtin atomic operations for short are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_short) + + AC_MSG_CHECKING([for atomic builtins for int]) + AC_CACHE_VAL(glibcxx_cv_atomic_int, [ + AC_TRY_LINK( + [ ], + [typedef int atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(&c1, c2); + __sync_val_compare_and_swap(&c1, c3, c2); + __sync_lock_test_and_set(&c1, c3); + __sync_lock_release(&c1); + __sync_synchronize();], + [glibcxx_cv_atomic_int=yes], + [glibcxx_cv_atomic_int=no]) + ]) + if test $glibcxx_cv_atomic_int = yes; then + AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1, + [Define if builtin atomic operations for int are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_int) + + AC_MSG_CHECKING([for atomic builtins for long long]) + AC_CACHE_VAL(glibcxx_cv_atomic_long_long, [ + AC_TRY_LINK( + [ ], + [typedef long long atomic_type; + atomic_type c1; + atomic_type c2; + const atomic_type c3(0); + __sync_fetch_and_add(&c1, c2); + __sync_val_compare_and_swap(&c1, c3, c2); + __sync_lock_test_and_set(&c1, c3); + __sync_lock_release(&c1); + __sync_synchronize();], + [glibcxx_cv_atomic_long_long=yes], + [glibcxx_cv_atomic_long_long=no]) + ]) + if test $glibcxx_cv_atomic_long_long = yes; then + AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1, + [Define if builtin atomic operations for long long are supported on this host.]) + fi + AC_MSG_RESULT($glibcxx_cv_atomic_long_long) + + else + + # Do asm tests. + # Compile unoptimized. CXXFLAGS='-O0 -S' - # Fake what AC_TRY_COMPILE does, without linking as this is - # unnecessary for a builtins test. + # Fake what AC_TRY_COMPILE does. cat > conftest.$ac_ext << EOF [#]line __oline__ "configure" @@ -2478,14 +2587,14 @@ AC_MSG_CHECKING([for atomic builtins for bool]) if AC_TRY_EVAL(ac_compile); then if grep __sync_ conftest.s >/dev/null 2>&1 ; then - enable_atomic_builtinsb=no + glibcxx_cv_atomic_bool=no else AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_1, 1, [Define if builtin atomic operations for bool are supported on this host.]) - enable_atomic_builtinsb=yes + glibcxx_cv_atomic_bool=yes fi fi - AC_MSG_RESULT($enable_atomic_builtinsb) + AC_MSG_RESULT($glibcxx_cv_atomic_bool) rm -f conftest* cat > conftest.$ac_ext << EOF @@ -2508,14 +2617,14 @@ AC_MSG_CHECKING([for atomic builtins for short]) if AC_TRY_EVAL(ac_compile); then if grep __sync_ conftest.s >/dev/null 2>&1 ; then - enable_atomic_builtinss=no + glibcxx_cv_atomic_short=no else AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_2, 1, [Define if builtin atomic operations for short are supported on this host.]) - enable_atomic_builtinss=yes + glibcxx_cv_atomic_short=yes fi fi - AC_MSG_RESULT($enable_atomic_builtinss) + AC_MSG_RESULT($glibcxx_cv_atomic_short) rm -f conftest* cat > conftest.$ac_ext << EOF @@ -2539,14 +2648,14 @@ AC_MSG_CHECKING([for atomic builtins for int]) if AC_TRY_EVAL(ac_compile); then if grep __sync_ conftest.s >/dev/null 2>&1 ; then - enable_atomic_builtinsi=no + glibcxx_cv_atomic_int=no else AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_4, 1, [Define if builtin atomic operations for int are supported on this host.]) - enable_atomic_builtinsi=yes + glibcxx_cv_atomic_int=yes fi fi - AC_MSG_RESULT($enable_atomic_builtinsi) + AC_MSG_RESULT($glibcxx_cv_atomic_int) rm -f conftest* cat > conftest.$ac_ext << EOF @@ -2569,22 +2678,23 @@ AC_MSG_CHECKING([for atomic builtins for long long]) if AC_TRY_EVAL(ac_compile); then if grep __sync_ conftest.s >/dev/null 2>&1 ; then - enable_atomic_builtinsll=no + glibcxx_cv_atomic_long_long=no else AC_DEFINE(_GLIBCXX_ATOMIC_BUILTINS_8, 1, [Define if builtin atomic operations for long long are supported on this host.]) - enable_atomic_builtinsll=yes + glibcxx_cv_atomic_long_long=yes fi fi - AC_MSG_RESULT($enable_atomic_builtinsll) + AC_MSG_RESULT($glibcxx_cv_atomic_long_long) rm -f conftest* + fi CXXFLAGS="$old_CXXFLAGS" AC_LANG_RESTORE # Set atomicity_dir to builtins if either of above tests pass. - if test $enable_atomic_builtinsi = yes || test $enable_atomic_builtinsb = yes ; then + if test $glibcxx_cv_atomic_int = yes || test $glibcxx_cv_atomic_bool = yes ; then atomicity_dir=cpu/generic/atomicity_builtins fi |
| Free embeddable forum powered by Nabble | Forum Help |
