commit 23f5f2a42ef1065d2c3eb91fe2161e4e570ba557
Author: Roberto E. Vargas Caballero <[email protected]>
AuthorDate: Thu Jun 16 11:36:55 2016 +0200
Commit: Roberto E. Vargas Caballero <[email protected]>
CommitDate: Thu Jun 16 11:36:55 2016 +0200
Modify README
The text about volatile was not correct. The definition of the standard
about volatile is very precise, and it is not related to optimizations
like it is said there. It is related to the concept of control points.
diff --git a/README b/README
index d3c382e..f65a08c 100644
--- a/README
+++ b/README
@@ -17,10 +17,7 @@ unnecessary complexity to the compiler (and increased
compilation time):
the compiler will treat them like normal variables (the standard
specifies that a diagnostic message must be printed).
- - volatile: The definition of volatile is not concrete, because
- it is defined as 'remove all optimizations applied to the
- variable', which of course depends on the kind of optimizations
- applied to the variable. This qualifier was added to the standard
+ - volatile: This qualifier was added to the standard
to be able to deal with longjmp (local variables that are not
volatile have undefined state) and for memory mapped registers
or variables whose values are modified asynchronously. This can
@@ -39,7 +36,7 @@ unnecessary complexity to the compiler (and increased
compilation time):
numerical algorithms, where FORTRAN could achieve a better
performance (and in fact even with this specifier FORTRAN has a
better performance in this field). Ignoring it doesn't make the
- code non-standard and in almost all applications the performance
+ compiler non-standard and in almost all applications the performance
will be the same.
- Function type names
