On Wed, 27 Aug 2008, Paolo Carlini wrote: > Hi, > > One significant case is where atomic operations are available with kernel > > help. SH GNU/Linux provides __sync_* in libgcc and there is an unreviewed > > patch to do the same for ARM GNU/Linux; both use kernel help in those > > implementations, and more targets may do this in future. (It's been > > proposed for HPPA. The ColdFire NPTL specification doesn't include > > exporting such helpers from libgcc but they could easily be exported from > > libc; the use of a vDSO may make exporting from libgcc harder.) The > > GLIBCXX_ENABLE_ATOMIC_BUILTINS configure test looks like it's incorrect for > > such cases, because it greps for __sync in a .s file and these targets will > > have such __sync_* references resolved in libgcc. So on GNU/Linux that > > configure test ought to be a link test. > > > For this issue, do you think it would be Ok to the change the current > open-coded test to the usual GCC_TRY_COMPILE_OR_LINK pattern?
The test will always compile, but sometimes the result will have references to the __sync_* functions in the output. Then, for certain targets where these functions are defined in a library, the result will link. (The only targets where these are defined in a library are targets where we can assume link tests are OK.) So a normal compile-or-link isn't what we want here; it's "link if you can do link tests, but otherwise check the .s file" or "link for *-*-linux* *-*-uclinux*, but otherwise check the .s file". -- Joseph S. Myers [EMAIL PROTECTED]
