Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch
Newsgroups: comp.lang.c++
Subject: Re: Performance of unaligned memory-accesses
Date: Thu, 15 Aug 2019 16:56:21 -0700
Organization: A noiseless patient Spider
Lines: 12
Message-ID: <86o90qc7a2.fsf@mailhub.linuxsc.com>
References: <_ic4F.727$t92.96@fx25.am4> <7yd4F.2$CO2.0@fx30.am4> <86mugb7lvg.fsf@mailhub.linuxsc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="d73af4a5781da3d2d34fddde94f66dc1"; logging-data="11889"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+WgcU/pTQalBWOZHRFx8qIg5yiHo2TixQ="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:Cb2wzapu/xmWSlorLlCirmXvqNE= sha1:uhuJdSDmsa6vd5Qjk4XJrUoLpwQ=
Xref: csiph.com comp.lang.c++:67672
Bonita Montero writes:
>> So it may change because of change of compiler, its version, compiling
>> options, device that it is ran on, settings of operating system or
>> other (possibly unrelated) code in same code-base.
>
> There's no reason why a compiler might get incorrect code because of
> this. It's undefined behaviour only because of the runtime-behaivour
> of the CPU / OS.
If you think that then you don't understand how the C and
C++ standards define the term "undefined behavior".