Windows support dropped from gcc trunk

Windows support dropped from gcc trunk

[Tim Prince]

Since Sept. 26, the partial support for Windows 64-bit has been dropped
from gcc trunk:
winnt.c apparently has problems with seh, which prevent bootstrapping,
and prevent the new gcc from building libraries.
libgfortran build throws a fatal error on account of lack of support for
__float128, even if a working gcc is used.
I didn't see any notification about this; maybe it wasn't a concensus
decision?
There are satisfactory pre-built gfortran 5.2 compilers (including
libgomp, although that is off by default and the testsuite wants acc as
well as OpenMP) available in cygwin64 (test version) and (apparently)
mingw-64.

-- 
Tim Prince

Fwd: Windows support dropped from gcc trunk

[Tim Prince]

Sorry if someone sees this multiple times; I think it may have been
stopped by ISP or text mode filtering:

Since Sept. 26, the partial support for Windows 64-bit has been dropped
from gcc trunk:
winnt.c apparently has problems with seh, which prevent bootstrapping,
and prevent the new gcc from building libraries.
libgfortran build throws a fatal error on account of lack of support for
__float128, even if a working gcc is used.
I didn't see any notification about this; maybe it wasn't a consensus
decision?
There are satisfactory pre-built gfortran 5.2 compilers (including
libgomp, although that is off by default and the testsuite wants acc as
well as OpenMP) available in cygwin64 (test version) and (apparently)
mingw-64.

-- 
Tim Prince

Re: Fwd: Windows support dropped from gcc trunk

[Steve Kargl]

On Wed, Oct 14, 2015 at 11:32:52AM -0400, Tim Prince wrote:
> 
> Sorry if someone sees this multiple times; I think it may have been
> stopped by ISP or text mode filtering:
> 
> Since Sept. 26, the partial support for Windows 64-bit has been dropped
> from gcc trunk:
> winnt.c apparently has problems with seh, which prevent bootstrapping,
> and prevent the new gcc from building libraries.
> libgfortran build throws a fatal error on account of lack of support for
> __float128, even if a working gcc is used.
> I didn't see any notification about this; maybe it wasn't a consensus
> decision?
> There are satisfactory pre-built gfortran 5.2 compilers (including
> libgomp, although that is off by default and the testsuite wants acc as
> well as OpenMP) available in cygwin64 (test version) and (apparently)
> mingw-64.
> 

The last comment to winnt.c is

2015-10-02  Kai Tietz  <ktietz70@googlemail.com>

        PR target/51726
        * config/i386/winnt.c (ix86_handle_selectany_attribute): Handle
        selectany within this function without need to keep attribute.
        (i386_pe_encode_section_info): Remove selectany-code.

Perhaps, contact Kai.

I added gcc@gcc.gnu.org as this technically isn't a Fortran issue.

-- 
Steve

Re: Fwd: Windows support dropped from gcc trunk

[Tim Prince]

On 10/14/2015 11:36 AM, Steve Kargl wrote:
> On Wed, Oct 14, 2015 at 11:32:52AM -0400, Tim Prince wrote:
>> Sorry if someone sees this multiple times; I think it may have been
>> stopped by ISP or text mode filtering:
>>
>> Since Sept. 26, the partial support for Windows 64-bit has been dropped
>> from gcc trunk:
>> winnt.c apparently has problems with seh, which prevent bootstrapping,
>> and prevent the new gcc from building libraries.
>> libgfortran build throws a fatal error on account of lack of support for
>> __float128, even if a working gcc is used.
>> I didn't see any notification about this; maybe it wasn't a consensus
>> decision?
>> There are satisfactory pre-built gfortran 5.2 compilers (including
>> libgomp, although that is off by default and the testsuite wants acc as
>> well as OpenMP) available in cygwin64 (test version) and (apparently)
>> mingw-64.
>>
> The last comment to winnt.c is
>
> 2015-10-02  Kai Tietz  <ktietz70@googlemail.com>
>
>         PR target/51726
>         * config/i386/winnt.c (ix86_handle_selectany_attribute): Handle
>         selectany within this function without need to keep attribute.
>         (i386_pe_encode_section_info): Remove selectany-code.
>
> Perhaps, contact Kai.
>
> 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
Please submit a full bug report,^M
I will file a bugzila if that is what is wanted, but I wanted to know if
there is a new configure option required.
As far as I know there were always problems with long double for Windows
targets, but the refusal of libgfortran to build on account of it is new.
Thanks,
Tim

Re: Fwd: Windows support dropped from gcc trunk

[Steve Kargl]

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.

-- 
Steve

Re: Fwd: Windows support dropped from gcc trunk

[Tim Prince]

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.
>
Filed as 67967
I couldn't figure out the format of some fields I tried to fill in.
Thanks

-- 
Tim Prince

Re: Fwd: Windows support dropped from gcc trunk

[Steve Kargl]

On Wed, Oct 14, 2015 at 01:29:18PM -0400, Tim Prince wrote:
> 
> 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.
> >
> Filed as 67967
> I couldn't figure out the format of some fields I tried to fill in.

Thanks, sorry I could not be of much more help.

-- 
Steve

Re: Fwd: Windows support dropped from gcc trunk

[Tim Prince]

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).

Re: Fwd: Windows support dropped from gcc trunk

[Paul Richard Thomas]

Dear Tim,

Thanks from all of us for taking this on. It is clear from clf that a
lot of people out there are using gfortran under windows and that the
poor support is not doing much for the reputation of gfortran.

Cheers

Paul

On 16 October 2015 at 22:57, Tim Prince <tprince818.tp@gmail.com> wrote:
>
>
> 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).



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

Re: Windows support dropped from gcc trunk

[FX]

> 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

Re: 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.

Re: Windows support dropped from gcc trunk

[FX]

Dear Tim,

> As far as I can see now, there is simply the one new explicit block against building gfortran libraries in the absence of __float128

Please, please be more explicit. There is no “explicit block against building gfortran libraries in the absence of __float128”. You can check on gcc-testresults list that there are a lot of targets without __float128. Also: you posted results for cygwin with trunk dated 20151014. Nothing has changed in libgfortran since then.

I am probably the best person to help you there, since I implemented support for __float128 in gfortran and libgfortran.
Unfortunately, I cannot help you more than that if you don’t give me any hard information:
 1. the error message
 2. the building options (configure options).

Once the build issues are sorted out, I can look into testsuite failures.

FX