From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18041 invoked by alias); 13 May 2011 18:24:40 -0000 Received: (qmail 18031 invoked by uid 22791); 13 May 2011 18:24:39 -0000 X-SWARE-Spam-Status: No, hits=-0.0 required=5.0 tests=AWL,BAYES_40,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,TW_CF X-Spam-Check-By: sourceware.org Received: from mail-qw0-f47.google.com (HELO mail-qw0-f47.google.com) (209.85.216.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 May 2011 18:24:25 +0000 Received: by qwh5 with SMTP id 5so1617851qwh.20 for ; Fri, 13 May 2011 11:24:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.7.3 with SMTP id b3mr1412897qcb.194.1305311064214; Fri, 13 May 2011 11:24:24 -0700 (PDT) Received: by 10.229.33.209 with HTTP; Fri, 13 May 2011 11:24:24 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 May 2011 21:56:00 -0000 Message-ID: Subject: Re: [patch gimplifier]: Make sure TRUTH_NOT_EXPR has boolean_type_node type and argument From: Kai Tietz To: Andrew Pinski Cc: GCC Patches , Richard Guenther Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-05/txt/msg01012.txt.bz2 2011/5/13 Kai Tietz : > 2011/5/13 Andrew Pinski : >> On Fri, May 13, 2011 at 4:31 AM, Kai Tietz wro= te: >>> >>> =A0 =A0 case TRUTH_NOT_EXPR: >>> + =A0 =A0 =A0if (!useless_type_conversion_p (boolean_type_node, =A0rhs1= _type) >>> + =A0 =A0 =A0 =A0 =A0|| !useless_type_conversion_p (boolean_type_node, = =A0lhs_type)) >> >> In Fortran (and maybe other langauges) there are booleans with >> different sizes but the same precision. >> Can you explain how you handle those and why this can't just be a >> BOOLEAN_TYPE type? > > Well, the issue is to be found in gimple_boolify. It is necessary that > it is ensured that operands getting boolified on demand. Doing this by > default boolean_type_node is used. > To verify that, patch converts also for wider-mode BOOLEAN-types back > to boolean_type_node type. > Before thi no boolification of operands were done for expressions with > any boolean type. As we want to make sure that operands getting fixed, > too, but gimplifier doesn't know which resulting type it should have, > we truncate it back to 1-bit boolean. > I assume that the underlying issue is here that some places introduce > - via the backdoor - gimple trees, with abitrary boolean-type. IMHO > those places should be fixed and use for this gimplication to make > sure things getting normalized. I investigate this a bit more in detail and indeed it is the fortran FE which do here enter in trans-*.c files their own gimple code. And this code doesn't run over the gimplify_expr routines and so it gets in conflict with tree-cfg.c checks. There are two ways to go. A) Adjust fortran's trans-* stuff so that it uses for conditionals and logical-expressions boolean_type consequent (as in some place this type is used, but sometimes artifical boolean_types direct). Or B) We relax tree-cfg checks for logical ops to allow also BOOLEAN types with wider size then 1-bit. Regards, Kai