[Bug c/114597] New: [GCC-14] Miscompilation of pointer assignment with inline assembly

[Bug c/114597] New: [GCC-14] Miscompilation of pointer assignment with inline assembly

[141242068 at smail dot nju.edu.cn]

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

            Bug ID: 114597
           Summary: [GCC-14] Miscompilation of pointer assignment with
                    inline assembly
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: 141242068 at smail dot nju.edu.cn
  Target Milestone: ---

Compiler Explorer: https://gcc.godbolt.org/z/Pn4EG3zzj

```
struct node { void *p; } n;
struct head { struct node *n; } h;

int main () {
  n.p = &h;
  asm("":"=m"(n.p):"r"(n.p));
  if (n.p != &h)
    __builtin_abort();
  return 0;
}
```

I sanitized this program with all sanitizers I know, they report nothing.
When compile this program with `gcc-14 -O2`, the compiled program aborts, while
`-O0` normally exits.

Any potential undefined behavior:
1. strict aliasing, I added option `-fno-strict-aliasing` to `-O2`, the abort
still exists.
2. If there is some other undefined behavior unknown to me cause this
compilation inconsistency, please let me know.

Regarding the inline assembly, it's important to note that even though `n.p` is
specified as an output operand with `=m`, this doesn't necessarily imply that
`n.p` will be altered. The inline assembly might simply reassign the original
value to `n.p`, leaving it effectively unchanged.

[Bug c/114597] [GCC-14] Miscompilation of pointer assignment with inline assembly

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The value that goes into the second operand of the  inline-asm is correct.

But since you don't mark the inline-asm as reading the memory location,  gcc
thinks you are not reading it (which is correct based on the definition of how
inline-asm works).

So invalid.

[Bug c/114597] [GCC-14] Miscompilation of pointer assignment with inline assembly

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=40988

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See PR 40988 for ways of fixing the inline-asm and even an expanded
explanation.

[Bug c/114597] [GCC-14] Miscompilation of pointer assignment with inline assembly

[141242068 at smail dot nju.edu.cn]

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

--- Comment #3 from wierton <141242068 at smail dot nju.edu.cn> ---
Thanks a lot, I have checked it out.

I'm still somewhat confused. Does the difference in compilation stem from GCC
interpreting "=m" and "=r" differently, leading it to assume that once "n.p" is
declared as an output operand without matched input declaration (eg. "=m"
expects "m", "=r" expects "r"), its value is expected to change?

```
asm("":"=m"(n.p):"r"(n.p)); // n.p is expected to change
asm("":"=r"(n.p):"r"(n.p)); // n.p can retain its value
asm("":"=m"(n.p):"m"(n.p)); // n.p can retain its value
```

Thanks in advance for any further explanation you can provide.

[Bug c/114597] [GCC-14] Miscompilation of pointer assignment with inline assembly

[xry111 at gcc dot gnu.org]

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

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #4 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to wierton from comment #3)
> Thanks a lot, I have checked it out.
> 
> I'm still somewhat confused. Does the difference in compilation stem from
> GCC interpreting "=m" and "=r" differently, leading it to assume that once
> "n.p" is declared as an output operand without matched input declaration
> (eg. "=m" expects "m", "=r" expects "r"), its value is expected to change?
> 
> ```
> asm("":"=m"(n.p):"r"(n.p)); // n.p is expected to change
> asm("":"=r"(n.p):"r"(n.p)); // n.p can retain its value
> asm("":"=m"(n.p):"m"(n.p)); // n.p can retain its value
> ```

I believe the second form is still incorrect and it just works by luck.  To
ensure it work you have to do:

asm("mov %1,%0":"=r"(n.p):"r"(n.p));

Or

asm("":"+r"(n.p));

Not so sure about the third form.

[Bug c/114597] [GCC-14] Miscompilation of pointer assignment with inline assembly

[141242068 at smail dot nju.edu.cn]

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

--- Comment #5 from wierton <141242068 at smail dot nju.edu.cn> ---
(In reply to Xi Ruoyao from comment #4)
> I believe the second form is still incorrect and it just works by luck.  To
> ensure it work you have to do:
> 
> asm("mov %1,%0":"=r"(n.p):"r"(n.p));
> 
> Or
> 
> asm("":"+r"(n.p));
> 
> Not so sure about the third form.

Thank you for your explanation, it helps me a lot :).