[Bug c/108740] New: two identical functions but the code generated differs. Why?

[Bug c/108740] New: two identical functions but the code generated differs. Why?

[jankowski938 at gmail dot com]

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

            Bug ID: 108740
           Summary: two identical functions but the code generated
                    differs. Why?
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jankowski938 at gmail dot com
  Target Milestone: ---

I know it is UB but I just wonder why two identical functions generate
different code:

```
#define OPPOSITE(c) (*((typeof(x) *)&(x)))


int foo(volatile int x)
{
    OPPOSITE(x) = OPPOSITE(x) + OPPOSITE(x);
    return x;
}

int bar(volatile int x)
{
    OPPOSITE(x) = OPPOSITE(x) + OPPOSITE(x);
    return x;
}
```

x86-65 gcc 12.2 -Wall -Wextra -Os 
```
foo:
        mov     DWORD PTR [rsp-4], edi
        mov     eax, DWORD PTR [rsp-4]
        mov     edx, DWORD PTR [rsp-4]
        add     eax, edx
        mov     DWORD PTR [rsp-4], eax
        mov     eax, DWORD PTR [rsp-4]
        ret
bar:
        mov     DWORD PTR [rsp-4], edi
        mov     eax, DWORD PTR [rsp-4]
        add     eax, eax
        ret
```

ARM-eabi-none 11.2.1 -Wall -Wextra -O3 (same -|Os)
```
foo:
        sub     sp, sp, #8
        str     r0, [sp, #4]
        ldr     r3, [sp, #4]
        ldr     r2, [sp, #4]
        add     r3, r3, r2
        str     r3, [sp, #4]
        ldr     r0, [sp, #4]
        add     sp, sp, #8
        bx      lr
bar:
        sub     sp, sp, #8
        str     r0, [sp, #4]
        ldr     r0, [sp, #4]
        lsl     r0, r0, #1
        add     sp, sp, #8
        bx      lr
```

https://godbolt.org/z/7eMbPcdqs 


I know that is UB in C11 onwards but I would expect both to be exactly the
same.

[Bug c/108740] two identical functions but the code generated differs. Why?

[jankowski938 at gmail dot com]

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

--- Comment #1 from Piotr <jankowski938 at gmail dot com> ---
-fno-ipa-icf makes it identical.

[Bug ipa/108740] two identical functions but the code generated differs. Why?

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org
          Component|c                           |ipa

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, ICF + re-inlining makes it ignore some of the pointless volatile dance?

[Bug ipa/108740] two identical functions but the code generated differs. Why?

[jankowski938 at gmail dot com]

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

--- Comment #3 from Piotr <jankowski938 at gmail dot com> ---
(In reply to Richard Biener from comment #2)
> Hmm, ICF + re-inlining makes it ignore some of the pointless volatile dance?

why the code is different abstracting form the sense of the assignment?

[Bug ipa/108740] two identical functions but the code generated differs. Why?

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Piotr from comment #3)
> (In reply to Richard Biener from comment #2)
> > Hmm, ICF + re-inlining makes it ignore some of the pointless volatile dance?
> 
> why the code is different abstracting form the sense of the assignment?

It is the volatileness of the argument. which by the way for C++20 is
deprecated ...

[Bug ipa/108740] two identical functions but the code generated differs due to volatile argument

[jankowski938 at gmail dot com]

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

--- Comment #5 from Piotr <jankowski938 at gmail dot com> ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Piotr from comment #3)
> > (In reply to Richard Biener from comment #2)
> > > Hmm, ICF + re-inlining makes it ignore some of the pointless volatile dance?
> > 
> > why the code is different abstracting form the sense of the assignment?
> 
> It is the volatileness of the argument. which by the way for C++20 is
> deprecated ...

It does not answer my question. Identical functions - different generated code.
Both have volatile arguments.