Henry Sudhof wrote:

Hi, I am experiencing the very same problems when compiling polyml 5 under Solaris 10 /SPARC. I was able to sidestep the ld errors by using stabs instead of the default debugging symbols (running configure with ' CFLAGS="-gstabs -O3" CXXFLAGS="-gstabs -O3" '), however that just led to this (without debugging behaves just as stabs):

Yeah, that is the reported segfault error I mentioned. I get this error also with gcc 4.0.2, and Martin Preen reported it with gcc 4.1.1

-- Peter

--snip

make all-recursive Making all in libpolyml Making all in libpolymain ./polyimport -H 10 imports/polymlsparc.txt < exportPoly.sml > /dev/null bash: line 1: 18755 Segmentation Fault ./polyimport -H 10 imports/polymlsparc.txt <exportPoly.sml >/dev/null *** Error code 139 make: Fatal error: Command failed for target `polyexport.o' Current working directory /home/swt/hsudhof/polyml *** Error code 1 The following command caused the error: failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ target=`echo all-recursive | sed s/-recursive//`; \ list='libpolyml libpolymain'; for subdir in $list; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ dot_seen=yes; \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (cd $subdir && make $local_target) \ || eval $failcom; \ done; \ if test "$dot_seen" = "no"; then \ make "$target-am" || exit 1; \ fi; test -z "$fail" make: Fatal error: Command failed for target `all-recursive' Current working directory /home/swt/hsudhof/polyml *** Error code 1 make: Fatal error: Command failed for target `all'

--snap

--snip

gcc -v Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs Configured with: /gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix

--snap

Thanks in advance, Regards,

Henry Sudhof

Peter Lammich wrote:

...

with gcc 4.0.2, I get the same segfault as already reported on this list. When using gcc 3.4.3, I get the following error:

... g++ -shared -nostdlib /usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.3/crti.o /usr/ccs/lib/values-Xa.o /usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.3/crtbegin.o .libs/mpoly.o .libs/gc.o .libs/diagnostics.o .libs/arb.o .libs/reals.o .libs/timing.o .libs/processes.o .libs/profiling.o .libs/realconv.o .libs/objsize.o .libs/proper_io.o .libs/foreign.o .libs/process_env.o .libs/basicio.o .libs/network.o .libs/unix_specific.o .libs/sighandler.o .libs/xwindows.o .libs/check_objects.o .libs/scanaddrs.o .libs/polystring.o .libs/run_time.o .libs/osmem.o .libs/save_vec.o .libs/rts_module.o .libs/bitmap.o .libs/poly_specific.o .libs/exporter.o .libs/sharedata.o .libs/memmgr.o .libs/pexport.o .libs/sparc_dep.o .libs/sparc_assembly.o .libs/elfexport.o -Wl,-R -Wl,/usr/sfw/lib -Wl,-R -Wl,/usr/sfw/lib -lsocket -lnsl -ldl -lgcc -L/usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.3 -L/usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3 -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../sparc-sun-solaris2.10/lib -L/usr/ccs/lib -L/usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.3/../../.. -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../.. /usr/sfw/lib/libstdc++.so -L/usr/sfw/lib -lm -lgcc_s /usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.3/crtend.o /usr/o0/gcc-3.4.3/sparc-sun-solaris2/usr/sfw/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.3/crtn.o -Wl,-h -Wl,libpolyml.so.0 -o .libs/libpolyml.so.0.0.0 ld: fatal: relocation error: R_SPARC_32: file .libs/sparc_assembly.o: symbol <unknown>: offset 0xfe34b57b is non-aligned ld: fatal: relocation error: R_SPARC_32: file .libs/sparc_assembly.o: symbol <unknown>: offset 0xfe34b581 is non-aligned ld: fatal: relocation error: R_SPARC_32: file .libs/sparc_assembly.o: symbol <unknown>: offset 0xfe34b585 is non-aligned ld: fatal: relocation error: R_SPARC_32: file .libs/sparc_assembly.o: symbol <unknown>: offset 0xfe34b589 is non-aligned ld: fatal: relocation error: R_SPARC_32: file .libs/sparc_assembly.o: symbol <unknown>: offset 0xfe3886f6 is non-aligned collect2: ld returned 1 exit status *** Error code 1

My system is [pergolesi] ~/opt/src/polyml.5.0 $ uname -a SunOS pergolesi 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Fire-V240 [pergolesi] ~/opt/src/polyml.5.0 $ gcc --version gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

Thanks in advance for any hints/help and greetings Peter Lammich

---

polyml mailing list polyml@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/polyml

Hello, I was wondering if PolyML does any cleaver memory sharing when using constructors.

Here's what I mean...

given:

datatype tree = Lf of int | Br of tr * tr

if I write:

fun trmap f (Lf x) = Lf (f x) | trmap f (Br (a,b)) = Br (trmap f a, trmap f b);

can PolyML avoid allocating more memory if I do the following:

trmap (fn x => if x = 0 then x + 1 else x) (Br (Lf 1, Lf 1))

My understanding is that most ML systems will allocate new memory every time they see a constructor, even if the same constructor on the same arguments already exists. I think that the compiler could automatically optimise such things and avoid the need for horrible exception throwing code which is otherwise useful to optimise memory management. Does PolyML do anything like this?

Any thoughts or suggestions?

thanks, lucas

Lucas Dixon wrote:

I get the a similar error when trying to install polyml 5 using darwin ports on MacOSX 10.3.9 (PPC).

It is unlikely that this is the same problem. Have you tried building from the original source rather than the darwin port?

I have a good idea what the problem is with the Sparc and Solaris 10 but since I haven't got access to a Sparc with Solaris 10 I can't test it to be sure. There is an experimental version of Poly/ML in CVS on sourceforge (See http://www.polyml.org/download.html for how to use it) and this version does not use the g7 register that may have been causing the problems. It will still need the CFLAGS="-gstabs -O3" CXXFLAGS="-gstabs -O3" workaround.

David

David Matthews wrote:

Lucas Dixon wrote:

...

I get the a similar error when trying to install polyml 5 using darwin ports on MacOSX 10.3.9 (PPC).

It is unlikely that this is the same problem. Have you tried building from the original source rather than the darwin port?

Yes, the same happens.

I have a good idea what the problem is with the Sparc and Solaris 10 but since I haven't got access to a Sparc with Solaris 10 I can't test it to be sure. There is an experimental version of Poly/ML in CVS on sourceforge (See http://www.polyml.org/download.html for how to use it) and this version does not use the g7 register that may have been causing the problems. It will still need the CFLAGS="-gstabs -O3" CXXFLAGS="-gstabs -O3" workaround.

I can set these just by export CFLAGS="... ", right?

doing this with the CVS version gives me the following compile error:

/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -DPOWER2 -DMACOSX -Wall -gstabs -O3 -MT gc.lo -MD -MP -MF .deps/gc.Tpo -c -o gc.lo gc.cpp g++ -DHAVE_CONFIG_H -I. -I.. -DPOWER2 -DMACOSX -Wall -gstabs -O3 -MT gc.lo -MD -MP -MF .deps/gc.Tpo -c gc.cpp -fno-common -DPIC -o .libs/gc.o gc.cpp: In function `void CopyStackFrame(StackObject*, StackObject*)': gc.cpp:276: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See URL:http://developer.apple.com/bugreporter for instructions. make[2]: *** [gc.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2

is there any other information you would like?

cheers, lucas