------- Comment #11 from jv244 at cam dot ac dot uk 2010-02-16 09:22 ------- (In reply to comment #10) > (In reply to comment #6) > > Joost, > > I held back from committing the patch this morning because I noticed that your > testcase below is also calling pack/unpack like it is going out of business. > > I have to confess that I looked into this because one of the maintainers > (Dominique, I think) asked me if I understood the fix to this segfault. My > off-the-cuff response was CLASSes but I see that this cannot entirely be the > case. In investigating, I found these extra temporaries and have eliminated > them. However, I did not have time to regtest and get the new patch to you.
Hi Paul not sure I understand your full reply. However, for the testcase below, I guess there have to be pack/unpacks, since newuob has an implicit interface and optstate%w(i:) is a slice from a 'pointer array', and thus packing is needed to guarantee things are contiguous. But I'm sure you know :-) Having said that, there is no pressure from my side to commit patches. Just commit whenever you think they are in good shape, ready, understood... Joost > > MODULE powell > > INTEGER, PARAMETER :: dp=8 > > TYPE opt_state_type > > REAL(dp), DIMENSION(:), POINTER :: w > > END TYPE opt_state_type > > CONTAINS > > SUBROUTINE newuoa (n,x,optstate) > > TYPE(opt_state_type) :: optstate > > CALL newuob (optstate%w(ixb:),optstate%w(ixo:),& > > optstate%w(ivl:),optstate%w(iw:),optstate) > > END SUBROUTINE newuoa > > END MODULE powell > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36932
