Problem in split_basic_block

Problem in split_basic_block

[Richard Kenner]

This comes up compiling the Ada library for ia64/VMS with SJLJ exceptions
and flag_non_call_exceptions.

Suppose we have a block with a CALL_INSN.  Ity has a REG_EH_REGION note.
The ia64 splitter splits that up into a number of insns, some of which
are memory load insns.  Then split_insns copies the REG_EH_REGION note
to that load insn.

Now we try to split the block.  The code moves all edges to the new
block.  But that's wrong since there might have been an ABNORMAL_CALL
edge that depended on the last insn of the block being a CALL_INSN.
But the CALL_INSN is now in the previous block.

Suggestions?

I don't understand this stuff too well.

Re: Problem in split_basic_block

[Richard Henderson]

On Fri, Aug 01, 2003 at 06:21:34PM -0400, Richard Kenner wrote:
> Suggestions?

Provide a test case.


r~

Re: Problem in split_basic_block

[Olivier Hainque]

Hello,

Richard Henderson wrote:
> [sherman:/scratch/rth/build/vms/gcc/ada] ../gnat1 -O2 [...] a-calend.adb
> 
> So was I expecting a crash, or something?
 
We now understand why you did not see the crash with Ada, and eventually came
up with a tiny C++ testcase exhibiting the issue Richard Kenner raised.

Using the same compiler, could you please try to compile the reproducer below
with -fnon-call-exceptions:

     // foo.cc
     void hook (void)
     {
     }

     void foo (void)
     {
       int x, y;

       try {
	 y = 0;
       } catch (...) {
	 hook ();
       }
     }

We are seeing this:

 $ ./cc1plus -fnon-call-exceptions foo.cc
 void hook()
 void hook()
 void foo()
 void foo()

foo.cc:15: error: Call edges for non-call insn in bb 9
foo.cc:15: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

Thanks in advance,

Olivier

Re: Problem in split_basic_block

[Richard Kenner]

    addp4 does a 32-bit add and then copies the 2 most significant bits of
    the 32-bit result (31 and 30) into the 2 most significant bits of the
    target register (63 and 62).  This gives you access to 4 segments
    (regions).

Right, I know that.

    You really should have some understanding of the IA-64 ISA if you are 
    trying to do a port.

I'm not the person most involved in the port, just the one that's
working on this particular bug.  The people doing the port certainly have
that documentation.

    See Vol 2 Section 4.1.9 32-bit Virtual Addressing.  This documents how 
    to do zero-extend, sign-extend, or pointer-swizzling addressing via 
    addp4.  All 3 are supported by the architecture.

OK, then there's indeed no efficiency issue after all.  Good.  HP obviously
gets to choose which one they want to use for VMS.

Re: Problem in split_basic_block

[Jim Wilson]

Richard Kenner wrote:
> Interesting.  I don't know the ia64 instruction set, but I'd always
> thought of the addp4 stuff as a horrible kludge.  I'm kind of curious
> about this myself now.

The upper three bits of an IA-64 address indicate the segment (region). 
  This is somewhat similar to the VAX I believe.  If you don't want 
segments you can define them in the obvious way to get a flat address space.

addp4 does a 32-bit add and then copies the 2 most significant bits of 
the 32-bit result (31 and 30) into the 2 most significant bits of the 
target register (63 and 62).  This gives you access to 4 segments (regions).

You really should have some understanding of the IA-64 ISA if you are 
trying to do a port.  IA-64 architecture manuals are available here:
	http://developer.intel.com/design/itanium/manuals.htm

See Vol 2 Section 4.1.9 32-bit Virtual Addressing.  This documents how 
to do zero-extend, sign-extend, or pointer-swizzling addressing via 
addp4.  All 3 are supported by the architecture.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Problem in split_basic_block

[Richard Kenner]

    [sherman:/scratch/rth/build/vms/gcc/ada] ../gnat1 -O2   -I- -I. -I../../../../src-gcc/gcc/ada -quiet -dumpbase a-calend.adb -g -gnatpg -gnata -W -Wall ../../../../src-gcc/gcc/ada/a-calend.adb -o /tmp/foo.s

    So was I expecting a crash, or something?

I got one.  Did you configure with sjlj-exceptions?

Also, I don't think I used -O2.

Re: Problem in split_basic_block

[Richard Henderson]

On Wed, Aug 06, 2003 at 06:58:59PM -0400, Richard Kenner wrote:
> Then try to compile the Ada library module a-calend.adb with -gnatpg.

[sherman:/scratch/rth/build/vms/gcc/ada] ../gnat1 -O2   -I- -I. -I../../../../src-gcc/gcc/ada -quiet -dumpbase a-calend.adb -g -gnatpg -gnata -W -Wall ../../../../src-gcc/gcc/ada/a-calend.adb -o /tmp/foo.s

So was I expecting a crash, or something?


r~

Re: Problem in split_basic_block

[Richard Kenner]

    But if you don't use addp4, you wind up with extra sext insns all
    the time.  Unlike Alpha, there's no add instruction that sign (or
    zero) extends from 32-bits.

Interesting.  I don't know the ia64 instruction set, but I'd always
thought of the addp4 stuff as a horrible kludge.  I'm kind of curious
about this myself now.

Anybody from HP know?

Re: Problem in split_basic_block

[Richard Henderson]

On Thu, Aug 07, 2003 at 04:38:04PM -0400, Richard Kenner wrote:
> I'm pretty sure not: it's only HPUX that's using it.  They are handling
> it the same way as VMS on Alpha.

Well, the thing is, they needn't set up the segments in any way
that's actually screwy.  They *can* lay them out nicely sequential.

But if you don't use addp4, you wind up with extra sext insns all
the time.  Unlike Alpha, there's no add instruction that sign (or
zero) extends from 32-bits.

None of my business, I guess.


r~

Re: Problem in split_basic_block

[Richard Kenner]

    ia64-vms really isn't going to use addp4 style extension?

I'm pretty sure not: it's only HPUX that's using it.  They are handling
it the same way as VMS on Alpha.

Re: Problem in split_basic_block

[Richard Henderson]

[ On a side note... ]

On Wed, Aug 06, 2003 at 06:58:59PM -0400, Richard Kenner wrote:
> + /* Pointer is 32 bits but the hardware has 64-bit addresses, sign extended.  */
> + #undef POINTER_SIZE
> + #define POINTER_SIZE 32
> + #define POINTERS_EXTEND_UNSIGNED 0

ia64-vms really isn't going to use addp4 style extension?


r~

Re: Problem in split_basic_block

[Richard Kenner]

    Does DEC C come with the operating system?  If not, there would be GPL
    problems.

Yeah, but a very marginal one.  I don't think that the assembler comes
with VMS either, though I'm not sure.  The intent of that part of the GPL,
as I understand it, is not to create a situation where the *distributor*
of the software would be demanding use of one of its proprietary programs
in order to build the software.  This is very different.  In the world
of "unbundling", it's not all uncommon for something needed to build GCC
to be in some optional "software development" component.

Re: Problem in split_basic_block

[Geoff Keating]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     > Because gcc doesn't have "pragma POINTER_SIZE <long | short>"
> 
>     It shouldn't be that hard to add.
> 
> Supporting multiple pointer sizes at the same time is a mess and it seems
> unnecessary work just to avoid having to compile two files with DEC C.

Does DEC C come with the operating system?  If not, there would be GPL
problems.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Problem in split_basic_block

[Nathanael Nerode]

>    So fix it in the setting of the installation path, not the
>    target_alias itself.
>
>But that's in common code: it seems better to keep kludges like this 
>local
>to the VMS part of the config file.

It isn't better.

The installation path is meant to be pretty freely alterable by the 
installer. (It isn't at the moment, but that's another issue.)  Adding
a hook to the installation-path part of the code to 'remangle' it for 
the particular system (with the remangling being decided by 'configure') 
would be a worthwhile improvement.  :-)

-- 
Nathanael Nerode  <neroden at gcc.gnu.org>
http://home.twcny.rr.com/nerode/neroden/fdl.html

Re: Problem in split_basic_block

[Richard Kenner]

    So fix it in the setting of the installation path, not the
    target_alias itself.

But that's in common code: it seems better to keep kludges like this local
to the VMS part of the config file.

Re: Problem in split_basic_block

[Richard Kenner]

    > Because gcc doesn't have "pragma POINTER_SIZE <long | short>"

    It shouldn't be that hard to add.

Supporting multiple pointer sizes at the same time is a mess and it seems
unnecessary work just to avoid having to compile two files with DEC C.

Re: Problem in split_basic_block

[Richard Kenner]

    I realize you're not contributing this port now, but...

I agree with most of your comments, except ...

> + # Assemble startup files.
> + vcrt0.o: $(CRT0_S) $(GCC_PASSES)
> + 	./decc -c /names=as_is $(srcdir)/config/ia64/vms-crt0.c -o vcrt0.o
> + 
> + pcrt0.o: $(CRT0_S) $(GCC_PASSES)
> + 	./decc -c /names=as_is $(srcdir)/config/ia64/vms-psxcrt0.c -o pcrt0.o

    why the hell can't this code be compiled with gcc?  (the alpha-vms port
    has the same problem)

The file says why, but I'm not totally sure I understand the comment: I
suspect DEC C special-cases the call in question.

    this also interferes with cross compiler use

Right.  There are numerous host/target confusions in a lot of the VMS stuff
that need to be fixed before the port can be considered finished.

Re: Problem in split_basic_block

[Zack Weinberg]

"Douglas B Rupp" <rupp@gnat.com> writes:
>> > + prefix=/gnu
>> > + local_prefix=/gnu
>>
>> > + #define MD_EXEC_PREFIX "/gnu/lib/gcc-lib/"
>> > + #define MD_STARTFILE_PREFIX "/gnu/lib/gcc-lib/"
>> > +
>> > + /* Specify the list of include file directories.  */
>> > + #define INCLUDE_DEFAULTS    \
>> > + {    \
>> > +   { "/gnu/lib/gcc-lib/include", 0, 0, 0 }, \
>> > +   { "/gnu_gxx_include", 0, 1, 1 },    \
>> > +   { "/gnu_cc_include", 0, 0, 0 },    \
>> > +   { "/gnu/include", 0, 0, 0 },            \
>> > +   { 0, 0, 0, 0 }    \
>> > + }
>>
>> this also interferes with cross compiler use
>
> I admit I don't know this stuff very well, so I fiddled around with
> these macros until I got something that worked.  In the past
> building a full cross compiler hasn't been an issue. If there's a
> better way to do it, please work with me to figure it out.

I'm the wrong person to ask.  I know that hardcoding values for
anything with "prefix" in the name causes problems, and I know that
defining INCLUDE_DEFAULTS does the same (because it overrides the
variations that cppdefaults.c puts in when cross compiling).

Talk to people like Dan Jacobowitz and Eric Christopher, they know
more about cross compiling.

zw

Re: Problem in split_basic_block

[Zack Weinberg]

"Douglas B Rupp" <rupp@gnat.com> writes:

>>
>> > + # This removes the cpu type and manufacturer components and
>> > + #  replaces "." with "_" in the operating system version.
>> > + case $host in *-*-*vms*)
>> > + target_alias=`echo $host \
>> > +   | sed 's/.*-.*-\(.*\)$/\1/' | sed 's/\./_/g'`
>> > + ;;
>> > + esac
>>
>> this should not be necessary
>
> Target_alias ends up in the installation path, and dots are illegal in VMS
> directory names.

So fix it in the setting of the installation path, not the
target_alias itself.

zw

Re: Problem in split_basic_block

[Zack Weinberg]

"Douglas B Rupp" <rupp@gnat.com> writes:

>> > Because gcc doesn't have "pragma POINTER_SIZE <long | short>"
>> 
>> It shouldn't be that hard to add.
>
> I was told it was alot of work.

Hmm, on reflection, it might be - specifically, operating with two
different pointer widths simultaneously might be difficult.  I
withdraw this criticism.

zw

Re: Problem in split_basic_block

[Douglas B Rupp]

>
> > + prefix=/gnu
> > + local_prefix=/gnu
>
> > + #define MD_EXEC_PREFIX "/gnu/lib/gcc-lib/"
> > + #define MD_STARTFILE_PREFIX "/gnu/lib/gcc-lib/"
> > +
> > + /* Specify the list of include file directories.  */
> > + #define INCLUDE_DEFAULTS    \
> > + {    \
> > +   { "/gnu/lib/gcc-lib/include", 0, 0, 0 }, \
> > +   { "/gnu_gxx_include", 0, 1, 1 },    \
> > +   { "/gnu_cc_include", 0, 0, 0 },    \
> > +   { "/gnu/include", 0, 0, 0 },            \
> > +   { 0, 0, 0, 0 }    \
> > + }
>
> this also interferes with cross compiler use

I admit I don't know this stuff very well, so I fiddled around with these
macros until I got something that worked.  In the past building a full cross
compiler hasn't been an issue. If there's a better way to do it, please work
with me to figure it out.

Re: Problem in split_basic_block

[Douglas B Rupp]

> > Because gcc doesn't have "pragma POINTER_SIZE <long | short>"
> 
> It shouldn't be that hard to add.

I was told it was alot of work.

Re: Problem in split_basic_block

[Douglas B Rupp]

>
> > + # This removes the cpu type and manufacturer components and
> > + #  replaces "." with "_" in the operating system version.
> > + case $host in *-*-*vms*)
> > + target_alias=`echo $host \
> > +   | sed 's/.*-.*-\(.*\)$/\1/' | sed 's/\./_/g'`
> > + ;;
> > + esac
>
> this should not be necessary

Target_alias ends up in the installation path, and dots are illegal in VMS
directory names.

Re: Problem in split_basic_block

[Zack Weinberg]

"Douglas B Rupp" <rupp@gnat.com> writes:

>> > + # Assemble startup files.
>> > + vcrt0.o: $(CRT0_S) $(GCC_PASSES)
>> > + ./decc -c /names=as_is $(srcdir)/config/ia64/vms-crt0.c -o vcrt0.o
>> > + 
>> > + pcrt0.o: $(CRT0_S) $(GCC_PASSES)
>> > + ./decc -c /names=as_is $(srcdir)/config/ia64/vms-psxcrt0.c -o pcrt0.o
>> 
>> why the hell can't this code be compiled with gcc?  (the alpha-vms port
>> has the same problem)
>
> Because gcc doesn't have "pragma POINTER_SIZE <long | short>"

It shouldn't be that hard to add.

zw

Re: Problem in split_basic_block

[Douglas B Rupp]

> > + # Assemble startup files.
> > + vcrt0.o: $(CRT0_S) $(GCC_PASSES)
> > + ./decc -c /names=as_is $(srcdir)/config/ia64/vms-crt0.c -o vcrt0.o
> > + 
> > + pcrt0.o: $(CRT0_S) $(GCC_PASSES)
> > + ./decc -c /names=as_is $(srcdir)/config/ia64/vms-psxcrt0.c -o pcrt0.o
> 
> why the hell can't this code be compiled with gcc?  (the alpha-vms port
> has the same problem)

Because gcc doesn't have "pragma POINTER_SIZE <long | short>"

Re: Problem in split_basic_block

[Zack Weinberg]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

I realize you're not contributing this port now, but...

> + 	# This removes the cpu type and manufacturer components and
> + 	#  replaces "." with "_" in the operating system version.
> + 	case $host in *-*-*vms*)
> + 		target_alias=`echo $host \
> + 		  | sed 's/.*-.*-\(.*\)$/\1/' | sed 's/\./_/g'`
> + 		;;
> + 	esac

this should not be necessary

> + 	prefix=/gnu
> + 	local_prefix=/gnu

inappropriate; you are overriding the user, and breaking installation
of cross compilers targeting this port

> + # Assemble startup files.
> + vcrt0.o: $(CRT0_S) $(GCC_PASSES)
> + 	./decc -c /names=as_is $(srcdir)/config/ia64/vms-crt0.c -o vcrt0.o
> + 
> + pcrt0.o: $(CRT0_S) $(GCC_PASSES)
> + 	./decc -c /names=as_is $(srcdir)/config/ia64/vms-psxcrt0.c -o pcrt0.o

why the hell can't this code be compiled with gcc?  (the alpha-vms port
has the same problem)

> + #define MD_EXEC_PREFIX "/gnu/lib/gcc-lib/"
> + #define MD_STARTFILE_PREFIX "/gnu/lib/gcc-lib/"
> + 
> + /* Specify the list of include file directories.  */
> + #define INCLUDE_DEFAULTS		   \
> + {					   \
> +   { "/gnu/lib/gcc-lib/include", 0, 0, 0 }, \
> +   { "/gnu_gxx_include", 0, 1, 1 },	   \
> +   { "/gnu_cc_include", 0, 0, 0 },	   \
> +   { "/gnu/include", 0, 0, 0 },	           \
> +   { 0, 0, 0, 0 }			   \
> + }

this also interferes with cross compiler use

zw

Re: Problem in split_basic_block

[Richard Kenner]

    > Suggestions?

    Provide a test case.

Apply the patch below, then configure for
	--target=ia64-hp-openvms8_0 --enable-sjlj-exceptions

Then try to compile the Ada library module a-calend.adb with -gnatpg.

But see the patch I subsequently posted since the above is a lot of work.

*** gcc/config.gcc	Fri Jul 25 11:29:12 2003
--- gcc/config.gcc	Thu Jul 17 20:12:15 2003
***************
*** 1277,1282 ****
--- 1277,1303 ----
  	c_target_objs="ia64-c.o"
  	cxx_target_objs="ia64-c.o"
  	;;
+ ia64*-hp-*vms*)
+ 	tm_file="${tm_file} elfos.h ia64/sysv4.h ia64/elf.h ia64/vms.h"
+ 	tmake_file=ia64/t-vms
+ 	xmake_file=ia64/x-vms
+ 	target_cpu_default="0"
+ 	if test x$gas = xyes
+ 	then
+ 		target_cpu_default="${target_cpu_default}|MASK_GNU_AS"
+ 	fi
+ 	exeext=.exe
+ 	# This removes the cpu type and manufacturer components and
+ 	#  replaces "." with "_" in the operating system version.
+ 	case $host in *-*-*vms*)
+ 		target_alias=`echo $host \
+ 		  | sed 's/.*-.*-\(.*\)$/\1/' | sed 's/\./_/g'`
+ 		;;
+ 	esac
+ 	install_headers_dir=install-headers-cp
+ 	prefix=/gnu
+ 	local_prefix=/gnu
+ 	;;
  ip2k-*-elf)
  	tm_file="elfos.h ${tm_file}"
  	;;
*** /dev/null	Fri Jul 25 12:42:42 2003
--- gcc/gcc/config/ia64/t-vms	Thu Jul 17 19:36:54 2003
***************
*** 0 ****
--- 1,43 ----
+ LIB1ASMSRC    = ia64/lib1funcs.asm
+ 
+ # We use different names for the DImode div/mod files so that they won't
+ # conflict with libgcc2.c files.  We used to use __ia64 as a prefix, now
+ # we use __ as the prefix.  Note that L_divdi3 in libgcc2.c actually defines
+ # a TImode divide function, so there is no actual overlap here between
+ # libgcc2.c and lib1funcs.asm.
+ LIB1ASMFUNCS  = __divtf3 __divdf3 __divsf3 \
+ 	__divdi3 __moddi3 __udivdi3 __umoddi3 \
+ 	__divsi3 __modsi3 __udivsi3 __umodsi3 __save_stack_nonlocal \
+ 	__nonlocal_goto __restore_stack_nonlocal __trampoline
+ 
+ STMP_FIXPROTO =
+ STMP_FIXINC =
+ 
+ LIB2FUNCS_EXTRA =
+ 
+ # VMS_EXTRA_PARTS is defined in x-vms and represent object files that
+ # are only needed for VMS targets, but can only be compiled on a VMS host
+ # (because they need DEC C).
+ EXTRA_PARTS = $(VMS_EXTRA_PARTS)
+ 
+ # Effectively disable the crtbegin/end rules using crtstuff.c
+ T = disable
+ 
+ # Assemble startup files.
+ vcrt0.o: $(CRT0_S) $(GCC_PASSES)
+ 	./decc -c /names=as_is $(srcdir)/config/ia64/vms-crt0.c -o vcrt0.o
+ 
+ pcrt0.o: $(CRT0_S) $(GCC_PASSES)
+ 	./decc -c /names=as_is $(srcdir)/config/ia64/vms-psxcrt0.c -o pcrt0.o
+ 
+ LIB2ADDEH = $(srcdir)/unwind-sjlj.c
+ 
+ # ??? Hack to get -P option used when compiling lib1funcs.asm, because Intel
+ # assembler does not accept # line number as a comment.
+ # ??? This breaks C++ pragma interface/implementation, which is used in the
+ # C++ part of libgcc2, hence it had to be disabled.  Must find some other way
+ # to support the Intel assembler.
+ #LIBGCC2_DEBUG_CFLAGS = -g1 -P
+ 
+ # genattrtab generates very long string literals.
+ insn-attrtab.o-warn = -Wno-error
*** /dev/null	Fri Jul 25 12:42:34 2003
--- gcc/gcc/config/ia64/vms.h	Thu Jul 17 19:36:55 2003
***************
*** 0 ****
--- 1,108 ----
+ /* Output variables, constants and external declarations, for GNU compiler.
+    Copyright (C) 2003
+    Free Software Foundation, Inc.
+ 
+ This file is part of GNU CC.
+ 
+ GNU CC is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2, or (at your option)
+ any later version.
+ 
+ GNU CC is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+ 
+ You should have received a copy of the GNU General Public License
+ along with GNU CC; see the file COPYING.  If not, write to
+ the Free Software Foundation, 59 Temple Place - Suite 330,
+ Boston, MA 02111-1307, USA.  */
+ 
+ #define TARGET_OBJECT_SUFFIX ".obj"
+ #define TARGET_EXECUTABLE_SUFFIX ".exe"
+ 
+ #define TARGET_OS_CPP_BUILTINS()		\
+     do {					\
+ 	builtin_define_std ("vms");		\
+ 	builtin_define_std ("VMS");		\
+ 	builtin_define ("__IA64");		\
+ 	builtin_assert ("system=vms");		\
+ 	builtin_define ("__IEEE_FLOAT");	\
+     } while (0)
+ 
+ /* By default, allow $ to be part of an identifier.  */
+ #define DOLLARS_IN_IDENTIFIERS 2
+ 
+ #undef TARGET_ABI_OPEN_VMS
+ #define TARGET_ABI_OPEN_VMS 1
+ 
+ #undef TARGET_NAME   
+ #define TARGET_NAME "OpenVMS/IA64"
+ #undef TARGET_VERSION
+ #define TARGET_VERSION fprintf (stderr, " (%s)", TARGET_NAME);           
+ 
+ /* "long" is 32 bits, but 64 bits for Ada.  */
+ #undef LONG_TYPE_SIZE
+ #define LONG_TYPE_SIZE 32
+ #define ADA_LONG_TYPE_SIZE 64
+ 
+ /* Pointer is 32 bits but the hardware has 64-bit addresses, sign extended.  */
+ #undef POINTER_SIZE
+ #define POINTER_SIZE 32
+ #define POINTERS_EXTEND_UNSIGNED 0
+ 
+ #undef STARTFILE_SPEC
+ #define STARTFILE_SPEC "%{!shared:%{mvms-return-codes:vcrt0.o%s} \
+ %{!mvms-return-codes:pcrt0.o%s}}"
+ 
+ #ifdef ENDFILE_SPEC
+ #undef ENDFILE_SPEC
+ #endif
+ 
+ #ifdef LINK_SPEC
+ #undef LINK_SPEC
+ #endif
+ 
+ #ifdef LIB_SPEC
+ #undef LIB_SPEC
+ #endif
+ #define LIB_SPEC ""
+ 
+ #ifdef ASM_SPEC
+ #undef ASM_SPEC
+ #endif
+ #define ASM_SPEC \
+   "%{!mgnu-as:-N so} %{mgnu-as:-x} %{mconstant-gp:-M const_gp}\
+    %{mauto-pic:-M no_plabel} %{!mvms_upcase:-N vms_upcase}"
+ 
+ /* Define the names of the division and modulus functions.  */
+ #define DIVSI3_LIBCALL "OTS$DIV_I"
+ #define DIVDI3_LIBCALL "OTS$DIV_L"
+ #define UDIVSI3_LIBCALL "OTS$DIV_UI"
+ #define UDIVDI3_LIBCALL "OTS$DIV_UL"
+ #define MODSI3_LIBCALL "OTS$REM_I"
+ #define MODDI3_LIBCALL "OTS$REM_L"
+ #define UMODSI3_LIBCALL "OTS$REM_UI"
+ #define UMODDI3_LIBCALL "OTS$REM_UL"
+ 
+ #define NAME__MAIN "__gccmain"
+ #define SYMBOL__MAIN __gccmain
+ 
+ #define MD_EXEC_PREFIX "/gnu/lib/gcc-lib/"
+ #define MD_STARTFILE_PREFIX "/gnu/lib/gcc-lib/"
+ 
+ /* Specify the list of include file directories.  */
+ #define INCLUDE_DEFAULTS		   \
+ {					   \
+   { "/gnu/lib/gcc-lib/include", 0, 0, 0 }, \
+   { "/gnu_gxx_include", 0, 1, 1 },	   \
+   { "/gnu_cc_include", 0, 0, 0 },	   \
+   { "/gnu/include", 0, 0, 0 },	           \
+   { 0, 0, 0, 0 }			   \
+ }
+ 
+ #define LONGLONG_STANDALONE 1
+ 
+ /* Maybe same as HPUX?  Needs to be checked. */
+ #define JMP_BUF_SIZE  (8 * 76)