[Bug c/54907] New: post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place

[Bug c/54907] New: post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place

[yangzhe1990 at gmail dot com]

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

             Bug #: 54907
           Summary: post increasing a value pointed by p in subexpression
                    of an expression modifying p saves the increased value
                    in the wrong place
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: yangzhe1990@gmail.com


#include <stdio.h>

int main() {
    char s[] = "axxxxx";
    char *p = s;

    printf("s = %s in the beginning.\n"
           "p is pointed at the %d-th char.\n", s, p - s);
    //p = p + (*p)++ * 3 + 2 - 'a' * 3; // (1)
    p += (*p)++ * 3 + 2 - 'a' * 3; // (2)
    printf("p is moved ahead by %d steps\n", p - s);
    printf("s = %s after the operation.\n", s);
    return 0;
}

The expected result is "bxxxxx". But the output is "axbxxx".

Maybe in the wrong code, when it saves the value, it lookups the address again
by *p, but p is modified in the expression.

As discussed in stackoverflow,
http://stackoverflow.com/questions/12823663/would-p-p-p-3-c-cause-an-undefined-behavior?answertab=votes#tab-top
most people think it's a bug of gcc.

Bug found in gcc 4.4.6, 4.7.1, g++ 4.4.6. g++ 4.7.1 produces the correct
result.

[Bug c/54907] post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place

[graham.stott at btinternet dot com]

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

--- Comment #1 from graham.stott at btinternet dot com 2012-10-12 10:24:30 UTC ---
Not a bug p is modified twice without a seqence point the result is undefined



________________________________
From: yangzhe1990 at gmail dot com <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org 
Sent: Friday, 12 October 2012, 11:10
Subject: [Bug c/54907] New: post increasing a value pointed by p in
subexpression of an expression modifying p saves the increased value in the
wrong place


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

            Bug #: 54907
          Summary: post increasing a value pointed by p in subexpression
                    of an expression modifying p saves the increased value
                    in the wrong place
    Classification: Unclassified
          Product: gcc
          Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
        Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: yangzhe1990@gmail.com


#include <stdio.h>

int main() {
    char s[] = "axxxxx";
    char *p = s;

    printf("s = %s in the beginning.\n"
          "p is pointed at the %d-th char.\n", s, p - s);
    //p = p + (*p)++ * 3 + 2 - 'a' * 3; // (1)
    p += (*p)++ * 3 + 2 - 'a' * 3; // (2)
    printf("p is moved ahead by %d steps\n", p - s);
    printf("s = %s after the operation.\n", s);
    return 0;
}

The expected result is "bxxxxx". But the output is "axbxxx".

Maybe in the wrong code, when it saves the value, it lookups the address again
by *p, but p is modified in the expression.

As discussed in stackoverflow,
http://stackoverflow.com/questions/12823663/would-p-p-p-3-c-cause-an-undefined-behavior?answertab=votes#tab-top
most people think it's a bug of gcc.

Bug found in gcc 4.4.6, 4.7.1, g++ 4.4.6. g++ 4.7.1 produces the correct
result.

[Bug c/54907] post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place

[yangzhe1990 at gmail dot com]

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

--- Comment #2 from yangzhe1990 at gmail dot com 2012-10-12 11:20:39 UTC ---
No, p is not modified twice.

p is modified once,
*p is modified once.

(In reply to comment #1)
> Not a bug p is modified twice without a seqence point the result is undefined
> 
> 
> 
> ________________________________
> From: yangzhe1990 at gmail dot com <gcc-bugzilla@gcc.gnu.org>
> To: gcc-bugs@gcc.gnu.org 
> Sent: Friday, 12 October 2012, 11:10
> Subject: [Bug c/54907] New: post increasing a value pointed by p in
> subexpression of an expression modifying p saves the increased value in the
> wrong place
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54907
> 
>             Bug #: 54907
>           Summary: post increasing a value pointed by p in subexpression
>                     of an expression modifying p saves the increased value
>                     in the wrong place
>     Classification: Unclassified
>           Product: gcc
>           Version: 4.7.1
>             Status: UNCONFIRMED
>           Severity: normal
>           Priority: P3
>         Component: c
>         AssignedTo: unassigned@gcc.gnu.org
>         ReportedBy: yangzhe1990@gmail.com
> 
> 
> #include <stdio.h>
> 
> int main() {
>     char s[] = "axxxxx";
>     char *p = s;
> 
>     printf("s = %s in the beginning.\n"
>           "p is pointed at the %d-th char.\n", s, p - s);
>     //p = p + (*p)++ * 3 + 2 - 'a' * 3; // (1)
>     p += (*p)++ * 3 + 2 - 'a' * 3; // (2)
>     printf("p is moved ahead by %d steps\n", p - s);
>     printf("s = %s after the operation.\n", s);
>     return 0;
> }
> 
> The expected result is "bxxxxx". But the output is "axbxxx".
> 
> Maybe in the wrong code, when it saves the value, it lookups the address again
> by *p, but p is modified in the expression.
> 
> As discussed in stackoverflow,
> http://stackoverflow.com/questions/12823663/would-p-p-p-3-c-cause-an-undefined-behavior?answertab=votes#tab-top
> most people think it's a bug of gcc.
> 
> Bug found in gcc 4.4.6, 4.7.1, g++ 4.4.6. g++ 4.7.1 produces the correct
> result.

[Bug c/54907] post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-12 11:23:52 UTC ---
On the RHS of the assignment *p is modified, not p

The difference in behaviour between gcc and g++ is probably due to
http://gcc.gnu.org/viewcvs?view=revision&revision=176072

[Bug c/54907] post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-10-12 15:40:05 UTC ---
I believe this code is well-defined.

There are two objects modified, p and *p.  p is modified by the 
assignment, and C11 6.5.16#3 says "The side effect of updating the stored 
value of the left operand is sequenced after the value computations of the 
left and right operands.".  For postfix increment, which modifies *p, "The 
value computation of the result is sequenced before the side effect of 
updating the stored value of the operand.".  Each object is modified only 
once, so there is no issue of two side effects on the same object being 
unsequenced.  And the value computation of the RHS, using p, is sequenced 
before p is updated by the assignment; furthermore, 5.1.2.3#2 says "Value 
computation for an lvalue expression includes determining the identity of 
the designated object.".  So I don't think either case of undefinedness in 
6.5#2, "If a side effect on a scalar object is unsequenced relative to 
either a different side effect on the same scalar object or a value 
computation using the value of the same scalar object, the behavior is 
undefined.", applies here.

[Bug c/54907] post increasing a value pointed by p in subexpression of an expression modifying p saves the increased value in the wrong place

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54907

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
      Known to work|                            |4.8.1
     Ever confirmed|0                           |1
      Known to fail|                            |4.6.4, 4.7.4
   Last reconfirmed|                            |2021-08-12

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The C part of this bug was fixed with r0-120559.
I don't know what fixed the C++ side of things though because it was before
4.7.x.

A testcase for this should definitely be put in.