This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, fortran] PR37735 - Allocatable components in vectors of derived types cause ICE on assignment

Daniel Kraft wrote:
> Paul Richard Thomas wrote:
>> The following testcase (which is now alloc_comp_assign_7.f90), would
>> ICE in the assignment to 'p' because structure_alloc_comps failed to
>> recognise that the array component 'r' is descriptorless.  I have
>> absolutely no idea how Erik and I managed to miss this sort of derived
>> type in our testsuite case - I guess that there are just too many
>> possible combinations.
> looks good to me.  Does not mean anything, though :)
Ditto from my side; I don't know how much that means ;-)

>> Bootstrapped and regtested on FC9/x86_i64
>> OK for trunk and 4.3?
OK thanks for the patch.

 * * *

Regarding 4.4 in general:

a) There are 117 P1 to P3 regressions, 7 of those are P1.
Branching is planned to happen if there are no P1 and below 100 P2/P3

b) gfortran has no real regression (ignoring the I/O performance PR,
some rejects-valid -> ICE-on-valid change, and Thomas' PR which has an
approved patch).

c) There are 5 non-suspended Fortran95 PRs and 17 wrong-code PRs, some
of which are quite special; in total there are 48 bugs in the
wrong-code/rejects-valid/ice-on-valid-code category. While I - as anyone
- would prefer zero bugs for (b) and (c), there is no real show stopper :-)

Paul wrote the other day (18 November):
> Tobias Burnus wrote:
> > Thus it looks quite good - unless there are buried regressions.
> "Quite good" is an understatement - you have all done a magnificent
> job to reduce the regressions, the F95 bugs and a load of others.

Well, I think there are others who did more work. But I agree, gfortran
has indeed only few bugs and it made also good progress in terms of
diagnostics and features. Thanks to all! Besides the usual suspects,
especially Jakub did a lot (lots of debugging patches, fixing
libgfortran ABI problem, some other fixes)! Kudos!

(With regards to debugging: (1) I think there are still some debugging
bugs which we should try to fix, esp. PR 34153; (2) Jan Kratochvil has
some GDB patches to support Fortran 95 array descriptors, cf.

>> > We should rebuild the binaries (partially they are quite out to date!)
>> > and should ask at c.l.f for testing the current version; also we should
>> > ask Dick Hendrickson to re-run his test suite.
> That would be a very good idea.  I have not done a search on
> "Hendrickson" in Bugzilla for a while.  Two are errors/warnings, one
> is suspended and the last is the MVBITS bug that Mikael is working on.
Well, I don't know whether there are more items which he has not yet
reported - or whether there is now a regression. I will write him after
your two patches are checked in.

> Indeed - I agree with that strongly.  We can use the time to start
> discussing the gcc-4.5 projects, to clean up the fortran PRs(reduce
> the UNCOs etc..) and do do some further triage on them(eliminate
> spurious/WONT_FIX bugs; identify low likelehood feature requests; and
> so on.).
Yes. Though there are enough smaller PRs which might make sense to still
get in 4.4.0.

One 4.5 item in which I'm interested is to get -finit-real-sNaN and
basic IEEE support working; that seems to be an area where gfortran is
featurewise behind other major compilers.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]