jkmcnk / sx-gcc

The GNU Compiler Collection port to NEC SX CPU architecture.
GNU General Public License v2.0
0 stars 2 forks source link

the "22_locale/collate/transform/wchar_t/28277.cc" test case fails if compiled with sx-g++ #136

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
It looks like the "22_locale/collate/transform/wchar_t/28277.cc" fails
because we are unable to allocate the sufficient amount of memory for the
test on SuperUX.

This is the output we get if we insert a ouple of printf statements in the
"libstdc++-v3/libsupc++/new_op.cc" file (this file contains the
implementation of the "operator new" operator for creating objects):

new_op.cc: allocating memory: size=40001504
new_op.cc: allocating memory: size=40001504
new_op.cc: allocating memory: size=80000000
new_op.cc: cannot allocate memory new_op.cc
test-gplusplus.cpp: allocation error: std::bad_alloc

The "new_op.cc: cannot allocate memory new_op.cc" error is printed out
because the "malloc" function is unable to allocate the 80MB of memory.

Does the SuperUX on the "a1" and "asama" perhaps have some restrictions on
the amount of memory that can be allocated?

Original issue reported on code.google.com by nou...@gmail.com on 16 Jun 2009 at 12:03

GoogleCodeExporter commented 8 years ago
It turns out that this is indeed the "malloc" issue. The program below also 
fails to
allocate 160MB of memory if executed on "a1":

{{{

#include <stdio.h>
#include <stdlib.h>

int main ()
{
  char * buffer;

  printf("Allocating memory... \n");
  buffer = (char*) malloc (160000000);
  if (buffer==NULL) {
    printf("Cannot allocate memory!\n");
    exit (1);
  }

  free (buffer);

  return 0;
}

}}}

Original comment by nou...@gmail.com on 16 Jun 2009 at 12:05

GoogleCodeExporter commented 8 years ago
As it turns out, the example above fails to allocate memory even if compiled 
with the
"sxcc" compiler on SuperUX...

Original comment by nou...@gmail.com on 16 Jun 2009 at 12:10

GoogleCodeExporter commented 8 years ago
It turns out the problem wasn't in the sx-gcc port, but the memory restrictions 
that
were enforced on the user account which was used for executing tests. 

The "ulimit" command showed that interactive users have only "195313kB" of 
memory
available. After increasing this limit, the "malloc" and C++ tests execute fine.

Original comment by nou...@gmail.com on 16 Jun 2009 at 1:53