My answer will be from the perspective of real world business and the challenges that every development team faces. What I see in this question and a lot of the answers is really about controlling defects.
Code can be bug-free. Take any of the "Hello World" code samples for any programming language, and run that on the platform it is intended and it will work consistently and produce the desired results. There ends any theory on the impossibility of code being bug-free.
The potential bugs come in as the logic becomes more complex. The simple Hello World example has no logic and does the same static thing each time. As soon as you add logic-driven dynamic behavior is what introduces the complexity which leads to the bugs. The logic itself can be flawed, or the data that is input to the logic can vary in a way the logic does not handle.
A modern application also depends on run-time libraries, CLR, middleware, database, etc. layers which while saving development time overall, are also layers where bugs within those layers can exist and go undetected through development & UAT testing and into production.
Lastly, the chain of apps/systems that the application consumes data which feed its logic are all sources of potential bugs either within their logic, or within the software stacks the logic rides on top of, or the upstream systems which it consumes data.
Developers are not in 100% control of every moving piece supporting the logic of their application. Actually, we are not in control of much. That is why unit testing is important, and configuration and change management are important processes which we must not ignore or be lazy/sloppy.
Also, documented agreements between your application which consumes data from a source beyond your control, which defines the specific format and specifications for the data transferred, as well as any limit or constraints which your system assumes the source system is responsible for ensuring output is within those bounds.
In the real world application of software engineering you won't be able to make it fly by explaining to the business why theoretically applications cannot be bug-free. Discussions of this nature between technology and the business will never happen except in the aftermath of a technological malfunction which impacted the business's ability to make money, prevent losing money, and/or keeping people alive. The answer to "how can this happen" cannot be "let me explain this theory so you understand."
In terms of massive computations that theoretically could take forever to perform the calculation and get a result, an application that cannot finish and return with a result -- that is a bug. If the nature of the computation is such that it is very time consuming and compute intensive, you take that request and provide feedback to the user how/when they can retrieve the result, and kick off the parallel threads to churn on it. If this needs to happen quicker than can be done on one server, and is business important enough, then you scale it out across as many systems as is needed. This is why cloud is very attractive, and the ability to spin up nodes to take on work and spin them down when done.
If the possibility exists to get a request that no amount of compute power can complete, it should not hang out there running to infinity with a business process waiting on the answer to what the business thinks is a finite problem.