This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RFA: hook doc patch (1/112): TARGET_HANDLE_C_OPTION
- From: Joern Rennecke <amylaar at spamcop dot net>
- To: gcc-patches at gcc dot gnu dot org
- Date: Fri, 15 Jan 2010 12:09:26 -0500
- Subject: RFA: hook doc patch (1/112): TARGET_HANDLE_C_OPTION
These patches fix inconsistencies that became apparent with
generating the prototypes from the header file type information,
fix some documentation content I found lacking along the way,
and canonicalize some things so that they can be consistently
auto-generated. I.e. return types are not put in braces if they
are a single word, otherwise they are put in braces.
function hooks always get a full prototype with types and names for
every argument. @findex is placed before the start of the paragraph,
and multiple findices are placed in the order of appearance of the
keywords inside the paragraph.
This is to prepare the documentation to match the auto-generated
documentation, as discussed here:
http://gcc.gnu.org/ml/gcc/2010-01/msg00283.html
I have bootstrapped all 112 patches together on i686-pc-linux-gnu,
and also tried 'make info'.
2010-01-15 Joern Rennecke <amylaar@spamcop.net>
* tm.texi (TARGET_HANDLE_C_OPTION): Explain arguments.
Index: tm.texi
===================================================================
--- tm.texi (revision 155367)
+++ tm.texi (working copy)
@@ -781,7 +781,8 @@ This target hook is called whenever the
target-specific C language family options described by the @file{.opt}
definition files(@pxref{Options}). It has the opportunity to do some
option-specific processing and should return true if the option is
-valid. The default definition does nothing but return false.
+valid. The arguments are like for @code{TARGET_HANDLE_OPTION}. The
+default definition does nothing but return false.
In general, you should use @code{TARGET_HANDLE_OPTION} to handle
options. However, if processing an option requires routines that are