------- Additional Comments From veksler at il dot ibm dot com 2005-06-27 22:00 ------- (In reply to comment #22) > (In reply to comment #21) > > 2. (OTOH) Undefind situations are unhelpful the the users, they complicate > > debugging, and make programming harder. Reducing rules that imply > > undefined behavior semantics is good for the users.
> No I disagree with that, most undefined behaviors are very easy to debug, > the most obvious one and most invoked undefined behavior in terms of bug > reports is violating C/C++ aliasing rules (see PR 21920 which has 69 > duplicates). What you disagree with? You're claiming that undefined behavior does not complicate debugging? Isn't it true that with undefined behavior you're most likely to bump into behavioral differences between -O2 and -O0? Isn't it true that debugging an -O2 code is more complicated than -O0 ? Q.E.D. Also, how did you come to the conclusion that "most undefined behaviors are very easy to debug"? You don't know how much time it took the user to reduce 100 KLOC to simple test cases of these 69 dups of PR 21920. Once the test case is reduced, it is pretty trival to understand it. > In fact if you look at GCC, it is the only compiler were people run into > violating C/C++ > aliasing rules beause we use them to check if two addresses can alias. > This is unlike almost all other > compilers which represent their aliasing info as base+address and they only > invoke the C/C++ aliasing > rules when they cannot figure out if they point to the same address. The first time I got into trouble with aliasing rules was with xlC, not with gcc. It was in template inline code (STL allocators). Trivial base+address would have detected that free_list_element* and T* alias (they were copies of one another!). Because I used a temporary copy of u.next_free_element, instead of accessing u.next_free_element directly, xlC would think that the pointers do not alias. Now since most normal people don't write STL allocators at their leisure, they have less chance to bump into such a complex scenario as I did. The aliasing rules were violated only due to inlining, a very difficult thing for a user to spot. I had to debug PPC assembly code to figure out what went wrong (remember that debugging with -O2 has a very limited utility). And yes, I was aware of the aliasing rules, just make a subtle mistake. Would I not have been aware of the aliasing rules, then it would take me 3 days instead of 1 to analyze it. I could I reduce my 100 KLOC (no valgrind for AIX to find this memory corruption) to 15 trival lines, which any competent C/C++ programmer would find to be invalid. Please, pretty please, take into account that the distance between the C++ text, and assembly (and probably GIMPLE) is significantly greater than that of C, due to generic programming. It is much harder to analyze the subtalties of undefined behavior in C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
