gfortran IRC meeting?

[Tobias Burnus]

Janne Blomqvist wrote:
> Hmm, I was thinking that the library should be the easy part

I also think that getting a working version should be relatively easy; 
to get a fast version, will be more effort. (Currently, several 
algorithms assume that one has ubound and strides in elements; thus, one 
might end up calculating:  "span = (stride_multiplier)/(element_size)" 
only to have a few lines later "span*element_size".)

> as there
> was a patch committed quite a while ago that hides direct access to
> the dimension triplets behind macros. Thus changing from (lbound,
> ubound, stride_in_elements) to (lbound, extent, stride_in_bytes)
> should be doable just by changing the macros? Or at least that was the
> grand idea, I suppose; as usual, it seems reality was a bit uglier?

Well, the reality is uglier as, e.g.,

#define GFC_DIMENSION_SET(dim,lb,ub,str) \
   do \
     { \
       (dim)._lbound = lb;                       \
       (dim)._ubound = ub;                       \
       (dim)._stride = str;                      \
     } while (0)

cannot simply translated into setting "_sm": One would need to calculate 
"str*elem_size" but the elem_size is not available to the macro. 
Additionally, I fear there are places where one directly sets, e.g., 
ubound without going through this macro - but I might be wrong, I have 
not audited fortran-dev's libgfortran. (My next project: Hacking 
fortran-dev's libgfortran such that _sm/_extend are properly set.)

However, I think the real effort is in trans*.c where one needs to make 
sure that _sm/_extend are correctly set and used - but also useless 
computations are avoided, which means some restructuring :-(

Tobias