Re: Computer architects leaving Intel...

On 15/09/2024 21:42, Michael S wrote:

On Sun, 15 Sep 2024 20:13:44 +0200
David Brown <david.brown@hesbynett.no> wrote:
 

On 14/09/2024 23:19, Michael S wrote:

>
Yes, exactly.
  

>
Contrary to your imagination - compilers have /never/ followed your
proposed semantics.  The oldest gcc version I found on godbolt.org is
3.4.6 from 2006, and given:
>
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".
 

Is this going to be a "No true Scotsman" argument?  Or did you forget to enable optimisations when testing /all/ the compilers on godbolt?
I tested a couple more.
With gcc for 32-bit ARM, the code re-arranges the stores - bar.x[i] gets the value of 42 before the store to bar.y is done, and bar.y is not reloaded.  This is perfectly valid code generation.
icc generates the same code as gcc for x86-64, other than the order of the first two instructions.
Compilers are, of course, free to re-read bar.y.  But they are not obliged to.  And a good enough optimising compiler will not re-read bar.y because it is a waste of instruction cycles.  Most of the C compilers on godbolt do not optimise as well as gcc does, though some (like clang and icc) will do better in a minority of cases.  I know of a number of other heavily optimising compilers that are not on godbolt because they have high costs and licenses that forbid that kind of use.
However, what we have from godbolt is a clear pattern - there is absolutely no basis for suggesting that accessing bar.x[] beyond the defined limit of the array is defined in any way, either within the C standards, practical real-world compilers, or documented extensions in compilers.