3.2.0

[Michael Goffioul]

Yes, it fixes the problem. Note that the following files are affected
by the same problem:

CmplxQR.cc
dbleQR.cc
fCmplxQR.cc
floatQR.cc

Michael.


On Wed, May 20, 2009 at 7:23 PM, John W. Eaton <jwe at octave.org> wrote:
> As I understand it, the problem is that the F77_XFCN macro uses
> setjmp inside a for loop which uses I again after the call to setjmp.
> So if I is placed in a register, it might be invalid if the function
> called by F77_XFCN ends up doing a longjmp.  Declaring I as volatile
> prevents GCC from placing it in a register, so the value is still
> valid after a longjmp.
>
> Does the following change avoid the problem you are seeing?  If so, I
> don't have a problem with making changes like this as needed.
>
> jwe
>
>
> diff --git a/liboctave/CmplxQR.cc b/liboctave/CmplxQR.cc
> --- a/liboctave/CmplxQR.cc
> +++ b/liboctave/CmplxQR.cc
> @@ -323,10 +323,11 @@
>       OCTAVE_LOCAL_BUFFER (double, rw, kmax);
>       for (volatile octave_idx_type i = 0; i < js.length (); i++)
>         {
> +         octave_idx_type ii = i;
>           ComplexColumnVector utmp = u.column (jsi(i));
> -          F77_XFCN (zqrinc, ZQRINC, (m, n + i, std::min (kmax, k + i),
> +          F77_XFCN (zqrinc, ZQRINC, (m, n + ii, std::min (kmax, k + ii),
>                                      q.fortran_vec (), q.rows (),
> -                                     r.fortran_vec (), r.rows (), js(i) + 1,
> +                                     r.fortran_vec (), r.rows (), js(ii) + 1,
>                                      utmp.data (), rw));
>         }
>     }
>
>