> Can I trust the debugging process when it is Ofast?
"Debugging process" is what *you* do. Can you trust *yourself*?
Debugging with -Ofast is harder (because the code is optimized and there's no longer a straighforward mapping from binary back to source, i.e. you cannot tell easily which binary instruction came from which line, source lines are omitted if redundant, execution is not linear from source line to source line, variables are removed if redundant or their interpretation is modified for easier/faster execution, etc.), but that does not mean you cannot debug.
Debugging is not just using breakpoints and single-stepping and looking at variables content - it involves a whole spectrum of tools and methods, whatever which helps you to reveal the cause of problem - which in the vast majority of cases is error in software you've written.
If you replaced the builtin memcpy() and memset() with your own implementation of these functions, and the application "stopped working", then it's very likely that those your implementations are faulty so that may be a point to start. Or, you can attack it from the "stopped working" side - observe, what are the differences to the expected behaviour and find the reason for those differences.
JW
