Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Mar 2017 02:35:19 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Andriy Gapon <avg@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org,  svn-src-head@freebsd.org
Subject:   Re: svn commit: r315068 - head/sys/modules/qlxgbe
Message-ID:  <20170313020809.P31989@besplex.bde.org>
In-Reply-To: <18e52ee7-0b27-7aff-6b69-75b27673a8f4@FreeBSD.org>
References:  <201703111516.v2BFGtkn006959@repo.freebsd.org> <20170312124945.C4483@besplex.bde.org> <18e52ee7-0b27-7aff-6b69-75b27673a8f4@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Mar 2017, Andriy Gapon wrote:

> On 12/03/2017 04:44, Bruce Evans wrote:
>> On Sat, 11 Mar 2017, Andriy Gapon wrote:
>>
>>> Log:
>>>  revert r314862, use of GCC_MS_EXTENSIONS in qlxgbe
>>>
>>>  Commit r278913 made explicit use of GCC_MS_EXTENSIONS  unnecessary.
>>>
>>>  Requested by:    glebius
>>
>> Does this module actually use ms extensions?  This seems unlikely, since
>> only gcc supports them.
>
> It probably doesn't.
>
>> My kernels compile correctly with the correct CFLAGS (gcc -std=gnu99
>> -fno-ms-extensions).
>
> How did you manage to pass -std=gnu99 to the module build?

I edited kern.mk to change CSTD together with removing -fms-extensions.

> No matter what flags I tried to modify the actual compiler invocations still had
> -std=iso9899:1999 after -std=gnu99 in them, so my modifications had no effect.
> GCC_MS_EXTENSIONS was the easiest way to get the job done.

Hmm, more bugs:
- kern.mk forces its wrong CSTD using '='.  bsd.sys.mk uses '?=' as well
   as the correct CSTD.
- -fms-extensions is now hard-coded too.  However, it is a bit earlier in
   CFLAGS so might be easier to override.

Controlling the order of CFLAGS has always been a problem.  There are many
undocumented macros and it isn't clear which ones are implementation details.
Now I get -std second last and -Werror last CFLAGS.  -Werror is set by
WERROR?=, so WERROR can be used for overrides.  Overriding -std is accepted
and hopefully works.

WERROR is before PROF in NORMAL_C, but PROF is not in NORMAL_S or
PROFILE_C, so of you want to override PROF then you have to fix this
or duplicate the overrides in WERROR and PROF.

There are further problems with special rules.  The ones for aesni are
of nearly the lowest quality.  These ensure breaking gcc using the
order WERROR, NO_CAST_QUAL, PROF, then main unportable -m's (with at least
-msse4 unsupported by gcc-4.2.1), then .IMPSRC.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170313020809.P31989>