CBLAS in sun performance library coming with solaris studio 12.2
Hello,
In sunperf library coming with sun studio 12u1 (linux x86) I can use cblas callings using the standard names cblas_xxxx. This interface do not appears in sunperf.h (you can use standard cblas.h) but the objects are in libsunperf.(a|so).
But in solaris studio 12.2 libsunperf cblas_xxxx objects do not exists. Is this normal? Contains libsunperf a standard c blas interface?
Thanks
Hello again,
In this blog post
http://www.mlds-networks.com/index.php/component/option,com_mojo/Itemid,29/p,35/
is explained how to link the ACML (AMD core math library) in order to use the standard CBLAS interface (ACML do not provides a standard CBLAS). I tried it and all runs OK. I did the same for the sun performance library in solstudio 12.2 and the compilation proccess runs ok, but in the testing step all functions fails becaude an incorrect argument in each function.
Exists any way for use the standard CBLAS interface with sun performance library? As I noted in my previous post, version 12.1 of sunstudio libsunperf contains the standard CBLAS interface, but I would like to use version 12.2
Thanks
Similar Messages
-
Sun Performance library or just a tuned BLAS for Solaris x86?
Hi,
I know the sun performance library is not available on Solaris x86, but is
there at least a tuned blas library available?
thanks,
timThe compilation line you list is correct. One way to see if there are outstanding unsatisfied references is to use the ldd command on the shared library that you created:
% CC -dalign -xarch=v9a -G -o LA.so $(OBJECTS) -library=sunperf -staticlib=sunperf
% ldd LA.so
I assume that one or more of the .o files in the $(OBJECTS) list makes calls to Perflib routines. Does your application (the code that is linking to the LA.so shared library) also make calls to Perflib routines? If so, these will not have been satisfied in the previous creation of the LA.so shared library. -
Unable to link to sun performance library
I am using SS12 with nevada build 70. When trying to link to sun performance library routine from F90 code, I am getting errors. See the code and output below,
PROGRAM DeepWell
USE SUNPERF
IMPLICIT NONE
INTEGER, PARAMETER :: N=5 ! No. of nucleons in consideration
INTEGER :: i,j,k,ios
DOUBLE PRECISION,DIMENSION(N,N) :: S,H
DOUBLE PRECISION,DIMENSION(N) :: eig
DOUBLE PRECISION :: tmp
DO i=1,N
DO j=i,N
k = i+j
IF (MOD(k,2) == 0) THEN
S(i,j) = 2.0/(k+5.0) - 4.0/(k+3.0) + 2.0/(k+1.0)
H(i,j) = 8*(k+2.0*i*j-1)/(k+3.0)/(k+1.0)/(k-1.0)
ELSE
S(i,j) = 0.0
H(i,j) = 0.0
ENDIF
ENDDO
ENDDO
call sygy(1,'V','U','N',H,B=S,W=eig)
END PROGRAM DeepWell
Output:
Running "/usr/bin/dmake -f Makefile CONF=Release" in /export/home/mbkumar/Thissjen/C3/This_C3_P1_VC
dmake: defaulting to parallel mode.
See the man page dmake(1) for more information on setting up the .dmakerc file.
bharat1 --> 1 job
/usr/bin/dmake -f nbproject/Makefile-Release.mk SUBPROJECTS= .build-conf
bharat1 --> 1 job
mkdir -p build/Release/Sun12-Solaris-x86
f90 -xtarget=opteron -m64 -dalign -xlic_lib=sunperf -c -O3 -w1 -o build/Release/Sun12-Solaris-x86/VC.o VC.f90
bharat1 --> Job output
mkdir -p build/Release/Sun12-Solaris-x86
f90 -xtarget=opteron -m64 -dalign -xlic_lib=sunperf -c -O3 -w1 -o build/Release/Sun12-Solaris-x86/VC.o VC.f90
(/export/home/mbkumar/Thissjen/C3/This_C3_P1_VC)VC.f90:
call ssygy(1,'V','U','N',H,B=S,W=eig)
^
"VC.f90", Line = 41, Column = 30: ERROR: An actual argument keyword is being used when an explicit interface is not known.
^
"VC.f90", Line = 41, Column = 34: ERROR: An actual argument keyword is being used when an explicit interface is not known.
f90comp: 44 SOURCE LINES
f90comp: 2 ERRORS, 0 WARNINGS, 0 OTHER MESSAGES, 0 ANSI
:(/export/home/mbkumar/Thissjen/C3/This_C3_P1_VC)VC.f90
*** Error code 1
dmake: Fatal error: Command failed for target `build/Release/Sun12-Solaris-x86/VC.o'
Current working directory /export/home/mbkumar/Thissjen/C3/This_C3_P1_VC
*** Error code 1
dmake: Fatal error: Command failed for target `.build-impl'
Build failed. Exit value 1.please ignore the above question. I called non-existing routine.
-
Sun Performance Library and OpenMP applications
Hi list,
I have a code that uses BLAS/Lapack libraries. This code requires the BLAS/Lapack to run in serial mode. If and when it runs in parallel this is a disaster. The code runs in parallel with OpenMP directives in SMP systems. I specify the number of threads by setting
OMP_NUM_THREADS
to the number of threads desired. Unfortunately if OMP_NUM_THREADS > 1 then sunperf runs in parallel as well. Is there anyway to tell to the sunperf library to run in serial mode no matter what the value of OMP_NUM_THREADS is?
For example GOTO BLAS library provides the environmental variable GOTO_NUM_THREADS which is dedicated to the threads of the GOTO library. So by setting GOTO_NUM_THREADS = 1, the library always runs in serial mode no matter what the value of OMP_NUM_THREADS is.
How could I achieve the same effect with Sun Performance Library?Take a look at Perflib's USE_THREADS routine :
man -s 3p use_threads
Doing a call to USE_THREADS with the value of "1", before calling Perflib routines may work for you.
Also, I've noticed applications that have lots of small chunks of parallel work, need the threads to be very responsive. (And not sleep in between work chunks)
A way to make the threads not sleep is with the ${SUNW_MP_THR_IDLE} environment variable. I always set the value to "SPIN" :
% setenv SUNW_MP_THR_IDLE SPIN
You can see other settings for this in the OpenMP User's Guide, page 18 :
http://docs.sun.com/app/docs/doc/819-5270
Hope this helps. -
FLTBOUNDS coredump, relative to sun performance library
Hi,
I got an core dump, the "truss" log is:
27346: lwp_kill(1209, SIG#0) Err#3 ESRCH
27346: lwp_create(0xFFBEF088, LWP_SUSPENDED, 0xFFBEF084) = 1210
27346: lwp_create() (returning as new lwp ...) = 0
27346: lwp_continue(1210) = 0
27346: lwp_schedctl(SC_STATE|SC_PREEMPT, 0, 0xFDEFBDA4) = 0
27346: sigprocmask(SIG_SETMASK, 0xFF35819C, 0x00000000) = 0
27346: lwp_exit()
27346: lwp_wait(1210, 0xFFBEF24C) = 0
27346: lwp_wait(1210, 0xFFBEF24C) Err#3 ESRCH
27346: lwp_kill(1210, SIG#0) Err#3 ESRCH
27346: lwp_create(0xFFBEF088, LWP_SUSPENDED, 0xFFBEF084) = 1211
27346: lwp_create() (returning as new lwp ...) = 0
27346: lwp_continue(1211) = 0
27346: lwp_schedctl(SC_STATE|SC_PREEMPT, 0, 0xFDEFBDA4) = 0
27346: Incurred fault #6, FLTBOUNDS %pc = 0xFEF7756C
27346: siginfo: SIGSEGV SEGV_MAPERR addr=0xFF194000
27346: Received signal #11, SIGSEGV [default]
27346: siginfo: SIGSEGV SEGV_MAPERR addr=0xFF194000
27346: *** process killed ***
I used "/mnts/cdstools/SunCC-7.0.5/solaris-sparc-2.8/bin/CC test.C -xlic_l=sunperf -g -mt -lthread -R/usr/lib/lwp/" to compile.
I suspect there is a bug in dgemm(one function from Sun Performance Library), since if I comment it out, anything become ok.
Any one have similar problem?
Thanks.
ljgCan you post a testcase of your code so I can try to replicate the problem?
Also, what is is your per-thread stack size set to? A large (4MB) stacksize is required if libsunperf is called from a user created thread.
See the following for more info if it is indeed a stacksize issue..
http://docs.sun.com/source/816-2463/plug_optimizing.html#pgfId-19550
-Moazam -
Extremely slow math execution with Solaris Studio 12.3 Fortran
I have a large Fortran program that I ran on a variety of problems. One case ran extremely slowly compared to all of the others (many hours versus a few minutes) and I managed to boil the problem down to the following program. For some reason, the line "y = (cos(x)**2+sin(x)**2)**1.5" takes several thousand times as long to execute when x is 1.278d-06 as when it is 1.279d-06.
program math_bug
call sub(1.279d-06)
call sub(1.278d-06)
contains
subroutine sub(x)
real(kind=8),intent(in)::x
integer ::i
real(kind=8)::t(2)
real(kind=8)::y
call cpu_time(t(1))
do i=1,10000
y = (cos(x)**2+sin(x)**2)**1.5
enddo
call cpu_time(t(2))
write(*,*) "Time: ",t(2)-t(1)
end subroutine sub
end program math_bug
Output:
Time: 3.1380653381347656E-3
Time: 13.27063798904419
I'm running Solaris Studio 12.3 on Red Hat Enterprise Linux Client release 5.11 (Tikanga) and compiled with no special flags -- simply f95 math_bug.f95 -o math_bug.
Can someone please look into this?
Thanks very much,
MikeThat's a bug in the 64-bit Linux libm library. The default compilation for Studio on Linux is -m64. With that default, you get:
ldd a.out | grep libm.so
libm.so.6 => /lib64/libm.so.6 (0x0000003fd4600000)
a.out
Time: 1.8830299377441406E-3
Time: 12.055269956588745
However, if you compile with -m32 to create a 32-bit executable (and 32-bit libm), you get:
ldd a.out | grep libm.so
libm.so.6 => /lib/libm.so.6 (0x008b6000)
[chvu@scapen-ssol5-0 misc]$ a.out
Time: 2.3509999737143516E-3
Time: 2.397000091150403E-3
Therefore, if your app does not require 64-bit address space then you might work around the problem with the -m32 option.
Since, the Linux libm is not produced and shipped by us, there's nothing that we can do about this. This has to be addressed by the Linux community. If this test it turned into a simple C program then I guess you can reproduce the problem with any C compilers. Fortran is high-level language so some Fortran vendors might choose to ship their own math supporting libraries with the compilers and that makes it harder to compare. -
Solaris 6 Library Compatibility with Solaris 7 Application?
I have a library (code/objects) that is compiled in 2.6 and I need to make an application (on Solaris 2.7) that inter-works with this library. According to SUN's statement, 2.6 and 2.7 are binary compatible. Will my 2.7 application work properly with my 2.6 library on my 2.7 SUN?
Thanks.we have ported our product to solaris 5.7 from solaris5.6. With this version we are unable to install the product on solaris 5.6. It is unable to find the following libraries in 5.6, while installing and finally it is failing.
libMrm.so.4
libXm.so.4
libgen.so.3
Is there any way to make my product work on both versions of solaris? -
Hi All,
i have very simple and short query, Is Sun Directory comes bundled with Solaris 10 ? or we need to download explicitely.
If we download that is a free version or we need to procure.
Thanks
AvninderHi Avninder,
No it does not come with Solaris 10, nor Solaris 10 current license gives you entitlement with support for it.
Please go and download from www.sun.com/dsee
Etienne -
Compiler Error after Upgrading Sun Studio 12 to Solaris Studio 12.3
This code compiled with Solaris Studio CC: Sun C++ 5.9 SunOS_sparc Patch 124863-02 2007/12/18
but fails to compile under CC: Sun C++ 5.12 SunOS_sparc Patch 148506-14 2013/09/24
CC -features=zla -mt -g -library=Cstd -DACE_HAS_KSTAT -DACE_HAS_CUSTOM_EXPORT_MACROS=0 -D_POSIX_PTHREAD_SEMANTICS -I/export/home/ttp/ACE_wrappers -DACE_HAS_SCTP -DACE_HAS_LKSCTP -D__ACE_INLINE__ -I../jpeg-6b -I../tiff-v3.5.7/libtiff/ -I../tags/ -I/RogueWave/SourcePro/12.5 -D_XPG4_2 -D__EXTENSIONS__ -D_RWCONFIG_15d -DRW_MULTI_THREAD -D_REENTRANT -DTTPVERSIONKEY=\"7.00-alpha-2013/11/15\" -DRW_USER_TRACE_LEVEL=5 -c -KPIC -o .shobj/julian.o julian.cc
Error Message: "/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/traits", line 538: Error: The function "wcsstr" must have a prototype
If I add the -H to trace the headers this is what I get below. I have been fighting with this for a week now and really don't know what to do at this point. We use the RogueWave libraries with the Solaris Studio Compiler for more additional libraries but RogueWave says our version is compatible with Solaris Studio 12.3 and in fact we successfully compiled the RogueWave libraries with this compiler. I"m sure it something in our code but I can't quite figure it out.
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2013.11.15 17:45:03 =~=~=~=~=~=~=~=~=~=~=~=
gmake -f GNUmakefile.TTPLib
GNUmakefile: /export/home/ttp/ttproot/ttp/TTPLib/GNUmakefile.TTPLib MAKEFLAGS=
CC -features=zla -H -mt -g -library=Cstd -DACE_HAS_KSTAT -DACE_HAS_CUSTOM_EXPORT_MACROS=0 -D_POSIX_PTHREAD_SEMANTICS -I/export/home/ttp/ACE_wrappers -DACE_HAS_SCTP -DACE_HAS_LKSCTP -D__ACE_INLINE__ -I../jpeg-6b -I../tiff-v3.5.7/libtiff/ -I../tags/ -I/RogueWave/SourcePro/12.5 -D_XPG4_2 -D__EXTENSIONS__ -D_RWCONFIG_15d -DRW_MULTI_THREAD -D_REENTRANT -DTTPVERSIONKEY=\"7.00-alpha-2013/11/15\" -DRW_USER_TRACE_LEVEL=5 -c -KPIC -o .shobj/julian.o julian.cc
julian.h
/usr/include/time.h
/usr/include/sys/feature_tests.h
/usr/include/sys/ccompile.h
/usr/include/sys/isa_defs.h
/usr/include/iso/time_iso.h
/usr/include/sys/types.h
/usr/include/sys/machtypes.h
/usr/include/sys/int_types.h
/usr/include/sys/select.h
/usr/include/sys/time_impl.h
/usr/include/sys/time.h
/usr/include/sys/types.h
/usr/include/sys/select.h
defines.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/deque
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/stddefs.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/stdcomp.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/compnent.h
/usr/include/stddef.h
/usr/include/iso/stddef_iso.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/rwdispatch.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/algorithm
/usr/include/stdlib.h
/usr/include/iso/stdlib_iso.h
/usr/include/iso/stdlib_c99.h
/usr/include/sys/wait.h
/usr/include/sys/resource.h
/usr/include/sys/siginfo.h
/usr/include/sys/machsig.h
/usr/include/sys/procset.h
/usr/include/sys/signal.h
/usr/include/sys/iso/signal_iso.h
/usr/include/sys/unistd.h
/usr/include/sys/ucontext.h
/usr/include/sys/regset.h
/usr/include/v7/sys/privregs.h
/usr/include/v7/sys/psr.h
/usr/include/sys/fsr.h
/usr/include/sys/signal.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/iterator
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/iterator
/opt/solarisstudio12.3/prod/include/CC/Cstd/ostream
/opt/solarisstudio12.3/prod/include/CC/Cstd/ios
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/rwstderr.h
/usr/include/stdarg.h
/usr/include/iso/stdarg_iso.h
/usr/include/sys/va_impl.h
/usr/include/sys/va_list.h
/usr/include/iso/stdarg_c99.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/rwstderr_macros.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/rwlocale
/opt/solarisstudio12.3/prod/include/CC/Cstd/string
/usr/include/string.h
/usr/include/iso/string_iso.h
/usr/include/ctype.h
/usr/include/iso/ctype_iso.h
/usr/include/iso/ctype_c99.h
/usr/include/wchar.h
/usr/include/iso/wchar_iso.h
/usr/include/stdio_tag.h
/usr/include/wchar_impl.h
/usr/include/stdio.h
/usr/include/iso/stdio_iso.h
/usr/include/stdio_impl.h
/usr/include/iso/stdio_c99.h
/usr/include/iso/wchar_c99.h
/usr/include/wctype.h
/usr/include/iso/wctype_iso.h
/usr/include/iso/wctype_c99.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/string_ref
/opt/solarisstudio12.3/prod/include/CC/Cstd/memory
/usr/include/limits.h
/usr/include/iso/limits_iso.h
/usr/include/sys/int_limits.h
/opt/solarisstudio12.3/prod/include/CC/new
/opt/solarisstudio12.3/prod/include/CC/exception
/opt/solarisstudio12.3/prod/include/CC/Cstd/utility
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/stdmutex.h
/usr/include/pthread.h
/usr/include/sched.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/traits
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/iotraits
/opt/solarisstudio12.3/prod/include/CC/Cstd/iosfwd
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/traits
"/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/traits", line 538: Error: The function "wcsstr" must have a prototype.
/opt/solarisstudio12.3/prod/include/CC/Cstd/stdexcept
/opt/solarisstudio12.3/prod/include/CC/typeinfo
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/locimpl
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/locvector
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/vendor
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/ctype
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/numeral
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/iosbase
/opt/solarisstudio12.3/prod/include/CC/Cstd/limits
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/math.h
/usr/include/math.h
/usr/include/iso/math_iso.h
/usr/include/iso/math_c99.h
/usr/include/floatingpoint.h
/usr/include/sys/ieeefp.h
/usr/include/float.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/codecvt
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/usefacet
/opt/solarisstudio12.3/prod/include/CC/Cstd/streambuf
/opt/solarisstudio12.3/prod/include/CC/Cstd/istream
/opt/solarisstudio12.3/prod/include/CC/Cstd/set
/opt/solarisstudio12.3/prod/include/CC/Cstd/functional
/opt/solarisstudio12.3/prod/include/CC/Cstd/rw/tree
/usr/include/sys/param.h
messages.h
/usr/include/assert.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/list
/RogueWave/SourcePro/12.5/rw/trace/trace.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceSetState.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceEventSeverity.h
/RogueWave/SourcePro/12.5/rw/trace/pkgdefs.h
/RogueWave/SourcePro/12.5/rw/config/rwconfig_trace.h
/RogueWave/SourcePro/12.5/rw/config/rwconfig.h
/RogueWave/SourcePro/12.5/rw/config/rwc_trace_15d.h
/RogueWave/SourcePro/12.5/rw/config/rwconfig_tls.h
/RogueWave/SourcePro/12.5/rw/config/rwc_tls_15d.h
/RogueWave/SourcePro/12.5/rw/defs.h
/usr/include/assert.h
/RogueWave/SourcePro/12.5/rw/compiler.h
/RogueWave/SourcePro/12.5/rw/config/rwconfig_tls.h
/RogueWave/SourcePro/12.5/rw/config/rwc_tls_15d.h
/RogueWave/SourcePro/12.5/rw/typedefs.h
/RogueWave/SourcePro/12.5/rw/config/rwconfig_tls.h
/RogueWave/SourcePro/12.5/rw/config/rwc_tls_15d.h
/RogueWave/SourcePro/12.5/rw/limits.h
/RogueWave/SourcePro/12.5/rw/config/rwconfig_tls.h
/RogueWave/SourcePro/12.5/rw/config/rwc_tls_15d.h
/RogueWave/SourcePro/12.5/rw/rwwind.h
/RogueWave/SourcePro/12.5/rw/compat.h
/RogueWave/SourcePro/12.5/rw/defs.h
/RogueWave/SourcePro/12.5/rw/utility.h
/RogueWave/SourcePro/12.5/rw/defs.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceEvent.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceEventClient.h
/RogueWave/SourcePro/12.5/rw/trace/except.h
/RogueWave/SourcePro/12.5/rw/rwerr.h
/RogueWave/SourcePro/12.5/rw/trace/fwd.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceEventClientImp.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceEventFilter.h
/RogueWave/SourcePro/12.5/rw/ref.h
/RogueWave/SourcePro/12.5/rw/tools/atomic.h
/RogueWave/SourcePro/12.5/rw/tools/atomics/atomic_sunpro.h
/RogueWave/SourcePro/12.5/rw/tools/atomicorder.h
/usr/include/sys/atomic.h
/usr/include/sys/inttypes.h
/usr/include/sys/int_const.h
/usr/include/sys/int_fmtio.h
/usr/include/stdint.h
/usr/include/sys/stdint.h
/RogueWave/SourcePro/12.5/rw/mutex.h
/usr/include/synch.h
/usr/include/sys/machlock.h
/usr/include/sys/synch.h
/usr/include/thread.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceOstreamClient.h
/RogueWave/SourcePro/12.5/rw/rstream.h
/RogueWave/SourcePro/12.5/rw/tools/ristream.h
/RogueWave/SourcePro/12.5/rw/tools/rostream.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/iostream
/RogueWave/SourcePro/12.5/rw/trace/RWTraceOstreamClientImp.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceEventFilterImp.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceSingleClientFilter.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceSingleClientFilterImp.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceLevelFilter.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceLevelFilterImp.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceMultiClientFilter.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceMultiClientFilterImp.h
/RogueWave/SourcePro/12.5/rw/tvordvec.h
/RogueWave/SourcePro/12.5/rw/epersist.h
/RogueWave/SourcePro/12.5/rw/vstream.h
/RogueWave/SourcePro/12.5/rw/rwfile.h
/RogueWave/SourcePro/12.5/rw/toolerr.h
/RogueWave/SourcePro/12.5/rw/message.h
/RogueWave/SourcePro/12.5/rw/rwstore.h
/RogueWave/SourcePro/12.5/rw/rwassert.h
/RogueWave/SourcePro/12.5/rw/rwset.h
/RogueWave/SourcePro/12.5/rw/hashtab.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/vector
/RogueWave/SourcePro/12.5/rw/colclass.h
/RogueWave/SourcePro/12.5/rw/collect.h
/RogueWave/SourcePro/12.5/rw/stringid.h
/RogueWave/SourcePro/12.5/rw/edefs.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTIdentity.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTIsSame.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWFalseType.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTrueType.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTRemoveReference.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTIsLvalueReference.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTIsRvalueReference.h
/RogueWave/SourcePro/12.5/rw/cstring.h
/RogueWave/SourcePro/12.5/rw/tools/stdcstring.h
/RogueWave/SourcePro/12.5/rw/tools/hash.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTConditional.h
/RogueWave/SourcePro/12.5/rw/tools/cstrutil.h
/RogueWave/SourcePro/12.5/rw/mempool.h
/RogueWave/SourcePro/12.5/rw/iterator.h
/RogueWave/SourcePro/12.5/rw/epfunc.h
/RogueWave/SourcePro/12.5/rw/tools/algorithm.h
/RogueWave/SourcePro/12.5/rw/tools/iterator.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTEnableIf.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTIsIntegral.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTRemoveCV.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTRemoveConst.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTIsConst.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTRemoveVolatile.h
/RogueWave/SourcePro/12.5/rw/tools/traits/RWTIsVolatile.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceManager.h
/RogueWave/SourcePro/12.5/rw/trace/RWTraceManagerImp.h
/RogueWave/SourcePro/12.5/rw/once.h
/RogueWave/SourcePro/12.5/rw/tvslist.h
/RogueWave/SourcePro/12.5/rw/stdex/slist.h
/RogueWave/SourcePro/12.5/rw/trace/userdefs.h
/RogueWave/SourcePro/12.5/rw/trace/tracemacros.h
/RogueWave/SourcePro/12.5/rw/tools/cstrstrm.h
/opt/solarisstudio12.3/prod/include/CC/Cstd/sstream
/RogueWave/SourcePro/12.5/rw/trace/RWTraceEntryExit.h
/RogueWave/SourcePro/12.5/rw/sync/RWMutexLock.h
/RogueWave/SourcePro/12.5/rw/sync/pkgdefs.h
/RogueWave/SourcePro/12.5/rw/config/rwconfig_sync.h
/RogueWave/SourcePro/12.5/rw/config/rwc_sync_15d.h
/RogueWave/SourcePro/12.5/rw/config/rwconfig_tls.h
/RogueWave/SourcePro/12.5/rw/config/rwc_tls_15d.h
/RogueWave/SourcePro/12.5/rw/config/rwconfig_trace.h
/RogueWave/SourcePro/12.5/rw/config/rwc_trace_15d.h
/RogueWave/SourcePro/12.5/rw/config/rwconfig_threxcept.h
/RogueWave/SourcePro/12.5/rw/config/rwc_threxcept_15d.h
/RogueWave/SourcePro/12.5/rw/config/rwconfig_tls.h
/RogueWave/SourcePro/12.5/rw/config/rwc_tls_15d.h
/RogueWave/SourcePro/12.5/rw/config/rwconfig_trace.h
/RogueWave/SourcePro/12.5/rw/config/rwc_trace_15d.h
/RogueWave/SourcePro/12.5/rw/sync/RWSynchObject.h
/RogueWave/SourcePro/12.5/rw/sync/RWCancellationState.h
/RogueWave/SourcePro/12.5/rw/threxcept/threxcept.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHRBoundsError.h
/RogueWave/SourcePro/12.5/rw/threxcept/pkgdefs.h
/RogueWave/SourcePro/12.5/rw/config/rwconfig_threxcept.h
/RogueWave/SourcePro/12.5/rw/config/rwc_threxcept_15d.h
/RogueWave/SourcePro/12.5/rw/threxcept/thrmsg.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHRIllegalUsage.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHRxmsg.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHRExternalError.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHRIllegalAccess.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHRInternalError.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHRInvalidPointer.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHROperationAborted.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHROperationCanceled.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHROperationNotAvailable.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHROperationNotImplemented.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHROperationNotSupported.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHROperationTerminated.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHRPermissionError.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHRResourceLimit.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHRThreadActive.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTHRThreadNotActive.h
/RogueWave/SourcePro/12.5/rw/threxcept/RWTTHRCompatibleException.h
/RogueWave/SourcePro/12.5/rw/sync/RWTLockGuard.h
/RogueWave/SourcePro/12.5/rw/sync/RWTLockGuardBase.h
/RogueWave/SourcePro/12.5/rw/sync/RWTGuardBase.h
/RogueWave/SourcePro/12.5/rw/sync/RWTReadLockGuard.h
/RogueWave/SourcePro/12.5/rw/sync/RWTReadLockGuardBase.h
/RogueWave/SourcePro/12.5/rw/sync/RWTReadGuardBase.h
/RogueWave/SourcePro/12.5/rw/sync/RWTWriteLockGuard.h
/RogueWave/SourcePro/12.5/rw/sync/RWTWriteLockGuardBase.h
/RogueWave/SourcePro/12.5/rw/sync/RWTWriteGuardBase.h
/RogueWave/SourcePro/12.5/rw/sync/RWTTryLockGuard.h
/RogueWave/SourcePro/12.5/rw/sync/RWTTryReadLockGuard.h
/RogueWave/SourcePro/12.5/rw/sync/RWTTryWriteLockGuard.h
/RogueWave/SourcePro/12.5/rw/sync/RWTUnlockGuard.h
/RogueWave/SourcePro/12.5/rw/sync/RWTReadUnlockGuard.h
/RogueWave/SourcePro/12.5/rw/sync/RWTWriteUnlockGuard.h
/RogueWave/SourcePro/12.5/rw/sync/RWThreadId.h
messageutilities.h
"messages.h", line 248: Warning: Implicit int is not supported in C++.
1 Error(s) and 1 Warning(s) detected.
gmake: *** [.shobj/julian.o] Error 2
tip1[~/ttproot/ttp/TTPLib]$I resolved this issue. The 2 defines: -D_XPG4_2 -D__EXTENSIONS__ are no longer needed and actually shouldn't be used.
Dave -
Solaris Studio 12.4 ccfe signal 11 with boost::unordered_set in C 11 mode
Using Solaris Studio 12.4 on Solaris 10 update 10 x86, the following program crashes ccfe:
#include <boost/unordered_set.hpp>
#include <string>
int main(int, char **)
boost::unordered_set<std::string> strSet;
std::string str("test");
strSet.insert(str);
return 0;
Assuming the code is saved to main.cc, build it in C++11 mode using:
CC -v -std=c++11 -m64 -I/usr/local/include/boost-1_54 main.cc
The output is:
### CC: Note: NLSPATH = /opt/solarisstudio12.4/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/solarisstudio12.4/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
### command line files and options (expanded):
### -v -std=c++11 -m64 -I/usr/local/include/boost-1_54 main.cc
/opt/solarisstudio12.4/lib/compilers/ccfe -xarch=amd64 -std=c++11 -D__SunOS_5_10 -D__SUNPRO_CC=0x5130 -D__unix -D__SVR4 -D__sun -D__SunOS "-D__builtin_expect(e,x)=e" -D__x86_64 -D__x86_64__ -D__amd64 -D__amd64__ -D_LP64 -D__LP64__ -D__BUILTIN_VA_STRUCT -Dunix -Dsun -D__SUN_PREFETCH -D__SUNPRO_CC_COMPAT='G' -include /opt/solarisstudio12.4/lib/compilers/include/CC/gnu/builtins.h -include /opt/solarisstudio12.4/lib/compilers/include/CC/gnu/builtins-def.h -I/usr/local/include/boost-1_54 -I-xbuiltin -I/opt/solarisstudio12.4/lib/compilers/include/CC/gnu -I/opt/solarisstudio12.4/lib/compilers/CC-gcc/include/c++/4.8.2/ -I/opt/solarisstudio12.4/lib/compilers/CC-gcc/include/c++/4.8.2//backward -I/opt/solarisstudio12.4/lib/compilers/CC-gcc/include/c++/4.8.2/i386-sun-solaris2.10/amd64/ -I/opt/solarisstudio12.4/lib/compilers/include/cc -I/usr/include -I/opt/solarisstudio12.4/lib/compilers/CC-gcc/lib/gcc/i386-sun-solaris2.10/4.8.2/include// -ptf /tmp/ccfe.1422033660.29374.03.%1.%2 -ptx /opt/solarisstudio12.4/bin/CC -ptk "-v -std=c++11 -m64 -I/usr/local/include/boost-1_54 " -compat=g -xdebuginfo=%none -xdbggen=dwarf+usedonly+incl -xF=%none -xbuiltin=%none -xldscope=global -xivdep=loop -O0 -xarrayloc main.cc -o /tmp/ccfe.1422033660.29374.01.ir 2> /tmp/ccfe.1422033660.29374.02.err
/opt/solarisstudio12.4/lib/compilers/stdlibfilt -stderr < /tmp/ccfe.1422033660.29374.02.err
>> Signal 11:
while processing main.cc at line 0.
rm /tmp/ccfe.1422033660.29374.02.err
rm /tmp/ccfe.1422033660.29374.01.ir
I know Boost 1.54 is not the most recent version, but the only changes to unordered_set.hpp between 1.54 and the current master branch in Boost's Git repository are Visual Studio 2013 workarounds, so I strongly suspect the same problem would occur with Solaris Studio 12.4 and more recent versions of Boost.
This problem can be avoided by using std::unordered_set instead of boost::unordered_set. However, since the compiler actually suffers a SEGV rather than giving a nice error message I thought I'd report this in case it's a sign of a problem in the compiler that might occur under other circumstances too.Thanks for the help. Yes, sorry, I should have made clear that this is after trying to use Boost in C++11 mode. I agree that the problem doesn't occur when using Solaris Studio in C++11 mode but Boost configured not to use any C++11 features.
I made quite a few edits to the Boost code, including the ones Steve posted in this thread. The edit that causes this problem to occur is the one to boost/config/compiler/sunpro_cc.hpp that removes all the BOOST_NO_CXX11_* macros.
It sounds like I should just hold off trying to use Boost in C++11 mode until the next version of Solaris Studio is out.
The pstack from the ccfe core dump is:
core 'core.1503' of 1503: /opt/solarisstudio12.4/lib/compilers/ccfe -xarch=amd64 -std=c++11 -D__
ffff0000 ???????? (8041218, 8, fcf58e0, 0)
082b7713 __1cPtemp_name_substKsubstitute6MrknQfull_syntax_name__1_ (8041260, 8041180) + 163
082be63d __1cKexpr_substKvisit_name6MpnJname_expr__v_ (80413c0, ad65da8, 8041348, 8275d73) + fd
082bc775 __1cKexpr_substKsubstitute6MpknEexpr__p1_ (80413c0, f2cab18, 80413a8) + 35
082b858b __1cPtemp_name_substQsubst_single_arg6MnPtemplate_actual__k1_ (80415d0, 8041b10, f2cab18, 103, 8041570, 0) + 2fb
082b8e10 __1cPtemp_name_substUsubstitute_temp_args6MrknbBtemplate_actuals_collection_pknXtemplate_parameter_list__1_ (8041890, 8041b10) + 150
082ba050 __1cPtemp_name_substPvisit_temp_args6MrknbJsyntax_name_with_template_arguments__v_ (8041b10, fc9dd80, 8041ac0, 8041964) + 30
082ba2c8 __1cPtemp_name_substFvisit6MrknQsyntax_name_impl4eInSsyntax_name_sort_t____v_ (8041b10, fc9dd80, fcf5610, 0) + 18
082b76d1 __1cPtemp_name_substKsubstitute6MrknQfull_syntax_name__1_ (8041bf0, 8041b10) + 121
082b526b __1cPtemp_type_substUvisit_name_dependent6MpnEtype_pnTname_dependent_type__v_ (8041eb0, f2e1aa4, f2e1a58, f2e21f0) + 5b
082b3930 __1cPtemp_type_substTsubstitute_ret_type6MpnJfunc_type__pnEtype__ (8041eb0, f2e2178, 8041d08, 8041d60) + 30
082b3c2c __1cPtemp_type_substKvisit_func6MpnEtype_pnJfunc_type__v_ (8041eb0, f2e21a0, f2e2178, f2e21f0) + 25c
082ba941 __1cPtemp_type_substTexpand_in_func_type6MpnJfunc_type__2_ (8041eb0) + 31
0816b754 __1cIfunc_symRnew_template_spec6kMrknbBtemplate_actuals_collection_rknIposition__pnDsym__ (f2e21f0) + c4
082c941b __1cQtemplate_matcherIgen_func6M_pnIfunc_sym__ (8042050, ad62d58, ad65960, 0) + 59b
0828af3f ???????? (80420f4, ad65940, 80421a0, 0, ad62c50, 0)
0828b2c9 __1cNoverload_call6FpnJcall_expr_rknJsym_array_4brknbBtemplate_actuals_collection_nEtypeKtype_class_b_2_ (8042198, ad65940, 804219c, 80421a0, 0, ad62c50) + 99
08204c38 ???????? (ad65940)
082086ff __1cLtypify_call6FpnJcall_expr_I_pnEexpr__ (ad65940, 4, 0, fd33148) + 9bf
081e36a5 __1cXtypify_dispatch_visitorKvisit_call6MpnJcall_expr__v_ (8042530, ad65940, 0, 0) + 15
081e4529 __1cGtypify6FpnEexpr_I_1_ (ad65940, 4, 0, 0) + c9
082b1e0a __1cJexpr_stmtOpass_thru_expr6MpnEexprHvisitor__v_ (ad659a0, 80425b0, 0, 83bb23e) + 1a
081e3cd1 __1cXtypify_dispatch_visitorPvisit_statement6MpnOstatement_expr__v_ (8042660, ad62b28, 8042608, 83bbbe9) + 71
081e4529 __1cGtypify6FpnEexpr_I_1_ (ad62b28, 0, 8759ec0, fc9b740) + c9
08266956 __1cWstore_inline_func_body6FpnIfunc_sym_pnFscope_bb_pnEexpr__ (fd2fc80, fc9b740, 1, 1) + 426
082700c8 __1cSinline_bookkeepingOprocess_inline6MpnIfunc_sym_pnJcall_expr_pnEexpr__6_ (8d61508) + 268
08270542 __1cSinline_bookkeepingNexpand_inline6MpnJcall_expr_pnEexpr__4_ (8d61508, ad5ecf8, 87594a8, 0) + f2
081e10e3 ???????? (ad5ecf8, 80005, 8043208, 85a44ab)
081d673e __1cWbind2_dispatch_visitorKvisit_call6MpnJcall_expr__v_ (8043220, ad5ecf8, fd1e6b8, fcb9a40) + 9e
081d7662 __1cHbind2erKbind2_body6FpnEexpr_I_2_ (ad5ecf8, 80005, 8043288, 0) + a2
082a94e7 ???????? (ad5ecf8, 0, 0, 0)
082aaaf3 __1cRstmt_bind_visitorKvisit_expr6MpnJexpr_stmt__v_ (8043350, ad5ed58, 80432f8, 804337c) + 93
082a8f2f __1cRstmt_bind_visitorOstmt_list_bind6MpnJstatement__2_ (8043350, ad5ed58, 2211, 7fefefef) + 8f
082b06b5 __1cRstmt_bind_visitorPvisit_statement6MpnOstatement_expr__v_ (8043350) + b5
082a9294 __1cJstmt_bind6FpnOstatement_expr_b_v_ (ad5bef0) + b4
081df9c6 ???????? (ad5bef0, 0, 8043428, 8272a37)
081d6e18 __1cWbind2_dispatch_visitorPvisit_statement6MpnOstatement_expr__v_ (8043420, ad5bef0, 8043448, 8043494) + 98
081d7662 __1cHbind2erKbind2_body6FpnEexpr_I_2_ (ad5bef0, 0, 8043488, 81710d5) + a2
082726f0 __1cSinline_bookkeepingQfinish_expansion6MrnbDfunction_definition_interface_pnEexpr__4_ (8d61508, fd2b46c, ad5bef0, 0) + 160
081e10f9 ???????? (ad4b210, 80005, 8043528, 82759da)
081d673e __1cWbind2_dispatch_visitorKvisit_call6MpnJcall_expr__v_ (8043520, ad4b210, 0, fcb9a40) + 9e
081d7662 __1cHbind2erKbind2_body6FpnEexpr_I_2_ (ad4b210, 80005, 8043578, ad55cc0) + a2
082a94e7 ???????? (ad4b210, 0, 0, 0)
082aaaf3 __1cRstmt_bind_visitorKvisit_expr6MpnJexpr_stmt__v_ (8043650, ad4b270, fd1e668, 874cef8) + 93
082a8f2f __1cRstmt_bind_visitorOstmt_list_bind6MpnJstatement__2_ (8043650, ad4a7b0, 1, 7fefefef) + 8f
082b06b5 __1cRstmt_bind_visitorPvisit_statement6MpnOstatement_expr__v_ (8043650) + b5
082a9294 __1cJstmt_bind6FpnOstatement_expr_b_v_ (ad4a520) + b4
081d6e18 __1cWbind2_dispatch_visitorPvisit_statement6MpnOstatement_expr__v_ (8043720, ad4a520, 8043748, 8043794) + 98
081d7662 __1cHbind2erKbind2_body6FpnEexpr_I_2_ (ad4a520, 0, 8043788, 81710d5) + a2
082726f0 __1cSinline_bookkeepingQfinish_expansion6MrnbDfunction_definition_interface_pnEexpr__4_ (8d61508, fc7b144, ad4a520, 0) + 160
081e10f9 ???????? (ad035e8, 80005, fd1e368, 85a4400)
081d673e __1cWbind2_dispatch_visitorKvisit_call6MpnJcall_expr__v_ (8043820, ad035e8, acffdb8, fcb9a40) + 9e
081d7662 __1cHbind2erKbind2_body6FpnEexpr_I_2_ (ad035e8, 80005, 8043878, 0) + a2
082a94e7 ???????? (ad035e8, 0, 0, 0)
082aaaf3 __1cRstmt_bind_visitorKvisit_expr6MpnJexpr_stmt__v_ (80439c0, ad03648, ad03668, 8759ec0) + 93
082a8f2f __1cRstmt_bind_visitorOstmt_list_bind6MpnJstatement__2_ (80439c0, acf9468, 0, 82d7323) + 8f
082afb6b __1cRstmt_bind_visitorWvisit_function_variant6MpnNfunction_stmt_b_v_ (80439c0, ad04358, 1, 8043a30) + 46b
082afe10 __1cRstmt_bind_visitorOvisit_function6MpnNfunction_stmt__v_ (80439c0, ad04358, ad04378, 8759ec0) + 40
082a916f __1cUstmt_bind_and_expand6FpnJstatement__1_ (ad04358, 3, fc55f4b, 80443c4) + 11f
08257545 __1cMfunc_contextJpostamble6MrnbDfunction_definition_interface_pnNfunction_stmt__v_ (871cc98) + d5
082e879d __1cTimmediate_func_body6FpnIfunc_sym__v_ (fbd3840, fbd3390, 8044dd0, 821b71f) + 3fd
08266428 __1cMparse_inline6FrnbDfunction_definition_interface__v_ (fbd385c, fbd38cc, 8044eb0, 95a38d4) + 188
084db8c8 __1cLemit_inline6FpnIsym_list__v_ (fca5328, fca5328) + 2d8
084d88f1 __1cQcompilation_unitFclean6M_b_ (8759310) + a1
084dd507 __1cIfinalgen6F_v_ (8c3ffa8, 8759178, 8046eb8, 815db68, 1, 8c41eb8) + 67
082f533b __1cGanalys6Fb_v_ (1, 8c41eb8, 8046eb8, 815d5d7) + db
0815db68 __1cHtmcplus6Fri0bpnHoptions__nHsym_set__ (8046f00, 8046ef8, 8046efc, 1, 8c4ced8, 86417b1) + 2be8
082e5943 main (34, 8047360, 8047434) + 283
08153f22 _start (34, 8047514, 804753e, 804754b, 8047556, 8047565) + 72 -
Assertion failure from ccfe in Solaris Studio 12.4 beta July refresh
I have found a way to get an assertion failure from the ccfe program that comes with the Solaris Studio 12.4 beta July refresh. The error that gets printed is:
>> Assertion: (../lnk/funcsym.cc, line 1679)
while processing text_woarchive.pre.cpp at line 0.
The problem occurs whilst compiling Boost 1.54. The original file in the distribution that causes it is libs/serialization/src/text_woarchive.cpp.
This problem can be reproduced by getting the pre-processed code I've put on http://pastebin.com/E9vxi2z7 and pasting it into a file called text_woarchive.pre.cpp. Then run:
CC -std=c++11 -mt -m64 -c -o text_woarchive.o text_woarchive.pre.cpp
and you get the assertion failure.
Running:
CC '-#' -std=c++11 -mt -m64 -c -o text_woarchive.o text_woarchive.pre.cpp
shows that the assertion is coming from ccfe.
In case you go back to the original Boost source code I should tell you that prior to generating the pre-processed source I changed:
#ifdef __SUNPRO_CC
to:
#if 0
in boost/archive/detail/register_archive.hpp. I did this because there was an error in the __SUNPRO_CC section and I wondered if that workaround code was no longer required with the more modern C++ compiler. Therefore, I cannot guarantee that the pre-processed source is 100% valid C++ code. However, even if it's not it would be nice to get a clear error message out of ccfe rather than an assertion failure.
In case it's relevant, I'm working on Oracle Solaris 10 1/13 s10x_u11wos_24a X86.You mentioned in the other answer that you are testing with Boost 1.55. Are you testing this in C++11 mode?
Today I downloaded Boost 1.55 and did the following:
In both tools/build/v2/engine/build.sh and tools/build/v2/tools/sun.jam globally replace SUNWspro with SolarisStudio12.4-beta_jul14-solaris-x86
In tools/build/v2/tools/sun.jam replace:
feature.extend stdlib : sun-stlport ;
feature.compose <stdlib>sun-stlport
: <cxxflags>-library=stlport4 <linkflags>-library=stlport4
with:
feature.extend stdlib : sun-stlport ;
feature.compose <stdlib>sun-stlport
: <cxxflags>-std=c++11 <linkflags>-std=c++11
Note: This is just the quick way I found to con the Boost build system into using C++11 instead of STLport. The feature in the jam file still has stlport in its name, but that's only a name and the code is being built in C++11 mode.
In boost/math/special_functions/detail/lanczos_sse2.hpp change line 15 from:
#if defined(__GNUC__) || defined(__PGI)
to:
#if defined(__GNUC__) || defined(__PGI) || defined(__SUNPRO_CC)
Run:
./bootstrap.sh --without-libraries=context --without-libraries=coroutine --without-libraries=graph_parallel --without-libraries=log --without-libraries=mpi --without-libraries=python --without-libraries=test --without-icu
Run:
./b2 -j4 --layout=versioned --disable-icu address-model=64 threading=multi optimization=speed inlining=full
At this point the vast majority of the code builds, but does not link.
There are 3 problems:
The compilation problem with tuple that you've already fixed
A linker problem with finding std::string related symbols - maybe also related to the gcc header upgrade and now fixed?
Numerous compilation problems caused by boost/archive/detail/register_archive.hpp
For this last one the code in the #ifdef __SUNPRO_CC section of boost/archive/detail/register_archive.hpp does appear to be invalid, and leads to the errors:
"./boost/archive/detail/register_archive.hpp", line 45: Error: The function "adjust_counter" must have a prototype.
"./boost/archive/detail/register_archive.hpp", line 46: Error: Expression must have a constant value.
"./boost/archive/detail/register_archive.hpp", line 47: Error: Expression must have a constant value.
"./boost/archive/detail/register_archive.hpp", line 48: Error: An integer constant expression is required within the array subscript operator.
Even with Boost 1.55, attempts to fix this lead to the same ccfe assertion. Trying to use the #else part of the code as I described in the original post does, as does moving the line:
char adjust_counter(counter<0>);
so that it comes before the place where adjust_counter is used also then leads to the same assertion:
>> Assertion: (../lnk/funcsym.cc, line 1679)
It's as though any change to boost/archive/detail/register_archive.hpp that fixes the basic code ordering issue lets ccfe get far enough to cause the assertion.
If there is somebody in your team looking at whether Boost 1.55 compiles with Solaris Studio 12.4 in C++11 mode then hopefully they can relate to what I'm seeing here. One key point is that they'll have had to edit the jam files to use C++11 mode.
The other thing is that any insights the person who has been trying to build Boost 1.55 has would be very useful. I know you don't want to get into officially supporting it, but maybe a blog post with any unofficial hints and tips on getting Boost to build in C++11 mode could be a way to share knowledge. -
Looking for feedback on Oracle Solaris Studio Express 6/10
Just a reminder that if you encounter bugs or have request for enhancements (RFEs), please submit them at:
[http://bugs.sun.com|http://bugreport.sun.com/bugreport/]
In addition, please take 5 minutes to fill out a short survey about your experience with Solaris Studio Express 6/10:
[OSSX 6/10 Survey Link|http://bit.ly/c9poXo]
The development teams do closely review these submissions and it is used by teams, and management, to prioritize development for future releases.
Thank you!
/ksoI know you have a more general concern, but here is the answer on SBR.
SBR - beyond Stack Bounds Read
foo () {
int a[5] = {0, 1, 2, 3, 4};
int i = a[-100]; // Read is beyond stack frame bounds
Possible causes: Reading a local array past the end or before the start. -
Use of __typeof__ in Solaris Studio 12.4
Solaris Studio 12.3 had a __typeof__ operator similar to decltype in C++11. This is available in a portable wrapper using the Boost macro BOOST_TYPEOF_TPL. It looks like the Solaris Studio team contributed the modification to Boost which added this in ticket 5745.
Now Solaris Studio 12.4 has a C++11 mode which supports decltype. However, is __typeof__ still supposed to work in Solaris Studio 12.4's C++03 mode? It doesn't seem to work as well as it used to.
The following program deduces the return type of operator() using __typeof__:
#include <boost/typeof/typeof.hpp>
#include <boost/type_traits/remove_reference.hpp>
#include <iostream>
#include <typeinfo>
// Helper to deduce the result type from a member function pointer.
template<typename T>
struct member_function_result_type
template<typename T, typename R, typename A1>
struct member_function_result_type<R (T::*)(A1) const>
typedef typename boost::remove_reference<R>::type type;
template<typename T>
struct function_result_type
typedef BOOST_TYPEOF_TPL(&T::operator()) F;
typedef typename member_function_result_type<F>::type type;
template<typename R, typename A>
struct function_result_type<R (*)(A)>
typedef typename boost::remove_reference<R>::type type;
struct my_functor
float operator()(float numerator) const
return numerator / 2.0f;
int main(int, char **)
typedef typename function_result_type<my_functor>::type my_type;
my_functor f;
my_type ret = f(5.0f);
if (typeid(my_type) == typeid(float))
std::cout << "As expected " << ret << std::endl;
else
std::cout << "Oh dear " << ret << std::endl;
return 0;
If you build this with Solaris Studio 12.3 as follows:
CC -m64 -I/usr/local/include/boost-1_54 main.cc
then it compiles and running a.out shows the return type of float has been correctly deduced.
However, with Solaris Studio 12.4 the same command:
CC -m64 -I/usr/local/include/boost-1_54 main.cc
results in:
"main.cc", line 23: Error: Unexpected type name "F" encountered.
"main.cc", line 42: Warning: "typename" must be used within a template.
1 Error(s) and 1 Warning(s) detected.
Now, obviously Solaris Studio 12.4 has a C++11 mode and it is possible to get this program to work by changing BOOST_TYPEOF_TPL to decltype and building with:
CC -std=c++11 -m64 -I/usr/local/include/boost-1_54 main.cc
But Solaris Studio 12.4's C++11 mode has other problems, so is there any way to somehow get a working __typeof__ or equivalent in Solaris Studio 12.4's C++03 mode?
(In case it makes any difference this is on Solaris 10 x86.)I couldn't see that any of the items listed in the "Enforcement of C++ rules" section of the documentation would affect this program.
Here's a cut down version of the test program that doesn't use Boost:
#include <iostream>
#include <typeinfo>
// Helper to deduce the result type from a member function pointer.
template<typename T>
struct member_function_result_type
template<typename T, typename R, typename A1>
struct member_function_result_type<R (T::*)(A1) const>
typedef R type;
template<typename T>
struct function_result_type
typedef __typeof__(&T::operator()) F;
typedef typename member_function_result_type<F>::type type;
template<typename R, typename A>
struct function_result_type<R (*)(A)>
typedef R type;
struct my_functor
float operator()(float numerator) const
return numerator / 2.0f;
int main(int, char **)
typedef function_result_type<my_functor>::type my_type;
my_functor f;
my_type ret = f(5.0f);
if (typeid(my_type) == typeid(float))
std::cout << "As expected " << ret << std::endl;
return 0;
Interestingly this doesn't compile with either Solaris Studio 12.3 or Solaris Studio 12.4, but each gives different errors:
Solaris Studio 12.3:
CC -m64 main.cc
>> Assertion: unexpected type_builder::visit_unspec (../lnk/v2mangler.cc, line 1636)
while processing main.cc at line 39.
Solaris Studio 12.4:
CC -m64 main.cc
"main.cc", line 20: Error: Unexpected type name "F" encountered.
1 Error(s) detected.
So Solaris Studio 12.4 is basically failing in the same way as the original test program that used the Boost wrappers. Solaris Studio 12.3 is failing with an assertion error that doesn't occur when the Boost wrappers are used.
It turns out that __typeof__ was only used in one place in our codebase (wrapped by Boost), so I've just removed it and implemented that code in a different way. So this isn't blocking upgrade of Solaris Studio, and we don't even have __typeof__ in our codebase any more, but I just thought you might be interested to have this program as a test case for future development.
It works fine with clang++ in C++03 mode on Mac OS X so I doubt the problem is caused by the source code not conforming to standard:
clang++ main.cc
./a.out
As expected 2.5
This case may be particularly tricky for a compiler to handle due to __typeof__ being applied to a pointer to a const member function. -
I've been trying to test out using LDAP to replace NIS.
My setup is a Sun Sparc box with Solaris 10 running
Sun One Directory 5.2 patch level 3. I have two x86_64 client
machines; one running Red Hat 4 and the other Solaris 10.
I have been able to authenticate on the RH 4 machine
with no problems, but have been unable to on the
Solaris 10 machine. I'm using Sun's native LDAP
client tools.
I've tried configuring the DS for anonymous access
to proxy access with simple authentication, but neither
one seems to matter.
I've copied over the pam.conf example provided by Sun
today, but it still doesn't seem to work. I can do a
"getent passwd" on the RH 4 and get all the local accounts
and the test one in the LDAP server. If I try that on the
Sun box I only get the local accounts, however if I
do a "getent password testuser" on the Solaris 10 box,
then I get the right account info. It looks like I can even
see the passwords, which are stored using md5; not
crypt, if that matters.
I'm tried searching for more info, but it doesn't appear
that DS 5.2 has been used too much on Solaris 10;
nor does Gary Tay's great documentation cover
Solaris 10. Is there something obvious I'm missing?
I can't believe it would be this hard to set LDAP up
with just Sun software.See related posts:
http://www.sunmanagers.org/pipermail/summaries/2005-August/006688.html
1) make sure /etc/nsswitch.conf has this entry in it:
ipnodes: files
2) must run these commands as root:
crle -u -s /usr/lib/mps
crle -64 -u -s /usr/lib/mps/64
Other than that I didn't need to do anything different than solaris 9.
I did have to run this command on occasion though:
svcadm enable svc:/network/ldap/client:defaulthttp://forum.sun.com/thread.jspa?forumID=271&threadID=25523
Gary -
Can not use SVM disc mirror on Sun X2200 M2 with solaris u7
Last year,I tried to build cluster with solaris u6, but I got this error "Insufficient metadevice database replicas located" after SVM set up.
I tried lastest solaris 10 u7(09/05) with Sun x2200 M2 server again, but I got the same error.
I think it maybe driver's problem,so I tested solaris 10 u7 again with one old x86 machines and this machines has pure scsi card and scsi disc.
Also I tried it with ide drive, and everything is fine without any error message.
I checked that solaris 10 u5 will consider sata disc on x2200 m2 as ide disc, so SVM works fine.
But after I upgrade to solaris 10 u7,system will consider sata disc as scsi drive, and SVM will not work.
So I can see this is a bug of solaris 10 u7?
Edited by: cheung79 on 2009/7/3 ?? 11:04-bash-3.00# metadb -i
flags first blk block count
a m p lu 16 8192 /dev/dsk/c0t0d0s7
a p l 8208 8192 /dev/dsk/c0t0d0s7
a p l 16400 8192 /dev/dsk/c0t0d0s7
M u 16 unknown /dev/dsk/c0t1d0s7
M u 8208 unknown /dev/dsk/c0t1d0s7
M u 16400 unknown /dev/dsk/c0t1d0s7
r - replica does not have device relocation information
o - replica active prior to last mddb configuration change
u - replica is up to date
l - locator for this replica was read successfully
c - replica's location was in /etc/lvm/mddb.cf
p - replica's location was patched in kernel
m - replica is master, this is replica selected as input
W - replica has device write errors
a - replica is active, commits are occurring to this replica
M - replica had problem with master blocks
D - replica had problem with data blocks
F - replica had format problems
S - replica is too small to hold current data base
R - replica had device read errors
I don't have "set md:mirrored_root_flag=1" line in /etc/system.
Do you mean boot device is scsi hdd? but it is sata hdd.
-bash-3.00# ls -l /dev/rdsk/c0t0d0s0
lrwxrwxrwx 1 root root 51 Jul 7 17:55 /dev/rdsk/c0t0d0s0 -> ../../devices/pci@0,0/pci108e,534b@5/disk@0,0:a,raw
Maybe you are looking for
-
Develop Form and Workflow in SharePoint Online and On-Premise
Hi Expert, I have the question about Form and Workflow in SharePoint Online vs ShrePoint On-Premise Current Problem : Customer is implemented Form and Workflow in SharePoint Online but they have a problem some features that didn't work in SharePoint
-
Is there a way to wirelessly connect my Airports?
I have an AirPort Extreme and just got an Airport Express. How do I connect them wirelessly so I don't need to connect them by Ethernet cord?
-
Unable to use Mac OS X Install DVD
My iMac came with Mac OS X Install DVD, but since I have upgraded to Mountain Lion through the Apple App Store and have made a bootable USB. So after formatting my HDD I'm unable to boot from the USB or the DVD. When prompt to select "where you want
-
Query for Stock Tranfer Mov-311
Dear Experts, I want to make a query to know value of stock transfer from one storage location to another on certain date or from x date to y date. In MB51 there is no value appears, as there is no financial transaction. I am preparing query using SQ
-
Can I use smart groups in icloud contacts?
I have a bunch of smart groups set up on my Mac, but I can't see them on icloud contacts. Are smart groups supported on icloud?