Windows support dropped from gcc trunk

[Tim Prince]

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.