From patchwork Sat Jul 12 19:15:02 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tobias Burnus X-Patchwork-Id: 369362 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 7072C1400B2 for ; Sun, 13 Jul 2014 05:15:19 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:content-type; q= dns; s=default; b=Yk/qgtbwUnTeWHV/Ub/KdBV5WuTkmFqUo7e9WRzDE2mLCG mAjJ6F1GZ76HBU3Dl43KHEzvLMpXysdH1ElaIH/UB8IRjd3nYa0GDtRRfDCFFZHp BX8nBZ+CA6NK0nyR9pxxUaaqADAz+dLH2EMxxYhQ1i1Cw6zgd8jJp75RA7xCY= 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 :message-id:date:from:mime-version:to:subject:content-type; s= default; bh=RGwDR/dEFJxLufxoKE5Jp1eUyNs=; b=PLATpMAAp3rXkDLe4sJr XSdZ9IAYcnDqm41xaKjv4mGduSGKZCLAOHHx3LSOSDB+SBaSD4NpEjqwzko9h3E5 jWcxbaWtPoXO6CswqTHMjTzCsWI0O4GDUvkizBPVPERkcKfaXkn/xgH7VGbbMbQh TV2bBlEStPi6XiO3kaJQ02M= Received: (qmail 26668 invoked by alias); 12 Jul 2014 19:15:08 -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 26646 invoked by uid 89); 12 Jul 2014 19:15:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx01.qsc.de Received: from mx01.qsc.de (HELO mx01.qsc.de) (213.148.129.14) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sat, 12 Jul 2014 19:15:06 +0000 Received: from tux.net-b.de (port-92-194-213-151.dynamic.qsc.de [92.194.213.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.qsc.de (Postfix) with ESMTPSA id 3B6D03CBC9; Sat, 12 Jul 2014 21:15:02 +0200 (CEST) Message-ID: <53C18936.1070001@net-b.de> Date: Sat, 12 Jul 2014 21:15:02 +0200 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: gcc-patches , gfortran Subject: [Patch, Fortran, committed] Fix Fortran bug affecting MinGW-w64, only 64bit Windows is special as "long" is only 32bit wide - while pointers are 64bit and, hence, wider. Another special code is gfortran's array descriptor. Its "dtype" field is of type ptrdiff_t and it stores the array rank and type in the first 6 bits and uses the remaining size to store the byte size for an array. In case of 32bit systems, one has 32bits - 6 bits = 24 bits (or There seems to be a single piece of code in gfortran, which assumes that a pointer and long have the same width. Namely, the code which checks that one can squeeze the array-element size together with the data type and the rank into the "dtype" field of the array descriptor, which has the type ptrdiff_t. For a system with 32bit pointer size (= type precision of size_type_node or for ptrdiff_t), one has 32 bits minus 6 bits = 26 bits space. Thus, a single array element might "only" be 64 mega bytes large. For 64bit pointers, 58 bits remain. For some odd reason, the code does not use size_type_node or something equivalent but it uses an unsigned long. On 32bit Windows and on Linux, everything is fine. But on 64bit Windows (i.e. MinGW-w64), one tries to squeeze 58 bits into a 32bit pointer – which will cause that gfc_max_array_element_size has the wrong result. This patch does the obvious: It masks out the required bits on a size_type_node instead. Committed as obvious as Rev. 212485. * * * Unfortunately, that patch does not solve the original problem: On 32bit – and now also on 64 bit – Windows, the array and the trailing "done" is not printed. One has still to investigate why that fails. Tobias Index: gcc/fortran/ChangeLog =================================================================== --- gcc/fortran/ChangeLog (Revision 212484) +++ gcc/fortran/ChangeLog (Arbeitskopie) @@ -1,5 +1,11 @@ 2014-07-12 Tobias Burnus + PR fortran/61628 + * trans-types.c (gfc_init_types): Fix data-type bug + with gfc_max_array_element_size. + +2014-07-12 Tobias Burnus + * libgfortran.h (libcaf_atomic_codes): Add. * trans-decl.c (gfor_fndecl_caf_atomic_def, gfor_fndecl_caf_atomic_ref, gfor_fndecl_caf_atomic_cas, Index: gcc/fortran/trans-types.c =================================================================== --- gcc/fortran/trans-types.c (Revision 212483) +++ gcc/fortran/trans-types.c (Arbeitskopie) @@ -955,9 +955,9 @@ gfc_init_types (void) n = TYPE_PRECISION (gfc_array_index_type) - GFC_DTYPE_SIZE_SHIFT; gfc_max_array_element_size - = wide_int_to_tree (long_unsigned_type_node, + = wide_int_to_tree (size_type_node, wi::mask (n, UNSIGNED, - TYPE_PRECISION (long_unsigned_type_node))); + TYPE_PRECISION (size_type_node))); boolean_type_node = gfc_get_logical_type (gfc_default_logical_kind); boolean_true_node = build_int_cst (boolean_type_node, 1);