topic Linux 64 bit. I'll first try in Intel® oneAPI Math Kernel Library

Broken dgeqp3 in Version 11.2 (Update 3) (Linux)

Samuel_H_1 — Wed, 01 Jul 2015 07:47:33 GMT

Hi all,

This was working in December 2014 when I last ran my code against MKL, but after upgrading to 11.2u3 I'm getting a response of -9 from the info parameter when calling dgeqp3... which is *really* weird because that indicates that the info parameter itself is wrong (being parameter 9).

My code works against reference LAPACK[1] and ATLAS / OpenBLAS so I'm inclined to suggest that a regression has appeared.

I could potentially create a minimal C test case for this, but it will take me some time. It would be good if Intel could check what has changed in this function. If I'm right, I believe it to be serious enough to warrant a patch fix.

[1] https://github.com/fommil/netlib-java/blob/master/netlib/LAPACK/dgeqp3.f

I'm downgrading to 11.2u2 to see if the problem goes away.

Best regards,

Sam

Sam, this is an unknown issue

Gennady_F_Intel — Wed, 01 Jul 2015 15:04:22 GMT

Sam, this is an unknown issue with dgeqp3. we will check the problem on our side. Are there any specific environment where you see the problem?

is that 32 or 64 bit? Lin or win or OS X? lp64 or Ilp64 modes?

--Gennady

I ran the test program at

mecej4 — Wed, 01 Jul 2015 16:43:00 GMT

I ran the test program at http://people.sc.fsu.edu/~jburkardt/f_src/geqp3/geqp3_prb.f90 using MKL 11.2.3 (Product Build 20150413 for 32-bit) with IFort 15.0.4.221 on Windows. No errors. Same for 64-bit version, same releases.

Linux 64 bit. I'll first try

Samuel_H_1 — Wed, 01 Jul 2015 17:14:14 GMT

Linux 64 bit. I'll first try to find which version works (reverting MKL version is a time sink) and let you know.

If that doesn't help, then I can put together a minimal C failure case if you're not able to reproduce.

Quote:Samuel H. wrote:

mecej4 — Thu, 02 Jul 2015 02:23:45 GMT

Samuel H. wrote:

reverting MKL version is a time sink

You can have more than one version of MKL installed, and select any one of them for a session in a shell command window.

more reliable way to know

Gennady_F_Intel — Thu, 02 Jul 2015 03:47:34 GMT

more reliable way to know which version you are using is to call mkl_get_version(*) function

These are my parameters, and

Samuel_H_1 — Sat, 04 Jul 2015 16:19:13 GMT

These are some test parameters, and the response

1 = 5
2 = 5
3 = [1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0]
4 = 5
5 = [0, 0, 0, 0, 0]
6 = [0.0, 0.0, 0.0, 0.0, 0.0]
7 = [0.0, 0.0, 0.0, 0.0, 0.0]
8 = 5
9 = 0

Intel MKL ERROR: Parameter 8 was incorrect on entry to DGEQP3.
INFO = -9

Two things to note here:

1. these exact parameters work OK when passed in to any other impl I have (netlib, ATLAS, OpenBLAS, including older MKL)

2. the MKL error is on stderr, but the response is -9 which itself doesn't agree with the error message (sounds like you're using C-based 0-indexing in your logs)... so it's ambiguous which parameter it claims is incorrect... and in either case BOTH are correct.

Can anyone reproduce this?

(aaargh.... this text input box is absolutely horrible to work with, excuse the formatting)

Ah! I may have found a bug in

Samuel_H_1 — Sat, 04 Jul 2015 16:30:26 GMT

Ah! I may have found a bug in my own code here. The WORK dimension looks like it might be too small.

BUT the return type is also wrong because it should have been -8, not -9.

I'm putting together a runnable C example to demonstrate.

Yup, my bad. Our framework is

Samuel_H_1 — Sat, 04 Jul 2015 16:46:09 GMT

Yup, my bad. Our framework is passing a work array that is too small and the other impls are allowing it!

So, from bug report, I backtrack and say "well done MKL for adding this constraint check, more of this please!" :-)