Subject: Re: [PATCH] C undefined behavior fix
To: dewar@gnat.com
Date: Sun, 6 Jan 2002 16:39:21 +0000 (GMT)
Cc: guerby@acm.org, gcc@gcc.gnu.org, linux-kernel@vger.kernel.org,
        paulus@samba.org, trini@kernel.crashing.org, velco@fadata.bg
In-Reply-To: <20020106162213.37901F28C5@nile.gnat.com> from "dewar@gnat.com" at Jan 06, 2002 11:22:13 AM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E16NGKQ-0005ky-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: linux-kernel-owner@vger.kernel.org

> I think it  is the compiler burden to prove that the extra stuff
> "read" is not observable (in the sense of external
> effect) at execution. In a memory-mapped I/O architecture
> where there is a distinction on external effects between a byte read
> and a word read (eg: a crash :),  the compiler can't get very far IMHO
> (if it accepts the declaration of course).

In the Linux case mmio isn't a problem. The rules for mmio in the portable
code require you use architecture dependant macros (readb etc) and that
the mmio space is mapped via ioremap.

Our ioremap/mmio stuff does a whole variety of things on different platforms
including simple memory accesses, adding I/O fences, motherboard specific
function calls, and tlb bypass.

That side of things is all nicely and cleanly handled.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/