Re: Fwd: Windows support dropped from gcc trunk

[Tim Prince <tprince818.tp@gmail.com>]

On 10/14/2015 1:08 PM, Steve Kargl wrote:
> On Wed, Oct 14, 2015 at 11:48:27AM -0400, Tim Prince wrote:
>>> I added gcc@gcc.gnu.org as this technically isn't a Fortran issue.
>> test suite reports hundred of new ICE instances, all referring to this
>> seh_unwind_emit function:
>>
>> /cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/gcc/testsuite/gcc.c-torture/compile/20000127-1.c:
>> In function 'foo':^M
>> /cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/gcc/testsuite/gcc.c-torture/compile/20000127-1.c:7:1:
>> internal compiler error: in i386_pe_seh_unwind_emit, at
>> config/i386/winnt.c:1137^M
> I think you'll need to file a bug report.  It probably
> should be labeled as target specific and give a major
> status.
>
The fixes checked in by Uros appear to have taken care of the C
problem.  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.  configure still finds correct results on
which math functions are supported in each data type.  There is a
sqrtl() but not much more (and that will be the same as sqrt as Windows
X64 sets 53-bit precision mode).
Assuming I get a satisfactory gfortran testsuite, I'll post it.  gcc and
g++ testsuites appeared to be back in the ballpark.
Testsuite always produced failure of all rounding tests because of the
lack of support for real(10) and real(16).