This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: g77 testsuite failures under hpux 10.20
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Subject: Re: g77 testsuite failures under hpux 10.20
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Fri, 07 Jul 2000 12:04:16 -0600
- cc: rth at cygnus dot com (Richard Henderson), gcc-bugs at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <200007071743.NAA03949@hiauly1.hia.nrc.ca>you write:
> I added a simple patch to store in gc memory if ggc_p is true. This
> appears to fix the problem. However, I am uncertain as to whether
> gc memory is suitable "permanent" labels.
It is. The whole point is we need that string to hang around until it's
not needed anymore :-) That's precisely what GC does. Once the last
reference goes away, the string itself can go away too.
> There is one other use of obstack_alloc is pa.c. This is for deferred
> plabels. I am wondering if this name should also be in ggc memory when
> ggc_p is true.
I believe we do the right thing in the deferred plabel code.
The difference is the encode case you're fixing modifies a hunk of RTL
and stuffs an obstack thingie into it.
The deferred plabels just uses the obstack as a place to hold a bunch of
strings until we don't need them anymore -- it never stomps on RTL bits.
> In looking at ia64_encode_section_info, it referred to the v850 port.
> On inspection, it may have the same problem as the pa port. Thus, the
> problem doesn't appear limited to just the pa.
Depends on the precise usage.
jeff