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

[Navdeep Parhar]

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).

Regards,
Navdeep