Re: labels-2.c / -Os fix

[Jan Hubicka <hubicka at atrey dot karlin dot mff dot cuni dot cz>]

> On Wed, Apr 26, 2000 at 05:37:51PM +0200, Jan Hubicka wrote:
> > The -Os failure at labels-2.c is caused by storing rtx containing LABEL_REF
> > into const pool.
> 
> For what target is this?  I ask because I don't see this fail
> on x86, which is where most of your other work is...
Ah, I forgot to mention, it actually fails only with enable checking on i386.
Otherwise the strlen probably passes. IMO.
> 
> > ... how to handle label_refs correctly, so I am making them all to
> > appear different.  This is safe and don't hurt much IMO.
> 
> Seems like output_constant_def couldn't really do it's job
> this way?  Perhaps you can rely on pointer equivalence of
> the referenced CODE_LABEL rather than on the UID?
I was thinking about this, but I am not sure if the CODE_LABELs can't
be garbage collected and dropped.  Also this would require me to figure
out the CODE_LABEL pointer I don't have available by mostly duplicating
the decode_addr_const (since I get useless label_ref with 0).
And lastly this appears only in the code with unreferenced labels:

struct bp { void *v, *b, *e; };
f ()
{
  struct bp x = { &&L2 };
  if (&&L3 - &&L1 > 1)
    abort ();
L1:return 1;
L2:abort ();
L3:;
}

(labels-2 testcase), that is not common and as I understand it, whole code
is only hack around the termporary storage of trees and will go away once
we kill obstack frontends.  Maybe I am wrong in this issue. If you think
there are some sane cases, where merging values with labels helps, I can
investigate this.

Honza

> 
> 
> r~