convert test_IN_1 to F90, allow it to return non-zero return code on error

[edwardhartnett]

Part of #308.
Part of #314

[edwardhartnett]

What is the purpose of INTSIZE_8?

In the code we have:

#ifdef INTSIZE_8
        INTEGER*4       IREADSB, IUPBS01, IUPBS3, IBFMS
        INTEGER*4       MXBF, nbyt, ierr
#endif

If the code is compiled with INTSIZE_8 then IREADSB is defined as INTEGER*4.

So when compiled without INTSIZE_8 it will be the default int size, again INTEGER*4.

But when I did not do this, my test still works...

[jbathegit]

What is the purpose of INTSIZE_8?

In the code we have:

#ifdef INTSIZE_8
        INTEGER*4       IREADSB, IUPBS01, IUPBS3, IBFMS
        INTEGER*4       MXBF, nbyt, ierr
#endif

If the code is compiled with INTSIZE_8 then IREADSB is defined as INTEGER*4.

So when compiled without INTSIZE_8 it will be the default int size, again INTEGER*4.

But when I did not do this, my test still works...

As noted above, the INTSIZE_8 is just a preprocessor flag for when we're building with 8-byte integers, similar to the KIND_8 you're now using. The reason it's used here is because IREADSB, IUPBS01, IUPBS3, and IBFMS are all library functions which return an integer, and since the only library build is now _4, then it's always going to return a 4-byte integer, even when the application program is compiled as _8. I'm surprised to hear you didn't encounter any errors when you removed those explicit INTEGER*4 declarations, because I was definitely seeing them previously on some platforms when Jack and I were working on #78, and which is why I had to put those declarations in in the first place. I agree they're not needed when you're testing a _4 or _d build of the test code, but when you're building any application code as _8 then you're going to have a mismatch if the code is expecting an 8-byte integer to be returned and instead it only gets back a 4-byte integer.

Similarly, MXBF, nbyt, and ierr are all arguments to the C library function crbmg.c, and the prototype is explicitly defined with these as "int" arguments, which again equates to 4-byte integers since we're only doing 4-byte builds of the library anymore.

So bottom line, I think those explicit INTEGER*4 declarations need to be retained, and again I'm really surprised this didn't trip you up at all during any of your testing.

[edwardhartnett]

OK, I have fixed those types. Seems like they are always going to be integer 4, so we don't need the ifdef, we can just always define them as int*4.

[edwardhartnett]

OK, @jbathegit take another look and see if we can get this merged...

[jbathegit]

I'm looking at it right now - just give me a couple of minutes...

[jbathegit]

So I'm curious why the target_compile_definitions(${name}_${kind} PUBLIC -DKIND_${kind}) preprocessor def is no longer needed in test/CMakeLists.txt? How else would the #ifdef KIND_8 block get triggered in intest1.F90 when it's testing the _8 build of that code?

[edwardhartnett]

Your right, of course. I forgot that. Let me re-add it...

[jbathegit]

Thanks, but shouldn't that def come before (vs. after) the add_test directive? Or does it not matter?

Either way, I'm really stumped how the intest1_8 test wasn't failing before you added that line back in.

[edwardhartnett]

If we could get the memory errors in the library fixed, then presumably the address sanitizer would find a problem without the KIND_8 flag.

My idea is to convert all the tests, remove the complexity related to testing in the CMakeLists.txt file, and then, with a more simple test situation, return to the problem of the memory issues.

[jbathegit]

OK, fair enough. I can help some with this, and hopefully @jack-woollen can help us out too, especially with the memory issues noted in #244 and #319. But I also need to get started with #79.