GCC 8 was just released. The release notes contain this in their fine print:
"Character variables longer than HUGE(0) elements are now possible on 64-bit targets. Note that this changes the procedure call ABI for all procedures with character arguments on 64-bit targets, as the type of the hidden character length argument has changed. The hidden character length argument is now of type INTEGER(C_SIZE_T)."
In other words, strings can now be longer than 2e9 characters. This is a good change. To make this possible, the length of strings is now passed as ptrdiff_t instead of as int, and consequently, the C/Fortran interoperability mechanism in Cactus may need to be updated. Without this, there might be a segfault e.g. when calling CCTK_INFO from Fortran. (It might also be that things just work most of the time, although this would be an unreliable coincidence.)
The respective include file that will need to be modified is "cctk_FortranString.h" in the flesh.
-erik
Hello all,
thank you for noticing this!
In other words, strings can now be longer than 2e9 characters. This is a good change. To make this possible, the length of strings is now passed as ptrdiff_t instead of as int, and consequently, the C/Fortran interoperability mechanism in Cactus may need to be updated. Without this, there might be a segfault e.g. when calling CCTK_INFO from Fortran. (It might also be that things just work most of the time, although this would be an unreliable coincidence.)
I expect that they (unfortunately) probably work most of the time since on a little endian machine (ie a Intel sytem) both a ptrdiff_t and an int will have the same first 4 bytes on the stack (and likely the next four bytes are zero given that zero is the most common value for any byte) and the string length is the last argument on the stack so its incorrect size is not visible due to eg other arguments having the wrong location.
Something similar to this happened before when we forgot to properly declare strdup() in code which led to it being implicitly declared to return an int which is then cast to char* which actually often worked (namely whenever the returned address what less than 2GB).
So we need to carefully check the Cactus code to see what it assumes about the string passing convention.
Yours, Roland
I pushed an untested patch to the eschnett/funhpc branch of the flesh.
-erik
On Wed, May 2, 2018 at 12:45 PM, Roland Haas rhaas@illinois.edu wrote:
Hello all,
thank you for noticing this!
In other words, strings can now be longer than 2e9 characters. This is a good change. To make this possible, the length of strings is now passed as ptrdiff_t instead of as int, and consequently, the C/Fortran interoperability mechanism in Cactus may need to be updated. Without this, there might be a segfault e.g. when calling CCTK_INFO from Fortran. (It might also be that things just work most of the time, although this would be an unreliable coincidence.)
I expect that they (unfortunately) probably work most of the time since on a little endian machine (ie a Intel sytem) both a ptrdiff_t and an int will have the same first 4 bytes on the stack (and likely the next four bytes are zero given that zero is the most common value for any byte) and the string length is the last argument on the stack so its incorrect size is not visible due to eg other arguments having the wrong location.
Something similar to this happened before when we forgot to properly declare strdup() in code which led to it being implicitly declared to return an int which is then cast to char* which actually often worked (namely whenever the returned address what less than 2GB).
So we need to carefully check the Cactus code to see what it assumes about the string passing convention.
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu .
Hello all,
I pushed an untested patch to the eschnett/funhpc branch of the flesh.
Homebrew now uses gcc-8 so we need to support gcc-8 before the next ET release (in August).
Can you turn your patch into a pull request, please?
Yours, Roland
Done; I added you as reviewer.
-erik
On Tue, Jun 26, 2018 at 3:08 PM, Roland Haas rhaas@illinois.edu wrote:
Hello all,
I pushed an untested patch to the eschnett/funhpc branch of the flesh.
Homebrew now uses gcc-8 so we need to support gcc-8 before the next ET release (in August).
Can you turn your patch into a pull request, please?
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
Hello Erik,
Done; I added you as reviewer.
Thank you. I will give it a look.
Yours, Roland
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Roland Haas