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".