Re: Computer architects leaving Intel...

Michael S <already5chosen@yahoo.com> schrieb:

On Fri, 13 Sep 2024 21:39:39 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
>

Michael S <already5chosen@yahoo.com> schrieb:

On Fri, 13 Sep 2024 04:12:21 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
 

Michael S <already5chosen@yahoo.com> writes: 

 

struct {
 char x[8]
 int  y;
} bar;
bar.y = 0; bar.x[8] = 42;
>
IMHO, here behavior should be fully defined by implementation.
And in practice it is.  Just not in theory.   

 
Do you mean union rather than struct?  And do you mean bar.x[7]
rather than bar.x[8]?  Surely no one would expect that storing
into bar.x[8] should be well-defined behavior.
 
If the code were this
 
    union {
      char x[8];
      int  y;
    } bar;
    bar.y = 0;  bar.x[7] = 42;
 
and assuming sizeof(int) == 4, what is it that you think should
be defined by the C standard but is not?  And the same question
for a struct if that is what you meant. 

>
>
No, I mean struct and I mean 8.
And I mean that a typical implementation-defined behavior would be
bar.y==42 on LE machines and bar.y==42*2**24 on BE machines.
As it actually happens in reality with all production compilers. 

 
Ah, you want to re-introduce Fortran's storage association and
common blocks, but without the type safety.  Good idea, that.
That created *really* interesting bugs, and Real Programmers (TM)
have to have something that pays their salaries, right?
 
SCNR

>
What I wrote is how all production C compilers work today. So it
will add no new bugs.

Maybe I should be a little bit more precise in why I think this
is an extemely bad idea.

struct {
  char x[8]
  int  y;
} bar;

Assume

  bar.y = 1234;
  bar.x[i] = 42;  // The compiler does not know i
  // Do something with bar.y

The compiler should then treat the access to bar.x[i] as if bar.y
was clobbered by the assignment statement, and reload bar.y if
it was kept in a register?  That is the semantics you propose.

So, either bar.y is treated as if it was volatile, or hard-to-detect
bugs would appear because, with optimization, the assignment would
sometimes change the value of bar.y and sometimes not.