Michael Matz wrote:
> bss _sections_ != bss-like segments in the executable. Targets might not
> have a bss section that could be named in the asm file, or no way to
> switch to it without disrupting surrounding code, but they might have
> common symbols, which ultimately might or might not be
Hi,
On Tue, 21 Nov 2017, Richard Biener wrote:
> > That would be a simple oversight then. That's one of the nice things
> > with common symbols, they contain their own alignment which you can
> > freely adjust, you don't have to care for something like section
> > alignment.
>
> You can't be
On Mon, Nov 20, 2017 at 11:00 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 20 Nov 2017, Richard Biener wrote:
>
>> Also we cannot raise alignment of commons and thus vectorization is
>> pessimized (all vectorizer testcases use - fno-common).
>
> That would be a simple oversight then. That's one of t
> There is one use in Ada which looks like an optimization for specific
> targets:
>
> /* Ada doesn't feature Fortran-like COMMON variables so we shouldn't
> try to fiddle with DECL_COMMON. However, on platforms that don't
> support global BSS sections, uninitialized global variables
Hi,
On Mon, 20 Nov 2017, Richard Biener wrote:
> Also we cannot raise alignment of commons and thus vectorization is
> pessimized (all vectorizer testcases use - fno-common).
That would be a simple oversight then. That's one of the nice things with
common symbols, they contain their own align
Hi,
On Mon, 20 Nov 2017, Sandra Loosemore wrote:
> > I have a hard time imaging that, so can you give details? FWIW I've
> > personally always considered using common symbols nicer.
>
> The optimization case I'm familiar with is for targets that support -G
> and GP-relative addressing modes t
On November 20, 2017 9:02:55 PM GMT+01:00, Sandra Loosemore
wrote:
>On 11/20/2017 10:34 AM, Michael Matz wrote:
>> What's your rationale for changing this? In your initial mail you
>said:
>>
>> "On many targets this means global variable accesses having an
>unnecessary
>> codesize and performan
On 11/20/2017 10:34 AM, Michael Matz wrote:
What's your rationale for changing this? In your initial mail you said:
"On many targets this means global variable accesses having an unnecessary
codesize and performance penalty in C code (the same source generates
better code when built as C++)."
Hi,
On Mon, 20 Nov 2017, Wilco Dijkstra wrote:
> > Note you have to make sure GFortran still works! So I think the patch
> > should be changed to make the default behavior be frontend dependent
> > or have a fortran/ adjustment that fixes things up for the fortran
> > dialects that need it.
>
Richard Biener wrote:
> A target specific default might be a good idea if we decide to revert.
>
> Note I proposed this change a few times already, but the fear was always
> we'll break too much legacy code.
It will definitely break some code, but new warnings with -Werror might too...
> Note y
On Sun, Nov 19, 2017 at 2:48 AM, Sandra Loosemore
wrote:
> On 11/17/2017 12:12 PM, Wilco Dijkstra wrote:
>>
>> GCC currently defaults to -fcommon. This is an optional C feature dating
>> back to early C implementations. On many targets this means global
>> variable
>> accesses having an unnecess
On 11/17/2017 12:12 PM, Wilco Dijkstra wrote:
GCC currently defaults to -fcommon. This is an optional C feature dating
back to early C implementations. On many targets this means global variable
accesses having an unnecessary codesize and performance penalty in C code
(the same source generates
On 11/17/2017 12:12 PM, Wilco Dijkstra wrote:
> GCC currently defaults to -fcommon. This is an optional C feature dating
> back to early C implementations. On many targets this means global variable
> accesses having an unnecessary codesize and performance penalty in C code
> (the same source gen
13 matches
Mail list logo
