On Mon, 8 Apr 2019, Richard Biener wrote:
> 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,
On Mon, Apr 8, 2019 at 11:33 AM Richard Biener
wrote:
>
> On Mon, Apr 8, 2019 at 10:38 AM Andrew Haley 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
On Mon, Apr 8, 2019 at 10:38 AM Andrew Haley 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 wil
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
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 :-)
Regards
On April 6, 2019 3:59:41 PM GMT+02:00, Thomas Koenig
wrote:
>Am 05.04.19 um 12:15 schrieb Richard Biener:
>
>> Putting readonly data into .rodata isn't required by the C standard I
>think
>> so we could freely choose .bss for data exceeding a reasonable
>> size limit.
>
>That would be the best so
Am 05.04.19 um 12:15 schrieb Richard Biener:
Putting readonly data into .rodata isn't required by the C standard I think
so we could freely choose .bss for data exceeding a reasonable
size limit.
That would be the best solution, I think.
IIRC GCC behaved one or another way in the past alread
On Thu, Apr 4, 2019 at 9:53 PM Thomas Koenig wrote:
>
> Hi Andreas,
>
> >> Well, nothing is going to write to it (this is not accessible by
> >> user code), so that should not be a problem.
> > Then don't make it read-only.
>
> I tried this, and while it solves the executable size problem, it
> ca
Hi Andreas,
Well, nothing is going to write to it (this is not accessible by
user code), so that should not be a problem.
Then don't make it read-only.
I tried this, and while it solves the executable size problem, it
causes an OpenMP regression (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?
On Apr 03 2019, Thomas Koenig wrote:
> Well, nothing is going to write to it (this is not accessible by
> user code), so that should not be a problem.
Then don't make it read-only.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780
Hi Andreas,
The large default initializers are all filled with zeros which end up in
the rodata section, like this:
... and so on. To reduce the size of the executable, it would make more
sense to put this into the BSS section.
Note that .bss is writable. There is no read-only bss section.
On Apr 03 2019, Thomas Koenig wrote:
> The large default initializers are all filled with zeros which end up in
> the rodata section, like this:
>
> .text
> .globl __types_module_MOD___def_init_types_module_Archive_type
> .section.rodata
> .align 32
>
Hi,
There is a large increase in rodata size for derived types in gfortran
starting with gcc 8 due to the presence of large initializers for
derived types. Among other things, this affects SPEC tonto (PR 84487),
but there are also other bug reports which mention this behavior.
The large default
13 matches
Mail list logo
