Re: i370 port - 3.4.6 to 4.4 upgrade attempt
Paul Edwards wrote: I can see one significant change: the GCC middle-end now no longer supports base-16 floating point at all. The old i370 port was the only user of this feature, and some time after the port was removed, the middle-end support was removed as well in order to simplify floating-point handling code. The s390 port uses IEEE float instead of hex float throughout, so it is not affected by this change. I found that if I didn't define anything for this at all, it still worked. I'm not sure when the lack of hex float will actually start affecting me. I got it to generate code like: LD 0,=D'5.599...e+0' which will only require minor modifications to be acceptable to HLASM. And in fact, that's basically the same code that was being generated with GCC 3.4.6 anyway. Well, there's two main points where lack of hex float support in the compiler may cause problems. The one is if you were to rely on the compiler to convert float constants into the binary representation. But from your sample above it seems that you're instead asking the assembler to do this, so it should not be an issue. The second problem is that whenever the compiler performs compile-time computations of floating point values, it will use the IEEE semantics, which means it might arrive at different results than what target code running on the mainframe would. This can manifest in the same source code leading to different results when compiled with optimizations as compared to without optimizations, for example. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
Well I have good news to report. I applied most of your recommended changes, but it still crashed, still at the same spot: built-in:0: internal compiler error: Segmentation fault However, I managed to track it down to some floating point stuff in the i370 code, and got rid of that, and now I can compile a hello, world program! The changes to 4.4.0 required to do that can be found here: http://rapidshare.com/files/317504205/gcc4-alpha6.zip I can see one significant change: the GCC middle-end now no longer supports base-16 floating point at all. The old i370 port was the only user of this feature, and some time after the port was removed, the middle-end support was removed as well in order to simplify floating-point handling code. The s390 port uses IEEE float instead of hex float throughout, so it is not affected by this change. I found that if I didn't define anything for this at all, it still worked. I'm not sure when the lack of hex float will actually start affecting me. I got it to generate code like: LD 0,=D'5.599...e+0' which will only require minor modifications to be acceptable to HLASM. And in fact, that's basically the same code that was being generated with GCC 3.4.6 anyway. In the meantime, I'll see how much of gcc 4.4 can be self-compiled. BFN. Paul.
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
Paul Edwards wrote:
So, given the scope below, can someone please explain what
4.4 changes are affecting me and what I need to do to overcome
them? Note that I have never had to do the machine changes
myself - in the past I simply waiting for Dave Pitts to do the
upgrade to the new version, and then with a working 370 code
generator I would make all the changes necessary for MVS.
Most of the things seem just minor changes, e.g. warning got
another argument, or target macros were replaced by targetm
callbacks.
I can see one significant change: the GCC middle-end now no
longer supports base-16 floating point at all. The old i370
port was the only user of this feature, and some time after
the port was removed, the middle-end support was removed as
well in order to simplify floating-point handling code.
The s390 port uses IEEE float instead of hex float throughout,
so it is not affected by this change.
+ i370-*-mvspdp)
+ xm_defines='POSIX' # 'FATAL_EXIT_CODE=12'
+ xm_file=i370/xm-mvs.h
+ tm_file=i370/mvspdp.h i370/i370.h
+ tmake_file=i370/t-mvs i370/t-i370
+ c_target_objs=i370-c.o
+ cxx_target_objs=i370-c.o
+ ;;
+ s390-*-linux*)
+ tm_file=s390/s390.h dbxelf.h elfos.h svr4.h linux.h s390/linux.h
+ tmake_file=${tmake_file} t-dfprules s390/t-crtstuff s390/t-linux
+ ;;
The s390 lines should not be added here.
! /* +++ c_lex has gone. however, we don't use it for anything important
anyway */
! #define c_lex(a)
Pragma handlers are now apparently supposed to use pragma_lex instead,
which is declared in the c-pragma.h header. See e.g. config/sol2-c.c
for examples of pragma handlers.
/* We're 370 floating point, not IEEE floating point. */
memset (real_format_for_mode, 0, sizeof real_format_for_mode);
! REAL_MODE_FORMAT (SFmode) = i370_single_format;
! REAL_MODE_FORMAT (DFmode) = i370_double_format;
This is a problem, see above.
/* We're 370 floating point, not IEEE floating point. */
memset (real_format_for_mode, 0, sizeof real_format_for_mode);
! /*REAL_MODE_FORMAT (SFmode) = i370_single_format;
! REAL_MODE_FORMAT (DFmode) = i370_double_format;*/
! /* +++ this is wrong */
! REAL_MODE_FORMAT (SFmode) = ibm_extended_format;
! REAL_MODE_FORMAT (DFmode) = ibm_extended_format;
ibm_extended_format is certainly wrong here; that's the
64 + 64 long double format used on PowerPC.
for (note = REG_NOTES (insn); note; note = XEXP(note,1))
{
+/* +++ what is reg_label? */
+/*
if (REG_LABEL == REG_NOTE_KIND(note))
{
Instead of REG_LABEL notes, the middle-end now generates two different
kinds of notes, REG_LABEL_TARGET and REG_LABEL_OPERAND.
REG_LABEL_TARGET is used in JUMP_INSNs to refer to a potential target
of this jump. REG_LABEL_OPERAND is used in other insns to denote labels
that are used otherwise, e.g. to load the address into a register.
In the context of this code in i370.c, it would appear you're concerned
about the second type of usage here. This means the REG_LABEL should
probably simply be replaced by REG_LABEL_OPERAND.
***
*** 1568,1574
fprintf (f, * Function %.*s prologue: stack = %ld, args = %d\n,
nlen, mvs_function_name,
l,
! current_function_outgoing_args_size);
#endif
current_function_outgoing_args_size must be replaced by crtl-outgoing_args_size
throughout. There was no change in semantics, just where the value is stored.
fprintf (f, * Function %.*s prologue: stack = %ld, args = %d\n,
nlen, mvs_function_name,
l,
! 0 /*cfun-machine-frame_size*/);
#endif
The cfun-machine-frame_size stuff does not seem correct here; use
crtl-outgoing_args_size.
+ #if 0
+ This unused (in mvspdp) stuff is now poisoned
/* Macro to define tables used to set the flags. This is a list in braces
of pairs in braces, each pair being { NAME, VALUE }
where VALUE is the bits to set or minus the bits to clear.
***
*** 99,104
--- 101,107
{ pickax, 2, Experimental i370 PIC}, \
{ no-pickax, -2, Disable experimental i370 PIC}, \
{ , TARGET_DEFAULT, 0} }
+ #endif
Command line options are now defined in a .opt file. If you want to
keep those extra options, you should provide a config/i370/i370.opt
file. See any of the other targets for examples.
+ #if 0 /* +++ now poisoned */
#define PREDICATE_CODES \
{r_or_s_operand, { REG, SUBREG, MEM }}, \
{s_operand, { MEM }},
+ #endif
Predicates must now be defined in a predicates.md file. Again, see
other targets for examples.
! #if 0 /*def TARGET_PDPMAC*/
! +++ this variable is now poisoned - check structs still get returned
! properly
#define STRUCT_VALUE_REGNUM 0
! #elif 0 /*used to be else*/
#define STRUCT_VALUE_REGNUM 1
#endif
If something except the default is needed here, you now
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
I can see one significant change: the GCC middle-end now no longer supports base-16 floating point at all. The old i370 port was the only user of this feature, and some time after the port was removed, the middle-end support was removed as well in order to simplify floating-point handling code. Hmmm. Well I don't know anything about floating point. Thanks very much for all your comments. I will see what difference that makes. Note that I'd expect that with the above obvious issues fixed, you may well run into additional problems in moving the port forward ... At some point, it will be necessary to be able to debug the back-end and resolve problems. Ok, well what I did in the original (3.2) port was to ANSIfy it and then use different debuggers (Borland, Watcom) on my Windows box. I'll see what I can come up with this time. Overall, I still think that adding HLASM support to the s390 back-end would probably be a simpler task ... Well in that case, maybe now is the time to be doing exactly that. I could make 3.4.6 the last of the i370 ports. Can you tell me what is required to convert s390, which has a very alien assembler output, into hlasm? And that brings me to another question. The i370 hlasm port uses tabs in every instruction to separate the instruction and operand. This is not valid in hlasm. In order to get around this, I ended up doing a #define for putc etc to channel everything through my own routine which converted those tabs into an appropriate number of spaces. I suspect there's a neater way to do things, but I never stumbled across that in my travels. Thanks. Paul.
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
Ok, now that 3.4.6 is fully working, I made a start on the 4.4 port.
4.4 appears to have invalidated a lot of 3.4.6 things. Below are all
the changes I needed to make just to get an xgcc executable
built. I didn't really know what most of it was about, but the
purpose was just to scope the changes. Any changes that need
to be done to 4.4 I can now refer to how it was accomplished
in 3.4.6.
So, given the scope below, can someone please explain what
4.4 changes are affecting me and what I need to do to overcome
them? Note that I have never had to do the machine changes
myself - in the past I simply waiting for Dave Pitts to do the
upgrade to the new version, and then with a working 370 code
generator I would make all the changes necessary for MVS.
This time I don't have a working code generator. With these
changes to force an executable, I can go:
xgcc --version
and it works, but when I attempt a compile (with -S), I get an
internal error in builtin line 0, which is presumably completely
meaningless because I haven't actually done the work yet.
Thanks. Paul.
Index: gcc4/config.sub
diff -c gcc4/config.sub:1.3 gcc4/config.sub:1.4
*** gcc4/config.sub:1.3 Mon Nov 23 12:58:07 2009
--- gcc4/config.sub Mon Nov 23 22:47:08 2009
***
*** 940,945
--- 940,948
rtpc | rtpc-*)
basic_machine=romp-ibm
;;
+ i370 | i370-*)
+ basic_machine=i370-ibm
+ ;;
s390 | s390-*)
basic_machine=s390-ibm
;;
Index: gcc4/gcc/config.gcc
diff -c gcc4/gcc/config.gcc:1.3 gcc4/gcc/config.gcc:1.4
*** gcc4/gcc/config.gcc:1.3 Mon Nov 23 12:58:07 2009
--- gcc4/gcc/config.gcc Mon Nov 23 22:46:56 2009
***
*** 358,363
--- 358,366
cpu_type=spu
need_64bit_hwint=yes
;;
+ i370*-*-*)
+ cpu_type=i370
+ ;;
s390*-*-*)
cpu_type=s390
need_64bit_hwint=yes
***
*** 1964,1969
--- 1967,1984
thread_file='aix'
extra_headers=altivec.h
;;
+ i370-*-mvspdp)
+ xm_defines='POSIX' # 'FATAL_EXIT_CODE=12'
+ xm_file=i370/xm-mvs.h
+ tm_file=i370/mvspdp.h i370/i370.h
+ tmake_file=i370/t-mvs i370/t-i370
+ c_target_objs=i370-c.o
+ cxx_target_objs=i370-c.o
+ ;;
+ s390-*-linux*)
+ tm_file=s390/s390.h dbxelf.h elfos.h svr4.h linux.h s390/linux.h
+ tmake_file=${tmake_file} t-dfprules s390/t-crtstuff s390/t-linux
+ ;;
s390-*-linux*)
tm_file=s390/s390.h dbxelf.h elfos.h svr4.h linux.h s390/linux.h
tmake_file=${tmake_file} t-dfprules s390/t-crtstuff s390/t-linux
Index: gcc4/gcc/config/i370/i370-c.c
diff -c gcc4/gcc/config/i370/i370-c.c:1.5 gcc4/gcc/config/i370/i370-c.c:1.6
*** gcc4/gcc/config/i370/i370-c.c:1.5 Mon Nov 23 22:17:42 2009
--- gcc4/gcc/config/i370/i370-c.c Mon Nov 23 22:46:22 2009
***
*** 34,40
#ifdef TARGET_HLASM
! #define BAD(msgid) do { warning (msgid); return; } while (0)
/* #pragma map (name, alias) -
In this implementation both name and alias are required to be
--- 34,43
#ifdef TARGET_HLASM
! #define BAD(msgid) do { warning (0, msgid); return; } while (0)
!
! /* +++ c_lex has gone. however, we don't use it for anything important
anyway */
! #define c_lex(a)
/* #pragma map (name, alias) -
In this implementation both name and alias are required to be
***
*** 42,52
anyone clarify? */
void
! i370_pr_map (pfile)
! cpp_reader *pfile ATTRIBUTE_UNUSED;
{
tree name, alias, x;
if (c_lex (x) != CPP_OPEN_PAREN)
BAD (missing '(' after '#pragma map' - ignored);
--- 45,55
anyone clarify? */
void
! i370_pr_map (cpp_reader *pfile ATTRIBUTE_UNUSED)
{
tree name, alias, x;
+ #if 0
if (c_lex (x) != CPP_OPEN_PAREN)
BAD (missing '(' after '#pragma map' - ignored);
***
*** 63,70
BAD (missing ')' for '#pragma map' - ignored);
if (c_lex (x) != CPP_EOF)
! warning (junk at end of '#pragma map');
!
mvs_add_alias (IDENTIFIER_POINTER (name), TREE_STRING_POINTER (alias),
1);
}
--- 66,73
BAD (missing ')' for '#pragma map' - ignored);
if (c_lex (x) != CPP_EOF)
! warning (0, junk at end of '#pragma map');
! #endif
mvs_add_alias (IDENTIFIER_POINTER (name), TREE_STRING_POINTER (alias),
1);
}
***
*** 74,84
anyone clarify? */
void
! i370_pr_linkage (pfile)
! cpp_reader *pfile ATTRIBUTE_UNUSED;
{
tree name, mode, x;
if (c_lex (x) != CPP_OPEN_PAREN)
BAD (missing '(' after '#pragma linkage' - ignored);
--- 77,87
anyone clarify? */
void
! i370_pr_linkage (cpp_reader *pfile ATTRIBUTE_UNUSED)
{
tree name, mode, x;
+ #if 0
if (c_lex (x) != CPP_OPEN_PAREN)
BAD (missing '(' after '#pragma linkage' - ignored);
***
*** 95,102
BAD (missing ')' for '#pragma linkage' - ignored);
if (c_lex (x) != CPP_EOF)
! warning (junk at end of '#pragma linkage');
!
}
/* #pragma checkout (mode) -
--- 98,105
BAD (missing ')' for '#pragma linkage' - ignored);
if (c_lex (x) != CPP_EOF)
! warning (0,
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
Paul Edwards mutazi...@gmail.com writes:
Index: gcc4/config.sub
diff -c gcc4/config.sub:1.3 gcc4/config.sub:1.4
*** gcc4/config.sub:1.3 Mon Nov 23 12:58:07 2009
--- gcc4/config.sub Mon Nov 23 22:47:08 2009
You should send patches for config.{guess,sub} to
config-patc...@gnu.org.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
And now for something completely different.
Re: i370 port - 3.4.6 to 4.4 upgrade attempt
On 11/23/2009 11:32 AM, Paul Edwards wrote: So, given the scope below, can someone please explain what 4.4 changes are affecting me and what I need to do to overcome them? I think your best bet is to grep the changelogs for what has changes, and see what was done for other ports. Many target macros have become target hooks. Or, PREDICATE_CODES for example will require you to rewrite the r_or_s_operand and s_operand as define_predicate RTL; grep the ChangeLog for predicates.md. And so on. Paolo
