Date: Mon, 5 Sep 2011 22:20:06 +0200 (CEST) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-ports@FreeBSD.ORG, matthias.andree@gmx.de, perryh@pluto.rain.com Subject: Re: reasons for rewriting regular memory Message-ID: <201109052020.p85KK63J013280@lurza.secnetix.de> In-Reply-To: <4e6491d0.MNLKNzL63JK0kXDG%perryh@pluto.rain.com>
next in thread | previous in thread | raw e-mail | index | archive | help
perryh@pluto.rain.com wrote: > Matthias Andree <matthias.andree@gmx.de> wrote: > > > I agree, but I can think of another valid exception. System with > > > Hamming correction on the memory, gets a single bit (correctable) > > > error. Need to rewrite the memory contents to reset all the parity > > > bits! > > That's a matter of the EDAC stuff, not the business of applications. > > True, but it may explain why clang does not flag "*x = *x;" when it > does flag "x = x;". A compiler cannot know the context in which the > compiled code will be used. No -- If a program requires that an access to a variable must not be optimized away by the compiler (because it is a hardware register or something similar), then it must declare the variable as "volatile". But there is a simple reason that "x = x;" is flagged while "*x = *x;" is not. It is trivial to detect that the former does not have any effect. No operators are involved (except for the assignment itself), so the compiler just has to compare the _names_. But in the latter case, it is not trivial at all, because the compiler has to compare the _values_ of the expressions and detect any side effects, and it has to take a lot of things into account. For example, x could be part of the struct to which x points, so the assignment could change the contents of the struct. Detecting these cases would involve a rather deep and extensive analysis of the code. Obviously clang isn't going that far (although, maybe a higher optimization level could change that). > BTW I agree that an understanding is needed of _why_ the code in > question was included. I think someone else already explained that in this thread. The GIT reposity reveals that the author removed a variable that was not used anymore, and replaced all occurences of it, probably with automated search&replace, which lead to the line in question, which is now superfluous. It should just be removed. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is to C as Lung Cancer is to Lung." -- Thomas Funke
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201109052020.p85KK63J013280>