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>