First of all, most people consider the "technical debt" of an application to only encompass the quality of the code itself, not its associated tools.
The biggest risk of using a deprecated build environment is that the longer you use it, the higher the risk you won't be able to fulfill one of its system requirements. For example, if your compiler won't run on Windows 7, you're stuck running on XP. If you go long enough down the road, you may not be able to find new computer hardware that will run XP, so when your hardware dies, you're forced to upgrade your build environment as well, and the timing may be extremely inconvenient. Likewise if your application itself can't run in newer environments.
That being said, it might take a long time to get to that point. I once had to port a BASIC application that ran for 20+ years on its original hardware. The company was forced to update because they could no longer find a source of ribbons for the dot matrix printers that computer required. Until that point there was no reason to incur the expense of porting it. Don't assume that just because something is old it necessarily needs replacing.
As far as security vulnerabilities go, there is one known vulnerability for that compiler, and it's a fairly minor one. To even be exploitable would require very specific uses of the
sizeof operator, and some cracking effort targeted specifically to your application. To be worth exploiting, your application would have to either run in a privileged mode, like a server, or process untrusted remote data, like a web browser. The chances of this hurting you are extremely small. You're far more likely to introduce your own vulnerabilities, or link to vulnerable libraries.
In other words, eventually you will most likely have to update your build environment, and it's okay to plan for that contingency, but unless you're already having system requirements problems it's not an urgent issue.