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

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

[0xe2 dot 0x9a dot 0x9b at gmail dot com]

#include <stdio.h>
#include <assert.h>

struct AB {
        unsigned a:1;
        unsigned b:31;
};

int main(int argc, char **argv) {
        unsigned in;
        struct AB ab;
        unsigned b2;

        sscanf(argv[1], "%x", &in);
        ab = (struct AB){0,in};

        b2 = ab.b + ab.b;
        assert(!(b2 <= 0x7fffffff));

        return 0;
}

Architecture: i386
Command line: ./a.out 7fffffff
Succeeds when compiled with: gcc -O0 ...
Fails when compiled with: gcc -O2 ...
Expected behavior: the program should execute successfully

Possible explanation: In the expression (ab.b + ab.b), the bit-field "b" gets
converted into an int. The addition is therefore of type (int+int), with an
(int) as result. The (int) result is then converted into an (unsigned int) -
but this step is skipped when using -O2, which leads the compiler to the wrong
conclusion that (b2 <= 0x7fffffff) is always true.


-- 
           Summary: Optimizer ignores type in a conversion
           Product: gcc
           Version: 4.4.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: 0xe2 dot 0x9a dot 0x9b at gmail dot com


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2010-02-16 10:16 -------
0x7fffffff + 1 overflows.  Signed overflow invokes undefined behavior.
Use -fwrapv if you want wrapping signed overflow.


-- 

rguenth at gcc dot gnu dot org changed:

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


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

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

[0xe2 dot 0x9a dot 0x9b at gmail dot com]

------- Comment #2 from 0xe2 dot 0x9a dot 0x9b at gmail dot com  2010-02-16 10:59 -------
(In reply to comment #1)
> 0x7fffffff + 1 overflows.  Signed overflow invokes undefined behavior.

Like so what? Is this your way of saying "I am not going to fix it"? Do you
find it convenient to hide your laziness behind the words "undefined behavior".

If I were to modify the test case like this:

int i = ab.b;
b2 = i + i;

I would be ALSO triggering undefined behavior. But the modified test-case would
succeed at any optimization level.

I don't think you understand what I am demanding here: I demand the compiler to
have CONSISTENT BEHAVIOR in cases which are not defined by the standard. The
modified code does clearly the SAME thing as the code in the test-case, only
the intermediate conversion to the integer is now more explicit.


-- 

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

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

[0xe2 dot 0x9a dot 0x9b at gmail dot com]

------- Comment #3 from 0xe2 dot 0x9a dot 0x9b at gmail dot com  2010-02-16 11:23 -------
(In reply to comment #2)
> 
> If I were to modify the test case like this:
> 
> int i = ab.b;
> b2 = i + i;
> 
> I would be ALSO triggering undefined behavior. But the modified test-case would
> succeed at any optimization level.

Whoops. This obviously is one of my bad days: the modified test-case would fail
at -O2 as well. Anyway, the test-case was extracted from a much larger piece of
code which works OK if I compile it with -O2 but generates a segmentation fault
when compiled with -O3, because the optimization is deeper and allows the
compiler to evaluate the conditional expression at compile-time.

Let me return to the original issue: the inconsistency between the behavior at
-Oi vs -O(i+1). Are you going to fix it, or not?

> I don't think you understand what I am demanding here: I demand the compiler to
> have CONSISTENT BEHAVIOR in cases which are not defined by the standard. The
> modified code does clearly the SAME thing as the code in the test-case, only
> the intermediate conversion to the integer is now more explicit.


-- 


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

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

[jakub at gcc dot gnu dot org]

------- Comment #4 from jakub at gcc dot gnu dot org  2010-02-16 11:56 -------
There is nothing to fix.  Your program triggers undefined behavior.  It can do
anything, which can include something you'd expect, or something completely
different and it can depend on compiler options, position of stars, etc.

As Richard said, if you want signed overflow to be well defined, compile with
-fwrapv.  Or, avoid doing the addition in this case in a signed type when you
want it to wrap.  E.g. b2 = (unsigned) ab.b + ab.b; does the addition in
unsigned type where wrapping is well defined (and even no wrapping occurs for
0x7fffffffU + 0x7fffffffU).


-- 

jakub at gcc dot gnu dot org changed:

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


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

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

[0xe2 dot 0x9a dot 0x9b at gmail dot com]

------- Comment #5 from 0xe2 dot 0x9a dot 0x9b at gmail dot com  2010-02-16 17:37 -------
(In reply to comment #4)
> There is nothing to fix.  Your program triggers undefined behavior.  It can do
> anything, which can include something you'd expect, or something completely
> different and it can depend on compiler options, position of stars, etc.

I understand what you are saying, but I do not agree with that. I my opinion,
an *optimization* option should never result in any change of a program's
behavior for this particular kind of undefined behaviors. I mean, there are
basically two different kinds of undefined behaviors:

1. Where the compiler has to choose a *particular* implementation.

2. Where the compiler does not choose anything or cannot choose anything
particular. (For example, what happens if accessing deallocated memory.)

The conversion test-case is of the 1st kind. Not of the 2nd kind. GCC -O0
chooses to generate a particular sequence of instructions to implement the
undefined behavior. GCC -O2 does not respect the choice made at -O0 (or vice
versa).

So, my question is: If it is possible for the problematic code to be
implemented in all contexts by the same operation, and in this case it indeed
is possible, why is GCC using two different operations? How do you justify
that?


-- 

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

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

[pinskia at gmail dot com]

------- Comment #6 from pinskia at gmail dot com  2010-02-16 17:51 -------
Subject: Re:  Optimizer ignores type in a conversion



Sent from my iPhone

On Feb 16, 2010, at 9:37 AM, "0xe2 dot 0x9a dot 0x9b at gmail dot com"  
<gcc-bugzilla@gcc.gnu.org> wrote:

>
>
> ------- Comment #5 from 0xe2 dot 0x9a dot 0x9b at gmail dot com   
> 2010-02-16 17:37 -------
> (In reply to comment #4)
>> There is nothing to fix.  Your program triggers undefined  
>> behavior.  It can do
>> anything, which can include something you'd expect, or something  
>> completely
>> different and it can depend on compiler options, position of stars,  
>> etc.
>
> I understand what you are saying, but I do not agree with that. I my  
> opinion,
> an *optimization* option should never result in any change of a  
> program's
> behavior for this particular kind of undefined behaviors. I mean,  
> there are
> basically two different kinds of undefined behaviors:
>
> 1. Where the compiler has to choose a *particular* implementation.

Huh, this is the opposite effect of undefined behavior. In fact for  
signed interger overflow, gcc sometimes optimizes it as wrapping and  
others as clamping. In this case it is clamping. It is hard sometimes  
to optimize constiently undefined behavior because of inlining and  
other optimizations that can change the ir before the optimization of  
undefined behavior.

>
> 2. Where the compiler does not choose anything or cannot choose  
> anything
> particular. (For example, what happens if accessing deallocated  
> memory.)
>
> The conversion test-case is of the 1st kind. Not of the 2nd kind.  
> GCC -O0
> chooses to generate a particular sequence of instructions to  
> implement the
> undefined behavior. GCC -O2 does not respect the choice made at -O0  
> (or vice
> versa).
>
> So, my question is: If it is possible for the problematic code to be
> implemented in all contexts by the same operation, and in this case  
> it indeed
> is possible, why is GCC using two different operations? How do you  
> justify
> that?
>
>
> -- 
>
> 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
>


-- 


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

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

[Andrew Pinski]

Sent from my iPhone

On Feb 16, 2010, at 9:37 AM, "0xe2 dot 0x9a dot 0x9b at gmail dot com"  
<gcc-bugzilla@gcc.gnu.org> wrote:

>
>
> ------- Comment #5 from 0xe2 dot 0x9a dot 0x9b at gmail dot com   
> 2010-02-16 17:37 -------
> (In reply to comment #4)
>> There is nothing to fix.  Your program triggers undefined  
>> behavior.  It can do
>> anything, which can include something you'd expect, or something  
>> completely
>> different and it can depend on compiler options, position of stars,  
>> etc.
>
> I understand what you are saying, but I do not agree with that. I my  
> opinion,
> an *optimization* option should never result in any change of a  
> program's
> behavior for this particular kind of undefined behaviors. I mean,  
> there are
> basically two different kinds of undefined behaviors:
>
> 1. Where the compiler has to choose a *particular* implementation.

Huh, this is the opposite effect of undefined behavior. In fact for  
signed interger overflow, gcc sometimes optimizes it as wrapping and  
others as clamping. In this case it is clamping. It is hard sometimes  
to optimize constiently undefined behavior because of inlining and  
other optimizations that can change the ir before the optimization of  
undefined behavior.

>
> 2. Where the compiler does not choose anything or cannot choose  
> anything
> particular. (For example, what happens if accessing deallocated  
> memory.)
>
> The conversion test-case is of the 1st kind. Not of the 2nd kind.  
> GCC -O0
> chooses to generate a particular sequence of instructions to  
> implement the
> undefined behavior. GCC -O2 does not respect the choice made at -O0  
> (or vice
> versa).
>
> So, my question is: If it is possible for the problematic code to be
> implemented in all contexts by the same operation, and in this case  
> it indeed
> is possible, why is GCC using two different operations? How do you  
> justify
> that?
>
>
> -- 
>
> 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
>

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

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2010-02-16 18:26 -------
Where the compiler always chooses some particular implementation is
implementation defined behavior, not undefined behavior.  Undefined behavior is
always just that, undefined.


-- 

jakub at gcc dot gnu dot org changed:

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


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

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

[0xe2 dot 0x9a dot 0x9b at gmail dot com]

------- Comment #8 from 0xe2 dot 0x9a dot 0x9b at gmail dot com  2010-02-17 14:16 -------
(In reply to comment #7)
> Where the compiler always chooses some particular implementation is
> implementation defined behavior, not undefined behavior.  Undefined behavior is
> always just that, undefined.

In comment #4 you wrote:

"There is nothing to fix.  Your program triggers undefined behavior."

Why didn't you (as well as others here) write "triggers implementation defined
behavior"?

Doesn't that invalidate the first of your statements I cited here (namely:
"There is nothing to fix")?

ISO/IEC 9899:1999, section 6.3.1.3 states that the result is implementation
defined.


-- 

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

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

[paolo dot carlini at oracle dot com]

------- Comment #9 from paolo dot carlini at oracle dot com  2010-02-17 14:39 -------
.


-- 

paolo dot carlini at oracle dot com changed:

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


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

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

[jakub at gcc dot gnu dot org]

------- Comment #10 from jakub at gcc dot gnu dot org  2010-02-17 14:41 -------
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.


-- 


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

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

[0xe2 dot 0x9a dot 0x9b at gmail dot com]

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

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

[paolo dot carlini at oracle dot com]

------- Comment #12 from paolo dot carlini at oracle dot com  2010-02-17 17:58 -------
.


-- 

paolo dot carlini at oracle dot com changed:

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


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2010-02-17 18:12 -------
Use -fwrapv if you want signed integer overflow being defined the way you want
it being defined.  That is the whole point of that flag.  The reason why GCC
acts the way it acts by default is to allow more optimizations to happen.  As I
mentioned before it is hard to have it act consistent with other optimizations
happening around it unless the hardware implements signed integer overflow
trapping or clamping.  That is the main reason why signed integer overflow is
undefined because hardware could implement it differently.  Even K&R C had it
undefined.


-- 


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