svn commit: r276485 - in head/sys: conf dev/cxgbe modules/cxgbe/if_cxgbe

[Navdeep Parhar]

On Wed, Jan 21, 2015 at 09:00:03AM +0100, Dimitry Andric wrote:
> On 21 Jan 2015, at 06:53, Navdeep Parhar <np at FreeBSD.org> wrote:
> > 
> > On Tue, Jan 20, 2015 at 10:36:16PM -0500, Pedro Giffuni wrote:
> >> 
> >> On 01/20/15 22:06, Adrian Chadd wrote:
> >>> On 20 January 2015 at 18:19, Alexey Dokuchaev <danfe at freebsd.org> wrote:
> >>>> On Tue, Jan 20, 2015 at 07:50:23PM -0500, Pedro Giffuni wrote:
> >>>>> But the fix is rather ugly, isn't it? I would personally prefer to just
> >>>>> kill the older gcc but in the meantime updating it so that it behaves
> >>>>> like the updated gcc/clang would be better. IMHO.
> >>>> Seconded.  Putting extra harness on the code to avoid bugs in the compiler
> >>>> that were actually fixed upsteam is totally bogus.
> >>> Right, but:
> >>> 
> >>> * not all of us work on compilers;
> >>> * not all of us want to currently be working on compilers;
> >>> * some of us have to use the gcc that's in tree;
> >>> * .. and apparently updating that gcc to something > 4.2 is verboten.
> >> 
> >> The external toolchain can't be that bad(?).
> >> 
> >>> So if someone wants to help Navdeep by backporting those options,
> >> 
> >> Hmm .. didn't I post a patch?
> >> 
> >>> please do. I bet he'd love the help.
> >>> 
> >> Ugh he doesn't and TBH, I don't care enough to look for
> >> consensus either.
> > 
> > Let's please just move on from this discussion then.  I am not familiar
> > with gcc internals so I can't vouch for this patch, and gcc is the
> > default compiler on platforms that I cannot test.  Given that, it would
> > be reckless of me to push a gcc patch just to get it to play nice with
> > one single file in the tree.  High risk, little reward (given that
> > -fms-extensions can be applied to just the file in question without
> > disturbing anything else in the tree).
> 
> Alternatively, just use the ${GCC_MS_EXTENSIONS} Makefile macro, which
> I specifically introduced for this issue.

Ah, a rose with another name.  I'm happy to use this but it's not clear why
there is a GCC in the macro's name when clang deals with -fms-extensions
just as well.  (It's not even clear why the longer ${GCC_MS_EXTENSIONS}
should be preferred to -fms-extentions.  Isn't this like #define ONE 1 ?)

In any case I'm perfectly fine with any change that doesn't involve a commit
from me to gcc.

Regards,
Navdeep

> 
> See e.g. sys/modules/ibcore/Makefile for an example.
> 
> -Dimitry
>