[arch-general] gcc: loop do not terminate

[LANGLOIS Olivier PIS -EXT]

>
> 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.


________________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.