In the summer of 1983 I was a summer student on an electronics project, tasked with making a number of transistor and diode measurements in the lab, and then based on those construct Gummel-Pool models of the various devices to deliver to the design engineers.
These models would be used in a variant of Spice (circuit emulation not spacecraft locations). Spice had first come out of UC Berkeley in 1973, and as public domain was taken up by various places to update and tweak, and those version then moved around and got further changed. The company I was working for had picked up their install from some other university. Spice was in Fortran, and we had compiled it for use on a Vax under VMS.
Well, I started putting together models, and then ran them in Spice simulations of the measurements I'd done in the lab. The models in Spice did not match the transistor curve traces off the oscilloscope. OK, checked and double checked my data interpretation to get the model parameters. That all seemed fine.
So, what was Spice doing with the model parameters? Hey, we've got source code so I can go look. Well, the source was pretty messy. Really messy. But I started seeing some weird things - things like a GOTO XXX, where XXX was a terminal page or two down the file. And there was no way to get into the code between the GOTO and the XXX label. So, a big chunk of skipped code, followed by a bunch of code that looked pretty similar.
Since it was pretty painful to trace the logic of the combined FORT4 and Fortran 77 dialects, I chose a simple first (well, now second or third) step - compile the code and have the compiler spit out a list of variables used.
Inspection of the variables revealed a number of near-alike variables. Often the difference was '1' vs 'l' or '0' vs 'O'. These were quite hard to see using the VT100 terminal fonts in use at our site, and would have been on various IBM terminals I had used at the time elsewhere.
Now that I had a list of funny variables I could search more easily. Well, all those weird skipped blocks contained one version or another of at least one near-alike variable name. But, the skipped block and the now-executed blocks of code were not precisely the same either.
My take was that various editors at various times had made typos and not recognized them. Then tried to get the code to work somehow. Once someone 'rewrote' a block and got something to kind of work, the next person would tweak something, but perhaps edited the wrong block and assumed it would be fine.
Anyway, I used the compiler dump of variables to go in an straighten out all those weird blocks and eliminate all the typos and recompile that code. And then, miracle of miracle, the Gummel-Poon models worked properly (sometimes to the disgust of the designers who had hoped the devices would behave somehow else).
Not sure that using compiler-provided data counts as 'static analysis tool'.