Re: Rethinking octave_idx_type

[Rik]

On 11/28/2016 05:28 AM, John W. Eaton wrote:
> On 11/28/2016 07:54 AM, John W. Eaton wrote:
>
>> The first step is to use F77_INT instead of octave_idx_type to declare
>> integer variables that are passed to Fortran functions.
>
> We can also get some help from GCC to identify where there are issues
> when working on this step.
>
> If we define F77_INT to be 32 bits wide and octave_idx_type to be 64 bits
> wide and compile with -Wconversion, we should see errors anywhere there
> are pointer mismatches and warnings about passing octave_idx_type where
> F77_INT is expected.  See the attached program, for example.  I know from
> experience that -Wconversion leads to a LOT of noise in the output from
> the compiler when building Octave, but the warnings from recent versions
> of GCC use the typedef names so it should be easy to filter the messages
> and find only the places where F77_INT is affected.

If the code patterns are "simple" enough I can help with a Perl script to
search/replace.

>
> We should already be using F77_INT for the function declarations of any
> Fortran code used by Octave so it should be fairly straightforward to
> find all the locations that are affected.

In liboctave, the shell command 'grep -rn '^\s*F77_INT ' * | wc -l' returns
16 so there aren't that many instances.

>
> Then we need a function to convert octave_idx_type to F77_INT and check
> for possible overflow.  For example, to safely extract the number of rows
> from a matrix that will be passed to a Fortran subroutine we would use
> something like this
>
>   // May error if A is too large for our Fortran libraries.
>   F77_INT nr = to_f77_int (A.rows ());
>
> instead of just
>
>   F77_INT nr = A.rows ();
>

In terms of performance, we currently have a static interface where
octave_idx_type and F77_INT are matched up during configure.  Now there
will be a runtime check every time a Fortran routine is called.  This will
be slower, but manageable as long as the work done in the Fortran routine
is large relative to the call overhead.

Is there anything that will need to change for people who are using the
mkoctfile interface to create their own links to Fortran code?  Will they
need to re-write their code to invoke to_f77_int?

--Rik




> jwe
>
>