From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17273 invoked by alias); 18 Jul 2009 11:28:51 -0000 Received: (qmail 17262 invoked by uid 22791); 18 Jul 2009 11:28:50 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f177.google.com (HELO mail-pz0-f177.google.com) (209.85.222.177) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 18 Jul 2009 11:28:44 +0000 Received: by pzk7 with SMTP id 7so977928pzk.0 for ; Sat, 18 Jul 2009 04:28:42 -0700 (PDT) Received: by 10.142.199.15 with SMTP id w15mr572151wff.78.1247916522064; Sat, 18 Jul 2009 04:28:42 -0700 (PDT) Received: from Paullaptop (203-206-7-21.dyn.iinet.net.au [203.206.7.21]) by mx.google.com with ESMTPS id 20sm6165663wfi.20.2009.07.18.04.28.38 (version=SSLv3 cipher=RC4-MD5); Sat, 18 Jul 2009 04:28:40 -0700 (PDT) Message-ID: <9561B75B3A4540B3AEAAA6671D42E583@Paullaptop> From: "Paul Edwards" To: "Ulrich Weigand" Cc: "Daniel Jacobowitz" , References: <200906191227.n5JCRm4b025019@d12av02.megacenter.de.ibm.com> In-Reply-To: <200906191227.n5JCRm4b025019@d12av02.megacenter.de.ibm.com> Subject: Re: i370 port Date: Sat, 18 Jul 2009 11:28: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-07/txt/msg00338.txt.bz2 >> But sometimes r_or_s_operand is being used as a source, in >> which case, the constant is fine. But when it is used as a >> destination, it is not fine. >> >> What is the *simplest* way of changing the setup so that the >> code generation remains the same, but the warning is eliminated? > > Well, I guess you need to do two things: > > - Define the PREDICATE_CODES macro -- if this is undefined, > genrecog will consider *any* target-defined predicate as > potentially allowing non-lvalues, because it cannot know > better. > > - Actually define two distinct predicates, one that allows > non-lvalue and one that doesn't, and use them as appropriate. > >> But wondering if there's something simpler and neater. > > Well, you could also simply ignore the warning -- nothing > is going to go wrong because of it. Thanks for pointing me in the right direction Ulrich. Unfortunately just short of what would have been best for this situation. I defined the PREDICATE_CODES macro and put in the things I thought were appropriate: C:\devel\gcc\gcc\config\i370>cvs diff -r 1.33 -r 1.34 i370.h Index: i370.h =================================================================== RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v retrieving revision 1.33 retrieving revision 1.34 diff -r1.33 -r1.34 200a201,204 > #define PREDICATE_CODES \ > {"r_or_s_operand", { REG, SUBREG, MEM, CONST_INT }}, \ > {"s_operand", { MEM, CONST_INT }}, > It had no effect on anything that I could see, but that was to be expected. I then had a closer look at the machine definitions and realised that some of them that were defined as r_or_s_operand could instead be nonimmediate_operand, which started eliminating warnings. So I proceeded down this track, eliminating things here and there, or in some cases, opening things up to be more general, with the hope that I would eventually have things so that the only r_or_s_operand I needed were ones that didn't require literals, so that I could (at the end), make this change: C:\devel\gcc\gcc\config\i370>cvs diff -r 1.34 -r 1.35 i370.h Index: i370.h =================================================================== RCS file: c:\cvsroot/gcc/gcc/config/i370/i370.h,v retrieving revision 1.34 retrieving revision 1.35 diff -r1.34 -r1.35 202,203c202,203 < {"r_or_s_operand", { REG, SUBREG, MEM, CONST_INT }}, \ < {"s_operand", { MEM, CONST_INT }}, --- > {"r_or_s_operand", { REG, SUBREG, MEM }}, \ > {"s_operand", { MEM }}, and something similar in i370.c, to make constants invalid, so that I could eliminate the warnings. It took a month to do that, because I kept on being hit by presumed bugs, which started generating bad or unexpected code when I made a seemingly innocuous change. To make matters worse, sometimes I could only find out whether the code was good or not by running it on MVS, via the emulator, which means a 2 hour wait for a result. However, I did get it down to just a handful of warnings, which would be eliminated now that I could drop the CONST_INT. And I would check the generated code to see what I had missed when I took off the CONST_INT. Anyway, I took off the CONST_INT, and the warnings all disappeared, and the code didn't change! I then found out that even with old versions of the machine definition, I can have the warning removed by simply not defining CONST_INT in the PREDICATE_CODES, even though it is allowed when the function is called. ie it seems to have no effect on the code generation, but succeeds in eliminating the warning, and without needing to define an extra constraint for non-constant situations. So I've revamped the machine definition unnecessarily. Well, I did make things defined more consistently, and did make code generation improvements, but they're not major, and I wouldn't have done any of it if I knew I could have just defined a predicate that wasn't really going to be used. Oh well. At the end of the day, the warning has gone, the code is better and the machine definition is more correct. :-) I've also got 3.4.6 working to some extent. I have managed to build an single GCC executable, and if I call it with no parameters, it prints its usage (as designed). However, if I try to pass parameters it doesn't recognize them. It could be something to do with not having run the appropriate stuff through bison (or flex) on an EBCDIC platform. Normally I use this to get around that problem: C:\devel\gccnew\gcc>cvs diff -r release-3_4_6 c-parse.c Index: c-parse.c =================================================================== RCS file: c:\cvsroot/gccnew/gcc/c-parse.c,v retrieving revision 1.1.1.1 retrieving revision 1.4 diff -r1.1.1.1 -r1.4 497a498,503 > #if defined(__MVS__) || defined(__CMS__) > #define YYTRANSLATE(YYX) \ > ((unsigned int) (YYX) <= YYMAXUTOK ? \ > ((unsigned int) (YYX) < 256 ? yytranslate[_sch_ebcasc[YYX]] \ > : yytranslate[YYX]) : YYUNDEFTOK) > #else 499a506 > #endif But perhaps the new gengtyp lex and yacc, although not used in the actual GCC executable, are causing a problem by being run on the ASCII machine. Next step is to see if I can run the generated files all on MVS so that that is eliminated from the equation. Since I actually do have an EBCDIC flex and bison available now (thanks to 3.2.3). I also had problems with 3.4.6 when I switched on optimization. A couple of internal errors popped up, which will presumably trace back to the i370 code, but be outside my knowledge to fix. BFN. Paul.