[Csdp] Using cblas and clapack with CSDP

[Brian Borchers]

I've retested example.c on my 64 bit system, and it runs without
errors and solves the SDP in 11 iterations.

It definitely appears to me that you have a situation in which
allocated memory blocks are being overwritten, making the code
unreliable.  I'm not sure of the details of what's going on here, but
I do have some background information that may be useful.

In moving to 64 bit systems, implementors of the C programming
language have had to make decisions about how C's short, int, long
int, and long long int should be implemented in a 64 bit system.
Historically, there was a similar problem with the transition from 16
bit to 32 bit systems, but that transition was so long ago that most
of the kids writing code today were in day care or not even born when
it happened...

In the 32 bit era, the programming model was universally "ILP32"  This
means that "int", "long int" and pointers were all 32 bits long.  Many
programmers foolishly assumed that int's and pointers would always be
of the same size and that pointers could be stored in the same space
as int's.  This is very bad.

In the 64 bit Linux world (and among nearly all other varieties of 64
bit unix with the notable exception of the old DEC Alpha systems), the
programming model is "I32LP64"  That is, "int" is a 32 bit integer,
"long int" is a 64 bit integer, and pointers are 64 bits.  Converting
an ILP32 code to I32LP64 requires finding and fixing every place where
a programmer assumed that size(int)=size(int *).

In the 64 bit Windows world, microsoft make the decision (for reasons
that I don't understand at all) to use IL32P64.  You can get a 64 bit
integer in this programming model by using "long long int"

CSDP is written for the I32LP64 model.  I've never tested it in the
IL32P64 model.  I expect that the code would break in at least some
calculations involving very large SDP's, since CSDP performs array
indexing calculations on arrays that could easily exceed 2^31-1
elements.  However, for smaller problems, I'm not aware of any
particular reason why CSDP would fail under the IL32P64 model.

My guess is that you've encountered a problem related to this.
However, I don't know exactly which programming model is implemented
by cygwin-64/gcc.  To determine this, could you run the simple
program:

#include <stdio.h>

int main()
{
  printf("sizeof(int)=%d\n",(int) sizeof(int));
  printf("sizeof(long int)=%d\n",(int) sizeof(long int));
  printf("sizeof(int *)=%d\n",(int) sizeof(int *));
}

On my I32LP64 Linux system, I get:
sizeof(int)=4
sizeof(long int)=8
sizeof(int *)=8


If CYGWIN-64 is using IL32P64, then size(long int) would be 4 rather
than 8.  This would explain why the f2c'd routines that used "long
int" rather than "int" would still work, since "long int" and "int"
are equivalent in the IL32P64 programming model.

-- 
Brian Borchers                          borchers at nmt.edu
Department of Mathematics      http://www.nmt.edu/~borchers/
New Mexico Tech                       Phone: (575) 322-2592
Socorro, NM 87801                   FAX: (575) 835-5366