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).
