)]}'
{
  "commit": "87abd9825d8e512dc89a4af8637ca52da42ebc68",
  "tree": "a7a34daf0a2eb9bd946782e04cc812b71a8bd421",
  "parents": [
    "adc29023a741fbeb23dc3e07a0328cca4e9061f1"
  ],
  "author": {
    "name": "Nils-Christian Kempke",
    "email": "nils-christian.kempke@intel.com",
    "time": "Mon Apr 11 14:06:56 2022 +0200"
  },
  "committer": {
    "name": "Nils-Christian Kempke",
    "email": "nils-christian.kempke@intel.com",
    "time": "Mon Apr 11 14:06:56 2022 +0200"
  },
  "message": "gdb/fortran: Change GDB print for fortran default types\n\nCurrently, when asking GDB to print the type of a Fortran default type\nsuch as INTEGER or REAL, GDB will return the default name of that type,\ne.g. \"integer\"/\"real\":\n\n   (gdb) ptype integer\n   type \u003d integer\n   (gdb) ptype real\n   type \u003d real\n\nFor LOGICAL and COMPLEX it would return the actual underlying types\n\n   (gdb) ptype logical\n   type \u003d logical*4\n   (gdb) ptype complex\n   type \u003d complex*4\n\nSimilarly, GDB would print the default integer type for the underlying\ndefault type:\n\n   (gdb) ptype integer*4\n   type \u003d integer\n   (gdb) ptype real*4\n   type \u003d real\n   (gdb) ptype logical\n   type \u003d logical*4\n   (gdb) ptype complex*4\n   type \u003d complex*4\n\nThis is inconsistent and a bit confusing.  Both options somehow indicate\nwhat the internal underlying type for the default type is - but I think\nthe logical/complex version is a bit clearer.\n\nConsider again:\n\n   (gdb) ptype integer\n   type \u003d integer\n\nThis indicates to a user that the type of \"integer\" is Fortran\u0027s default\ninteger type.  Without examining \"ptype integer*4\" I would expect, that\nany variable declared integer in the actual code would also fit into a\nGDB integer.  But, since we cannot adapt out internal types to the\ncompiler flags used at compile time of a debugged binary, this might be\nwrong.  Consider debugging Fortran code compiled with GNU and e.g. the\n\"-fdefault-integer-8\" flag.  In this case the gfortran default integer\nwould be integer*8 while GDB internally still would use a builtin_integer,\nso an integer of the size of an integer*4 type.  On the other hand having\nGDB print\n\n   (gdb) ptype integer\n   type \u003d integer*4\n\nmakes this clearer.  I would still be tempted to fit a variable declared\ninteger in the code into a GDB integer - but at least ptype would\ndirectly tell me what is going on.  Note, that when debugging a binary\ncompiled with \"-fdefault-integer-8\" a user will always see the actual\nunderlying type of any variable declared \"integer\" in the Fortran code.\nSo having the code\n\n   program test\n     integer :: a \u003d 5\n     print *, a ! breakpt\n   end program test\n\nwill, when breaking at breakpt print\n\n   (gdb) ptype var\n   type \u003d integer(kind\u003d4)\n\nor\n\n   (gdb) ptype var\n   type \u003d integer(kind\u003d8)\n\ndepending on the compiler flag.\n\nThis patch changes the outputs for the REAL and INTEGER default types to\nactually print the internally used type over the default type name.\n\nThe new behavior for the above examples is:\n\n   (gdb) ptype integer\n   type \u003d integer*4\n   (gdb) ptype integer*4\n   type \u003d integer*4\n\nExisting testcases have been adapted to reflect the new behavior.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "82252bfd5dc8a22a480a87e41672204b80d7c9b2",
      "old_mode": 33188,
      "old_path": "gdb/f-lang.c",
      "new_id": "94669c609e08b12e6ef33bf54f59bcfb361a82eb",
      "new_mode": 33188,
      "new_path": "gdb/f-lang.c"
    },
    {
      "type": "modify",
      "old_id": "60f7c8e25531f626d78e79630a1165d0b19c4b7b",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.fortran/complex.exp",
      "new_id": "f4a80fbf783c8f93f32144b8cd43f212b4ca7213",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.fortran/complex.exp"
    },
    {
      "type": "modify",
      "old_id": "5ab44b10a37ee25b6ba895a63b0384bf8ce78e94",
      "old_mode": 33188,
      "old_path": "gdb/testsuite/gdb.fortran/types.exp",
      "new_id": "594276f3a7b7febe6c7e0e9c9cac2aa5d02c0089",
      "new_mode": 33188,
      "new_path": "gdb/testsuite/gdb.fortran/types.exp"
    }
  ]
}