diff mbox

Group static constructors and destructors in specific subsections, take 2

Message ID 20101110174442.GA11157@bromo.med.uc.edu
State New
Headers show

Commit Message

Jack Howarth Nov. 10, 2010, 5:44 p.m. UTC 
On Wed, Nov 10, 2010 at 06:04:12PM +0100, Jan Hubicka wrote:
> 
> Makefile now has this funny message of copying tm.texi.in into tm.texi.  It seems that you copied
> doc/tm.texi.in into doc/tm.texi while you need to copy tm.texi.in from your build directory.
> 
> Honza

Honza,
   Isn't part of the problem due to...


This change adds a new @deftypefn without adding any text or the closing
@end deftypefn? There could be other issues as well but that doesn't seem
correct.
                  Jack

Comments

Ralf Wildenhues Nov. 11, 2010, 6:55 p.m. UTC | #1 
* Jack Howarth wrote on Wed, Nov 10, 2010 at 06:44:42PM CET:
> Honza,
>    Isn't part of the problem due to...
> 

> --- doc/tm.texi	(revision 166490)
> +++ doc/tm.texi	(working copy)
> @@ -7335,6 +7335,8 @@ macro is not defined, nothing is output 
>  @end defmac
>  
>  @deftypefn {Target Hook} void TARGET_ASM_NAMED_SECTION (const char *@var{name}, unsigned int @var{flags}, tree @var{decl})
> +
> +@deftypefn {Target Hook} {section *} TARGET_ASM_FUNCTION_SECTION (tree @var{decl}, enum node_frequency @var{freq}, bool @var{startup}, bool @var{exit})
>  Output assembly directives to switch to section @var{name}.  The section
>  should have attributes as specified by @var{flags}, which is a bit mask
>  of the @code{SECTION_*} flags defined in @file{output.h}.  If @var{decl}
> 
> This change adds a new @deftypefn without adding any text or the closing
> @end deftypefn? There could be other issues as well but that doesn't seem
> correct.

If this entry should be there, then it should be a @deftypefnx one,
and without a preceding empty line.

You can wrap long @def* lines by ending the line with an @,
and optional indenting spaces on the following line.

Cheers,
Ralf
Dave Korn Nov. 11, 2010, 10:04 p.m. UTC | #2 
On 11/11/2010 18:55, Ralf Wildenhues wrote:
> * Jack Howarth wrote on Wed, Nov 10, 2010 at 06:44:42PM CET:
>> Honza,
>>    Isn't part of the problem due to...
>>
> 
>> --- doc/tm.texi	(revision 166490)
>> +++ doc/tm.texi	(working copy)
>> @@ -7335,6 +7335,8 @@ macro is not defined, nothing is output 
>>  @end defmac
>>  
>>  @deftypefn {Target Hook} void TARGET_ASM_NAMED_SECTION (const char *@var{name}, unsigned int @var{flags}, tree @var{decl})
>> +
>> +@deftypefn {Target Hook} {section *} TARGET_ASM_FUNCTION_SECTION (tree @var{decl}, enum node_frequency @var{freq}, bool @var{startup}, bool @var{exit})
>>  Output assembly directives to switch to section @var{name}.  The section
>>  should have attributes as specified by @var{flags}, which is a bit mask
>>  of the @code{SECTION_*} flags defined in @file{output.h}.  If @var{decl}
>>
>> This change adds a new @deftypefn without adding any text or the closing
>> @end deftypefn? There could be other issues as well but that doesn't seem
>> correct.
> 
> If this entry should be there, then it should be a @deftypefnx one,
> and without a preceding empty line.
> 
> You can wrap long @def* lines by ending the line with an @,
> and optional indenting spaces on the following line.

  The change is coming from genhooks, autogenerated based on the addition to
target.def.  It appears that if you add a new hook in target.def, but don't
add an @hook documentation paragraph in tm.texi.in to match, genhooks.c emits
the @deftype{fn,var} start marker along with the function name and parameters,
but then fails to enter this if clause in emit_documentation():

	      if (hook_array[i].doc[0])
		{
		  printf ("\n");
		  /* Print each documentation paragraph in turn.  */
		  for (doc = hook_array[i].doc; *doc; doc = p_end)
		    {
		      /* Find paragraph end.  */
		      p_end = strstr (doc, "\n\n");
		      p_end = (p_end ? p_end + 2 : doc + strlen (doc));
		      /* Print paragraph, emitting @Fcode as @code.  */
		      for (; (fcode = strstr (doc, "@Fcode{")) && fcode < p_end;
			   doc = fcode + 2)
			printf ("%.*s@", (int) (fcode - doc), doc);
		      printf ("%.*s", (int) (p_end - doc), doc);
		      /* Emit function indices for next paragraph.  */
		      emit_findices (p_end, name);
		    }
		  printf ("\n@end %s", deftype);
		}

... which is where the end directive gets emitted.  Genhooks should probably
fail more gracefully, but I imagine it is an error to add a new hook to
target.def without documenting it in tm.texi.in.  (If this isn't attempting to
enforce policy, then moving the final printf() outside the if condition should
do the trick.)


    cheers,
      DaveK
Dave Korn Nov. 11, 2010, 11:23 p.m. UTC | #3 
On 11/11/2010 22:04, Dave Korn wrote:

>> If this entry should be there, then it should be a @deftypefnx one, and
>> without a preceding empty line.

> The change is coming from genhooks, autogenerated based on the addition to 
> target.def.  It appears that if you add a new hook in target.def, but don't
>  add an @hook documentation paragraph in tm.texi.in to match, genhooks.c
> emits the @deftype{fn,var} start marker along with the function name and
> parameters, but then fails to enter this if clause in emit_documentation():

> ... which is where the end directive gets emitted.  Genhooks should
> probably fail more gracefully, but I imagine it is an error to add a new
> hook to target.def without documenting it in tm.texi.in.  (If this isn't
> attempting to enforce policy, then moving the final printf() outside the if
> condition should do the trick.)

  Actually, it's deliberate:

>    When the doc field is "", @deftypefn/@deftypevr and the hook signature
>    is emitted, but not the matching @end.  This allows all the free-form
>    documentation to be placed in IN_FNAME, to work around GPL/GFDL
>    licensing incompatibility issues.  */

  If what is desired is no docs at all,

>    In particular, a doc field of "*" means not to emit any ocumentation for
>    this target.def / hook_array entry at all (there might be documentation
>    for this hook in the file named IN_FNAME, though).

is the way to go, but using "" deliberately indicates "free-form documentation
[...] in " ... tm.texi.in.  (I expect in this case that adding docs to
tm.texi.in rather than using "*" to create an undocumented target hook is the
desired fix.)

    cheers,
      DaveK
Ralf Wildenhues Nov. 12, 2010, 6:52 p.m. UTC | #4 
* Dave Korn wrote on Fri, Nov 12, 2010 at 12:23:25AM CET:
> On 11/11/2010 22:04, Dave Korn wrote:
> 
> >> If this entry should be there, then it should be a @deftypefnx one, and
> >> without a preceding empty line.
> 
> > The change is coming from genhooks, autogenerated based on the addition to 
> > target.def.  It appears that if you add a new hook in target.def, but don't
> >  add an @hook documentation paragraph in tm.texi.in to match, genhooks.c
> > emits the @deftype{fn,var} start marker along with the function name and
> > parameters, but then fails to enter this if clause in emit_documentation():
> 
> > ... which is where the end directive gets emitted.  Genhooks should
> > probably fail more gracefully, but I imagine it is an error to add a new
> > hook to target.def without documenting it in tm.texi.in.  (If this isn't
> > attempting to enforce policy, then moving the final printf() outside the if
> > condition should do the trick.)
> 
>   Actually, it's deliberate:

It doesn't matter if it's deliberate or not.  A texinfo file must be
well-formed.  That means, each @deftypefn must end with @end deftypefn,
without intervening @deftypefn lines.  Between these two, there may be
zero or more @deftypefnx lines.

Cheers,
Ralf
Dave Korn Nov. 12, 2010, 8:47 p.m. UTC | #5 
On 12/11/2010 18:52, Ralf Wildenhues wrote:
> * Dave Korn wrote on Fri, Nov 12, 2010 at 12:23:25AM CET:
>> On 11/11/2010 22:04, Dave Korn wrote:
>>
>>>> If this entry should be there, then it should be a @deftypefnx one, and
>>>> without a preceding empty line.
>>> The change is coming from genhooks, autogenerated based on the addition to 
>>> target.def.  It appears that if you add a new hook in target.def, but don't
>>>  add an @hook documentation paragraph in tm.texi.in to match, genhooks.c
>>> emits the @deftype{fn,var} start marker along with the function name and
>>> parameters, but then fails to enter this if clause in emit_documentation():
>>> ... which is where the end directive gets emitted.  Genhooks should
>>> probably fail more gracefully, but I imagine it is an error to add a new
>>> hook to target.def without documenting it in tm.texi.in.  (If this isn't
>>> attempting to enforce policy, then moving the final printf() outside the if
>>> condition should do the trick.)
>>   Actually, it's deliberate:
> 
> It doesn't matter if it's deliberate or not.  A texinfo file must be
> well-formed.  That means, each @deftypefn must end with @end deftypefn,
> without intervening @deftypefn lines.  Between these two, there may be
> zero or more @deftypefnx lines.

  Yes, and if the @hook hunk had not been missing from tm.texi.in, that is
exactly what genhooks would have output.  But the @hook hunk was missing,
which is not allowed when the doc string is "".  This is a simple case of
GIGO: the input to genhooks was invalid, and it ended up generating invalid
texinfo output as a result.


    cheers,
      DaveK
diff mbox

Patch

Index: doc/tm.texi
===================================================================
--- doc/tm.texi	(revision 166490)
+++ doc/tm.texi	(working copy)
@@ -7335,6 +7335,8 @@  macro is not defined, nothing is output 
 @end defmac
 
 @deftypefn {Target Hook} void TARGET_ASM_NAMED_SECTION (const char *@var{name}, unsigned int @var{flags}, tree @var{decl})
+
+@deftypefn {Target Hook} {section *} TARGET_ASM_FUNCTION_SECTION (tree @var{decl}, enum node_frequency @var{freq}, bool @var{startup}, bool @var{exit})
 Output assembly directives to switch to section @var{name}.  The section
 should have attributes as specified by @var{flags}, which is a bit mask
 of the @code{SECTION_*} flags defined in @file{output.h}.  If @var{decl}