Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Erik Schnetter 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Erik Schnetter): The problem is caused by bounds checking, in particular the `-fcheck=bounds` option that is used in debug mode. See <[https://godbolt.org/z/zhGv3bjj6](https://godbolt.org/z/zhGv3bjj6)> for a shortened example. The error message and the comparison \(line 8 \) are clearly visible. I assume what happens is that gfortran stores the actual string length in memory, presumably just before the actual string. With bounds checking enabled, the string length is checked. Cactus never sets up the string length since it just reinterprets pointers, assuming that gfortran’s string layout mimics that of C. You could define a new type \(“struct”\) instead of using `character*8`: ```fortran subroutine sub(beta) implicit none type empty end type type(empty) beta end subroutine sub ``` However, this wouldn’t allow the `kind` trick to make the function argument appear used. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Roland Haas 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Roland Haas): The error message mentions a line number \(13\) in `Cactus/arrangements/EinsteinBase/TmunuBase/src/SetStressEnergyState.F90` which is the line: ```fortran subroutine TmunuBase_SetStressEnergyState (CCTK_ARGUMENTS) ``` The error message also gives the dummy argument in question and the found and expected lengths \(0 and 8 respectively\): `'dtbetax_p' (0/8)` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Roland Haas 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Roland Haas): It apparently happened in a simulation of Kiki’s \(Kyriaki Dionysopoulou\). Apparently this happened \(the error messages in the ticket description\) in a regular run and “with different parameter files” and “completely different setups” \(quoting Kiki\). I have no idea why this never showed up before in the time since it has been introduced. Not sure if this matters but apparently this happened on \(at least\) an older, Intel macOS laptop using: CPP = cpp-11 FPP = cpp-11 CC = gcc-11 CXX = g\+\+-11 F90 = gfortran-11 GNU Fortran \(Homebrew GCC 11.2.0\) 11.2.0 Copyright \(C\) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Erik Schnetter 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Erik Schnetter): Which line triggers the original error about the string length? Is it the call to the `kind` function, or is it the call to that routine? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Roland Haas 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Roland Haas): Ah, one exception: we do worry about assignment without parenthesis in the case of grid scalars eg `ADMBase::shift_state` would be accessed like this `if(shift_state .ne. 0) then STOP endif`. Though I am not sure if either `charater*8` or `logical*8` would prevent this \(I suspect not\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Roland Haas 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Roland Haas): Changing from `charater*8` to `logical*8` may not be not be enough to avoid assignment. The intel compiler \(ifort \(IFORT\) 18.0.3 20180410\) compiles this without warning: ```fortran program foo implicit none logical*8 :: bar integer*4 :: baz bar = baz end program ``` On the other hand we are not worried about assignment to the pointer itself. We want to fails is things like: `bar(1,2,3)` for reading and writing and passing `bar` to a subroutine \(which we likely cannot prevent no matter what\). So it should be enough for our purposes. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Steven R. Brandt 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Steven R. Brandt): That’s a trivial enough change to make -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Erik Schnetter 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Erik Schnetter): Clever! Character types are a bit magical in Fortran; they don’t really behave like strings in C. You could use `logical*8` instead; assignments between `integer`/\`real\` and `logical` are also disallowed in Fortran. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Roland Haas 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Roland Haas): We are using `characTer*8, intent(IN) :: dtbetax_p` for grid functions that are neither read nor written by a scheduled function that is that should not even be accessible. Since there is only a single C to Fortran wrapper per thorn, they are still being passed to the Fortran subroutine but we want to make sure that the compiler aborts with an error if the code actually tries to access it. Declaring it as a nonsensical type achieves that since the compiler will not let you assign a real or integer number to a `charcater*8`. We can only use `character*(*)` if that does not add an extra integer “length of string” to the end of the argument list. We may however have to do something like: ``` CCTK_REAL :: dtbetax_p integer, parameter :: cctki_use_dtbetax_p = kind(dtbetax_p) #define dtbetax_p dtbetax_p_IS_NOT_ACCESSIBLE ``` ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Erik Schnetter 20 Oct '21

20 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Erik Schnetter): A declaration `character*8` as input argument is really strange. one would only use that if one knows that the length is 8, similar to passing a character array in C \(instead of a character pointer\). Usually one would write `character*(*)`, and the compiler then passes the actual string length as additional \(hidden\) argument, and uses that length in the callee. In this case I rather think that the Fortran code is a mistranslation from C, and that the code generating the `_CHECKED` macro is wrong. `dtbetax_p` should be declared as `CCTK_REAL dtbetax_p(ash0, ash1, ash2)` instead. None of the Cactus grid function or parameter passing arguments or declaration use Fortran `character` variables. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac