This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, fortran] PR37735 - Allocatable components in vectors of derived types cause ICE on assignment
- From: Tobias Burnus <burnus at net-b dot de>
- To: Daniel Kraft <d at domob dot eu>
- Cc: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>, Fortran List <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 23 Nov 2008 20:23:24 +0100
- Subject: Re: [Patch, fortran] PR37735 - Allocatable components in vectors of derived types cause ICE on assignment
- References: <email@example.com> <firstname.lastname@example.org>
- Reply-to: "'fortran at gcc dot gnu dot org'" <fortran at gcc dot gnu dot org>
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
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.