Re: Missing concept check instantiations on sparc-sun-solaris2.8 cross sometimes

[Brad Spencer <spencer at infointeractive dot com>]

On Mon, Jun 16, 2003 at 05:37:17PM -0300, Brad Spencer wrote:
> > ... hm.  You might try compiling that file by hand, by copying and pasting
> > the long compiler command, but removing the -fno-implicit-templates bit.
> > If there's any difference at all in the generated symbol list, something
> > is very wrong.

I've rebuild the (cross) compiler from scratch and suspended the build
right after it made concept-inst.o and here's what I'm seeing (excuse
the noise):

/bin/sh ../libtool --tag CXX --mode=compile
/build/eng-linux1/spencer/gcc-cross/sparc-sun-solaris2.8/build-gcc/gcc/xgcc
-shared-libgcc
-B/build/eng-linux1/spencer/gcc-cross/sparc-sun-solaris2.8/build-gcc/gcc/
-nostdinc++
-L/build/eng-linux1/spencer/gcc-cross/sparc-sun-solaris2.8/build-gcc/sparc-sun-solaris2.8/libstdc++-v3/src
-L/build/eng-linux1/spencer/gcc-cross/sparc-sun-solaris2.8/build-gcc/sparc-sun-solaris2.8/libstdc++-v3/src/.libs
-B/opt/gcc-3.3-cross/sparc-sun-solaris2.8/sparc-sun-solaris2.8/bin/
-B/opt/gcc-3.3-cross/sparc-sun-solaris2.8/sparc-sun-solaris2.8/lib/
-isystem
/opt/gcc-3.3-cross/sparc-sun-solaris2.8/sparc-sun-solaris2.8/include
-nostdinc++
-I/build/eng-linux1/spencer/gcc-cross/sparc-sun-solaris2.8/build-gcc/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8
-I/build/eng-linux1/spencer/gcc-cross/sparc-sun-solaris2.8/build-gcc/sparc-sun-solaris2.8/libstdc++-v3/include
-I../../../../../gcc-3.3/libstdc++-v3/libsupc++
-I../../../../../gcc-3.3/libstdc++-v3/libmath    -g -O2
-fno-implicit-templates  -Wall -Wno-format -W -Wwrite-strings
-fdiagnostics-show-location=once      -D_GLIBCPP_CONCEPT_CHECKS
-fimplicit-templates -c
../../../../../gcc-3.3/libstdc++-v3/src/concept-inst.cc

/build/eng-linux1/spencer/gcc-cross/sparc-sun-solaris2.8/build-gcc/gcc/xgcc
-shared-libgcc
-B/build/eng-linux1/spencer/gcc-cross/sparc-sun-solaris2.8/build-gcc/gcc/
-nostdinc++
-L/build/eng-linux1/spencer/gcc-cross/sparc-sun-solaris2.8/build-gcc/sparc-sun-solaris2.8/libstdc++-v3/src
-L/build/eng-linux1/spencer/gcc-cross/sparc-sun-solaris2.8/build-gcc/sparc-sun-solaris2.8/libstdc++-v3/src/.libs
-B/opt/gcc-3.3-cross/sparc-sun-solaris2.8/sparc-sun-solaris2.8/bin/
-B/opt/gcc-3.3-cross/sparc-sun-solaris2.8/sparc-sun-solaris2.8/lib/
-isystem
/opt/gcc-3.3-cross/sparc-sun-solaris2.8/sparc-sun-solaris2.8/include
-nostdinc++
-I/build/eng-linux1/spencer/gcc-cross/sparc-sun-solaris2.8/build-gcc/sparc-sun-solaris2.8/libstdc++-v3/include/sparc-sun-solaris2.8
-I/build/eng-linux1/spencer/gcc-cross/sparc-sun-solaris2.8/build-gcc/sparc-sun-solaris2.8/libstdc++-v3/include
-I../../../../../gcc-3.3/libstdc++-v3/libsupc++
-I../../../../../gcc-3.3/libstdc++-v3/libmath -g -O2
-fno-implicit-templates -Wall -Wno-format -W -Wwrite-strings
-fdiagnostics-show-location=once -D_GLIBCPP_CONCEPT_CHECKS
-fimplicit-templates -c
../../../../../gcc-3.3/libstdc++-v3/src/concept-inst.cc -o
concept-inst.o

After this line runs, an examination of the concept-inst.o that it
generated shows just the few symbols:

concept-inst.o:00000000 a *ABS*
concept-inst.o:00000034 t __atomic_add(int volatile*, int)
concept-inst.o:00000000 t __exchange_and_add(int volatile*, int)
concept-inst.o:00000000 V __Atomicity_lock<(int)0>::_S_atomicity_lock
concept-inst.o:00000000 W void
__gnu_cxx::__function_requires<__gnu_cxx::_ConvertibleConcept<unsigned,
unsigned> >()
concept-inst.o:00000000 W void
__gnu_cxx::__function_requires<__gnu_cxx::_InputIteratorConcept<char
const*> >()
concept-inst.o:00000000 W void
__gnu_cxx::__function_requires<__gnu_cxx::_InputIteratorConcept<char*>
>()
concept-inst.o:00000000 W void
__gnu_cxx::__function_requires<__gnu_cxx::_OutputIteratorConcept<std::ostreambuf_iterator<char,
std::char_traits<char> >, char> >()
concept-inst.o:00000000 W void
__gnu_cxx::__function_requires<__gnu_cxx::_LessThanComparableConcept<char*>
>()
concept-inst.o:00000000 W void
__gnu_cxx::__function_requires<__gnu_cxx::_LessThanComparableConcept<int>
>()
concept-inst.o:00000000 W void
__gnu_cxx::__function_requires<__gnu_cxx::_LessThanComparableConcept<long>
>()
concept-inst.o:00000000 W void
__gnu_cxx::__function_requires<__gnu_cxx::_LessThanComparableConcept<long
long> >()
concept-inst.o:00000000 W void
__gnu_cxx::__function_requires<__gnu_cxx::_RandomAccessIteratorConcept<__gnu_cxx::__normal_iterator<char
const*, std::basic_string<char, std::char_traits<char>,
std::allocator<char> > > > >()
concept-inst.o:00000000 W void
__gnu_cxx::__function_requires<__gnu_cxx::_RandomAccessIteratorConcept<__gnu_cxx::__normal_iterator<char*,
std::basic_string<char, std::char_traits<char>, std::allocator<char> >
> > >()
concept-inst.o:00000000 W void
__gnu_cxx::__function_requires<__gnu_cxx::_RandomAccessIteratorConcept<char
const*> >()
concept-inst.o:00000000 W void
__gnu_cxx::__function_requires<__gnu_cxx::_RandomAccessIteratorConcept<char*>
>()

Or, more succinctly:
nm src/concept-inst.o  |wc -l
    16

If I stop the build process and make it again, it generates the same
symbols.  But, if I stop the build process and do a "make clean; make"
from the libstdc++-v3 build directory, I get a _lot_ more symbols:

nm src/concept-inst.o  |wc -l
    156

Sure enough, it appears that the command lines are
_different_ when I run things in these two ways.  The 16-symbol
(broken) object's build line contains "-g -O2", while the 156-symbol
(ok?) object's build line has neither.  Removing "-g" had no effect,
but removing the "-O2" flag brought in all 156 symbols.  Uh-oh.  Going
to "-O3" brought the count down to 14.

Is there anything else I can look into?  I presume that either there
is a bug in the compiler, or the compiler is allowed to trim these
instantiations and the mechanism used to emit them isn't going to
work. 

-- 
------------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company