* [Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output
2023-04-12 9:49 [Bug middle-end/109484] New: [Wrong Code][inline-asm] output operands overlap with output 570070308 at qq dot com
@ 2023-04-12 10:51 ` rguenth at gcc dot gnu.org
2023-04-12 11:03 ` 570070308 at qq dot com
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-04-12 10:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
but you clobber 'temp' early and fail to indicate that so GCC allocates the
same register as part of the "+m" output.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output
2023-04-12 9:49 [Bug middle-end/109484] New: [Wrong Code][inline-asm] output operands overlap with output 570070308 at qq dot com
2023-04-12 10:51 ` [Bug middle-end/109484] " rguenth at gcc dot gnu.org
@ 2023-04-12 11:03 ` 570070308 at qq dot com
2023-04-12 11:07 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: 570070308 at qq dot com @ 2023-04-12 11:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484
--- Comment #2 from 。 <570070308 at qq dot com> ---
(In reply to Richard Biener from comment #1)
> but you clobber 'temp' early and fail to indicate that so GCC allocates the
> same register as part of the "+m" output.
The requirements you describe are not reflected in the documentation. The
document only says that `GCC assumpts that the assembler code consumes its
inputs before producing outputs`, and this code fits the assumption. First, it
reads the input from %1, then write the output to %0, then write the output to
%1. No outputs happend before inputs.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output
2023-04-12 9:49 [Bug middle-end/109484] New: [Wrong Code][inline-asm] output operands overlap with output 570070308 at qq dot com
2023-04-12 10:51 ` [Bug middle-end/109484] " rguenth at gcc dot gnu.org
2023-04-12 11:03 ` 570070308 at qq dot com
@ 2023-04-12 11:07 ` rguenth at gcc dot gnu.org
2023-04-12 11:09 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-04-12 11:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to 。 from comment #2)
> (In reply to Richard Biener from comment #1)
> > but you clobber 'temp' early and fail to indicate that so GCC allocates the
> > same register as part of the "+m" output.
>
> The requirements you describe are not reflected in the documentation. The
> document only says that `GCC assumpts that the assembler code consumes its
> inputs before producing outputs`, and this code fits the assumption. First,
> it reads the input from %1, then write the output to %0, then write the
> output to %1. No outputs happend before inputs.
You first write to 'temp' and then read from it. The wording applies to the
assigned register / address, _not_ to the C variables mapped.
Note I'm not an expert here and I wonder if an output operand is the
appropriate
way to create a scratch register for arbitrary use.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output
2023-04-12 9:49 [Bug middle-end/109484] New: [Wrong Code][inline-asm] output operands overlap with output 570070308 at qq dot com
` (2 preceding siblings ...)
2023-04-12 11:07 ` rguenth at gcc dot gnu.org
@ 2023-04-12 11:09 ` rguenth at gcc dot gnu.org
2023-04-12 11:13 ` 570070308 at qq dot com
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-04-12 11:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
So, use "=&r" (temp) (an early-clobber), that should fix it.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output
2023-04-12 9:49 [Bug middle-end/109484] New: [Wrong Code][inline-asm] output operands overlap with output 570070308 at qq dot com
` (3 preceding siblings ...)
2023-04-12 11:09 ` rguenth at gcc dot gnu.org
@ 2023-04-12 11:13 ` 570070308 at qq dot com
2023-04-12 12:48 ` 570070308 at qq dot com
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: 570070308 at qq dot com @ 2023-04-12 11:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484
--- Comment #5 from 。 <570070308 at qq dot com> ---
(In reply to Richard Biener from comment #3)
> (In reply to 。 from comment #2)
> > (In reply to Richard Biener from comment #1)
> > > but you clobber 'temp' early and fail to indicate that so GCC allocates the
> > > same register as part of the "+m" output.
> >
> > The requirements you describe are not reflected in the documentation. The
> > document only says that `GCC assumpts that the assembler code consumes its
> > inputs before producing outputs`, and this code fits the assumption. First,
> > it reads the input from %1, then write the output to %0, then write the
> > output to %1. No outputs happend before inputs.
>
> You first write to 'temp' and then read from it. The wording applies to the
> assigned register / address, _not_ to the C variables mapped.
>
> Note I'm not an expert here and I wonder if an output operand is the
> appropriate
> way to create a scratch register for arbitrary use.
The second instruction is $0, not %0.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output
2023-04-12 9:49 [Bug middle-end/109484] New: [Wrong Code][inline-asm] output operands overlap with output 570070308 at qq dot com
` (4 preceding siblings ...)
2023-04-12 11:13 ` 570070308 at qq dot com
@ 2023-04-12 12:48 ` 570070308 at qq dot com
2023-04-12 13:03 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: 570070308 at qq dot com @ 2023-04-12 12:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484
--- Comment #6 from 。 <570070308 at qq dot com> ---
A better testcase:
```c
void kkk(void **const pp)
{
void *temp;
__asm__ volatile (
"movq $0xff, %0\n\t"
"movq $0xff, %1"
:"=r"(temp), "=m"(*pp)
:
:);
__asm__ volatile(""::"D"(temp):);
}
```
After compile:
```assemble
kkk:
movq $0xff, %rdi
movq $0xff, (%rdi) # abort
ret
```
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output
2023-04-12 9:49 [Bug middle-end/109484] New: [Wrong Code][inline-asm] output operands overlap with output 570070308 at qq dot com
` (5 preceding siblings ...)
2023-04-12 12:48 ` 570070308 at qq dot com
@ 2023-04-12 13:03 ` jakub at gcc dot gnu.org
2023-04-13 11:51 ` xry111 at gcc dot gnu.org
2023-04-13 11:55 ` jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-04-12 13:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
CC| |jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Similar bug. The basic GCC expectations for inline-asm is that the whole
assembly template after substitutions (which is for GCC mostly intentionally a
black box) works as a single instruction which reads all its inputs (and that
obviously doesn't mean just the input themselves, but also any other
register/memory used in the input) and then stores all its outputs.
Early clobbers are the way to tell the compiler that it is not the case and
some output is written before all the inputs are used.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output
2023-04-12 9:49 [Bug middle-end/109484] New: [Wrong Code][inline-asm] output operands overlap with output 570070308 at qq dot com
` (6 preceding siblings ...)
2023-04-12 13:03 ` jakub at gcc dot gnu.org
@ 2023-04-13 11:51 ` xry111 at gcc dot gnu.org
2023-04-13 11:55 ` jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: xry111 at gcc dot gnu.org @ 2023-04-13 11:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484
Xi Ruoyao <xry111 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |xry111 at gcc dot gnu.org
--- Comment #8 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> Similar bug. The basic GCC expectations for inline-asm is that the whole
> assembly template after substitutions (which is for GCC mostly intentionally
> a black box) works as a single instruction which reads all its inputs (and
> that obviously doesn't mean just the input themselves, but also any other
> register/memory used in the input) and then stores all its outputs.
> Early clobbers are the way to tell the compiler that it is not the case and
> some output is written before all the inputs are used.
Should we add this info into the doc?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug middle-end/109484] [Wrong Code][inline-asm] output operands overlap with output
2023-04-12 9:49 [Bug middle-end/109484] New: [Wrong Code][inline-asm] output operands overlap with output 570070308 at qq dot com
` (7 preceding siblings ...)
2023-04-13 11:51 ` xry111 at gcc dot gnu.org
@ 2023-04-13 11:55 ` jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-04-13 11:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The documentation already says that.
^ permalink raw reply [flat|nested] 10+ messages in thread