Thomas Koenig wrote:
There are still 227 test-suite failures ("FAIL" lines) affecting 27
test-suite files. That's slightly down from the 269 lines the branch
currently has. (Some issues can be fixed by modifying the tree dump
patterns, but most seem to be "real" problems.)
Build and regtested on x86-64-linux.
OK for the branch?
The library parts look OK to me.
I have now commit it (Rev. 185199) - thanks for looking at the library part.
There is just one point of efficiency.
+#define GFC_DESCRIPTOR_STRIDE(desc,i) \
+ (GFC_DESCRIPTOR_SM(desc,i) / GFC_DESCRIPTOR_SIZE(desc))
In most generated files, GFC_DESCRIPTOR_SIZE is a constant known
at compile-time (and usually a power of two), which means that the
division can be done in a simple shift. If we get the size from the
descriptor, we actually have to divide, which is expensive.
I think one should also go through all the files and check whether one
can replace _STRIDE by _SM. In some cases, the code actually does this:
It calls _STRIDE and later multiplies by the byte size. I tried to avoid
_STRIDE at some places, but I only looked at it in the context of
setting the descriptor. Similarly, but less critical: One should check
whether EXTENT can replace UBOUND.
Side note: c_f_pointer0 (which is called for array with shape) is
currently broken as "dtype" is not set before the call - and thus the
size is not known, which is required for setting the "sm". I think the
best would be to replace it by inline code. (That's the reason behind 5
of the 24 failing test-case files.)
I would commit the patch now, adding
TODO:
- Fixing the regressions.
- Cleanup of the library and the front end
- Switching also from ubound -> extent for nondescriptor arrays?
- Properly implement subpointers
- Avoid division for GFC_DESCRIPTOR_STRIDE where possible.
Well, that's what I meant by cleanup: Trying to update the usage such
that one avoids ubound/stride when extent/sm are required - and doing
other optimizations like that one. Maybe one can also get rid of some of
the macros if they are unused.
In any case, I would be happy if you could have a look.
I think the real fun will start when we have to implement the other
parts (esp. lower_bound semantic, elem_len and in particular the type
system of TS29113).
Tobias
