From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8353 invoked by alias); 31 Mar 2017 10:34:49 -0000 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 Received: (qmail 8330 invoked by uid 89); 31 Mar 2017 10:34:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=BAYES_05,FREEMAIL_FROM,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=worlds, Jun, H*c:original, H*c:reply-type X-HELO: mail-pg0-f43.google.com Received: from mail-pg0-f43.google.com (HELO mail-pg0-f43.google.com) (74.125.83.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Mar 2017 10:34:45 +0000 Received: by mail-pg0-f43.google.com with SMTP id 81so67535772pgh.2 for ; Fri, 31 Mar 2017 03:34:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=jAtVI0ugNfkrgogIwkEUxHchlgYfSCQhjE0N56bebwg=; b=okHXO8jUsoaRVFojVDk8zuALq2kzJBfoa4oHR1w01z2KzmoU6E1m1LVBXdulrAMuqY KaC83ko5TMgxdBtvMx7PXFaPjR2jxHcO6mCRXzVVyfU6uELwmR4tl1wYHxhL/xplp789 xqhIrMoEDsjqH0U+h3//IhOpWZ385o0uDEXMBekg/Rk3S4iMSXqMGNMs6F/bSIeROl2E RVtfei7YY80Uy9R3bcXs+8TJQGBj1xD6PlGaNzzcB7Unub1PLtG3lxwXyxi/xrFpERHF 1nhIombIU7J5rmPhJSmpS1Q3KTv5xrttfKnSJuUPQAFNd2dh/DZrwbKqX4N+skPNxFlE x06A== X-Gm-Message-State: AFeK/H2JkvfzEzhILzcLbbXjt1DgioxTvn0ryJCeuvFFsjsJETPc1dkuLPKcVIN/JARR7Q== X-Received: by 10.99.178.6 with SMTP id x6mr2605912pge.80.1490956485342; Fri, 31 Mar 2017 03:34:45 -0700 (PDT) Received: from PaulDell ([103.217.166.189]) by smtp.gmail.com with ESMTPSA id b77sm9705831pfl.2.2017.03.31.03.34.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Mar 2017 03:34:44 -0700 (PDT) Message-ID: From: "Paul Edwards" To: "Joseph S. Myers" Cc: References: <22637DCC73B54BD1B74D5A5F1939C6AF@Paullaptop> In-Reply-To: Subject: Re: i370 port Date: Fri, 31 Mar 2017 10:34:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-SW-Source: 2017-03/txt/msg00190.txt.bz2 Hi Joseph. (reviving a thread from 2009) I have been streamlining the execution of MVS (i370) via my "runmvs" script recently, and now it only takes a few seconds to do a test on MVS because I have taken out all the unnecessary pauses and made lots of other improvements, and bypassing bugs in Hercules. Numerous other i370 bugs have been fixed in GCC 3.2.3 too. So I decided it was time to take a look at the test suite to see what state that was in. With the aid of a script (below), I got the following results: C:\devel\gcc\gcc\config\i370\test>showres C:\devel\gcc\gcc\config\i370\test>grep passed results.txt | wc 516 1032 10278 C:\devel\gcc\gcc\config\i370\test>grep failed results.txt | wc 117 234 2373 C:\devel\gcc\gcc\config\i370\test> I looked at the first few errors. One was deficiencies with "long long" which is currently in the "too hard" basket. Some were ASCII assumptions (the i370 port is EBCDIC). And there was a genuine bug which I have passed on to Dave Pitts for analysis. Regarding the ASCII errors, here’s an example: C:\devel\gcc\gcc\testsuite\gcc.c-torture\execute>type 20000412-3.c typedef struct { char y; char x[32]; } X; int z (void) { X xxx; xxx.x[0] = xxx.x[31] = '0'; xxx.y = 0xf; return f (xxx, xxx); } int main (void) { int val; val = z (); if (val != 0x60) abort (); exit (0); } int f(X x, X y) { if (x.y != y.y) return 'F'; return x.x[0] + y.x[0]; } They have assumed that '0' is 0x30, but on EBCDIC it is 0xf0. The documentation says: C:\devel\gcc\gcc\testsuite>grep PORTABLE readme.gcc DO NOT PUT NON-PORTABLE TESTCASES IN gcc.c-torture. So what do you suggest I do with this class of error? The choices seem to be: 1. Remove/ignore it as it is non-portable so shouldn't be there in the first place. 2. Create a new internal define like __EBCDIC__ and if that is set, do something different. 3. Create a user-define like -DEBCDIC to be tested. 4. Do something like: #if '0' == 0x30 (untested) 5. Use an existing define, like __MVS__ and if that is set, do something-or-other. Any suggestions? I know 3.2.3 is very old, but this is a very long road, and this is where the most stable i370.md environment is. BTW, I saw someone mention something about a "compile farm". MVS/380 is a freely available i370 platform which allows you to run tests on MVS pretty easily, if a time comes when people want to run tests on MVS to see if their code works on EBCDIC as C90 allows. Here is what it looks like on my system: Just call this script: call mvsgccr cprog.c output.txt and it produces an output file that includes: 07.28.30 JOB 1 $HASP373 MVSGCCR STARTED - INIT 3 - CLASS C - SYS BSP1 07.28.30 JOB 1 IEF403I MVSGCCR - STARTED - TIME=07.28.30 07.28.30 JOB 1 IEFACTRT - Stepname Procstep Program Retcode 07.28.31 JOB 1 MVSGCCR S1 CREATE IEFBR14 RC= 0000 07.28.31 JOB 1 *IEF233A M 401,PCTOMF,,MVSGCCR,COMP 07.28.32 JOB 1 MVSGCCR S1 COMP GCCNOMM RC= 0000 07.28.33 JOB 1 MVSGCCR S1 ASM ASMA90 RC= 0000 07.28.33 JOB 1 MVSGCCR S1 LKED IEWL RC= 0000 07.28.33 JOB 1 MVSGCCR S1 EXECC CPROG RC= 0000 07.28.33 JOB 1 IEF404I MVSGCCR - ENDED - TIME=07.28.33 07.28.33 JOB 1 $HASP395 MVSGCCR ENDED On a failure of a test case, this line: 07.28.33 JOB 1 MVSGCCR S1 EXECC CPROG RC= 0000 changes to: 07.28.33 JOB 1 MVSGCCR S1 EXECC CPROG RC= 0012 MVS is a very interesting environment in my opinion, and it's cool to have code working there too. I was thinking that maybe for people who don't wish to install MVS/380 or TK4- on their system, there could be some sort of hacked ftp so that people could go: ftp some.site put cprog.c put go.txt (this hangs while the C program is compiled) get output.txt bye Or for the more generic case: ftp some.different.site put in.jcl put in.zip put go.txt (hangs possibly 10 minutes) get output.txt get out.zip bye (for when you wish to build an entire application, like "sed", on MVS). go.txt could have the required runmvs command, such as: runmvs in.jcl output.txt in.zip out.zip Usage here: C:\mvs380>runmvs Usage runmvs jcl.file print.file [aux_input.file|none] [aux_output.file|none] [ascii|binary|rdwund|rdwvar|vart] [ascii|binary] [awstap.file|none] e.g. runmvs compile.jcl output.txt world.c world.s ascii ascii or runmvs buildgcc.jcl output.txt source.zip xmit.dat default is for files (if provided) to be binary BTW, is that the main testsuite I should be running? There's 633 C files there. Is that enough, given that I'm only building and testing C, or should I also compile the stuff in the "compile" directory at the same level as "execute"? Thanks. Paul. C:\devel\gcc\gcc\config\i370\test>type onecomp.bat rem this should be run in a directory under config/i370 copy ..\..\..\testsuite\gcc.c-torture\execute\%1 cprog.c call mvsgccr cprog.c output.txt grep "EXECC CPROG RC= 0000" output.txt if errorlevel 1 goto bad echo %1 passed >>results.txt goto exit :bad echo %1 failed >>results.txt :exit C:\devel\gcc\gcc\config\i370\test> C:\devel\gcc\gcc\config\i370\test>head dotests.bat del results.txt call onecomp 20000112-1.c call onecomp 20000113-1.c call onecomp 20000121-1.c call onecomp 20000205-1.c call onecomp 20000217-1.c call onecomp 20000223-1.c call onecomp 20000224-1.c call onecomp 20000225-1.c C:\devel\gcc\gcc\config\i370\test> -----Original Message----- From: Joseph S. Myers Sent: Saturday, June 6, 2009 1:02 AM To: Paul Edwards Cc: gcc@gcc.gnu.org Subject: Re: i370 port On Sat, 6 Jun 2009, Paul Edwards wrote: > The port is to a pure C90 environment (ie not posix, not unix). It was a > major effort to achieve that, and it has only just been completed to the > point where the compiler recompiles itself with full optimization. The > environment where it runs is not set up to run shell scripts or makes > or test suites. It's set up to run JCL, and there's a stack of JCL card > decks to allow GCC to compile, which would be good to have included > in the i370 directory. You can test a cross compiler if you have some way of copying a test executable to the i370 system, running it and getting its output and exit status back (actually you don't need to be able to get the exit status since DejaGnu has wrappers to include it in the output if needed). There is no need for the target to be able to run shell scripts or makes. You would need to write your own DejaGnu board file that deals with copying to/from the i370 system and running programs there. The testsuite routinely runs for much more limited embedded systems (using appropriate board files). -- Joseph S. Myers joseph@codesourcery.com