diff options
Diffstat (limited to 'gcc/doc/extend.texi')
| -rw-r--r-- | gcc/doc/extend.texi | 34 |
1 files changed, 17 insertions, 17 deletions
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi index 90f8b7a..1ac1d8d 100644 --- a/gcc/doc/extend.texi +++ b/gcc/doc/extend.texi @@ -2692,24 +2692,24 @@ an inlined PLT. @item leaf @cindex @code{leaf} function attribute Calls to external functions with this attribute must return to the current -compilation unit only by return or by exception handling. In particular, leaf -functions are not allowed to call callback function passed to it from current +compilation unit only by return or by exception handling. In particular, leaf +functions are not allowed to call callback function passed to it from the current compilation unit or directly call functions exported by the unit or longjmp -into the unit. Still leaf function might call functions from other complation -units and thus they are not neccesarily leaf in the sense that they contains no +into the unit. Leaf function might still call functions from other compilation +units and thus they are not necessarily leaf in the sense that they contain no function calls at all. The attribute is intended for library functions to improve dataflow analysis. -Compiler takes the hint that any data not escaping current compilation unit can -not be used or modified by the leaf function. For example, function @code{sin} -is leaf, function @code{qsort} is not. +The compiler takes the hint that any data not escaping the current compilation unit can +not be used or modified by the leaf function. For example, the @code{sin} function +is a leaf function, but @code{qsort} is not. -Note that the leaf functions might invoke signals and signal handlers might be -defined in the current compilation unit and use static variables. Only +Note that leaf functions might invoke signals and signal handlers might be +defined in the current compilation unit and use static variables. The only compliant way to write such a signal handler is to declare such variables @code{volatile}. -The attribute has no effect on functions defined within current compilation +The attribute has no effect on functions defined within the current compilation unit. This is to allow easy merging of multiple compilation units into one, for example, by using the link time optimization. For this reason the attribute is not allowed on types to annotate indirect calls. @@ -3589,16 +3589,16 @@ away so that a longer more expensive calling sequence is required. @item cpu=@var{CPU} @cindex @code{target("cpu=@var{CPU}")} attribute -Specify the architecture to generate code for in compiling the -function. If you select @code{"target("cpu=power7)"} attribute when +Specify the architecture to generate code for when compiling the +function. If you select the @code{"target("cpu=power7)"} attribute when generating 32-bit code, VSX and Altivec instructions are not generated unless you use the @option{-mabi=altivec} option on the command line. @item tune=@var{TUNE} @cindex @code{target("tune=@var{TUNE}")} attribute -Specify the architecture to tune for in compiling the function. If +Specify the architecture to tune for when compiling the function. If you do not specify the @code{target("tune=@var{TUNE}")} attribute and -you do specifiy the @code{target("cpu=@var{CPU}")} attribute, +you do specify the @code{target("cpu=@var{CPU}")} attribute, compilation will tune for the @var{CPU} architecture, and not the default tuning specified on the command line. @end table @@ -5358,14 +5358,14 @@ the single copy in the library. C has the concept of volatile objects. These are normally accessed by pointers and used for accessing hardware or inter-thread -communication. The standard encourage compilers to refrain from +communication. The standard encourages compilers to refrain from optimizations concerning accesses to volatile objects, but leaves it implementation defined as to what constitutes a volatile access. The minimum requirement is that at a sequence point all previous accesses to volatile objects have stabilized and no subsequent accesses have occurred. Thus an implementation is free to reorder and combine volatile accesses which occur between sequence points, but cannot do -so for accesses across a sequence point. The use of volatiles does +so for accesses across a sequence point. The use of volatile does not allow you to violate the restriction on updating objects multiple times between two sequence points. @@ -5394,7 +5394,7 @@ asm volatile ("" : : : "memory"); vobj = 1; @end smallexample -A scalar volatile object is read, when it is accessed in a void context: +A scalar volatile object is read when it is accessed in a void context: @smallexample volatile int *src = @var{somevalue}; |