[arch-general] gcc: loop do not terminate

Daniel Micay danielmicay at gmail.com
Mon May 13 18:21:59 EDT 2013


On Mon, May 13, 2013 at 4:59 PM, LANGLOIS Olivier PIS -EXT
<olivier.pis.langlois at 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.


More information about the arch-general mailing list