A good example on C and C++ code, is the UB that isn't there in first place, but gets triggered due to the way code is inlined, and suddenly the optimizer becomes aware of optimization opportunities that wouldn't be taken, if it wasn't for the code being inlined.
I'm not sure that I understand. A compiler inlining a function can't create undefined behaviour (UB) where there wasn't any before. Otherwise it would be breaking valid code.
Do you mean that after inlining the compiler has more visibility can can idenitfy UB that it was not sure was UB before?
An inliner should, by itself, never introduce a bug, except maybe inefficient code.
An inliner together with other optimizations can definitely lead to weird behaviour if you are not intimately familiar with the C spec.
Inlining can be a problem as it is the reason many other optimizations are being run. For example, I managed to recover "sensitive data" due to a DSR pass being run after inlining. The code worked fine at O1, but kept "sensitive data" ( not really, it was a programming course in HS where we broke eachothers programs) in memory at O2.
Edit: but yes, almost all of the time the problem is PEBKAC.
Yes, without inlining pass, there would be code in another function that wouldn't be visible, but after inlining the code structure changes, and a later optimizer pass sees e.g. a pointer check (which was inlined from another function), so now it can assume the pointer is never null and do its thing.
