From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86396 invoked by alias); 9 Apr 2015 18:54:54 -0000 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 Received: (qmail 86289 invoked by uid 89); 9 Apr 2015 18:54:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 09 Apr 2015 18:54:52 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t39IspN6025820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 9 Apr 2015 14:54:51 -0400 Received: from [10.10.52.246] (unused [10.10.52.246] (may be forged)) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t39IsoH2017752 for ; Thu, 9 Apr 2015 14:54:50 -0400 Message-ID: <5526CAF9.8080907@redhat.com> Date: Thu, 09 Apr 2015 18:54:00 -0000 From: Martin Sebor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Gcc Patch List Subject: [PATCH] gfortran.dg/pr32627.f03 prints nul byte Content-Type: multipart/mixed; boundary="------------080004020201030508030207" X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00408.txt.bz2 This is a multi-part message in MIME format. --------------080004020201030508030207 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-length: 641 We've been debugging a problem where nul (and other control) characters have been randomly appearing in powerpc parallel build logs. In the process, I noticed that some of the nuls are readily reproducible. One such case is due to the pr32627.f03 test which verifies that Fortran programs can initialize character arrays from C strings. The test declares an array as big as the C string (including the terminating nul) and prints its value to stdout. This then causes the nul to appear in the log files. The attached patch changes the declaration of the Fortran array to match the number of non-nul characters. Tested on powerpc64. Martin --------------080004020201030508030207 Content-Type: text/x-patch; name="gcc-pr32627.f03-nul.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gcc-pr32627.f03-nul.patch" Content-length: 607 2015-04-09 Martin Sebor * gfortran.dg/pr32627.f03 (strptr): Change size to match the number of non-nul characters. diff --git a/gcc/testsuite/gfortran.dg/pr32627.f03 b/gcc/testsuite/gfortran.dg/pr32627.f03 index f8695e0..d9e2b13 100644 --- a/gcc/testsuite/gfortran.dg/pr32627.f03 +++ b/gcc/testsuite/gfortran.dg/pr32627.f03 @@ -18,7 +18,7 @@ program main type( c_ptr ) :: x type( A ), pointer :: fptr type( A ), target :: my_a_type - character( len=9 ), pointer :: strptr + character( len=8 ), pointer :: strptr fptr => my_a_type --------------080004020201030508030207--