GCC 4.7.0 Status Report (2011-10-11)

[Janne Blomqvist]

On Wed, Oct 12, 2011 at 00:11, Tobias Burnus <burnus@net-b.de> wrote:
> For your interest.
>
> General GCC status: See below. But first a short gfortran 4.7 status report:
>
> * 8 regressions:
> PR50690 [4.7] ICE with front-end optimization and OpenMP
>        - Thomas has a patch
> PR50570 [4.6/4.7] Pointer intent: Rejects valid
>        - Assigned to Janus, draft patch exists
> PR50410 [4.6/4.7] ICE with invalid DATA init
> PR50659 [4.4--4.7] ICE with valid PROCEDURE statement
>        - Fixed for 4.7, backporting pending
> PR47023 [4.6/4.7] C_SIZEOF - Rejects valid arg
> PR50105 [4.6/4.7] Wrong number of "*" with I/O
>        - One probably should request an interpretation request
>        - Old behaviour probably correct
>        - (slightly) more compiler show current result
> PR49791 [4.4--4.7] Extended namelist read fails
>        - Remains: Special case of a vendor extension
> PR42954 [4.5/4.6/4.7] CPP target macros

I think one could add 50016 as a regression as well.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50016

It seems IO performance in some cases on Windows has tanked since the
4.6 release (at least by 2 orders of magnitude according to the bug
reporter). I don't have a windows system to test on, so I can't
confirm whether my suspicion that I mentioned in the PR is correct.
But it seems reasonable.

I think in general, we ought to think what inquiring for the size of
an open file means (the standard doesn't really help here, AFAICS):

- Is it the size of the file as reported by the OS?

- Is it the size of the file as seen by libgfortran? (which can be
different than the previous option, due to buffering)

- Or should we flush the buffer in order to make the OS and
libgfortran sizes consistent at the moment of the inquire execution?
This is what we do now, but for some strange reason it seems to
require the equivalent of fsync() on windows (WTF?), so performance is
bad.



-- 
Janne Blomqvist