From owner-sc22wg5@open-std.org  Fri Nov 13 20:25:35 2009
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id 9D30DC178E4; Fri, 13 Nov 2009 20:25:35 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
X-Greylist: delayed 416 seconds by postgrey-1.18 at www2.open-std.org; Fri, 13 Nov 2009 20:25:34 CET
Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224])
	by www2.open-std.org (Postfix) with ESMTP id BF76FC178E2
	for <sc22wg5@open-std.org>; Fri, 13 Nov 2009 20:25:34 +0100 (CET)
Received: by gxk24 with SMTP id 24so850918gxk.6
        for <sc22wg5@open-std.org>; Fri, 13 Nov 2009 11:25:33 -0800 (PST)
Received: by 10.101.11.10 with SMTP id o10mr5609023ani.91.1258139916425;
        Fri, 13 Nov 2009 11:18:36 -0800 (PST)
Received: from ?10.64.79.197? (72-254-99-154.client.stsn.net [72.254.99.154])
        by mx.google.com with ESMTPS id 4sm13893ywd.44.2009.11.13.11.18.09
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Fri, 13 Nov 2009 11:18:35 -0800 (PST)
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v1076)
Subject: Problems created by some compiler extended size options
From: Craig Rasmussen <crasmussen@newmexicoconsortium.org>
In-Reply-To: <31F0E6B7-DFAE-4E3D-BA8F-21EDAA094A97@mac.com>
Date: Fri, 13 Nov 2009 12:18:07 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <1FAC2E45-A159-463B-A037-16B069990D29@newmexicoconsortium.org>
References: <31F0E6B7-DFAE-4E3D-BA8F-21EDAA094A97@mac.com>
To: WG5 <sc22wg5@open-std.org>
X-Mailer: Apple Mail (2.1076)
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

There was a discussion at the MPI forum regarding the use of extended  
size compiler options.  It appears that there some options on some  
compilers that promote integers even if the kind parameter is specified.

The problem with this is that it breaks the C interoperability  
standard.  For example, the code,

       integer(C_INT) :: i
       call bindc_function(i)

appears to be broken as the variable i will get promoted.

Is this a common compiler option?  I've been told that users most  
often chose the compiler option that promotes everything, even if an  
explicit kind is provided.

I think this practice is evil!

-craig