Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Mon, 16 Sep 2024 12:32:39 +0200
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <vc91g7$2ptfd$1@dont-email.me>
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>
 <vc784p$2a405$1@dont-email.me> <20240915224235.00006f73@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 16 Sep 2024 12:32:40 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d1583d3c65366d20e8e7bb3dd5deb61e";
	logging-data="2946541"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18U9eGMubDh4kxYqzmmWqD3g9fEqq6CJco="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:Bcodbe/+90+wCPk+moHyEj/Wlcw=
In-Reply-To: <20240915224235.00006f73@yahoo.com>
Content-Language: en-GB
Bytes: 4024

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.