From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120178 invoked by alias); 18 Oct 2015 09:51:07 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 120165 invoked by uid 89); 18 Oct 2015 09:51:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ig0-f181.google.com Received: from mail-ig0-f181.google.com (HELO mail-ig0-f181.google.com) (209.85.213.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 18 Oct 2015 09:51:04 +0000 Received: by igbhv6 with SMTP id hv6so39800919igb.0 for ; Sun, 18 Oct 2015 02:51:02 -0700 (PDT) X-Received: by 10.50.78.194 with SMTP id d2mr2293718igx.72.1445161862602; Sun, 18 Oct 2015 02:51:02 -0700 (PDT) Received: from [192.168.0.8] (cpe-98-30-246-22.cinci.res.rr.com. [98.30.246.22]) by smtp.googlemail.com with ESMTPSA id k202sm11982284ioe.41.2015.10.18.02.51.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Oct 2015 02:51:02 -0700 (PDT) Message-ID: <56236B6A.5070308@gmail.com> Date: Sun, 18 Oct 2015 09:51:00 -0000 From: Tim Prince User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: FX , Paul Richard Thomas CC: Steve Kargl , "fortran@gcc.gnu.org" , ktietz70@googlemail.com Subject: Re: Windows support dropped from gcc trunk References: <561E67C1.40701@aol.com> <561E75A4.50001@gmail.com> <20151014153647.GA56419@troutmask.apl.washington.edu> <561E794B.60203@gmail.com> <20151014170853.GA56746@troutmask.apl.washington.edu> <562164AB.5080306@gmail.com> <0B5FC90C-7B68-4ABE-863A-483A80DA16DD@gmail.com> In-Reply-To: <0B5FC90C-7B68-4ABE-863A-483A80DA16DD@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2015-10/txt/msg00086.txt.bz2 On 10/18/2015 3:58 AM, FX wrote: >> I am just finishing up a build of libgfortran using the new >> compiler, after editing the .h files to permit building in spite of the >> lack of support for either real(10) or real(16). It still looks >> intentional that someone changed libgfortran so that it won't build >> automatically for this case. > I don’t understand what you mean here. I’m not sure if this is meant to be an accusation (against whom?), but please don’t do that. Just point us to 1. what is the actual problem, 2. what change in the libgfortran code lead to it (if you know), and then we’ll fix it. > > FX I'm sorry, the current releases made it unexpectedly difficult to restore working build. As far as I can see now, there is simply the one new explicit block against building gfortran libraries in the absence of __float128, with the evident work-around of eliminating the warning, which is treated as fatal even in the presence of --disable-werror (should __float128 be defined somewhere?). By building libquadmath individually if and when it is skipped (by cd'ing into the directory and running its configure) , remaining problems with missing real(10) and real(16) support can be overcome. In recent months, it was sufficient a majority of the time to update from svn and run make -j 3. A majority of the times when that failed, it was sufficient to bootstrap by cleaning out the build directory, configure, and issuing the make command once. make distclean may appear to work but can't be relied upon. The faster method is to rename the build directory in order to delete it, and create a new directory. Testsuite still has questions about what is being tested: default_format_denormal_1.f90 doesn't set the IEEE underflow mode, so the XPASS is likely due to running with abrupt underflow (the Windows X64 default). round_4.f90 still reports "failed to produce executable" even though it is only real(10) which is not supported. I think the missing nextafterl() is seen during configure. Likewise, large_1 and large_2 fail on account of lack of nextafterl() and rintl(). I haven't understood whether anything is done to take care of OS such as Windows X64 which set x87 53-bit precision mode as well as SSE abrupt underflow prior to launching each .exe. Microsoft C++ runtime relies on those settings, while gcc/gfortran seems to rely on hardware defaults. In Windows 32-bit, each application is expected to set 53-bit mode and abrupt underflow prior to calling Microsoft math functions.