weird clang++ error

[Ben Goodrich]

Doing test-unit with clang++ (only), I immediately get

clang++ -I src -I lib/eigen_3.1.2 -I lib/boost_1.53.0 -Wall -DBOOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -Wno-unused-function -Wno-uninitialized   -c -O3 -DGTEST_HAS_PTHREAD=0 -I lib/gtest_1.6.0/include -I lib/gtest_1.6.0 lib/gtest_1.6.0/src/gtest-all.cc -o test/gtest.o
In file included from lib/gtest_1.6.0/src/gtest-all.cc:42:
In file included from lib/gtest_1.6.0/src/gtest.cc:132:
lib/gtest_1.6.0/src/gtest-internal-inl.h:206:8: warning: private field 'pretty_' is not used [-Wunused-private-field]
  bool pretty_;
       ^
fatal error: error in backend: Cannot select: 0x508a070: i64 = fabs 0x5074840 [ORD=532] [ID=31]
  0x5074840: i64 = zero_extend 0x5074940 [ID=30]
    0x5074940: i8 = X86ISD::SETCC 0x5089970, 0x541b400:1 [ID=28]
      0x5089970: i8 = Constant<9> [ID=15]
      0x541b400: i64,i32 = X86ISD::SUB 0x541b000, 0x5074b40 [ID=26]
        0x541b000: i64 = add 0x541b200, 0x5363500 [ORD=528] [ID=24]
          0x541b200: i64,ch = load 0x541b100, 0x5363700, 0x541a800<LD8[%149](tbaa=!"any pointer")> [ORD=527] [ID=22]
            0x5363700: i64 = FrameIndex<7> [ORD=522] [ID=1]
            0x541a800: i64 = undef [ORD=526] [ID=7]
          0x5363500: i64 = Constant<-24> [ORD=528] [ID=10]
        0x5074b40: i64 = X86ISD::Wrapper 0x5089670 [ID=19]
          0x5089670: i64 = TargetGlobalAddress<[0 x i64]* @_ZNSs4_Rep20_S_empty_rep_storageE> 0 [ID=16]
In function: _ZN7testing8UnitTest17AddTestPartResultENS_14TestPartResult4TypeEPKciRKNS_8internal6StringES8_
make: *** [test/gtest.o] Error 1

Is anyone else seeing this?

Ben

[Bob Carpenter]

clang++ still works OK on our macs. But it could
easily work differently under linux. I believe what
is happening is that some of the old c lib functions
get automatically brought into global scope on some
platforms. We're not explicitly qualifying them so as
to use argument-dependent lookup where we need to for
our auto-diff vars.

We just need to add explicit using statements in the
scopes where fabs gets used (NOT namespace scope -- restrict
as locally as possible within a function).

We only tracked this down because of the weird behavior we were
getting from lgamma at one point.

- Bob

> --
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Ben Goodrich]

On Friday, March 29, 2013 2:51:49 PM UTC-4, Bob Carpenter wrote:

clang++ still works OK on our macs.  But it could
easily work differently under linux.  I believe what
is happening is that some of the old c lib functions
get automatically brought into global scope on some
platforms.  We're not explicitly qualifying them so as
to use argument-dependent lookup where we need to for
our auto-diff vars.

That might be part of the story, but I also found a similar Debian bugreport for clang 3.2 that seems to be triggered when someone upgrades to g++-4.8 and libc 2.17 (and thus changes some of the underlying libraries). Also, the error message refers to a string

In function: _ZN7testing8UnitTest17AddTestPartResultENS_14TestPartResult4TypeEPKciRKNS_8internal6StringES8_

so I don't know how fabs would get involved. Anyway, the problem probably has more to do with my setup than with Stan.

Ben

[Jiqiang Guo]

Just to report that I do not have this problem for clang 3.0 (I do not know to upgrade to 3.2 on linux easily):

$ clang -v

Debian clang version 3.0-6.1 (tags/RELEASE_30/final) (based on LLVM 3.0)

Target: x86_64-pc-linux-gnu

Thread model: posix

In addition, that long function's real names is:

$ c++filt _ZN7testing8UnitTest17AddTestPartResultENS_14TestPartResult4TypeEPKciRKNS_8internal6StringES8_

testing::UnitTest::AddTestPartResult(testing::TestPartResult::Type, char const*, int, testing::internal::String const&, testing::internal::String const&)