On 21 Jan 2015, at 06:53, Navdeep Parhar <n...@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 <da...@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.

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

-Dimitry

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to