------- Additional Comments From paulthomas2 at wanadoo dot fr 2005-07-09 13:00 ------- (In reply to comment #9) > Oh, and there's a third option which is probably awkward and very pessimizing: > instead of assuming REAL*4 sized objects in the array, the callee could read > the > size from the array desriptor, and skip fields accordingly. Of course, one > would then still have to point to &z[0].y instead of &z[0] in the second call.
Yes, the derived type could contain all sorts of bizarrenesses that would prevent an adjusted stride from working. I agree that the third option is awkward and pessimising; in addition, I just do not have the competence to implement it. This is why I went for the first option. I have modified the test to check to see if ->ts.derived is the same for the expression and the symbol, rather than the type. This allows derived_type = derived_type_function (args) to work. I was about to try the same for the rvalue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18022
