0

I am using the Reduced Precision Emulator library to emulate reduced precision in some Fortran code. The library gives a new type that can replace real type variables with reduced-precision variables and overloads basic arithmetic operations so that the variable is truncated after each operation. The library uses elemental subroutines to achieve this.

I want to trigger an error within the library (during the truncation operation) when certain criteria are met but the elemental subroutines are restrictive. I used the code from the answer to this previous question to trigger an error from within an elemental subroutine in the reduced-precision emulator library. However, the error triggered doesn't produce any traceback. I've used the gfortran compiler and tried the -g and -ftraceback in the compilation of the main Fortran code and the library itself but I only get a traceback when the error is produced outside the elemental subroutines.

Does anyone know how I can trigger an error within an elemental subroutine and get a useful traceback?

The code I am editing is https://github.com/aopp-pred/rpe/blob/master/src/rp_emulator.F90, specifically the elemental function adjust_ieee_half.

Vladimir F Героям слава
  • 57,977
  • 4
  • 76
  • 119
LSaffin
  • 1
  • 1
  • 1
    Welcome, please take the [tour]. It would be good to illustrate the question with an actual code example and the program output. – Vladimir F Героям слава May 17 '19 at 13:33
  • As you're using gfortran, add `CALL ABORT`. This, on any reasonable OS, will drop a core file, and you can use gdb to debug the code. I do note that `adjust_ieee_half` is used once within the file and it is `PRIVATE`. gfortran might be in-lining the routine. You may be able play with options to prevent in-line. – evets May 17 '19 at 15:09
  • @evets unfortunately ABORT can't be called within pure/elemental functions. How would the in-lining cause issues here? If I could generate an error with backtrace from any of the elemental subroutines it would be useful. – LSaffin May 17 '19 at 15:42
  • @LSaffin, for debugging purposes and if `adjust_ieee_half` is not referenced with a vector argument, you can remove the `ELEMENTAL` prefix to get `CALL ABORT` to work. – Steve May 17 '19 at 18:48
  • @LSaffin, in-lining can allow the compiler to do more aggressive optimization to the point that the in-lined function/subroutine is no longer recognizable. I forgot that `ABORT` was not pure. It seems that your best option at this point is to simply run the code under gdb and set a breakpoint at line you are interested in. This may however be problematic as the file is first past through the pre-processor and I suspect that will screw up line number info. – evets May 18 '19 at 02:00
  • @evets, thanks for the explanation. Since I'm not interested in the line number in the emulator, just where it occurs in the code it is implemented in this isn't an issue at the moment but that's good to know. Thanks for suggesting gdb, in the future I hope I can generate the traceback automatically but that's worked for what I'm doing now. – LSaffin May 20 '19 at 10:01
  • @LSaffin please confirm the proposed solution from evets worked. And evets please consider turning it into a proper answer. – Rodrigo Rodrigues May 20 '19 at 16:48
  • @RodrigoRodrigues, that's not what I meant. It's a helpful comment but definitely not a solution to the problem. – LSaffin May 21 '19 at 17:55

0 Answers0