[Bug tree-optimization/43089] Optimizer ignores type in a conversion

["0xe2 dot 0x9a dot 0x9b at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #11 from 0xe2 dot 0x9a dot 0x9b at gmail dot com  2010-02-17 17:52 -------
(In reply to comment #10)
> Please stop reopening.  6.3.1.3 is about casts between integer types.
> Signed integer overflow is even mentioned as an example of undefined behavior
> in 3.4.3.

Well, look, maybe you didn't notice what is this about so I should spell it out
for you in a more explicit way so that you can understand it more clearly:

1. The test-case which is an issue here is triggering undefined behavior. I
completely agree that it indeed does trigger it. I have no problem admitting
it.

2. On the grounds that it is undefined behavior, you are claiming that the
things which GCC currently does in case the undefined behavior gets triggered
are OK - the validity of which follows from the fact that since the compiler's
handling of an undefined state in a program is allowed to be arbitrary. Well,
guess what, I completely agree with this and I have no problem accepting the
validity of this reasoning.

3. Since the compiler's handling of an undefined state in a program is allowed
to be arbitrary, the sequence A of actions GCC is currently doing while
compiling the test-case is not the only valid one. There also exist other
perfectly valid sequences of actions GCC *could* be doing while compiling the
test-case. Even if those other sequences mean that the generated code has a
completely different semantics (when the program reaches the undefined state)
than the code generated if using A. (And yes, this even includes mixing in the
not-directly related section 6.3.1.3 into the sequence of actions. Even that is
perfectly valid, since anything is valid.)

4. You are saying that you are not going to change how the compiler deals with
the test-case. On the other hand, I am saying that the compiler should handle
the test-case in a different way. You cannot dismiss my suggestion, because it
is a valid proposal - and I cannot dismiss your will to maintain the status
quo, because it is a valid approach.

5. Who is going to win here? Obviously, the one who has more power and control.
In this case it is you and the other GCC folks, because you have more control
over how GCC gets developed, and because I am not willing to spend the time I
have on persuading you that GCC should be patched.

... so, now I am going to reopen this bug to piss you all off just because I
*subjectively* think that my proposal is better than the status quo. And you
have absolutely no way of persuading me that I am doing something wrong or
something against the C99 standard. So, there you have it: the beauty of
letting the notion of undefined behavior slip into the formalization of a
programming language.


-- 

0xe2 dot 0x9a dot 0x9b at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43089