[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section

[rsandifo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490

--- Comment #24 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #23)
> Comment on attachment 45830 [details]
> proposed patch
> 
> Please update the get_block_for_section function comment accordingly:
> 
> /* Return the object_block structure for section SECT.  Create a new
>    structure if we haven't created one already.  Return null if SECT
>    itself is null.  */
> 
> This should say that we return NULL also for mergeable sections and why
> - that section anchors can't be used in mergeable sections anyway, because
> the linker might move objects around, and that using the object blocks
> infrastructure in that case is both a waste and maintenance burden.

I think we should also remove the test in default_use_anchors_for_symbol_p,
since:

  sect = SYMBOL_REF_BLOCK (symbol)->sect;

will surely fault if the block is null.  Agree the patch looks good
with those changes.

> Given:
>   /* Don't use anchors for small data sections.  The small data register
>      acts as an anchor for such sections.  */
>   if (sect->common.flags & SECTION_SMALL)
>     return false;
> we could do the same for SECTION_SMALL, but I'm not suggesting that ATM.

The idea was that the block infrastructure could also be used
at some future time to organise decls into a specific order,
e.g. to promote locality.  Obviously that hasn't happened yet,
but I think we should keep the SECTION_SMALL stuff as-is and
only exclude decls that can't be put into blocks for correctness
reasons.

In general, the section anchor/section block stuff could probably
be cleaned up a lot now that unit-at-a-time is the only supported
mode.  (That wasn't true when it was originally written.)