On 11/11/2013 11:57 PM, Richard Biener wrote: > On Mon, Nov 11, 2013 at 2:39 PM, Jakub Jelinek <ja...@redhat.com> wrote: >> On Mon, Nov 11, 2013 at 02:13:24PM +0100, Richard Biener wrote: >>> On Mon, Nov 11, 2013 at 12:39 PM, Jakub Jelinek <ja...@redhat.com> wrote: >>>> On Mon, Nov 11, 2013 at 12:29:29PM +0100, Richard Biener wrote: >>>>> On Fri, Nov 8, 2013 at 6:51 PM, Hendrik Greving >>>>> <hendrik.greving.in...@gmail.com> wrote: >>>>>> That didn't do it. What was the rationale w.r.t. to the relation >>>>>> between the vectorized sequenced and/or the alignment (I think these >>>>>> things are actually 2 separate things..) and the common block?! >>>>> >>>>> We cannot adjust the alignment of a common block as we don't know >>>>> which common block the linker will pick in the end. We can (and do) >>>>> adjust the alignment of global variables though. And C++ defaults >>>>> to -fno-common. >>>>> >>>>> In general when asking optimization questions it helps to provide >>>>> a testcase that can be compiled - otherwise you just provoke >>>>> random guesses (like mine) ;) >>>> >>>> Well, we had the discussion about turning -fno-common by default for C as >>>> well, I think it wouldn't hurt and let people use -fcommon if they need it. >>> >>> Yeah, so ... shall we just do it? Maybe just for a selected set of >>> targets (based on OS?)? >> >> I vote for it. Perhaps with the exception when the variables are also weak, >> this worst case results in a link time failure which is easily fixable by >> adding -fcommon where really required, and in the usual case (dynamic >> linking) it is limited to the each package individually, if we document this >> in porting_to.html, I think changing the default is fine. >> >> But I guess it would be nice to hear more voices. > > Most fallout will be from headers that fail to declare variables > as 'extern' (IIRC SPEC CPU 2000 has tons of that). It also > hides bugs where one unit has 'int x' and one 'float x' (SPEC CPU 2006, > LTO diagnoses this).
It's for reasons like this that I'd not be especially comfortable changing the default of -fcommon for c89 (or gnu89, our default). I think we'd be ok changing the default for c99+, as that implies a certain "recentness" about the program under compilation, which to me implies they ought to know better. > > I suppose targets without .bss section support should not switch > (that is, targets not defining BSS_SECTION_ASM_OP or > ASM_OUTPUT_ALIGNED_BSS). Good point. I don't expect that we have many of those left, but if any do still exist... r~
