Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sun, 15 Sep 2024 12:50:06 +0300
Organization: A noiseless patient Spider
Lines: 106
Message-ID: <20240915125006.00006e78@yahoo.com>
References: <vaqgtl$3526$1@dont-email.me>
	<memo.20240830090549.19028u@jgd.cix.co.uk>
	<2024Aug30.161204@mips.complang.tuwien.ac.at>
	<86r09ulqyp.fsf@linuxsc.com>
	<2024Sep8.173639@mips.complang.tuwien.ac.at>
	<p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com>
	<2024Sep10.101932@mips.complang.tuwien.ac.at>
	<ygn8qvztf16.fsf@y.z>
	<2024Sep11.123824@mips.complang.tuwien.ac.at>
	<vbsoro$3ol1a$1@dont-email.me>
	<867cbhgozo.fsf@linuxsc.com>
	<20240912142948.00002757@yahoo.com>
	<865xqzg63u.fsf@linuxsc.com>
	<20240913144411.00005866@yahoo.com>
	<vc2ber$120mf$1@dont-email.me>
	<20240914215922.000033d1@yahoo.com>
	<vc4qqv$1lgpq$1@dont-email.me>
	<20240915001939.00003be0@yahoo.com>
	<vc64gr$22g95$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 15 Sep 2024 11:49:42 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b1d11931d9aad568cedfe64b3767d71c";
	logging-data="2177741"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19sVXrDsOBkEv28th2Tg19kl6jsfCFz7vQ="
Cancel-Lock: sha1:S7+UxWzPw00bMA+9zHwinP+n7nw=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 5410

On Sun, 15 Sep 2024 08:05:47 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> Michael S <already5chosen@yahoo.com> schrieb:
> > On Sat, 14 Sep 2024 20:14:23 -0000 (UTC)
> > Thomas Koenig <tkoenig@netcologne.de> wrote:
> >  
> >> 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.
> >>   
> >
> > Yes, exactly.  
> 
> So, volatile for all structs, 

No.
Access to field of struct's should be ordered only relatively to
accesses to other fields *of the same instance* of the struct. And,
of course, usual 'as if' applies, so optimizing compiler can figure out
that bar.x[7] and bar.y do not overlap and thus generate code knowing
that write to one does not clobber the other. 
That's pretty far from semantics of volatile.

> plus prescribed behavior on array overruns.

Only withing bound of struct. bar.x[12] remains UB

> 
> At the risk of repeating myself: This is an extremely bad idea.
> 
> I rest my case.

You seem to think that C should be as optimizable and as full of UBs as
Fortran. Many compiler authors agree with you. 
I have different idea. IMHO, your party exploits the letter of C
standard in violation to its spirit.