| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 29 Nov 2006 17:04:28 -0800 From: "David Schwartz" <davids@...master.com> To: "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org> Subject: RE: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet_tick away Ask yourself this question: Can an assignment to a non-volatile variable be optimized out? Then ask yourself this question: Does casting away volatile make it not volatile any more? > The volatile'ness does not simply disappear the moment you > assign the result to some local variable which is not volatile. Yes, it does. That's what a cast does, it tells the compiler to, in all respects, pretend that a variable is of a different type than it 'actually is', such that it actually isn't anymore. > Half of our drivers would break if this were true. On the contrary, they'd break if it was true. If casting away volatile didn't make it go away, then casting in volatile wouldn't have to make it appear. A cast causes the compiler to act as if a variable really was the type you cast it to. If you cast volatile away, that has the reverse of the same affect casting to volatile has. The 'readl' function should actually assign the value to a volatile variable. Assignments to volatiles cannot be cast away, but casts can and assignments to non-volatile variables can be optimized out. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists