Path: ...!weretis.net!feeder8.news.weretis.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: Wed, 4 Sep 2024 09:04:40 +0200
Organization: A noiseless patient Spider
Lines: 65
Message-ID: <vb90q8$3nlvo$3@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me>
 <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me>
 <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me>
 <vb2hir$1ju7q$1@dont-email.me> <8lcadjhnlcj5se1hrmo232viiccjk5alu4@4ax.com>
 <vb3k0m$1rth7$1@dont-email.me>
 <17d615c6a9e70e9fabe1721c55cfa176@www.novabbs.org>
 <vb7l56$3eh1o$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 04 Sep 2024 09:04:40 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0366692407b62e2f3ab0bc1ba1697c81";
	logging-data="3921912"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18m7pOIPbJOx2cYqLVh1VwtyRHpcoG8l5Y="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:XxrP1WJiELOkgpkp664rPOTuXL8=
Content-Language: en-GB
In-Reply-To: <vb7l56$3eh1o$1@dont-email.me>
Bytes: 4149

On 03/09/2024 20:39, BGB wrote:
> On 9/2/2024 8:36 AM, MitchAlsup1 wrote:
>> On Mon, 2 Sep 2024 5:55:34 +0000, Thomas Koenig wrote:
>>
>>> George Neuner <gneuner2@comcast.net> schrieb:
>>>
>>>> I'm not going to argue about whether UB in code is wrong.  The
>>>> question I have concerns what to do with something that explicitly is
>>>> mentioned as UB in some standard N, but was not addressed in previous
>>>> standards.
>>>>
>>>> Was it always UB?  Or should it be considered ID until it became UB?
>>>
>>> Can you give an exapmple?
>>
>> Memcopy() with overlapping pointers.
> 
> I had just recently discovered that newer versions of GCC will cause 
> code to break if it is missing a return value in C++ mode.
> 

No, the error in the code caused the code to break.  You don't get to 
blame the compiler if you write rubbish.  You get to /thank/ the 
compiler if it has helpfully added an instruction to cause the program 
to stop abruptly with a UD2 instruction.

Note that in C, falling off the end of Foo here is fine - it is only if 
the caller attempts to use the non-existent return value that there is 
UB.  Thus in C mode, gcc implements Foo as "ret" (when optimised), and 
will only warn you if you enable warnings.

In C++, it is the act of falling off the end of Foo that is UB, thus the 
compiler will generate an UB2 (for -O0) or no code at all (when 
optimised), and will warn you without requiring options.

> So:
> int Foo() { }
> 
> Will (in theory) cause the program to crash when called (emitting a 
> 'UD2' instruction), except in WSL it seems this doesn't quite work 
> correctly (the UD2 doesn't result in an immediate crash), and the 
> program seemingly instead "goes off the rails and crashes at a later 
> point" (GCC omits the epilog when it does this, and seemingly control 
> flow then goes into whatever function follows in the binary, crashing 
> when that function tries to return seemingly by branching to an invalid 
> address or similar).
> 
> This was mostly effecting "init" functions in my Verilator test benches...
> 
> 
> Well, that, and a more inconsistent variant, where if one declares 
> struct fields as 8 and 3 bytes and then strncpy's 11 bytes into the 
> combined field, it may also insert a UD2 and skip emitting the following 
> code.
> 
> ...
> 
> 
> But, yeah, that was annoying...
> 

If your compiler tells you you are doing something stupid, and you 
ignore it, I really don't think you can claim "the compiler broke my code".