public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Re: Problem in split_basic_block
@ 2003-08-08  3:04 Richard Kenner
  2003-08-10  8:06 ` Jim Wilson
  0 siblings, 1 reply; 27+ messages in thread
From: Richard Kenner @ 2003-08-08  3:04 UTC (permalink / raw)
  To: rth; +Cc: gcc

    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?

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: Problem in split_basic_block
@ 2003-08-10 16:35 Richard Kenner
  0 siblings, 0 replies; 27+ messages in thread
From: Richard Kenner @ 2003-08-10 16:35 UTC (permalink / raw)
  To: wilson; +Cc: gcc

    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.

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: Problem in split_basic_block
@ 2003-08-08 23:53 Richard Kenner
  0 siblings, 0 replies; 27+ messages in thread
From: Richard Kenner @ 2003-08-08 23:53 UTC (permalink / raw)
  To: rth; +Cc: gcc

    [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.

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: Problem in split_basic_block
@ 2003-08-07 21:08 Richard Kenner
  2003-08-07 22:45 ` Richard Henderson
  0 siblings, 1 reply; 27+ messages in thread
From: Richard Kenner @ 2003-08-07 21:08 UTC (permalink / raw)
  To: rth; +Cc: gcc

    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.

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: Problem in split_basic_block
@ 2003-08-07 20:30 Richard Kenner
  0 siblings, 0 replies; 27+ messages in thread
From: Richard Kenner @ 2003-08-07 20:30 UTC (permalink / raw)
  To: geoffk; +Cc: gcc

    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.

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: Problem in split_basic_block
@ 2003-08-07 19:30 Nathanael Nerode
  0 siblings, 0 replies; 27+ messages in thread
From: Nathanael Nerode @ 2003-08-07 19:30 UTC (permalink / raw)
  To: kenner, gcc

>    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

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: Problem in split_basic_block
@ 2003-08-07 13:10 Richard Kenner
  0 siblings, 0 replies; 27+ messages in thread
From: Richard Kenner @ 2003-08-07 13:10 UTC (permalink / raw)
  To: zack; +Cc: gcc

    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.

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: Problem in split_basic_block
@ 2003-08-07  7:01 Richard Kenner
  2003-08-07 19:33 ` Geoff Keating
  0 siblings, 1 reply; 27+ messages in thread
From: Richard Kenner @ 2003-08-07  7:01 UTC (permalink / raw)
  To: zack; +Cc: gcc

    > 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.

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: Problem in split_basic_block
@ 2003-08-07  5:32 Richard Kenner
  0 siblings, 0 replies; 27+ messages in thread
From: Richard Kenner @ 2003-08-07  5:32 UTC (permalink / raw)
  To: zack; +Cc: gcc

    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.

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Re: Problem in split_basic_block
@ 2003-08-06 23:42 Richard Kenner
  2003-08-06 23:47 ` Zack Weinberg
                   ` (2 more replies)
  0 siblings, 3 replies; 27+ messages in thread
From: Richard Kenner @ 2003-08-06 23:42 UTC (permalink / raw)
  To: rth; +Cc: gcc

    > 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)

^ permalink raw reply	[flat|nested] 27+ messages in thread
* Problem in split_basic_block
@ 2003-08-01 23:07 Richard Kenner
  2003-08-06 22:41 ` Richard Henderson
  0 siblings, 1 reply; 27+ messages in thread
From: Richard Kenner @ 2003-08-01 23:07 UTC (permalink / raw)
  To: gcc

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.

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2003-09-01 13:18 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-08  3:04 Problem in split_basic_block Richard Kenner
2003-08-10  8:06 ` Jim Wilson
  -- strict thread matches above, loose matches on Subject: below --
2003-08-10 16:35 Richard Kenner
2003-08-08 23:53 Richard Kenner
2003-08-07 21:08 Richard Kenner
2003-08-07 22:45 ` Richard Henderson
2003-08-07 20:30 Richard Kenner
2003-08-07 19:30 Nathanael Nerode
2003-08-07 13:10 Richard Kenner
2003-08-07  7:01 Richard Kenner
2003-08-07 19:33 ` Geoff Keating
2003-08-07  5:32 Richard Kenner
2003-08-06 23:42 Richard Kenner
2003-08-06 23:47 ` Zack Weinberg
2003-08-06 23:56   ` Douglas B Rupp
2003-08-06 23:57     ` Zack Weinberg
2003-08-07  0:16       ` Douglas B Rupp
2003-08-07  0:40         ` Zack Weinberg
2003-08-06 23:57   ` Douglas B Rupp
2003-08-07  0:43     ` Zack Weinberg
2003-08-07  0:38   ` Douglas B Rupp
2003-08-07  1:05     ` Zack Weinberg
2003-08-07 20:59 ` Richard Henderson
2003-08-08 23:41 ` Richard Henderson
2003-09-01 13:18   ` Olivier Hainque
2003-08-01 23:07 Richard Kenner
2003-08-06 22:41 ` Richard Henderson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).