Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

static assert fires in exmemy.c on win32 build #405

Open
Keno opened this issue Sep 25, 2023 · 3 comments
Open

static assert fires in exmemy.c on win32 build #405

Keno opened this issue Sep 25, 2023 · 3 comments
Assignees
Labels

Comments

@Keno
Copy link

Keno commented Sep 25, 2023

I'm working on building Trilinos (including seacas) for distribution in the Julia language package ecosystem. Windows is one of our Tier 1 platforms, so I'm trying to build for windows as well (even though I don't expect may users).

I'm seeing the following assert fire in my 32-bit windows build:

CT_ASSERT(sizeof(FTNINT) == sizeof(void *));

Now, looking at

/* Default system */
#if Build64
#if defined(WIN32) || defined(__WIN32__) || defined(_WIN32) || defined(_MSC_VER) || \
defined(__MINGW32__) || defined(_WIN64) || defined(__MINGW64__)
#define FTNREAL double
#define FTNINT long long int
#else
#define FTNREAL double
#define FTNINT long int
#endif
#else
#define FTNREAL float
#define FTNINT int
#endif

I'm assuming that FTNINT stands for fortran int and I see that at

https://github.com/sandialabs/seacas/blob/1e5138cf4b6a2855e54ea69b172df5ae36013a2b/packages/seacas/cmake/FortranSettings.cmake#L3C1-L18

the fortran integer size is unconditionally set to 8 bytes, which matches the definition of FTNINT, but obviously does not match the assert. Interestingly, it does build on linux32, because long int is 32 bits there (though it then of course does not match the fortran int size).

So my question is, what's the expected behavior:

  1. Should FTNINT always match the fortran int size (if so, is there an issue on linux32)?
  2. If so, does that mean that a 32bit build of seacas is unsupported? or
  3. Is there some other adjustment I should be doing.
@gsjaardema
Copy link
Member

The 32-bit builds have definitely not been used lately and could probably be considered unsupported. The code still exists in various places, but I can't remember the last time I or someone did a 32-bit build especially with the fortran codes.

Depending on what you are trying to support, you might not need the fortran-based seacas applications. The exodus and IOSS libraries do not need fortran. There are a few seacas applications that are still commonly used that need fortran (explore, grepos are probably the two most used fortran seacas codes).

The whole fortran/C 32/64 bit integer strangeness started a few decades ago and we would definitely do something different if we had to start over today (and we have improved it somewhat...).

But, we do require that the size of the integers used by the fortran compiler are able to store a pointer since this is used in the dynamic memory system that we developed a long long time ago for use in fortran... I don't know enough about windows fortran to know how to force 8-byte integers in windows fortran, but the file you link to is how it is done on various compilers...

I can give more help if needed depending on your needs with this. Easiest may be to not build the fortran-dependent seacas codes which might give you the functionality you need.

@gsjaardema gsjaardema self-assigned this Sep 26, 2023
@Keno
Copy link
Author

Keno commented Sep 26, 2023

The 32-bit builds have definitely not been used lately and could probably be considered unsupported. The code still exists in various places, but I can't remember the last time I or someone did a 32-bit build especially with the fortran codes.

I probably don't have users for this, I just need to make choice one way or another whether I should try to fix something (letting anybody who might care try at their own risk) or just disable it entirely, so I figured I'd check in.

But, we do require that the size of the integers used by the fortran compiler are able to store a pointer since this is used in the dynamic memory system that we developed a long long time ago for use in fortran...

So is the only requirement then that sizeof(FTNINT) >= sizeof(void *)? Just to clarify, FTNINT is properly 8 byte on 32bit windows with the current code, which matches Fortran as defined. The only issue is that sizeof(void*) is 4 byte, so the assert fails (and as mentioned FTNINT is likely incorrect on 32-bit linux).

I don't know enough about windows fortran to know how to force 8-byte integers in windows fortran, but the file you link to is how it is done on various compilers...

Our toolchain is just gfortran there, so the existing setting is working (which is what's causing the assert to fail ;) ).

@gsjaardema
Copy link
Member

It might be OK to modify the test to sizeof(FTNINT) >= sizeof(void*). It's just been so long since I looked at the special cases in that code that I don't know for sure whether there are any assumptions for strict equality vs just being big enough.

I would think that if you make the change, it should show up immediately when running either explore or grepos whether anything is broken...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants