Patchwork Group static constructors and destructors in specific subsections, take 2

login
register
mail settings
Submitter Jack Howarth
Date Nov. 10, 2010, 10:26 p.m.
Message ID <20101110222612.GA12611@bromo.med.uc.edu>
Download mbox | patch
Permalink /patch/70697/
State New
Headers show

Comments

Jack Howarth - Nov. 10, 2010, 10:26 p.m.
On Wed, Nov 10, 2010 at 06:13:17PM +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.
> 
> You can also just revert the doc directory change.  It needs no testing on multiple targets.
> 
> Thanks for doing the Darwin run BTW :)
> Honza
> > 
> > Honza

Honza,
   I can't seem to get past the error...

gcc   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE  -o build/gengenrtl \
	    build/gengenrtl.o build/errors.o ../build-x86_64-apple-darwin10.5.0/libiberty/libiberty.a
/bin/sh ../../gcc/gcc/../move-if-change tmp-tm.texi tm.texi

Verify that you have permission to grant a GFDL license for all
new text in tm.texi, then copy it to ../../gcc/gcc/doc/tm.texi.
make[2]: *** [s-tm-texi] Error 1
make[2]: *** Waiting for unfinished jobs....
rm gfdl.pod cpp.pod gcov.pod fsf-funding.pod gcc.pod
make[1]: *** [all-gcc] Error 2
make: *** [all] Error 2

even with the simple build...

../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw --with-mpc=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-languages=c --disable-bootstrap

...using your patch except for the section...


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.
         Jack
Jan Hubicka - Nov. 10, 2010, 10:56 p.m.
> 
> 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
Jack Howarth - Nov. 11, 2010, 1:15 a.m.
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
Jack Howarth - Nov. 11, 2010, 2:53 a.m.
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
Dave Korn - Nov. 11, 2010, 2:57 a.m.
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
Jack Howarth - Nov. 11, 2010, 12:12 p.m.
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
Jan Hubicka - Nov. 11, 2010, 4:27 p.m.
> 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

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}