Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Michael S 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: <2024Aug30.161204@mips.complang.tuwien.ac.at> <86r09ulqyp.fsf@linuxsc.com> <2024Sep8.173639@mips.complang.tuwien.ac.at> <2024Sep10.101932@mips.complang.tuwien.ac.at> <2024Sep11.123824@mips.complang.tuwien.ac.at> <867cbhgozo.fsf@linuxsc.com> <20240912142948.00002757@yahoo.com> <865xqzg63u.fsf@linuxsc.com> <20240913144411.00005866@yahoo.com> <20240914215922.000033d1@yahoo.com> <20240915001939.00003be0@yahoo.com> 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 wrote: > Michael S schrieb: > > On Sat, 14 Sep 2024 20:14:23 -0000 (UTC) > > Thomas Koenig wrote: > > > >> Michael S schrieb: > >> > On Fri, 13 Sep 2024 21:39:39 -0000 (UTC) > >> > Thomas Koenig wrote: > >> > > >> >> Michael S schrieb: > >> >> > On Fri, 13 Sep 2024 04:12:21 -0700 > >> >> > Tim Rentsch wrote: > >> >> > > >> >> >> Michael S 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.