NCR compiler problems on NCR

NCR compiler problems on NCR

[Cosmo]

I'm trying to make some use of an old NCR machine but I am having some trouble
compiling Zsh with the native compiler. The configure script works out that there
is a 64 bit type of long long and so zlong is defined as such. However the compiler
does not like the following syntax:

extern long long func1();

func2()
{
    /* This fails */
    int Z1 = (int)func1();
    
    /* This is OK */
    long long Z2 = func1();
}

Giving errors like:

>>>At "b.c", 8: >>>>>>>>   S Y S T E M   E R R O R   1   <<<<<<<<, in 
pop() -- stack is empty!

This is a problem in the zsh src (I'm using 3.1.9) with all the references
to zstrtol() which is of type zlong->long long. 

Trying to compile gcc on this machine is also not going very well so I need
a way to dissable the detection of long long type or some other way to get 
round this problem. It has an old zsh 2.6 which works but needs to be 
replaced.

cc -V gives me: NCR High Performance C Compiler R1.0 (SCDE 2.03.00)

If any one knows how to fix the compiler, fix the zsh src config or build
a working gcc I'd love to know.




Cosmo

RE: NCR compiler problems on NCR

[Andrej Borsenkow]

>
> I'm trying to make some use of an old NCR machine but I am having
> some trouble
> compiling Zsh with the native compiler. The configure script works
> out that there
> is a 64 bit type of long long and so zlong is defined as such.
> However the compiler
> does not like the following syntax:
>
...
>
> If any one knows how to fix the compiler, fix the zsh src config or build
> a working gcc I'd love to know.
>

Try to run zsh's configure with --disable-lfs. See --help output if I
misspelled it. It should prevent Zsh from searching for 64 bit type _unless_
your system happens to have 64-bit off_t or ino_t.

Remove old config.cache, of course.

-andrej

Re: NCR compiler problems on NCR

[Cosmo]

Andrej Borsenkow wrote:
> 
> >
> > I'm trying to make some use of an old NCR machine but I am having
> > some trouble
> > compiling Zsh with the native compiler. The configure script works
> > out that there
> > is a 64 bit type of long long and so zlong is defined as such.

> Try to run zsh's configure with --disable-lfs. See --help output if I
> misspelled it. It should prevent Zsh from searching for 64 bit type _unless_
> your system happens to have 64-bit off_t or ino_t.

That works, thanx a lot! Perhaps this should be added to Etc/MACHINES?





Cosmo

RE: NCR compiler problems on NCR

[Andrej Borsenkow]

>
> Andrej Borsenkow wrote:
> >
> > >
> > > I'm trying to make some use of an old NCR machine but I am having
> > > some trouble
> > > compiling Zsh with the native compiler. The configure script works
> > > out that there
> > > is a 64 bit type of long long and so zlong is defined as such.
>
> > Try to run zsh's configure with --disable-lfs. See --help output if I
> > misspelled it. It should prevent Zsh from searching for 64 bit
> type _unless_
> > your system happens to have 64-bit off_t or ino_t.
>
> That works, thanx a lot! Perhaps this should be added to Etc/MACHINES?
>

Better yet is a configure check that compiler can cast long long to int. As
long as you are the only person who can reproduce it - would you mind to write
a patch? Or at least would you take time to check if it works?

The relevant part is zsh_64_BIT_TYPE macro in aczsh.m4. Currently it just
checks that sizeof(long long) == 8; it is trivial to add one more check if it
can cast value to int.

cheers

-andrej

PATCH: NCR compiler problems on NCR

[Andrej Borsenkow]

>
> Better yet is a configure check that compiler can cast long long to int. As
> long as you are the only person who can reproduce it - would you
> mind to write
> a patch? Or at least would you take time to check if it works?
>


Cosmo, could you please check, that this patch fixes your problem? (I mean,
that configure now autodetects broken 64 bit type)? It does not break things
here, at least :-)

cheers

-andrej

Index: aczsh.m4
===================================================================
RCS file: /cvsroot/zsh/zsh/aczsh.m4,v
retrieving revision 1.5
diff -u -r1.5 aczsh.m4
--- aczsh.m4	2000/09/06 15:50:16	1.5
+++ aczsh.m4	2000/10/11 08:49:56
@@ -87,9 +87,14 @@
 dnl   This macro does not produce messages as it may be run several times
 dnl   before finding the right type.
 dnl
+dnl   Cosmo <cosmo@informix.com> reported, that NCR C compiler
+dnl   (High Performance C Compiler R1.0 (SCDE 2.03.00)) supports long long
+dnl   but cannot cast it to int. Check for this too.

 AC_DEFUN(zsh_64_BIT_TYPE,
-[AC_TRY_RUN([
+[
+zsh_64_bit_type_found=no
+AC_TRY_RUN([
 #ifdef HAVE_SYS_TYPES_H
 #include <sys/types.h>
 #endif
@@ -99,12 +104,25 @@
   $1 foo = 0;
   return sizeof($1) != 8;
 }
-], $2="$1", $2=no,
-  [if test x$3 != x ; then
+], zsh_64_bit_type_found=yes)
+if test x$zsh_64_bit_type_found = xyes; then
+AC_TRY_COMPILE([
+#ifdef HAVE_SYS_TYPES_H
+#include <sys/types.h>
+#endif
+extern long long func1();],
+[int Z1 = (int)func1();], , zsh_64_bit_type_found=no)
+fi
+[if test x$zsh_64_bit_type_found = xyes; then
+  $2="$1"
+else
+  $2=no
+  if test x$3 != x ; then
     $2="$1"
   else
     $2=no
-  fi])
+  fi
+fi]
 ])

Re: NCR compiler problems on NCR

[Cosmo]

Andrej Borsenkow wrote:

> Better yet is a configure check that compiler can cast long long to int. As
> long as you are the only person who can reproduce it - would you mind to write
> a patch? Or at least would you take time to check if it works?

OK here's a patch that causes configure to not use long long with my broken NCR
compiler. Now ./configure works straight out of the box on this machine.

*** zsh/aczsh.m4-orig	Wed Sep  6 16:50:16 2000
--- zsh/aczsh.m4	Wed Oct 11 11:27:18 2000
***************
*** 84,89 ****
--- 84,90 ----
  dnl   Sets the variable given in the second argument to the first argument
  dnl   if the test worked, `no' otherwise.  Be careful testing this, as it
  dnl   may produce two words `long long' on an unquoted substitution.
+ dnl   Also check that the compiler does not mind it being cast to int.
  dnl   This macro does not produce messages as it may be run several times
  dnl   before finding the right type.
  dnl
***************
*** 97,102 ****
--- 98,104 ----
  main()
  {
    $1 foo = 0;
+   int bar = (int) foo;
    return sizeof($1) != 8;
  }
  ], $2="$1", $2=no,

RE: NCR compiler problems on NCR

[Andrej Borsenkow]

> 
> OK here's a patch that causes configure to not use long long with 
> my broken NCR
> compiler. Now ./configure works straight out of the box on this machine.
> 

I've committed it. 

-andrej