Hi Mikael, > This pointer stuff is very difficult to swallow to me.
I totally understand. When doing the patch I had to restart twice, because I mixed up the development on the class arrays so completely, that I couldn't get it right again. > I understand that for classes, the CLASS_DATA (sym)->pointer is always > set, but almost everywhere the checks for pointerness are like > (sym->ts.type != BT_CLASS && sym->attr.pointer) > || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->attr.class_pointer) > and I don't see a convincing reason to have it different here. I see your point. Currently I am bootstraping and regtesting some patches for commit. While this is running, my machine is nearly unusable. I will look into this as soon, as my machine allows, but probably not before tomorrow. > At least gfc_is_nodesc_array should return 0 if sym->ts.type == BT_CLASS > which solves the problem there; for the other cases, I think that > class_pointer should be looked at. gfc_build_class_symbol clears the > sym->attr.pointer flag for class containers so it doesn't make sense to > test that flag. Completely right again. But I figured, that because sym->attr.pointer is never set for BT_CLASS there is no harm to check it and furthermore no need to guard it by checking whether ts.type == BT_CLASS. Fortunately not checking for class_pointer in _data's attr, didn't throw any regressions. Thinking about it now, I also think that it is probably safer to add the check for the class_pointer attribute were attr.pointer is checked on the sym, having the expression like you pointed out: > (sym->ts.type != BT_CLASS && sym->attr.pointer) > || (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->attr.class_pointer) Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de