From: "Paul Edwards" <mutazilah@gmail.com>
To: "Joseph S. Myers" <joseph@codesourcery.com>,
"Ulrich Weigand" <uweigand@de.ibm.com>
Cc: <gcc@gcc.gnu.org>
Subject: Re: i370 port
Date: Tue, 08 Sep 2009 15:55:00 -0000 [thread overview]
Message-ID: <A5C0F5CEA2FA42E48C5733AC4747F302@Paullaptop> (raw)
In-Reply-To: <Pine.LNX.4.64.0906051541460.7321@digraph.polyomino.org.uk>
>> I understand current GCC supports various source and target character
>> sets a lot better out of the box, so it may be EBCDIC isn't even an
>> issue any more. If there are other problems related to MVS host
>
> I think the EBCDIC support is largely theoretical and not tested on any
> actual EBCDIC host (or target). cpplib knows the character set name
> UTF-EBCDIC, but whenever it does anything internally that involves the
> encoding of its internal character set it uses UTF-8 rules (which is not
> something valid to do with UTF-EBCDIC).
Results are finally in.
EBCDIC (or arbitrary character set) support was introduced in 3.4.6,
and continues to be the same today, correct?
I've just succeeded today in getting gcc 3.4.6 to self-compile on an
EBCDIC host. :-) That's after a gcc 3.4.6 ascii to ebcdic cross-compile.
It's fascinating to look back at what it took. Note that there are still
some relatively minor cleanups I have yet to do, but it won't change
much.
Caveats:
1. The generated (from machine definition) files are still generated on
the PC.
2. I am unable to do an optimized compile even as a cross-compile,
I get an internal error in this function:
gcse.c:
static void
compute_hash_table_work (struct hash_table *table)
{
...
if (!current_bb) /* +++ why are we getting NULL here? */
{
printf("internal error in gcse\n");
exit(EXIT_FAILURE);
}
FOR_EACH_BB (current_bb)
and indeed, I can't see anything that would initialize that current_bb,
so it's not that surprising that it's NULL!
3. As with gcc 3.2.3, the compiler is still producing slightly different
results on the PC vs mainframe, probably still because of floating
point comparisons being done to select the next register to use
or something like that.
4. There is one thing that doesn't have proper ASCII to EBCDIC
translation being done - the __FUNCTION__ builtin.
So here is the code generated on the PC:
COPY PDPTOP
CSECT
* Program text area
@@V1 EQU *
DC X'78'
DC X'31'
DC X'32'
DC X'33'
DC X'0'
LC0 EQU *
DC C'%s %d %s'
DC X'15'
DC X'0'
LC1 EQU *
DC C'zatest.c'
DC X'0'
DS 0F
* X-func x123 prologue
X123 PDPPRLG CINDEX=0,FRAME=104,BASER=12,ENTRY=YES
B FEN0
LTORG
FEN0 EQU *
DROP 12
BALR 12,0
USING *,12
PG0 EQU *
LR 11,1
L 10,=A(PGT0)
* Function x123 code
MVC 88(4,13),=A(LC0)
MVC 92(4,13),=A(LC1)
MVC 96(4,13),=F'5'
MVC 100(4,13),=A(@@V1)
LA 1,88(,13)
L 15,=V(PRINTF)
BALR 14,15
* Function x123 epilogue
PDPEPIL
* Function x123 literal pool
DS 0F
LTORG
* Function x123 page table
DS 0F
PGT0 EQU *
DC A(PG0)
END
for this source:
#include <stdlib.h>
void x123(void)
{
printf("%s %d %s\n", __FILE__, __LINE__, __FUNCTION__);
}
However, that anomaly is not integral to getting the compiler on the
mainframe, and once on the mainframe, the problem goes away
with the next pass. :-)
I think the problem is this function:
c-decl.c:
c_make_fname_decl (tree id, int type_dep)
needs to call cpp_interpret_string or something like that to get
converted into EBCDIC.
There's not that much mainline code that needs to be changed.
You can see for youself here:
http://rapidshare.com/files/277287822/gccnew-beta51.zip
The file is 250k compressed containing diffs, but most of them are
simply the generated files (which appear as new). Here are the
real file changes:
diff -c gccnew/gcc/builtins.c:1.1.1.1 gccnew/gcc/builtins.c:1.3
diff -c gccnew/gcc/c-common.c:1.1.1.1 gccnew/gcc/c-common.c:1.2
diff -c gccnew/gcc/c-incpath.c:1.1.1.1 gccnew/gcc/c-incpath.c:1.3
diff -c gccnew/gcc/c-opts.c:1.1.1.1 gccnew/gcc/c-opts.c:1.2
diff -c gccnew/gcc/c-parse.c:1.1.1.1 gccnew/gcc/c-parse.c:1.5
diff -c gccnew/gcc/c-pch.c:1.1.1.1 gccnew/gcc/c-pch.c:1.3
diff -c gccnew/gcc/cppcharset.c:1.1.1.1 gccnew/gcc/cppcharset.c:1.6
diff -c gccnew/gcc/cpperror.c:1.1.1.1 gccnew/gcc/cpperror.c:1.2
diff -c gccnew/gcc/cppfiles.c:1.1.1.1 gccnew/gcc/cppfiles.c:1.7
diff -c gccnew/gcc/cpplib.h:1.1.1.1 gccnew/gcc/cpplib.h:1.2
diff -c gccnew/gcc/cppmacro.c:1.1.1.1 gccnew/gcc/cppmacro.c:1.2
diff -c gccnew/gcc/cppspec.c:1.1.1.1 gccnew/gcc/cppspec.c:1.3
diff -c gccnew/gcc/gcc.c:1.1.1.1 gccnew/gcc/gcc.c:1.6
diff -c gccnew/gcc/gcc.h:1.1.1.1 gccnew/gcc/gcc.h:1.2
diff -c gccnew/gcc/gcov-io.c:1.1.1.1 gccnew/gcc/gcov-io.c:1.2
diff -c gccnew/gcc/gcov-io.h:1.1.1.1 gccnew/gcc/gcov-io.h:1.2
diff -c gccnew/gcc/gcse.c:1.1.1.1 gccnew/gcc/gcse.c:1.3
diff -c gccnew/gcc/hwint.h:1.1.1.1 gccnew/gcc/hwint.h:1.2
diff -c gccnew/gcc/longlong.h:1.1.1.1 gccnew/gcc/longlong.h:1.2
diff -c gccnew/gcc/opts.c:1.1.1.1 gccnew/gcc/opts.c:1.2
diff -c gccnew/gcc/opts.h:1.1.1.1 gccnew/gcc/opts.h:1.3
diff -c gccnew/gcc/opts.sh:1.1.1.1 gccnew/gcc/opts.sh:1.1.1.2
diff -c gccnew/gcc/pretty-print.c:1.1.1.1 gccnew/gcc/pretty-print.c:1.2
diff -c gccnew/gcc/read-rtl.c:1.1.1.1 gccnew/gcc/read-rtl.c:1.2
diff -c gccnew/gcc/real.c:1.1.1.1 gccnew/gcc/real.c:1.3
diff -c gccnew/gcc/system.h:1.1.1.1 gccnew/gcc/system.h:1.2
diff -c gccnew/gcc/toplev.c:1.1.1.1 gccnew/gcc/toplev.c:1.3
diff -c gccnew/gcc/varasm.c:1.1.1.1 gccnew/gcc/varasm.c:1.2
diff -c gccnew/gcc/version.c:1.1.1.1 gccnew/gcc/version.c:1.2
diff -c gccnew/gcc/config/i370/i370-c.c:1.1.1.1
gccnew/gcc/config/i370/i370-c.c:1.2
diff -c gccnew/gcc/config/i370/i370-protos.h:1.1.1.1
gccnew/gcc/config/i370/i370-protos.h:1.2
diff -c gccnew/gcc/config/i370/i370.c:1.1.1.1
gccnew/gcc/config/i370/i370.c:1.23
diff -c gccnew/gcc/config/i370/i370.h:1.1.1.1
gccnew/gcc/config/i370/i370.h:1.15
diff -c gccnew/gcc/config/i370/i370.md:1.1.1.1
gccnew/gcc/config/i370/i370.md:1.3
diff -c gccnew/gcc/config/i370/linux.h:1.1.1.1
gccnew/gcc/config/i370/linux.h:1.1.1.2
diff -c gccnew/gcc/config/i370/oe.h:1.1.1.1
gccnew/gcc/config/i370/oe.h:1.1.1.2
diff -c gccnew/include/fnmatch.h:1.1.1.1 gccnew/include/fnmatch.h:1.2
diff -c gccnew/include/safe-ctype.h:1.1.1.1
gccnew/include/safe-ctype.h:1.1.1.2
diff -c gccnew/include/sort.h:1.1.1.1 gccnew/include/sort.h:1.2
diff -c gccnew/include/xregex2.h:1.1.1.1 gccnew/include/xregex2.h:1.2
diff -c gccnew/libiberty/argv.c:1.1.1.1 gccnew/libiberty/argv.c:1.4
diff -c gccnew/libiberty/concat.c:1.1.1.1 gccnew/libiberty/concat.c:1.2
diff -c gccnew/libiberty/cplus-dem.c:1.1.1.1
gccnew/libiberty/cplus-dem.c:1.2
diff -c gccnew/libiberty/fdmatch.c:1.1.1.1 gccnew/libiberty/fdmatch.c:1.2
diff -c gccnew/libiberty/getpagesize.c:1.1.1.1
gccnew/libiberty/getpagesize.c:1.2
diff -c gccnew/libiberty/getpwd.c:1.1.1.1 gccnew/libiberty/getpwd.c:1.2
diff -c gccnew/libiberty/getruntime.c:1.1.1.1
gccnew/libiberty/getruntime.c:1.2
diff -c gccnew/libiberty/hashtab.c:1.1.1.1 gccnew/libiberty/hashtab.c:1.2
diff -c gccnew/libiberty/hex.c:1.1.1.1 gccnew/libiberty/hex.c:1.1.1.2
diff -c gccnew/libiberty/lrealpath.c:1.1.1.1
gccnew/libiberty/lrealpath.c:1.2
diff -c gccnew/libiberty/make-temp-file.c:1.1.1.1
gccnew/libiberty/make-temp-file.c:1.2
diff -c gccnew/libiberty/md5.c:1.1.1.1 gccnew/libiberty/md5.c:1.2
diff -c gccnew/libiberty/mkstemps.c:1.1.1.1 gccnew/libiberty/mkstemps.c:1.2
diff -c gccnew/libiberty/obstack.c:1.1.1.1 gccnew/libiberty/obstack.c:1.2
diff -c gccnew/libiberty/physmem.c:1.1.1.1 gccnew/libiberty/physmem.c:1.2
diff -c gccnew/libiberty/regex.c:1.1.1.1 gccnew/libiberty/regex.c:1.2
diff -c gccnew/libiberty/safe-ctype.c:1.1.1.1
gccnew/libiberty/safe-ctype.c:1.4
diff -c gccnew/libiberty/vasprintf.c:1.1.1.1
gccnew/libiberty/vasprintf.c:1.1.1.2
diff -c gccnew/libiberty/xmalloc.c:1.1.1.1 gccnew/libiberty/xmalloc.c:1.3
diff -c gccnew/libiberty/xmemdup.c:1.1.1.1 gccnew/libiberty/xmemdup.c:1.2
diff -c gccnew/libiberty/xstrdup.c:1.1.1.1 gccnew/libiberty/xstrdup.c:1.2
(most files are just a few lines of change though).
The most intrusive change was the #include processing which is
done differently on MVS.
Anyway, I'm planning on spending a bit more time consolidating this
build. Not sure if the optimization problem can be solved, but even if
it can't, at least all the i370 code is now consolidated ready for the
push forward. Hopefully these issues are more readily solved in the
latest codebase.
Hopefully also some of those other minor issues (like including
non-standard header files like sys/types) can also be remedied. :-)
This has certainly taken a while. The number of people who have
asked me why I don't use 3.4.6 as if it is trivial to do these things,
just change a couple of numbers surely. :-)
Interesting how well the EBCDIC conversion held up too. GCC 3.2.3
was a lot more intrusive to get working in that regard.
Let me know if you find anything that should have been done
differently too. :-)
BFN. Paul.
next prev parent reply other threads:[~2009-09-08 15:55 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-05 12:45 Paul Edwards
2009-06-05 14:33 ` Joseph S. Myers
2009-06-05 14:57 ` Paul Edwards
2009-06-05 15:03 ` Joseph S. Myers
2009-06-05 15:24 ` Paul Edwards
2009-06-05 15:47 ` Joseph S. Myers
2009-09-11 17:35 ` i370 port - in search of hooks Paul Edwards
2017-03-31 10:34 ` i370 port Paul Edwards
2009-09-12 12:41 ` Paul Edwards
2009-06-05 15:21 ` Ulrich Weigand
2009-06-05 15:39 ` Paul Edwards
2009-06-05 15:49 ` Daniel Jacobowitz
2009-06-05 15:57 ` Paul Edwards
2009-06-05 20:20 ` Joseph S. Myers
2009-06-05 20:45 ` Paul Edwards
2009-06-06 15:00 ` Paul Edwards
2009-06-15 17:46 ` Ulrich Weigand
2009-06-19 0:06 ` Paul Edwards
2009-06-19 12:28 ` Ulrich Weigand
2009-07-18 11:28 ` Paul Edwards
2009-07-20 14:27 ` Ulrich Weigand
2009-08-08 12:04 ` Paul Edwards
2009-08-10 21:25 ` Ulrich Weigand
2009-08-11 0:34 ` Paul Edwards
2009-08-11 15:21 ` Ulrich Weigand
2009-08-12 11:52 ` Paul Edwards
2009-08-12 15:27 ` Paolo Bonzini
2009-08-12 16:35 ` Ulrich Weigand
2009-08-12 17:27 ` Paul Edwards
2009-08-12 17:56 ` Paolo Bonzini
2009-08-12 19:46 ` Ulrich Weigand
2009-08-12 20:31 ` Paul Edwards
2009-08-19 12:07 ` Paul Edwards
2009-08-19 12:27 ` Paolo Bonzini
2009-08-20 12:49 ` Paul Edwards
2009-08-20 22:48 ` Ulrich Weigand
2009-08-21 2:37 ` Paul Edwards
2009-08-21 16:46 ` Ulrich Weigand
2009-06-05 15:44 ` Joseph S. Myers
2009-06-05 15:52 ` Paul Edwards
2009-09-08 15:55 ` Paul Edwards [this message]
2009-09-14 15:32 ` Ulrich Weigand
2021-09-02 8:15 ` s390 port Paul Edwards
2021-09-02 14:34 ` Ulrich Weigand
2021-09-02 14:50 ` Paul Edwards
2021-09-02 14:53 ` Ulrich Weigand
2021-09-02 15:01 ` Paul Edwards
2021-09-02 15:13 ` Ulrich Weigand
2021-09-02 15:26 ` Paul Edwards
2021-09-02 19:46 ` Ulrich Weigand
2021-09-02 20:05 ` Paul Edwards
2021-09-02 20:16 ` Andreas Schwab
2021-09-03 11:18 ` Ulrich Weigand
2021-09-03 11:35 ` Paul Edwards
2021-09-03 12:12 ` Ulrich Weigand
2021-09-03 12:38 ` Paul Edwards
2021-09-03 12:53 ` Jakub Jelinek
2021-09-03 13:12 ` Paul Edwards
2022-12-20 4:27 ` Paul Edwards
2009-08-23 8:50 i370 port Paul Edwards
2009-08-26 22:13 ` Henrik Sorensen
2009-09-09 22:33 Paul Edwards
2009-09-14 15:42 ` Ulrich Weigand
2009-09-15 12:59 ` Paul Edwards
2009-09-15 13:51 ` Ulrich Weigand
2009-09-17 13:00 ` Paul Edwards
2009-09-17 17:55 ` Ulrich Weigand
2009-09-18 0:35 ` Paul Edwards
2009-09-18 12:06 ` Ulrich Weigand
2009-09-18 12:23 ` Paul Edwards
2009-09-18 13:27 ` Ulrich Weigand
2009-09-18 13:42 ` Paul Edwards
2009-09-18 16:08 ` Ulrich Weigand
2009-09-19 12:57 ` Paul Edwards
2009-09-25 10:19 ` Paul Edwards
2009-09-25 15:20 ` Ulrich Weigand
2009-11-04 5:21 ` Paul Edwards
2009-11-04 16:47 ` Ulrich Weigand
2009-11-09 14:55 ` Paul Edwards
2009-11-09 15:57 ` Ian Lance Taylor
2009-11-09 23:10 ` Paul Edwards
2009-11-10 14:58 ` Paul Edwards
2009-11-10 15:36 ` Ian Lance Taylor
2009-11-10 15:51 ` Paul Edwards
2009-11-10 15:56 ` Ian Lance Taylor
2009-12-02 22:03 ` Paul Edwards
2011-08-13 8:34 ` Paul Edwards
2011-08-15 14:32 ` Ulrich Weigand
2011-08-15 15:26 ` Paul Edwards
2011-08-15 17:23 ` Ulrich Weigand
2011-08-16 11:20 ` Paul Edwards
2011-08-16 13:26 ` Ulrich Weigand
2011-08-18 12:15 ` Paul Edwards
2011-08-18 13:14 ` Ulrich Weigand
2011-08-18 14:18 ` Paul Edwards
2009-09-22 12:31 Paul Edwards
2011-08-20 7:44 Paul Edwards
2011-08-20 10:09 Paul Edwards
2011-08-20 12:15 Paul Edwards
2011-08-22 12:23 ` Ulrich Weigand
2012-04-05 13:32 ` Paul Edwards
2012-04-06 18:13 ` Ulrich Weigand
2012-04-06 5:51 Paul Edwards
2012-04-06 12:49 Paul Edwards
2012-04-06 18:16 ` Ulrich Weigand
2012-04-07 4:12 ` Paul Edwards
2012-04-07 5:45 Paul Edwards
2012-04-08 17:43 ` Ulrich Weigand
2014-02-11 17:01 ` Paul Edwards
2014-02-13 4:23 Paul Edwards
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A5C0F5CEA2FA42E48C5733AC4747F302@Paullaptop \
--to=mutazilah@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=uweigand@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).