On Mon, Apr 8, 2019 at 11:33 AM Richard Biener
<richard.guent...@gmail.com> wrote:
>
> On Mon, Apr 8, 2019 at 10:38 AM Andrew Haley <a...@redhat.com> wrote:
> >
> > On 4/7/19 5:03 PM, Thomas Koenig wrote:
> > > Hi Richard,
> > >
> > >> I don't know without looking, but I'd start at assemble_variable in
> > >> varasm.c.
> > >
> > > Thanks. I've done that, and this is what a patch could look like.
> > > However, I will not have time to formally submit this until next
> > > weekend.
> > >
> > > In the meantime, comments are still welcome :-)
> >
> > Did you look at
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100
> >
> > This was the change that caused this behaviour.
>
> Actually that just changed the behavior for DECL_COMMONs
> which may of course match the fortran case here in case you
> bisected this. OTOH DECL_COMMONs are tentative and
> do not have an initializer (and not go to .rodata either).
That is, the C testcase
const char x[1024*1024] = {};
reproduces the "issue". The comment in bss_initializer_p though
explicitely says
/* Do not put non-common constants into the .bss section, they belong in
a readonly section, except when NAMED is true. */
return ((!TREE_READONLY (decl) || DECL_COMMON (decl) || named)
(where named refers to explicit .bss section marked decls). Note
the docs for -fzero-initialized-in-bss doesn't mention that this doesn't
apply for readonly variables.
Richard.
> Richard.
>
> >
> > --
> > Andrew Haley
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <https://www.redhat.com>
> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
