Does -fno-built-function work with g++ compiler optimization Ofast?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-08-19 12:15 AM
Hi,
My program works with gcc compiler optimization Ofast and g++ compiler optimization Og without any problem in STM32CubeIDE. I also use -fno-builtin-memcpy and -fno-builtin-memset. However, when I change g++ compiler optimization to Ofast, my code doesn't work. So, I can't be sure that -fno-builtin can work with Ofast.
Solved! Go to Solution.
- Labels:
-
STM32CubeIDE
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-08-19 01:35 AM
> 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-08-19 01:10 AM
> my code doesn't work
Then debug it.
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-08-19 01:25 AM
But STM32CubeIDE User guide says;
Can I trust the debugging process when it is Ofast?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2022-08-19 01:35 AM
> 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