This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Committed: fix source-code reference in SIZE_TYPE docs (was: How do I set SIG_ATOMIC_TYPE to a variant of a C-type?)
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: joseph at codesourcery dot com
- Date: Wed, 16 May 2012 01:44:58 +0200
- Subject: Committed: fix source-code reference in SIZE_TYPE docs (was: How do I set SIG_ATOMIC_TYPE to a variant of a C-type?)
(Originally a post to gcc@. I don't know why I bother posting
there; it usually ends up with a patch. :)
> From: Hans-Peter Nilsson <hp@axis.com>
> Date: Tue, 15 May 2012 23:44:49 +0200
> > From: "Joseph S. Myers" <joseph@codesourcery.com>
> > Date: Tue, 15 May 2012 22:06:03 +0200
>
> > And as you have discovered, there are rules for these type
> > strings documented in tm.texi under SIZE_TYPE; to use some other variant
> > you'll need to find and eliminate all the dependencies on whatever rule
> > you wish to change.
>
> What I missed was more careful reading, the clue being: "The
> string must exactly match one of the data type names defined in
> the function..."
That quote stopped just before an obsolete source-code
reference. (Maybe I could argue that made me subconsciously
filter out the whole section when reading. :) Updated as below,
committed as obvious after inspection of the DVI output.
gcc:
* doc/tm.texi.in (Type Layout) <SIZE_TYPE>: Update reference to
source-code.
* doc/tm.texi: Regenerate.
Index: tm.texi.in
===================================================================
--- tm.texi.in (revision 187558)
+++ tm.texi.in (working copy)
@@ -1622,9 +1622,9 @@ The string can contain more than one key
spaces, and write first any length keyword, then @code{unsigned} if
appropriate, and finally @code{int}. The string must exactly match one
of the data type names defined in the function
-@code{init_decl_processing} in the file @file{c-decl.c}. You may not
-omit @code{int} or change the order---that would cause the compiler to
-crash on startup.
+@code{c_common_nodes_and_builtins} in the file @file{c-family/c-common.c}.
+You may not omit @code{int} or change the order---that would cause the
+compiler to crash on startup.
If you don't define this macro, the default is @code{"long unsigned
int"}.
brgds, H-P