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

Reply via email to