This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: String pools versus ENCODE_SECTION_INFO
- To: gcc-patches at gcc dot gnu dot org
- Subject: Re: String pools versus ENCODE_SECTION_INFO
- From: Alexandre Oliva <aoliva at redhat dot com>
- Date: 26 Dec 2000 01:12:13 -0200
- Organization: GCC Team, Red Hat
- References: <or66k8z11c.fsf@guarana.lsd.ic.unicamp.br>
On Dec 25, 2000, Alexandre Oliva <aoliva@redhat.com> wrote:
> If ENCODE_SECTION_INFO modifies the label in a string constant, the
> hash table won't find a match. Here's a patch that corrects this, by
> arranging that we always use the string of the symbol_ref, which is
> the only thing available when marking the constants.
Along the same line... When the RTL associated with a constant is
modified by ENCODE_SECTION_INFO, we shouldn't modify it again when we
find a duplicate of this constant. Ok to install?
Index: gcc/ChangeLog
from Alexandre Oliva <aoliva@redhat.com>
* varasm.c (output_constant_def): Don't ENCODE_SECTION_INFO twice.
Index: gcc/varasm.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/varasm.c,v
retrieving revision 1.148
diff -u -p -r1.148 varasm.c
--- gcc/varasm.c 2000/12/22 12:27:36 1.148
+++ gcc/varasm.c 2000/12/26 03:11:27
@@ -3204,7 +3204,10 @@ output_constant_def (exp, defer)
such as that it is a function name. If the name is changed, the macro
ASM_OUTPUT_LABELREF will have to know how to strip this information. */
#ifdef ENCODE_SECTION_INFO
- ENCODE_SECTION_INFO (exp);
+ /* A previously-processed constant would already have section info
+ encoded in it. */
+ if (! found)
+ ENCODE_SECTION_INFO (exp);
#endif
#ifdef CONSTANT_AFTER_FUNCTION_P
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me