Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!news.ecp.fr!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.lang.forth Subject: Re: rhel 7 and kforth Date: Mon, 27 Apr 2015 18:21:26 -0400 Organization: Aioe.org NNTP Server Lines: 69 Message-ID: References: <2015Apr20.140504@mips.complang.tuwien.ac.at> <87sibtx8ob.fsf@jester.gateway.sonic.net> <2015Apr22.130001@mips.complang.tuwien.ac.at> <878udhmle2.fsf@jester.gateway.sonic.net> <2015Apr25.184119@mips.complang.tuwien.ac.at> <2015Apr26.165622@mips.complang.tuwien.ac.at> <5352fdc7-d735-4270-a89c-6b7bddc43758@googlegroups.com> <2015Apr27.111948@mips.complang.tuwien.ac.at> NNTP-Posting-Host: n4wpt9zq8xR26Ttf9mo2BA.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.lang.forth:38662 On Mon, 27 Apr 2015 05:19:48 -0400, Anton Ertl wrote: > I'll try to explain it again: > > If you have > > i=5; > if (i<16) > ... > > you know that "i<16" is true, so you can optimize it to true. > > If you have > > i=... > if (i<16) { > ... \ no change in i > if (i<16) > ... > > In the second "i<16", you know that it is true, so you can optimize it > to true. > > That's all fine and well. Now consider: > > int a[16]; > i=...; \ too complex to determine the range of i > r=a[i]; > if (i<16) > ... > > Here the compiler does not really know the range of i, but because it > occurs in a[i], it assumes that i<16 (otherwise the access a[i] would > be undefined behaviour), So? Who said undefined behavior is incorrect? There is a difference. AIR, the C specifications say that undefined behavior can be defined for a platform, i.e., correct on a specific platform. E.g., it's common for most C platforms to allow a value to be assigned to a pointer. That's undefined behavior which is defined for the specific host. It's not the compiler's job to correct undefined behavior. Undefined behavior might be exactly what the coder wanted. The compiler's job is to do exactly what it was told to do without changing the end result as understood by people. Clearly, it fails here. > so it miscompiles the "i<16" to true (or at > least the version that miscompiled the SPEC program did). Logic error. Why should it assume "i<16" is true from "a[i]"? It could just as easily assume "a[i]" is incorrect, but "i<16" isn't. > However, in real programs out-of-bounds accesses and other undefined > behaviours do happen (not frequent for out-of-bounds accesses, but > still), and "optimizing" based on the assumption that they don't is > miscompilation. Agreed. Rod Pemberton -- Cars kill more people than guns in the U.S. Yet, no one is trying to take away your car.