I'd gotten the norm and magnitude mixed up (partly because the document I
was following got the names mixed up), and then munged the formulas
together.
It seems (some versions of) windows vsnprintf don't count the terminating 0
when limiting the number of chars written to the buffer. Nor do they
guarantee the output string will be terminated.
Return statements never flow to the next block (or any other block, for
that matter), so drawing arrows leaving them not only messes up dot's
graphs, but is quite missleading.
When mering if/goto (ie, if skipping a goto), the rest of the dead code
remover is used to delete the goto. That part of the code unuses the goto's
label. The if was getting the goto's label without the lable's used count
being incremented (the usaged temporarily increases by one). I have no idea
why the problem showed up randomly, but this seems to fix it (it fixes /a/
bug, anyway).
The naive implementation of the if/goto merging was letting the old target
of the if get dropped because the block would lose its label and thus be
judged unreachable because the preceeding goto block was still in the list.
Instead, when the if/goto are "merged", mark the goto block as unreachable,
the following block as reachable, and break out of the analysis loop to
force the removal of the goto block. Since the dead block removal function
loops until no action is taken, all other dead blocks will be removed.
The output can be controlled via --block-dot (not yet documented). The
files a named <sourcefile>.<function>.<stage>.dot. Currently, stage will be
one of "initial" (after expression to statement conversion), "thread"
(after jump threading), "dead" (after dead block removal), "final" (final
state before actual code emission).
Labels can be shared between multiple flow-control instructions, so use the
label's used counter to determine when to remove the label. This was
causing problems with the jump threading.
The common cause seems to be casting a cast (very common, and I'm not sure
just realiasing the expression would be right). It does't cause any harm
(particularly, it doesn't trigger alias def chains), so I won't worry about
it.
The actual bug might still be elsewhere, but at least now I know the alias
chains were coming from accessing .return and .param_N, which are unions
(not directly usable by the progs engine). Emitting a reference to a union
(or struct) would create an alias def, but an alias expression was created
in the expression tree to simplify return/param access. The double layer
(sometimes 3 or 4) alias isn't really neaded, so rather than layering the
aliases, just re-alias the alaised def.
It is inteded for flagging buggy conditions in the compiler, particularly
after having fixed the original bug (in case something comes back from the
dead).
