Liste des Groupes | Revenir à c arch |
On Sun, 15 Sep 2024 18:47:06 -0700I also did not mean to imply that - I meant merely to show that gcc has generated code this way since at least that version.
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Michael S <already5chosen@yahoo.com> writes:I didn't mean to say that gcc3 is the only gcc version that returns
>On Sun, 15 Sep 2024 20:13:44 +0200>
David Brown <david.brown@hesbynett.no> wrote:
struct Bar {>
char x[8];
int y;
} bar;
>
>
int foo(int i) {
bar.y = 1234;
bar.x[i] = 42;
return bar.y;
}
>
It generates:
>
foo:
movslq %edi,%rdi
movl $1234, %eax
movl $1234, bar+8(%rip)
movb $42, bar(%rdi)
ret
>
That is, y is /not/ reloaded after bar.x[i] is set.
No other compiler on godbolt is doing it, except possibly gcc
clones. Not even clang, who's former leader wrote "Nasal Manifest".
Test runs on two different Ubuntu machines (gcc 7.4.0 and gcc 8.4.0)
both show bar.y not being overwritten (optimization levels -01 or -O2)
when foo() is called.
non-overwritten value.
I meant to say that all gcc versions are in one camp and the rest ofYes, but you were wrong about that. And even if you were right, it would still be irrelevant - your argument that "what I wrote is how all production C compilers work today" has been shattered. The most-used C compiler does not work as you thought, and has not done so for at least 20 years. Indeed, for some targets (such as 32-bit ARM that I tested) it does the write to bar.x[i] first, then the write to bar.y, because that makes more sense from an instruction scheduling viewpoint.
compilers represented on Goldbolt is in the other camp.
Les messages affichés proviennent d'usenet.