On Sat, Apr 13, 2019 at 8:48 PM Thomas Koenig <tkoe...@netcologne.de> wrote:
>
> Hello world,
>
> the attached patch fixes a 8/9 regression where _def_init, an internal
> Fortran variable containing only zeros, was placed into the .rodata
> section. This led to a large increase in executable size.
>
> There should be no impact on other languages because the change to
> varasm.c is guarded by lang_GNU_Fortran ().
>
> Regarding the test case: I did find one other test which checks
> for .bss, so I suppose this is safe.
>
> Regression-tested with a full test (--enable-languages=all and
> make -j64 -k check) on POWER9.
>
> I would like to apply it to both affected branches.
>
> OK for the general and the Fortran part?

This won't work with LTO.  Note we have the issue in the middle-end as well
since we promote variables we see are not written to to TREE_READONLY.
This can be seen with (the somewhat artificial...):

int a[1024*1024] = { 0 };

int __attribute__((noinline)) foo() { return *(volatile int *)a; }

int main()
{
  return foo ();
}

where without -flto a gets placed into .bss while with -flto it
gets into .rodata.  So I believe we should add a DECL flag
specifying whether for section placement we can "ignore"
TREE_READONLY.  We'd initialize that with the original
state of TREE_READONLY so that the R/O promotion doesn't
change section placement.  Also the Fortran FE can then
simply set this flag on variables that may live in .bss.

There are 14 unused bits in tree_decl_with_vis so a
patch for the middle-end part could look like the attached
(w/o solving the LTO issue yet).

Of course adding sth like a .robss section would be nice.

Richard.

> Regards
>
>         Thomas
>
> 2019-04-13  Thomas Koenig  <tkoe...@gcc.gnu.org>
>
>          PR fortran/84487
>          * trans-decl.c (gfc_get_symbol_decl): Mark _def_init as
>          artificial.
>
> 2019-04-13  Thomas Koenig  <tkoe...@gcc.gnu.org>
>
>          PR fortran/84487
>          * varasm.c (bss_initializer_p): If we are compiling Fortran, the
>          decl is artifical and it has a size larger than 255, it can be
>          put into BSS.
>
> 2019-04-13  Thomas Koenig  <tkoe...@gcc.gnu.org>
>
>          PR fortran/84487
>          * gfortran.dg/def_init_1.f90: New test.
>
>

Attachment: p
Description: Binary data

Reply via email to