From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20247 invoked by alias); 8 Sep 2009 15:55:48 -0000 Received: (qmail 20133 invoked by uid 22791); 8 Sep 2009 15:55:45 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_05,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-px0-f199.google.com (HELO mail-px0-f199.google.com) (209.85.216.199) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Sep 2009 15:55:33 +0000 Received: by pxi37 with SMTP id 37so3264860pxi.28 for ; Tue, 08 Sep 2009 08:55:30 -0700 (PDT) Received: by 10.115.102.38 with SMTP id e38mr17865924wam.207.1252424883278; Tue, 08 Sep 2009 08:48:03 -0700 (PDT) Received: from Paullaptop (203-206-7-21.dyn.iinet.net.au [203.206.7.21]) by mx.google.com with ESMTPS id 21sm599429pzk.3.2009.09.08.08.47.53 (version=SSLv3 cipher=RC4-MD5); Tue, 08 Sep 2009 08:47:55 -0700 (PDT) Message-ID: From: "Paul Edwards" To: "Joseph S. Myers" , "Ulrich Weigand" Cc: References: <200906051520.n55FKg7T016481@d12av02.megacenter.de.ibm.com> In-Reply-To: Subject: Re: i370 port Date: Tue, 08 Sep 2009 15:55:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-09/txt/msg00166.txt.bz2 >> 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 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.