From patchwork Tue May 24 12:47:49 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Hubicka X-Patchwork-Id: 625616 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3rDbQm0Z3Mz9sCy for ; Tue, 24 May 2016 23:11:43 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=mfg1bNbU; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=twbc5eTxHG/GgZTYh iqcnmVHPNLCTOaI3xEVTE1nzuvUuXapFlPJ6mH51RkKcbMRj+ugeauOKHTI/0Rbz cvZzheLnGygCWsRKTj5A5ZKakn8RSDVQyNRBHRbqa5+3BkBNMMLsY/ocYW+agpOW 1TViKGsyR6Nnd03Qy0FiZlD+A8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=WBTW9fR9FlXqoVnX/2Lnm1e Kczc=; b=mfg1bNbUTyk6RNtWWaoRpIkJrFUVEH6+I2WJXlISnvd7LBrM7K+yXV1 0hmqz4ycH6IyNLuARIpG0ey5M3b9lvToiBLfuX4etSIIoV9bGaph1cm5ZDuUMtlx XGjJlhdJt/JzW/LK2GrHkwYfy3nAoVvWi51KUm16f5WGzdxtOBUE= Received: (qmail 129965 invoked by alias); 24 May 2016 12:55:41 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 114486 invoked by uid 89); 24 May 2016 12:53:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 24 May 2016 12:48:25 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 9F3C4545484; Tue, 24 May 2016 14:47:49 +0200 (CEST) Date: Tue, 24 May 2016 14:47:49 +0200 From: Jan Hubicka To: Jan Hubicka Cc: Richard Biener , gcc-patches@gcc.gnu.org, jvdelisle@gcc.gnu.org, tkoenig@gcc.gnu.org, pault@gcc.gnu.org Subject: Re: [fortran] Re: Make array_at_struct_end_p to grok MEM_REFs Message-ID: <20160524124749.GE60007@kam.mff.cuni.cz> References: <20160520131048.GA55871@kam.mff.cuni.cz> <20160523163236.GA60007@kam.mff.cuni.cz> <20160524102702.GB63338@kam.mff.cuni.cz> <20160524122259.GC60007@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160524122259.GC60007@kam.mff.cuni.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Hi, I tried the attached patch that gets rid of gfc_array_range_type because it seems pointless from middle-end POV. It however affects .original dumps in the following way: --- assumed_type_2.f90.003t.original 2016-05-24 14:32:45.771503552 +0200 +++ ../assumed_type_2.f90.003t.original 2016-05-24 14:34:07.637311579 +0200 @@ -246,7 +246,7 @@ parm.20.offset = NON_LVALUE_EXPR ; D.3504 = _gfortran_internal_pack (&parm.20); sub_array_assumed (D.3504); - if ((void *[0:] *) parm.20.data != (void *[0:] *) D.3504) + if ((void *[] *) parm.20.data != (void *[] *) D.3504) { _gfortran_internal_unpack (&parm.20, D.3504); __builtin_free (D.3504); @@ -576,12 +576,12 @@ { static logical(kind=4) C.3584 = 1; - sub_scalar (&(*(real(kind=4)[0:] * restrict) array_real_alloc.data)[(array_real_alloc.offset + array_real_alloc.dim[1].stride * 2) + 3], &C.3584); + sub_scalar (&(*(real(kind=4)[] * restrict) array_real_alloc.data)[(array_real_alloc.offset + array_real_alloc.dim[1].stride * 2) + 3], &C.3584); } { static logical(kind=4) C.3585 = 1; - sub_scalar (&(*(character(kind=1)[0:][1:1] *) array_char_ptr.data)[array_char_ptr.offset + NON_LVALUE_EXPR ], &C.3585, 1); + sub_scalar (&(*(character(kind=1)[][1:1] *) array_char_ptr.data)[array_char_ptr.offset + NON_LVALUE_EXPR ], &C.3585, 1); } { static logical(kind=4) C.3586 = 1; Which breaks testsuite. Perhaps just can be printed as 0: (because that is what NULL domain means). This is done by dump_array_domain in pretty-print.c and I am not quite sure who else relies on the format. Or we can just compoensate the testsuite given that the bounds are really unknown... Honza Index: trans-types.c =================================================================== --- trans-types.c (revision 236556) +++ trans-types.c (working copy) @@ -52,7 +52,6 @@ along with GCC; see the file COPYING3. CInteropKind_t c_interop_kinds_table[ISOCBINDING_NUMBER]; tree gfc_array_index_type; -tree gfc_array_range_type; tree gfc_character1_type_node; tree pvoid_type_node; tree prvoid_type_node; @@ -945,12 +944,6 @@ gfc_init_types (void) = build_pointer_type (build_function_type_list (void_type_node, NULL_TREE)); gfc_array_index_type = gfc_get_int_type (gfc_index_integer_kind); - /* We cannot use gfc_index_zero_node in definition of gfc_array_range_type, - since this function is called before gfc_init_constants. */ - gfc_array_range_type - = build_range_type (gfc_array_index_type, - build_int_cst (gfc_array_index_type, 0), - NULL_TREE); /* The maximum array element size that can be handled is determined by the number of bits available to store this field in the array @@ -1920,12 +1913,12 @@ gfc_get_array_type_bounds (tree etype, i /* We define data as an array with the correct size if possible. Much better than doing pointer arithmetic. */ - if (stride) + if (stride && akind >= GFC_ARRAY_UNKNOWN) rtype = build_range_type (gfc_array_index_type, gfc_index_zero_node, int_const_binop (MINUS_EXPR, stride, build_int_cst (TREE_TYPE (stride), 1))); else - rtype = gfc_array_range_type; + rtype = NULL; arraytype = build_array_type (etype, rtype); arraytype = build_pointer_type (arraytype); if (restricted)