From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-386402-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 14197 invoked by alias); 3 Dec 2014 00:21:08 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 14177 invoked by uid 89); 3 Dec 2014 00:21:07 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2
X-Spam-User: qpsmtpd, 2 recipients
X-HELO: relay1.mentorg.com
Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 Dec 2014 00:21:06 +0000
Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com)	by relay1.mentorg.com with esmtp 	id 1Xvxgj-0002xO-MB from Tom_deVries@mentor.com ; Tue, 02 Dec 2014 16:21:01 -0800
Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.181.6; Wed, 3 Dec 2014 00:21:00 +0000
Message-ID: <547E575A.1060808@mentor.com>
Date: Wed, 03 Dec 2014 00:21:00 -0000
From: Tom de Vries <Tom_deVries@mentor.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Paul Richard Thomas <paul.richard.thomas@gmail.com>, Tobias Burnus	<burnus@net-b.de>
CC: gcc patches FOR <gcc-patches@gcc.gnu.org>, gfortran <fortran@gcc.gnu.org>
Subject: Re: [4.8, Fortran, Patch] PR 48820 - Support TYPE(*) of TS29113
References: <4F50AEDB.2010008@net-b.de> <CAGkQGiKmNMfQ9gMJvo=WC+LFcFEkA_qVo3pxTBMitYnUDr41Eg@mail.gmail.com>
In-Reply-To: <CAGkQGiKmNMfQ9gMJvo=WC+LFcFEkA_qVo3pxTBMitYnUDr41Eg@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-SW-Source: 2014-12/txt/msg00231.txt.bz2

On 03/03/12 08:41, Paul Richard Thomas wrote:
> Dear Tobias,
> 
> This is certainly OK for 4.8.
> 
> I have a couple of remarks:
> (i) The DTYPE_TYPE_MASK is 0x38 so that we saturated it a long time
> since!  At the moment it does not cause any problems because of the
> extremely limited use of the dtype 'type'.

Hi,

AFAIU, you're saying here that since there are very few uses of the type part of
dtype, it's not a problem.

But at the moment, BT_ASSUMED with value 11 bleeds into the size part of dtype.

In gfc_get_dtype_rank_type, we just set the type directly without applying the mask:
...
  i = rank | (n << GFC_DTYPE_TYPE_SHIFT);
...

In fact, the mask seems completely unused.

>  Whilst the array
> descriptor revamp will eliminate such worries, we should be mindful of
> this; and

I think that if we have a mask that we're not respecting, we need to clearly
document at the definiton how that's done and why that's not a problem. And
ideally, add some asserts to detect when we break that allowed usage pattern.

Thanks,
- Tom