Strange (?) ReadGuard placement

[fingolfin]

I am seeing some compiler warnings for some code mangled by ward. Specifically, ward turns this code:

  else {
    ErrorQuit( "usage: DownEnv( [ <depth> ] )", 0L, 0L );
    return 0;
  }

into this:

  else {
    {
    ReadGuard(args);
#line 978 "../../src/gap.c"
    ErrorQuit( "usage: DownEnv( [ <depth> ] )", 0L, 0L );
    }
#line 979 "../../src/gap.c"
    return ReadGuard(args), 0;
  }
}

The warning I get is this:

../../src/gap.c:979:12: warning: incompatible integer to pointer conversion returning 'int' from a function with result type 'Obj' (aka 'unsigned long long **') [-Wint-conversion]
    return ReadGuard(args), 0;
           ^~~~~~~~~~~~~~~~~~

As it is, I am confused: Why does ward insert ReadGuard(args) here at all, and why twice?

Is this a bug (resp. a case of ward being too eager), or am I missing something here?

[fingolfin]

@rbehrends any idea about this?

[fingolfin]

@rbehrends ping?

[fingolfin]

Quoting @rbehrends from Slack:

This is extremely odd. I’m not sure why the C compiler emits a warning here. The insertion of the ReadGuard() is probably related to something that I’ve been looking into recently.
And which also leads to the creation of superfluous guards elsewhere.
The nodes in the program graph are traversed in the order they are created for purposes of autogenerating guards, but do not necessarily reflect the control flow in a function.