Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Kaz Kylheku <847-115-0292@kylheku.com> Newsgroups: comp.compilers Subject: Re: Optimization techniques Date: Thu, 2 May 2019 17:51:31 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 31 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <19-05-012@comp.compilers> References: <72d208c9-169f-155c-5e73-9ca74f78e390@gkc.org.uk> <910eaf6f-f9ae-9c02-5052-f06474024d96@hesbynett.no> <19-04-027@comp.compilers> <19-05-005@comp.compilers> Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="95933"; mail-complaints-to="abuse@iecc.com" Keywords: optimize, errors Posted-Date: 02 May 2019 14:17:43 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:2248 On 2019-05-02, Martin Ward wrote: > On 26/04/19 19:46, Martin Ward wrote: >> Note that even knowing that there is undefined behaviour, you still >> may not be able to avoid it by testing for its occurrence: the >> optimiser might spot that you are testing for undefined behaviour and >> optimise away your test, because it is allowed to assume that the >> undefined behaviour can never happen! (This is what actually occurred >> in the last example I gave). > > I was a little hasty here. As I now understand it, the real problem > with the example was that undefined behaviour occured before > it was tested for, and this resulted in the test being optimised away: > > struct agnx_priv *priv = dev->priv; > if (!dev) return; > ... do stuff using dev ... Here, clearly, the compiler is acting on knowledge that is supicious, without sharing it in the form of a diagnostic. The compiler knows that the pointer is used first, and then tested for null afterward, because that's the logical basis for removing the test. The pointer being used is what it's taking as the assurance that it isn't null, which is the basis for deleting the null test. But if a pointer is used first, and tested for null afterward, that is, first and foremost, a code smell which deserves a diagnostic. Tests of run-time conditions should not be carelessly deleted without a diagnostic. Especially tests that speak to the grave validity of a datum such as a pointer.