RE: Porting gcc to HP Nonstop Ux

["praveen" <praveen dot khanna at wipro dot com>]

Hi Jim,

Thanks a lot for the response. I shall try to look into the problems.

I had two things to discuss:

1. Regarding the problem with the redefinition of __STDC__, I had used
the following tm_file for my system(have attached the same).

Our compiler(the SGI cc ported on our systems) supports three modes of
compilation, 
-Xt or -std0
             This is the default. The traditional K&R Version 7 C
             with  various  extensions, including function proto-
             types, void and  void*.   The  symbols  _MIPS_FPSET,
             _MIPS_ISA,   _MIPS_SIM,  _MIPS_SZINT,  _MIPS_SZLONG,
             _MIPS_SZPTR, LANGUAGE_C,  _LANGUAGE_C,  __nonstopux,
             unix,   mips,   host_mips   ,  __unix,  __host_mips,
             _SVR4_SOURCE,  SYSTYPE_SVR4,  _SYSTYPE_SVR4,  _LONG-
             LONG,  __mips, _MIPSEB, MIPSEB, and _CFE are defined
             to the preprocessor.

-Xc or -std1
            (ANSI/ISO C only.)  Pure ANSI/ISO  C.   The  symbols
             _MIPS_FPSET,   _MIPS_ISA,   _MIPS_SIM,  _MIPS_SZINT,
             _MIPS_SZLONG,  _MIPS_SZPTR,   _LANGUAGE_C,   __unix,
             __host_mips,    _SYSTYPE_SVR4,    __mips,   _MIPSEB,
             __STDC__, and _CFE are defined to the  preprocessor.
             ANSI/ISO  trigraphs  are processed by default.  When
             compiling in pure  ANSI/ISO  mode  (-Xc  or  -std1),
		             several  standard  UNIX  symbols  (e.g.,
environ and
             end) may  only  be  referenced  by  their  ANSI/ISO-
             compliant  counterparts  (e.g.,  _environ and _end).
             The type long long is allowed but results in a warn-
             ing in -Xc (-std1) mode.

     -Xa or -std
             (ANSI/ISO C only.)  ANSI/ISO C  with  all  the  same
             definitions  as  -cckr.   __STDC__  is  defined, the
             value is set to 0, and it adds many symbols into the
             namespace.


To mimic that, we had written in the tm_file, name nonstopux.h,
"#define SUBTARGET_CPP_SPEC " \
%{!ansi:%{!traditional:-D_LONGLONG -D_NEC_SOURCE -D__STDC__=0}} \
%{ansi:-D__STDC__=1} \
%{traditional:-D_LONGLONG -Dhost_mips -Dunix -U__STDC__} \
%{!mips*:-D_MIPS_ISA=_MIPS_ISA_MIPS2 -D__mips=2 -D__mips__=2 \
        %{traditional:-Dmips=2} \
} \"


Perhaps the above could be a source of the problem, in traditional,
__STDC__ is undefined while
In -std, it is defined as 0.

Could that be a source of the warning?

2. Another question that I had is once a successful port is done, how do
we declare it to gnu.
Do I send the modified/new files to the gnu product specifc group and
then they will incorporate it
As a prt of their product. In short, how is a new port accepted by the
gnu product specific groups.

Thanks very much. 
With Regards-Praveen
------------------------------------------------------------------------
----------------
Praveen Khanna                       Tel:(91)-(80)-5732296(2020)
Wipro Technologies,                       98442-63812
#26,Hosur Main Road,               e-mail:praveen.khanna@wipro.com      
Bommanhalli,                  
Bangalore-68
"Kindness is in our power, even when fondness is not. 
-Samuel Johnson, lexicographer"
------------------------------------------------------------------------
----------------


-----Original Message-----
From: Jim Wilson [mailto:wilson@tuliptree.org] 
Sent: Friday, May 02, 2003 1:03 AM
To: praveen
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: Porting gcc to HP Nonstop Ux


praveen wrote:
> In trying to port gcc, I was able to build gcc till stage2. During the
> stage3 build, I got the following problem:
> /usr/lib/cmplrs/cc/ld:
> gengenrtl.o: Error: Unresolved:
> formats

Since the stage2 output looks OK, and the stage3 output doesn't, this 
means the stage2 compiler is broken.  It must have been miscompiled by 
the stage1 compiler.  This implies that there is something wrong with 
your port, since your port is generating bad code.  It is also possible 
that the stage1 gcc was miscompiled by the host compiler.

This may take you some time to track down.  You need to first figure out

what is wrong with the stage2 compiler.  You need to figure out why it 
is generating bad code.  Adding a -S option to the gengenrtl.o build 
command may help, or alternatively you can use --save-temps.  You will 
have to debug the stage2 compiler to figure out what is wrong with it. 
You should be able to identify a line of code that has been miscompiled.
Comparing stage1 .s output against stage2 .s output should be helpful.

Then you debug the stage1 compiler to figure out why that line of code 
was miscompiled.  If this is an optimizer bug, then add the -da option 
to dump all debugging dumps.  You can use this info to narrow down where

the miscompilation occurred.  Once you know what is wrong with the 
stage1 compiler, you should be able to fix your port to avoid the
problem.

Jim

Attachment: nonstopux.h
Description: Binary data