[Bug c++/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin

["iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jason Merrill from comment #10)
> (In reply to Jonathan Wakely from comment #8)
> > (In reply to Iain Sandoe from comment #7)
> > > So I am actually asking if the extension actually has any useful meaning?
> > 
> > For non-darwin, yes, it requests the storage of two initializer lists to be
> > merged (see the commit msg for r14-1500-g4d935f52b0d5c0).
> 
> Though that doesn't involve the attribute, and promoting init-lists to
> static should work fine on darwin.

I think that is working we end up with two constant text arrays (no copy via
automatic storage as mentioned in the paper)

> (In reply to Jonathan Wakely from comment #6)
> > The question then is whether the attribute is supposed to be a non-binding
> > request or not.
> > 
> > If it's a non-binding request then the test should be adjusted/unsupported
> > for this target.
> 
> It is a non-binding request. And yes, if this optimization is problematic on
> darwin, we should adjust the test.

Actually, the optimisation is failing on Darwin - we produce two distinct
arrays.

(although, if it succeeds then technically that's breaking the ABI since we
then have two external symbols with the same addresss).

SO I suppose the question is do we want to figure out why the opt is failing
(knowing that if it succeeds that is a secondary issue) - or just
dg-xfail-run-if for Darwin?

This is what we generate now:
        .const
        .align 3
_i:
        .long   1
        .long   2
        .long   3
        .globl _j
        .align 3
_j:
        .long   1
        .long   2
        .long   3

and we do access i and j directly (i.e. not via the GOT).