This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] C undefined behavior fix
- From: Alan Cox <alan at lxorguk dot ukuu dot org dot uk>
- To: dewar at gnat dot com
- Cc: guerby at acm dot org, gcc at gcc dot gnu dot org, linux-kernel at vger dot kernel dot org,paulus at samba dot org, trini at kernel dot crashing dot org, velco at fadata dot bg
- Date: Sun, 6 Jan 2002 16:39:21 +0000 (GMT)
- Subject: Re: [PATCH] C undefined behavior fix
> 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.