)]}'
{
  "commit": "52db3adefd3e50d7f391a6dd77832cb9cfec71e1",
  "tree": "b2207b1e5d89ab872730d16add105d9065547a3d",
  "parents": [
    "391b113a2b78e9ec66acfae75c1ca3679d166fb6"
  ],
  "author": {
    "name": "Jakub Jelinek",
    "email": "jakub@redhat.com",
    "time": "Sat Aug 29 14:19:29 2026 +0200"
  },
  "committer": {
    "name": "Jakub Jelinek",
    "email": "jakub@gcc.gnu.org",
    "time": "Sat Aug 29 14:21:23 2026 +0200"
  },
  "message": "testsuite: Improve guality/arg1.f90 testcase\n\nThe guality/arg1.f90 testcase started failing on s390x and aarch64 in GCC\n16, on both arches it is\nFAIL: gfortran.dg/guality/arg1.f90   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  line 14 a(10) \u003d\u003d 10\nFAIL: gfortran.dg/guality/arg1.f90   -O3 -g  line 14 a(10) \u003d\u003d 10\nI\u0027ve only looked at s390x, but bet it is the same thing on aarch64.\n\nThis regressed with r16-372 which changed inlining heuristics.\nNot really sure whether we shouldn\u0027t treat Fortran MAIN__ similarly to\nC/C++ main, because it is again something only called once, but let\u0027s\nleave that aside for now.\n\nThe result of the inlining heuristic change is that the sub procedure is\nnow inlinined into MAIN__, even when it is called twice (but at -O3, so\nwe are asking to inline a lot of stuff).\n\nThe actual problem why the testcase fails is that the breakpoint is too early\nafter that change.\n\nIn *.optimized dump we still have\n  # DEBUG i \u003d\u003e 10\n  [arg1.f90:12:12] MEM \u003cvector(2) integer(kind\u003d4)\u003e [(integer(kind\u003d4) *)\u0026a] \u003d { 1, 2 };\n  [arg1.f90:12:12] MEM \u003cvector(2) integer(kind\u003d4)\u003e [(integer(kind\u003d4) *)\u0026a + 8B] \u003d { 3, 4 };\n  [arg1.f90:12:12] MEM \u003cvector(2) integer(kind\u003d4)\u003e [(integer(kind\u003d4) *)\u0026a + 16B] \u003d { 5, 6 };\n  [arg1.f90:12:12] MEM \u003cvector(2) integer(kind\u003d4)\u003e [(integer(kind\u003d4) *)\u0026a + 24B] \u003d { 7, 8 };\n  [arg1.f90:12:12] MEM \u003cvector(2) integer(kind\u003d4)\u003e [(integer(kind\u003d4) *)\u0026a + 32B] \u003d { 9, 10 };\n  # DEBUG i \u003d\u003e 11\n  [arg1.f90:14:59] [arg1.f90:14:59] [arg1.f90:14:59] dt_parm.2.common.filename \u003d [arg1.f90:14:59] \u0026[arg1.f90:14:59] \"arg1.f90\"[1]{lb: 1 sz: 1};\n...\n\nso the first statement with line 14 is after all the elements of the array are\nstored into the array.\n\nBut later on sched1 moves some instructions from the write (,) a statement\nwhich don’t depend on the stores to the a array before those stores and\nbecause breakpoint on line 14 chooses the first insn on that line at least\nin this case (I think partially  Alex Oliva’s DWARF extensions were supposed\nto change it in some cases, but clearly not in this one), when we ask\nabout a(10), we see uninitialized memory  and so print whatever happens\nto be there (in my case 0).\n\nBecause a is an in memory array, we really don’t do var-tracking for individual\nelements of the array, so I think it is pretty much normal thing in optimized\ncode that if a breakpoint happens earlier than all stores from earlier\nstatements finished we can see in the debugger something inaccurate.  The user\ncan just stepi or step further even in this case and eventually a(10) will\nhave the expected value.\n\nThe testcase has been added for PR41558, where we emitted some wrong DWARF,\nit doesn\u0027t care that much where exactly we query the a(10) value as long as\nit is after all the stores into the array have been done.\nIn various gcc.dg/guality tests we put a breakpoint on volatile variable\nincrement which tends to be simple instruction or 3 on most arches and\nusually isn\u0027t hoisted earlier too much.\n\nThe following patch does this for this testcase too.\nI’ve verified the test built with r0-96138 still fails on x86_64 and with\nr0-96139 succeeds, so it is still testing what the test is supposed to\ntest.  And on s390x with this change it works even at -O3.\n\n2026-08-29  Jakub Jelinek  \u003cjakub@redhat.com\u003e\n\n\t* gfortran.dg/guality/arg1.f90: Put a breakpoint on volatile\n\tvariable increment instead of on the write statement.\n\nReviewed-by: Richard Biener \u003crguenth@suse.de\u003e\n(cherry picked from commit d048c1bb016c3c7b911086ce2ca90f3dc9b24947)\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "775b7bb304f1a473e34b450ddb0ff632fdb901d6",
      "old_mode": 33188,
      "old_path": "gcc/testsuite/gfortran.dg/guality/arg1.f90",
      "new_id": "4e9ab8880d5a389cb41534c5d38990d844dbea7c",
      "new_mode": 33188,
      "new_path": "gcc/testsuite/gfortran.dg/guality/arg1.f90"
    }
  ]
}