On Mon, May 13, 2013 at 4:59 PM, LANGLOIS Olivier PIS -EXT <olivier.pis.langlois@transport.alstom.com> wrote:
The only time the switch makes a difference is when the program is already incorrect. I really doubt Arch is going to enable a flag slowing down all programs to make invalid programs behave *differently* (not necessary as they were intended to behave, just *differently*).
GCC is correctly noticing a situation that would result in undefined behaviour, and optimizing based on the assumption that it never happens. The solution is to write valid code not relying on undefined behaviour - accessing beyond the end of an array is undefined behaviour regardless of whether there's more allocated memory.
C99 has this feature as a flexible-length array member using `foo array[];` and that might be valid C++11 but I'm not sure and I don't feel like digging through the standard. Using `foo array[0]` will also work because it's a GNU extension, but keep in mind that you've left the land of standard C++.
Compilers are going to get better and better at optimizing away code that's not needed if the program is assumed to be correct. I recommend using another language if you don't want to worry about incorrect code that seems to work now breaking from future optimizations.
I hear you. I, however, disagree when you qualify the old C trick pattern as incorrect. My A B toy structs are a simplification of what I have seen in the AMD ADL SDK and was causing the loop problem with:
http://code.google.com/p/overdrive5/
What is debatable, IMO, is how widespread the usage of this particular pattern is. Personally, I am not using it but I knew it for having seen it in the past a couple of times.
My expectations of compiler optimization is that they should be transparent and respect the intent of the program. This optimization switch must probably be doing a lot of good stuff but this particular manifestation is, IMO, a stunning reinterpretation of an explicit request to iterate n times.
According to the C and C++ standards, it's undefined behaviour to index past the end of an array with a given size. It's not debatable whether it's incorrect - the standards committee explicitly considered this case and finally standardized a way to do it without undefined behaviour in C99.