This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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] PR29422 and PR29428 - allocatable component wrinkles


François-Xavier Coudert wrote:
About that: I've thought again, and I think the best we can do is to
actually add the extra code in the {L,U}BOUND intrinsic. gfortran uses
0-based temporaries and incorrect bounds for many array functions
return values, but it doesn't matter at all. It's all internal code,
the only place where it shows up is when you call {L,U}BOUND, because
it gets the value directly from the descriptor.

I'm now working on a very different solution to PR29391, where LBOUND
actually checks whether its argument is "a whole array or array
structure component", whether it is "an assumed-size array of rank
DIM, or has extent zero in dimension DIM" and fetch the descriptor
bounds only in this case (and in this case, I believe that they
descriptor bound values are always "right"); in other cases, it
returns 1 (or, for UBOUND, returns the number of elements in this
dimension).

What do you think about that?

Note that, when we do implement array assignments with allocation, this issue will likely turn up again. This can be avoided by directly using the LBOUND code in that case, though -- which seems appropriate, since the Fortran Standard uses the LBOUND intrinsic to define how those assignments work!


- Brooks


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