[Patch, fortran] PR37735 - Allocatable components in vectors of derived types cause ICE on assignment
Tobias Burnus
burnus@net-b.de
Sun Nov 23 19:24:00 GMT 2008
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
regressions
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.
http://people.redhat.com/jkratoch/vla/)
>> > 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.
Tobias
More information about the Fortran
mailing list