Signal 11 when building on HP-UX w/ aCC 3.73

[Patrick Happel-2]

Hello,
  A customer I'm working with noticed the following error, which seems
to occur when building the stdcxx 4.2.0 release packaged with SourcePro
Ed 10 on HP-UX 11.11 with aCC A.03.73:
 
generating dependencies for $(TOPDIR)/src/locale_body.cpp
aCC +Maked -E  -D_RWSTDDEBUG
-I/nmlpkgs/sourcepro10_build/3rdparty/stdcxx/stdcxx-4.2.0/include
-I/nmlpkgs/sourcepro10_oc15/stdcxx/ad/include  -AA  -g +d   +w +W392
+W655 +W684 +W818 +W819 +W849  +Z
/nmlpkgs/sourcepro10_build/3rdparty/stdcxx/stdcxx-4.2.0/src/locale_body.
cpp
Signal 11
( 0)  0x002983b8   sighandler__FiT1 + 0x134
[/nmlpkgs/aCC373/lbin/ctcom.pa20]
( 1)  0xc020bfe0   _sigreturn  [/usr/lib/libc.2]
( 2)  0x002748d8   synthesize__15LibraryRoutinesF19LibraryRoutinesEnum +
0x7c  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
( 3)  0x00278880   enter__15LibraryRoutinesF19LibraryRoutinesEnum + 0x10
[/nmlpkgs/aCC373/lbin/ctcom.pa20]
( 4)  0x001d0194
lookup__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11Dynamic
ListXTP4 + 0x168  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
( 5)  0x001cff40
find__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11DynamicLi
stXTP4No + 0x9c  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
( 6)  0x001a8744
hasPointerToMemberComing__12PreprocessorFQ2_12Preprocessor8PTMStateP11De
claratio + 0x844  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
( 7)  0x0023d468   isProbablyAnIdentifier__12PreprocessorFb + 0x54
[/nmlpkgs/aCC373/lbin/ctcom.pa20]
( 8)  0x001cdc24
resolveIdentifier__12PreprocessorFP12ScannerValue11StringToken + 0xbd4
[/nmlpkgs/aCC373/lbin/ctcom.pa20]
( 9)  0x001cbad8   nextToken__12PreprocessorFP12ScannerValue + 0x210
[/nmlpkgs/aCC373/lbin/ctcom.pa20]
(10)  0x00273f30   DoCompile__8CompilerFv + 0xd44
[/nmlpkgs/aCC373/lbin/ctcom.pa20]
(11)  0x000b7c00   DoCompile__8CompilerFP6Buffer + 0x34
[/nmlpkgs/aCC373/lbin/ctcom.pa20]
(12)  0x000c3a28   DoCompileFile__8CompilerFPc + 0x110
[/nmlpkgs/aCC373/lbin/ctcom.pa20]
(13)  0x000cb744   main + 0x404  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
(14)  0xc01434d0   _start + 0xc0  [/usr/lib/libc.2]
(15)  0x000b8120   $START$ + 0x178  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
Error (system problem) 689: # Compiler received signal 11

  This looks similar to the issue described in STDCXX-276, but only the
locale_body.cpp source file fails to build.  The library seems to build
fine, but I'm not sure how this may effect its behavior.  I wasn't able
to find a mention of this issue in the documentation- hopefully I didn't
miss it.
  Any insight into the cause of this issue and effects it may have on
the library would be appreciated.
 
Thanks,
 -Patrick Happel
 
Rogue Wave Software, Inc.
Technical Support
E-mail: support@...
Web: http://www.roguewave.com/support

[Martin Sebor]

Patrick Happel wrote:

> Hello,
>   A customer I'm working with noticed the following error, which seems
> to occur when building the stdcxx 4.2.0 release packaged with SourcePro
> Ed 10 on HP-UX 11.11 with aCC A.03.73:
>  
> generating dependencies for $(TOPDIR)/src/locale_body.cpp
> aCC +Maked -E  -D_RWSTDDEBUG
> -I/nmlpkgs/sourcepro10_build/3rdparty/stdcxx/stdcxx-4.2.0/include
> -I/nmlpkgs/sourcepro10_oc15/stdcxx/ad/include  -AA  -g +d   +w +W392
> +W655 +W684 +W818 +W819 +W849  +Z
> /nmlpkgs/sourcepro10_build/3rdparty/stdcxx/stdcxx-4.2.0/src/locale_body.
> cpp
> Signal 11
> ( 0)  0x002983b8   sighandler__FiT1 + 0x134
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 1)  0xc020bfe0   _sigreturn  [/usr/lib/libc.2]
> ( 2)  0x002748d8   synthesize__15LibraryRoutinesF19LibraryRoutinesEnum +
> 0x7c  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 3)  0x00278880   enter__15LibraryRoutinesF19LibraryRoutinesEnum + 0x10
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 4)  0x001d0194
> lookup__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11Dynamic
> ListXTP4 + 0x168  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 5)  0x001cff40
> find__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11DynamicLi
> stXTP4No + 0x9c  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 6)  0x001a8744
> hasPointerToMemberComing__12PreprocessorFQ2_12Preprocessor8PTMStateP11De
> claratio + 0x844  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 7)  0x0023d468   isProbablyAnIdentifier__12PreprocessorFb + 0x54
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 8)  0x001cdc24
> resolveIdentifier__12PreprocessorFP12ScannerValue11StringToken + 0xbd4
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 9)  0x001cbad8   nextToken__12PreprocessorFP12ScannerValue + 0x210
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> (10)  0x00273f30   DoCompile__8CompilerFv + 0xd44
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> (11)  0x000b7c00   DoCompile__8CompilerFP6Buffer + 0x34
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> (12)  0x000c3a28   DoCompileFile__8CompilerFPc + 0x110
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> (13)  0x000cb744   main + 0x404  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> (14)  0xc01434d0   _start + 0xc0  [/usr/lib/libc.2]
> (15)  0x000b8120   $START$ + 0x178  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> Error (system problem) 689: # Compiler received signal 11
>
>   This looks similar to the issue described in STDCXX-276, but only the
> locale_body.cpp source file fails to build.  The library seems to build
> fine, but I'm not sure how this may effect its behavior.  I wasn't able
> to find a mention of this issue in the documentation- hopefully I didn't
> miss it.
>   Any insight into the cause of this issue and effects it may have on
> the library would be appreciated.

If it's the same thing as STDCXX-276 (i.e., the ICE happens when
generating dependencies) it's safe to ignore it. The error is due
to a compiler bug: http://issues.apache.org/jira/browse/STDCXX-275
and the only thing it affects is the .d file in the lib/.depend
directory, which just contains dependencies for make to know when
to recompile the source after a change to one or more of the
headers it includes.

Martin

[Patrick Happel-2]

Thanks, Martin.  I'll pass this on to the customer.

 -Patrick

-----Original Message-----
From: Martin Sebor [mailto:sebor@...]
Sent: Thursday, February 07, 2008 3:17 PM
To: user@...
Subject: Re: Signal 11 when building on HP-UX w/ aCC 3.73

Patrick Happel wrote:
> Hello,
>   A customer I'm working with noticed the following error, which seems

> to occur when building the stdcxx 4.2.0 release packaged with
> SourcePro Ed 10 on HP-UX 11.11 with aCC A.03.73:
>  
> generating dependencies for $(TOPDIR)/src/locale_body.cpp aCC +Maked
> -E  -D_RWSTDDEBUG
> -I/nmlpkgs/sourcepro10_build/3rdparty/stdcxx/stdcxx-4.2.0/include
> -I/nmlpkgs/sourcepro10_oc15/stdcxx/ad/include  -AA  -g +d   +w +W392
> +W655 +W684 +W818 +W819 +W849  +Z
>
/nmlpkgs/sourcepro10_build/3rdparty/stdcxx/stdcxx-4.2.0/src/locale_body.
> cpp
> Signal 11
> ( 0)  0x002983b8   sighandler__FiT1 + 0x134
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 1)  0xc020bfe0   _sigreturn  [/usr/lib/libc.2]
> ( 2)  0x002748d8   synthesize__15LibraryRoutinesF19LibraryRoutinesEnum
+
> 0x7c  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 3)  0x00278880   enter__15LibraryRoutinesF19LibraryRoutinesEnum +
0x10
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 4)  0x001d0194
> lookup__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11Dynam
> ic
> ListXTP4 + 0x168  [/nmlpkgs/aCC373/lbin/ctcom.pa20] ( 5)  0x001cff40
> find__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11Dynamic
> Li stXTP4No + 0x9c  [/nmlpkgs/aCC373/lbin/ctcom.pa20] ( 6)  0x001a8744

> hasPointerToMemberComing__12PreprocessorFQ2_12Preprocessor8PTMStateP11
> De claratio + 0x844  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 7)  0x0023d468   isProbablyAnIdentifier__12PreprocessorFb + 0x54
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 8)  0x001cdc24
> resolveIdentifier__12PreprocessorFP12ScannerValue11StringToken + 0xbd4

> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> ( 9)  0x001cbad8   nextToken__12PreprocessorFP12ScannerValue + 0x210
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> (10)  0x00273f30   DoCompile__8CompilerFv + 0xd44
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> (11)  0x000b7c00   DoCompile__8CompilerFP6Buffer + 0x34
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> (12)  0x000c3a28   DoCompileFile__8CompilerFPc + 0x110
> [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> (13)  0x000cb744   main + 0x404  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> (14)  0xc01434d0   _start + 0xc0  [/usr/lib/libc.2]
> (15)  0x000b8120   $START$ + 0x178  [/nmlpkgs/aCC373/lbin/ctcom.pa20]
> Error (system problem) 689: # Compiler received signal 11
>
>   This looks similar to the issue described in STDCXX-276, but only
> the locale_body.cpp source file fails to build.  The library seems to
> build fine, but I'm not sure how this may effect its behavior.  I
> wasn't able to find a mention of this issue in the documentation-
> hopefully I didn't miss it.
>   Any insight into the cause of this issue and effects it may have on
> the library would be appreciated.

If it's the same thing as STDCXX-276 (i.e., the ICE happens when
generating dependencies) it's safe to ignore it. The error is due to a
compiler bug: http://issues.apache.org/jira/browse/STDCXX-275
and the only thing it affects is the .d file in the lib/.depend
directory, which just contains dependencies for make to know when to
recompile the source after a change to one or more of the headers it
includes.

Martin

[Giai Truong]

Hello,

A customer discovered a problem with std::numeric_limits<> in stdcxx.
Passing std::numeric_limits<> as an lvalue as in the example below
results in undefined symbols for the symbol std::numeric_limits<> at
link time:
   
#include <iostream>
#include <algorithm>
#include <limits>

int main()
{
  int i = std::numeric_limits<double>::digits10;
  int j = std::min(std::numeric_limits<double>::digits10, 10);
//Undefined Symbols
  int j1 = std::max(std::numeric_limits<float>::min_exponent10, 2);
//Undefined Symbols
  std::cout << i << std::endl;
  std::cout << j << std::endl;
}


Undefined                       first referenced
 symbol                             in file
std::numeric_limits<double>::digits10 t.o
[Hint: static member std::numeric_limits<double>::digits10 must be
defined in the program]

ld: fatal: Symbol referencing errors. No output written to t
*** Error code 1
make: Fatal error: Command failed for target `t'

Any insight into the cause of this issue? The problem doesn't seem to
occur with native STL. The platform is Solaris/Sun Studio.

[Martin Sebor]

It's caused by a compiler bug. I reduced it to a small test case
(see http://issues.apache.org/jira/browse/STDCXX-936) and sent it
to Sun. It has been assigned a review ID of 1249871.

The fix is to use the quoted form of the #include directive in
limits.cpp, like so:

Index: src/limits.cpp
===================================================================
--- src/limits.cpp      (revision 656806)
+++ src/limits.cpp      (working copy)
@@ -22,7 +22,7 @@
   * implied.   See  the License  for  the  specific language  governing
   * permissions and limitations under the License.
   *
- * Copyright 1994-2006 Rogue Wave Software.
+ * Copyright 1994-2008 Rogue Wave Software, Inc.
   *
 
**************************************************************************/

@@ -31,12 +31,12 @@
  #include <rw/_defs.h>

  // define generic template and specializations
-#include <limits>
+#include "limits"

  #if _MSC_VER != 1300   // working around an MSVC 7.0 bug (PR #26562)
  #  undef _RWSTD_LIMITS_INCLUDED
  #  define _RWSTD_DEFINE_EXPORTS

     // define static data members of specializations
-#  include <limits>
+#  include "limits"
  #endif   // MSVC != 7.0


Giai Truong wrote:

> Hello,
>
> A customer discovered a problem with std::numeric_limits<> in stdcxx.
> Passing std::numeric_limits<> as an lvalue as in the example below
> results in undefined symbols for the symbol std::numeric_limits<> at
> link time:
>    
> #include <iostream>
> #include <algorithm>
> #include <limits>
>
> int main()
> {
>   int i = std::numeric_limits<double>::digits10;
>   int j = std::min(std::numeric_limits<double>::digits10, 10);
> //Undefined Symbols
>   int j1 = std::max(std::numeric_limits<float>::min_exponent10, 2);
> //Undefined Symbols
>   std::cout << i << std::endl;
>   std::cout << j << std::endl;
> }
>
>
> Undefined                       first referenced
>  symbol                             in file
> std::numeric_limits<double>::digits10 t.o
> [Hint: static member std::numeric_limits<double>::digits10 must be
> defined in the program]
>
> ld: fatal: Symbol referencing errors. No output written to t
> *** Error code 1
> make: Fatal error: Command failed for target `t'
>
> Any insight into the cause of this issue? The problem doesn't seem to
> occur with native STL. The platform is Solaris/Sun Studio.