Re: new module for temporary files in temporary directories

[Paul Eggert]

Bruno Haible <address@hidden> writes:

> The Intel compiler people also have the declared goal of supporting the
> Linux kernel. They spent a lot of effort adding support for __asm__ in gcc's
> semantics; I don't think they would drop this support for a different
> semantics of 'volatile'.

Sure, but that depends on what one means by "semantics of 'volatile'".
There are undeniably many uses of 'volatile' in the Linux kernel, but
most of them are for uses like 'asm volatile' that won't help us in
writing portable code.

I'm not a kernel hacker, but my impression is that 'volatile' is
mostly of use in writing drivers that access device registers (the
original goal of 'volatile') and that their use in other areas is
problematic and not well-understood or well-documented.  For this
reason Linus Torvalds has deprecated the use of 'volatile' in data
structures for optimization barriers (which is the use that started
this thread), and prefers the use of primitives like barrier()
instead.  For example, please see
<http://groups.google.com/group/mlist.linux.kernel/msg/48a539a4bfb11a5a>
where Linus writes:

   Adding "volatile" often helps poorly written code.

   In fact, the one AND ONLY reason to add volatile to data structures
   is in fact poorly written code.

   Now, think about that for a minute, and maybe you'll understand why
   I don't want more volatiles in the kernel.


>> My intuition is the oppposite; I would expect 'malloc' to have more
>> problems than a random user function, since the compiler "knows" more
>> of malloc's properties.
>
> The compiler knows about it, but its code is quite complex, therefore hardly
> inlinable if the 'size' argument is not known at compile-time.

Well again it's merely my intuition at work here and I'm mostly
handwaving, but I can imagine a generation-based approach having a
malloc that is mostly inlined (just as traditional getc is mostly
inlined), where the problem might occur.  Such a malloc would be
considerably faster than traditional malloc, so this problem may
happen at some point (if it hasn't already).


> on SPARC, PowerPC, or x86_64, yes. libsigsegv's tests/sigsegv2.c
> definitely fails with gcc 3.3.4 on PowerPC if 'volatile' is
> omitted. I looked at the code generated by gcc and saw the
> instruction reordering done by gcc.

Thanks for checking this.  I installed the following into
the Autoconf manual.


2006-07-24  Paul Eggert  <address@hidden>

        * doc/autoconf.texi (Volatile Objects): Be even a little
        less skeptical about "volatile", after discussion with
        Bruno Haible on bug-gnulib.

--- autoconf.texi.~1.1063.~     2006-07-20 14:20:31.000000000 -0700
+++ autoconf.texi       2006-07-24 12:33:35.000000000 -0700
@@ -14949,18 +14949,32 @@ restrictions imposed by the @acronym{GNU
 differ on other platforms.
 
 If possible, it is best to use a signal handler that fits within the
-limits imposed by the C and Posix standards.  If this is not practical,
-then a signal handler should access only objects defined with a volatile
-type, and should not assume that these objects have an internally
-consistent state if they are larger than a machine word.  If that is not
-practical either, then it
-may be difficult to write portable code, and it is not clear whether
-using volatile lvalues will help much.
+limits imposed by the C and Posix standards.
+
+If this is not practical, you can try the following rules of thumb.  A
+signal handler should access only volatile lvalues, preferably lvalues
+that refer to objects defined with a volatile type, and should not
+assume that the accessed objects have an internally consistent state
+if they are larger than a machine word.  Furthermore, installers
+should employ compilers and compiler options that are commonly used
+for building operating system kernels, because kernels often need more
+from @code{volatile} than the C Standard requires, and installers who
+compile an application in a similar environment can sometimes benefit
+from the extra constraints imposed by kernels on compilers.
+Admittedly we are handwaving somewhat here, as there are few
+guarantees in this area; the rules of thumb may help to fix some bugs
+but there is a good chance that they will not fix them all.
 
 For @code{volatile}, C++ has the same problems that C does.
 Multithreaded applications have even more problems with @code{volatile},
 but they are beyond the scope of this section.
 
+The bottom line is that using @code{volatile} typically hurts
+performance but should not hurt correctness.  In some cases its use
+does help correctness, but these cases are often so poorly understood
+that all too often adding @code{volatile} to a data structure merely
+alleviates some symptoms of a bug while not fixing the bug in general.
+
 @node Floating Point Portability
 @section Floating Point Portability
 @cindex floating point