| Message ID | 20101110222612.GA12611@bromo.med.uc.edu |
|---|---|
| State | New |
| Headers | show |
> > that I pruned off of it. If I revert your patch and repeat the build, the error disappears. It is unclear > to me what section in the remainder of the patch could be causing this problem. It is the tm.texi being build from tm.texi.in just revert both doc directory changes and you should be safe. Thanks, Honza > Jack
On Wed, Nov 10, 2010 at 11:56:18PM +0100, Jan Hubicka wrote: > > > > that I pruned off of it. If I revert your patch and repeat the build, the error disappears. It is unclear > > to me what section in the remainder of the patch could be causing this problem. > > It is the tm.texi being build from tm.texi.in > just revert both doc directory changes and you should be safe. > > Thanks, > Honza Honza, The problem is that you can't avoid making the texi changes. Without the doc/tm.texi section of your patch applied, the build actually ends up recreating it in the build directory and then demands that the change be moved over into the source tree's gcc/doc/tm.texi. If you do that (ie restore the original patch), the error changes to a complaint that the gcc/doc/tm.texi is missing the matching `@end deftypefn' for the new entry. If you correct that, the error changes yet again to a complaint that the changes should be in gcc/doc/tm.texi.in rather than gcc/doc/tm.texi. Once you correct that the build can complete. So your patch seems to require properly formatted changes to gcc/doc/tm.texi.in which you currently lack. Pretty weird texinfo bug. Jack > > Jack
On Thu, Nov 11, 2010 at 02:57:02AM +0000, Dave Korn wrote: > On 11/11/2010 01:15, Jack Howarth wrote: > > On Wed, Nov 10, 2010 at 11:56:18PM +0100, Jan Hubicka wrote: > >>> that I pruned off of it. If I revert your patch and repeat the build, > >>> the error disappears. It is unclear to me what section in the remainder > >>> of the patch could be causing this problem. > >> It is the tm.texi being build from tm.texi.in just revert both doc > >> directory changes and you should be safe. > >> > >> Thanks, Honza > > > > Honza, The problem is that you can't avoid making the texi changes. > > Yes you can. Just start with a fresh build dir, a clean source tree, and > discard the entire tm.texi hunk from Honza's patch, which was most likely > inadvertent since it's not mentioned in the changelog. Dave, No, I did that. Starting from a fresh source tree and using all of the patch except for the first hunk gcc/doc/tm.texi (which I deleted manually from the patch before applying), the failure still occurs. Something in the build triggers the generation of the same exact lines which were omitted manually from the patch. Believe me I tried this four or five times to verify the behavior exists. Jack > > > Without > > the doc/tm.texi section of your patch applied, the build actually ends up > > recreating it in the build directory and then demands that the change be > > moved over into the source tree's gcc/doc/tm.texi. > > Not if $srcdir/gcc/doc/tm.texi.in is clean. > > cheers, > DaveK
On 11/11/2010 01:15, Jack Howarth wrote: > On Wed, Nov 10, 2010 at 11:56:18PM +0100, Jan Hubicka wrote: >>> that I pruned off of it. If I revert your patch and repeat the build, >>> the error disappears. It is unclear to me what section in the remainder >>> of the patch could be causing this problem. >> It is the tm.texi being build from tm.texi.in just revert both doc >> directory changes and you should be safe. >> >> Thanks, Honza > > Honza, The problem is that you can't avoid making the texi changes. Yes you can. Just start with a fresh build dir, a clean source tree, and discard the entire tm.texi hunk from Honza's patch, which was most likely inadvertent since it's not mentioned in the changelog. > Without > the doc/tm.texi section of your patch applied, the build actually ends up > recreating it in the build directory and then demands that the change be > moved over into the source tree's gcc/doc/tm.texi. Not if $srcdir/gcc/doc/tm.texi.in is clean. cheers, DaveK
On Wed, Nov 10, 2010 at 11:56:18PM +0100, Jan Hubicka wrote: > > > > that I pruned off of it. If I revert your patch and repeat the build, the error disappears. It is unclear > > to me what section in the remainder of the patch could be causing this problem. > > It is the tm.texi being build from tm.texi.in > just revert both doc directory changes and you should be safe. > > Thanks, > Honza > > Jack Honza, The proposed patch from http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00983.html with the fix from http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01035.html shows no regressions on x86_64-apple-darwin10... http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg00874.html Jack
> Honza, > The proposed patch from http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00983.html > with the fix from http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01035.html shows > no regressions on x86_64-apple-darwin10... > > http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg00874.html Thanks. I will make at least one extra revision to incorporate Richard's comments once we are settled, but it is good to know that it generally wroks. I was affraid of getting section flags wrong by removing all the special cases on cold sections. Honza > > Jack
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}