#
272461 |
|
02-Oct-2014 |
gjb |
Copy stable/10@r272459 to releng/10.1 as part of the 10.1-RELEASE process.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
263763 |
|
26-Mar-2014 |
dim |
MFC r262613:
Merge the projects/clang-sparc64 branch back to head. This brings in several updates from the llvm and clang trunks to make the sparc64 backend fully functional.
Apart from one patch to sys/sparc64/include/pcpu.h which is still under discussion, this makes it possible to let clang fully build world and kernel for sparc64.
Any assistance with testing this on actual sparc64 hardware is greatly appreciated, as there will unavoidably be bugs left.
Many thanks go to Roman Divacky for his upstream work on getting the sparc64 backend into shape.
MFC r262985:
Repair a few minor mismerges from r262261 in the clang-sparc64 project branch. This is also to minimize differences with upstream.
|
#
263508 |
|
21-Mar-2014 |
dim |
MFC 261991:
Upgrade our copy of llvm/clang to 3.4 release. This version supports all of the features in the current working draft of the upcoming C++ standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The PowerPC backend has made several major improvements to code generation quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ backends have all seen major feature work.
Release notes for llvm and clang can be found here: <http://llvm.org/releases/3.4/docs/ReleaseNotes.html> <http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC 262121 (by emaste):
Update lldb for clang/llvm 3.4 import
This commit largely restores the lldb source to the upstream r196259 snapshot with the addition of threaded inferior support and a few bug fixes.
Specific upstream lldb revisions restored include: SVN git 181387 779e6ac 181703 7bef4e2 182099 b31044e 182650 f2dcf35 182683 0d91b80 183862 15c1774 183929 99447a6 184177 0b2934b 184948 4dc3761 184954 007e7bc 186990 eebd175
Sponsored by: DARPA, AFRL
MFC 262186 (by emaste):
Fix mismerge in r262121
A break statement was lost in the merge. The error had no functional impact, but restore it to reduce the diff against upstream.
MFC 262303:
Pull in r197521 from upstream clang trunk (by rdivacky):
Use the integrated assembler by default on FreeBSD/ppc and ppc64.
Requested by: jhibbits
MFC 262611:
Pull in r196874 from upstream llvm trunk:
Fix a crash that occurs when PWD is invalid.
MCJIT needs to be able to run in hostile environments, even when PWD is invalid. There's no need to crash MCJIT in this case.
The obvious fix is to simply leave MCContext's CompilationDir empty when PWD can't be determined. This way, MCJIT clients, and other clients that link with LLVM don't need a valid working directory.
If we do want to guarantee valid CompilationDir, that should be done only for clients of getCompilationDir(). This is as simple as checking for an empty string.
The only current use of getCompilationDir is EmitGenDwarfInfo, which won't conceivably run with an invalid working dir. However, in the purely hypothetically and untestable case that this happens, the AT_comp_dir will be omitted from the compilation_unit DIE.
This should help fix assertions occurring with ports-mgmt/tinderbox, when it is using jails, and sometimes invalidates clang's current working directory.
Reported by: decke
MFC 262809:
Pull in r203007 from upstream clang trunk:
Don't produce an alias between destructors with different calling conventions.
Fixes pr19007.
(Please note that is an LLVM PR identifier, not a FreeBSD one.)
This should fix Firefox and/or libxul crashes (due to problems with regparm/stdcall calling conventions) on i386.
Reported by: multiple users on freebsd-current PR: bin/187103
MFC 263048:
Repair recognition of "CC" as an alias for the C++ compiler, since it was silently broken by upstream for a Windows-specific use-case.
Apparently some versions of CMake still rely on this archaic feature...
Reported by: rakuco
MFC 263049:
Garbage collect the old way of adding the libstdc++ include directories in clang's InitHeaderSearch.cpp. This has been superseded by David Chisnall's commit in r255321.
Moreover, if libc++ is used, the libstdc++ include directories should not be in the search path at all. These directories are now only used if you pass -stdlib=libstdc++.
|
#
262964 |
|
09-Mar-2014 |
ache |
MFC r262689:
Add fetch and patch to .PHONY and .NOTMAIN only if PORTNAME is defined. Unconditional addition cause real fetch(1) and patch(1) programs are builded every time.
|
#
262459 |
|
24-Feb-2014 |
dim |
MFC r262310:
Move the part in bsd.own.mk that sets -Wno-c++11-extensions for clang to bsd.sys.mk, where it really belongs. This also causes the flag to get added when clang is *not* the default system compiler, but is still used, e.g. by setting WITH_CLANG_IS_CC manually.
|
#
260495 |
|
09-Jan-2014 |
dim |
MFC r260102:
Similar to r260020, only use -fms-extensions with gcc, for all other modules which require this flag to compile. Use a GCC_MS_EXTENSIONS variable, defined in kern.pre.mk, which can be used to easily supply the flag (or not), depending on the compiler type.
MFC r260322:
In addition to r260102, also define GCC_MS_EXTENSIONS in bsd.sys.mk, since kernel module builds do not use kern.pre.mk.
|
#
260096 |
|
30-Dec-2013 |
dim |
MFC r257532 (by adrian):
Fix this build for clang.
MFC r259730:
To avoid having to explicitly test COMPILER_TYPE for setting clang-specific or gcc-specific flags, introduce the following new variables for use in Makefiles:
CFLAGS.clang CFLAGS.gcc CXXFLAGS.clang CXXFLAGS.gcc
In bsd.sys.mk, these get appended to the regular CFLAGS or CXXFLAGS for the right compiler.
MFC r259913:
For libstand and sys/boot, split off gcc-only flags into CFLAGS.gcc.
MFC r259927:
Fix pc98 build, by also forcing COMPILER_TYPE in sys/boot/pc98/boot2's Makefile.
Pointy hat to: dim
|
#
259158 |
|
10-Dec-2013 |
dim |
MFC r259083:
For WARNS <= 3, change the clang warning flag -Wno-conversion to -Wno-enum-conversion. In earlier clang versions (before 3.2), the latter did not exist, and suppressing enum conversion warnings was really the goal of this warning suppression flag.
This should enable the same kind of warning again as was fixed by r259072 ("incompatible integer to pointer conversion passing 'Elf_Addr' (aka 'unsigned int') to parameter of type 'void *'"), and which was only emitted by gcc.
Noticed by: kib
|
#
256281 |
|
10-Oct-2013 |
gjb |
Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
|
#
249657 |
|
19-Apr-2013 |
ed |
Add the Clang specific -Wmissing-variable-declarations to WARNS=6.
This compiler flag enforces that that people either mark variables static or use an external declarations for the variable, similar to how -Wmissing-prototypes works for functions.
Due to the fact that Yacc/Lex generate code that cannot trivially be changed to not warn because of this (lots of yy* variables), add a NO_WMISSING_VARIABLE_DECLARATIONS that can be used to turn off this specific compiler warning.
Announced on: toolchain@
|
#
246880 |
|
16-Feb-2013 |
dim |
Since clang 3.2 now has an option to suppress warnings about implicitly promoted K&R parameters, remove the workarounds added for sendmail components in r228558.
MFC after: 1 week
|
#
241298 |
|
06-Oct-2012 |
marcel |
Add support for bmake. This includes: 1. Don't do upgrade_checks when using bmake. As long as we have WITH_BMAKE, there's a bootstrap complication in ths respect. Avoid it. Make the necessary changes to have upgrade_checks work wth bmake anyway. 2. Remove the use of -E. It's not needed in our build because we use ?= for the respective variables, which means that we'll take the environment value (if any) anyway. 3. Properly declare phony targets as phony as bmake is a lot smarter (and thus agressive) about build avoidance. 4. Make sure CLEANFILES is complete and use it on .NOPATH. bmake is a lot smarter about build avoidance and should not find files we generate in the source tree. We should not have files in the repository we want to generate, but this is an easier way to cross this hurdle. 5. Have behavior under bmake the same as it is under make with respect to halting when sub-commands fail. Add "set -e" to compound commands so that bmake is informed when sub-commands fail. 6. Make sure crunchgen uses the same make as the rest of the build. This is important when the make utility isn't called make (but bmake for example). 7. While here, add support for using MAKEOBJDIR to set the object tree location. It's the second alternative bmake looks for when determining the actual object directory (= .OBJDIR).
Submitted by: Simon Gerraty <sjg@juniper.net> Submitted by: John Van Horne <jvanhorne@juniper.net>
|
#
240468 |
|
13-Sep-2012 |
brooks |
Introduce a new make variable COMPILER_TYPE that specifies what type of compiler is being used (currently clang or gcc). COMPILER_TYPE is set in the new bsd.compiler.mk file based on the value of the CC variable or, should it prove informative, by running ${CC} --version and examining the output.
To avoid negative performance impacts in the default case and correct value for COMPILER_TYPE type is determined and passed in the environment of submake instances while building world.
Replace adhoc attempts at determining the compiler type by examining CC or MK_CLANG_IS_CC with checks of COMPILER_TYPE. This eliminates bootstrapping complications when first setting WITH_CLANG_IS_CC.
Sponsored by: DARPA, AFRL Reviewed by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>, imp, linimon (with some modifications post review) MFC after: 2 weeks
|
#
236528 |
|
03-Jun-2012 |
dim |
During buildworld and buildkernel, define EARLY_BUILD in the earlier stages (build-tools, cross-tools, etc) of the build, so we can detect in bsd.*.mk whether to pass compiler-specific flags to ${CC}.
In particular, this commit will allow using WITH_CLANG_IS_CC when the base compiler is still gcc, and when ${CC}, ${CXX} and ${CPP} are left at their defaults. The early stages will then be built using gcc, and no clang-specific flags will be passed to it. The later stages will be built as usual.
The EARLY_BUILD define can also serve other uses, such as building the world stage C++ executables with libc++ instead of libstdc++: during the early build stages, we cannot assume libc++ is already available, so we must still build with libstdc++ at that time.
MFC after: 1 week
|
#
234353 |
|
16-Apr-2012 |
dim |
Upgrade our copy of llvm/clang to trunk r154661, in preparation of the upcoming 3.1 release (expected in a few weeks). Preliminary release notes can be found at: <http://llvm.org/docs/ReleaseNotes.html>
MFC after: 2 weeks
|
#
233052 |
|
16-Mar-2012 |
dim |
Change the style of share/mk/bsd.sys.mk to that of the other bsd.*.mk files, and style.Makefile(5), where applicable. While here, update the link to the gcc warning documentation.
No functional change.
MFC after: 1 week
|
#
232754 |
|
09-Mar-2012 |
jkim |
Make boot2 build with Clang again.
Submitted by: dim (bsd.sys.mk) Reviewed by: dim, jhb
|
#
232476 |
|
03-Mar-2012 |
dim |
Revert r232473. I have been convinced by Doug Barton and Bjoern Zeeb that it is better to error out when people attempt to build using the wrong bsd.*.mk files, than to silently ignore the problem.
This means, that after this commit, if you want to build kernel modules by hand (or via a port) from a head source tree, you *must* make sure the files in /usr/share/mk are in sync with that tree. If that isn't possible, for example when you are running on an older FreeBSD branch, you can:
- Run "make buildenv" from your head source tree, to have the correct environment setup. (It's advisable to have run "make buildworld", or at a minimum "make toolchain" first.) - Alternatively, set MAKESYSPATH to the share/mk directory under your head source tree. If your build tools are too old, other problems may still occur. - Alternatively, use "make -m" and specify the share/mk directory under your head source tree. Again, build tools that are too old may still result in trouble.
MFC after: 2 weeks
|
#
232473 |
|
03-Mar-2012 |
dim |
After r232322, it turned out many people (and some ports) are building kernel modules using their old installed /usr/share/mk/bsd.*.mk files, instead of the updated ones in their source tree. This leads to errors like:
"sys/conf/kmod.mk", line 111: Malformed conditional (${MK_CLANG_IS_CC} == "no" && ${CC:T:Mclang} != "clang")
Obviously, these errors will go away after a "make installworld", or alternatively, by using "make buildenv" before attempting to manually build modules.
However, since it is apparently an expected use case to build using old .mk files, change the way we test for clang, so it also works when the MK_CLANG_IS_CC macro doesn't exist.
Note the conditional expressions are becoming rather unreadable now, but I will attempt to fix that on a followup commit.
MFC after: 2 weeks
|
#
232322 |
|
29-Feb-2012 |
dim |
Add a WITH_CLANG_IS_CC option for src.conf(5), disabled by default, that installs clang as /usr/bin/cc, /usr/bin/c++ and /usr/bin/cpp.
Note this does *not* disable building and installing gcc, which will still be available as /usr/bin/gcc, /usr/bin/g++ and /usr/bin/gcpp. If you want to disable gcc completely, you must use WITHOUT_GCC.
MFC after: 2 weeks
|
#
232263 |
|
28-Feb-2012 |
dim |
Define several extra macros in bsd.sys.mk and sys/conf/kern.pre.mk, to get rid of testing explicitly for clang (using ${CC:T:Mclang}) in individual Makefiles.
Instead, use the following extra macros, for use with clang: - NO_WERROR.clang (disables -Werror) - NO_WCAST_ALIGN.clang (disables -Wcast-align) - NO_WFORMAT.clang (disables -Wformat and friends) - CLANG_NO_IAS (disables integrated assembler) - CLANG_OPT_SMALL (adds flags for extra small size optimizations)
As a side effect, this enables setting CC/CXX/CPP in src.conf instead of make.conf! For clang, use the following:
CC=clang CXX=clang++ CPP=clang-cpp
MFC after: 2 weeks
|
#
228677 |
|
17-Dec-2011 |
dim |
Disable another clang warning (-Wempty-body) when WARNS <= 2.
MFC after: 1 week
|
#
228675 |
|
17-Dec-2011 |
dim |
Disable yet another clang warning (-Wconversion) when WARNS <= 3.
MFC after: 1 week
|
#
228617 |
|
17-Dec-2011 |
dim |
Disable yet another clang warning when WARNS <= 3.
MFC after: 1 week
|
#
228606 |
|
16-Dec-2011 |
dim |
Add a NO_WARRAY_BOUNDS setting to bsd.sys.mk, only applicable to clang, to selectively work around warnings in programs that don't use flexible array members, but instead define arrays of length 1 at the end of the struct, and then access those beyond their declared bounds.
MFC after: 1 week
|
#
228551 |
|
15-Dec-2011 |
dim |
Disable one more clang warning when WARNS <= 3.
MFC after: 1 week
|
#
228546 |
|
15-Dec-2011 |
dim |
Clang has more warnings enabled by default, and when using -Wall, so if WARNS is set to low values, some of them have to be disabled explicitly.
MFC after: 1 week
|
#
220863 |
|
19-Apr-2011 |
dim |
Remove support for the Intel C Compiler from the build infrastructure. This support has not worked for several years, and is not likely to work again, unless Intel decides to release a native FreeBSD version of their compiler. ;)
|
#
219368 |
|
07-Mar-2011 |
pjd |
To be able to use printf extensions we need to turn off gcc format checking. Following the convention of NO_WERROR and NO_WCAST_ALIGN add NO_WFORMAT, which, when defined in Makefile, turns off compile-time format checking (by adding -Wno-format), but still allows to use high WARNS level.
MFC after: 2 weeks
|
#
211725 |
|
23-Aug-2010 |
imp |
MFtbemd:
Prefer MACHNE_CPUARCH to MACHINE_ARCH in most contexts where you want to test of all the CPUs of a given family conform.
|
#
211437 |
|
17-Aug-2010 |
rpaulo |
For every instance of '.if ${CC} == "foo"' or '.if ${CC} != "foo"' in Makefiles or *.mk files, use ${CC:T:Mfoo} instead, so only the basename of the compiler command (excluding any arguments) is considered.
This allows you to use, for example, CC="/nondefault/path/clang -xxx", and still have the various tests in bsd.*.mk identify your compiler as clang correctly.
ICC if cases were also changed.
Submitted by: Dimitry Andric <dimitry at andric.com>
|
#
204025 |
|
18-Feb-2010 |
marcel |
Allow suppression of -Wcast-align for WARNS>=4 by defining NO_WCAST_ALIGN. The headers of the standard C++ library are not 64-bit clean and trigger the warning. This prevents use of WARNS>=4 on ia64 for example.
|
#
202596 |
|
18-Jan-2010 |
trasz |
Undo r169961, removing WITH_GCC3, added as a temporary workaround three years ago.
|
#
201300 |
|
30-Dec-2009 |
ed |
Disable K&R style function definitions for WARNS=6.
Unfortunately there are two slight problems with that:
- Yacc and lex might generate code that generates warnings because of this. Require yacc and lex to be rebuilt during bootstrap. I'm not incrementing __FreeBSD_version here, because I assume someone else will do this eventually.
- When running `make buildkernel', it uses share/mk from the source treeo to build aicasm. Because aicasm also depends on lex, this would break. Lower WARNS to 5 for now. We should just increment it to 6 again somewhere in the very far future.
|
#
198365 |
|
22-Oct-2009 |
ru |
Unbreak NO_WARNS, keeping CSTD effect on CFLAGS out of its control. Unbreak compiles with icc.
|
#
198335 |
|
21-Oct-2009 |
rdivacky |
Set CSTD in all cases except when CC=icc and NO_WARNS is set. This way we can set desired C standard even for cross tools etc.
Tested by: make universe Approved by: ed (maintainer) OK by: das
|
#
189801 |
|
14-Mar-2009 |
rdivacky |
Switch over to gnu99 compilation on default for userland.
Tested by: make universe Tested by: ports exp build (done by pav) Reviewed by: ru Reviewed by: silence on arch Approved by: ed (mentor)
|
#
180731 |
|
23-Jul-2008 |
imp |
Turn of SSP for mips for now until support is added to the base architecture.
|
#
180605 |
|
18-Jul-2008 |
cognet |
Disable SSP on arm for the time being. The segfaults when using SSP seem to be a gcc bug, a patch is available in the gcc bugzilla, and will be imported once it's committed into the official gcc tree.
|
#
180012 |
|
25-Jun-2008 |
ru |
Enable GCC stack protection (aka Propolice) for userland: - It is opt-out for now so as to give it maximum testing, but it may be turned opt-in for stable branches depending on the consensus. You can turn it off with WITHOUT_SSP. - WITHOUT_SSP was previously used to disable the build of GNU libssp. It is harmless to steal the knob as SSP symbols have been provided by libc for a long time, GNU libssp should not have been much used. - SSP is disabled in a few corners such as system bootstrap programs (sys/boot), process bootstrap code (rtld, csu) and SSP symbols themselves. - It should be safe to use -fstack-protector-all to build world, however libc will be automatically downgraded to -fstack-protector because it breaks rtld otherwise. - This option is unavailable on ia64.
Enable GCC stack protection (aka Propolice) for kernel: - It is opt-out for now so as to give it maximum testing. - Do not compile your kernel with -fstack-protector-all, it won't work.
Submitted by: Jeremie Le Hen <jeremie@le-hen.org>
|
#
173850 |
|
22-Nov-2007 |
jb |
Re-enable -Werror again.
This time, change the default CFLAGS to match the simple defaults that the tinderboxes use. That is, don't use -fno-strict-aliasing by default.
My last attempt to re-anable -Werror gave me a lesson in what strict aliasing is all about. There was code in libthr that wasn't 64-bit clean. The default use of -fno-strict-aliasing hid that.
By using -fno-strict-aliasing by default we were choosing to ignore problems in code which had the potential to shoot ourselves in the foot. Sometimes it would be the 64-bit foot. I have both feet. The left ones are 32 bits and the right ones are 64 bits. Don't ask about my endian orientation. :-)
The -fno-strict-aliasing compiler arg can still be used if NO_STRING_ALIASING is define in make.
We are early in the FreeBSD 8 development, so we have the opportunity to wait and see if this works for us. I am sure that people will complain. We can easily revert this. All I ask is that we take sides: clean code or not. YMMV.
Note that by using -fno-strict-aliasing the build won't actually break. Only where WARNS is set (and -Werror is used) will a compiler warning break the build. The use of WARNS levels implies (to me at least) that the developer has taken some care to make the code pass basic checks. This commit makes those checks just a little bit more strict.
|
#
173758 |
|
19-Nov-2007 |
jb |
Unfortunately the tinderbox setup uses custom CFLAGS which are a big obstacle to enabling -Werror. I'll continue to work on cleaning up the code so that we can keep this enabled.
If the tinderboxes would just use the default CFLAGS set in this file, all would be fine and we'd be able to make use of -Werror.
|
#
173748 |
|
19-Nov-2007 |
jb |
Re-enable -Werror ins WARNS as it was roughly 6 months ago before being disabled while gcc 4.2 was bedded in.
Tested with 'make release' (amd64 arm i386 ia64 pc98 powerpc sparc64 sun4v)
|
#
169961 |
|
24-May-2007 |
obrien |
Temporarily add 'WITH_GCC3' that removes -Wno-pointer-sign from the compiler invocation. This is just to help get over the hump of people tracking down bugs that may cross the GCC 4.2 upgrade. It is envisioned that this option goes away after a suitable amount of time.
|
#
169723 |
|
19-May-2007 |
kan |
Universally disable -Werror until src/ is in better shape for GCC 4.2. There are new warnings that kill the build otherwise.
Disable pointer destination sign mismatch warning alltogether. Our tree is in no shape to have that enabled yet.
|
#
163971 |
|
04-Nov-2006 |
jb |
Allow a makefile to set IGNORE_PRAGMA so that OpenSolaris code can be built with other gcc warnings enabled.
Every Solaris source file has a #pragma ident in it. We can just ignore those definitions.
|
#
161214 |
|
11-Aug-2006 |
des |
Reintroduce CSTD, which allows a Makefile to specify the precise dialect of C in which the program or library is written.
Note that this is *not* intended to be used across the whole tree. It is intended to be used for individual libraries or programs which use specific language features which the compiler must know about in order to produce correct warnings at high WARNS levels.
MFC after: 1 month
|
#
140361 |
|
16-Jan-2005 |
obrien |
Move -Wunused-parameter from WARNS level 3 level 4.
Also break long lines -- note that the '\' must be up against the last character of a line to keep command-line spacing proper.
Requested by: rwatson
|
#
140359 |
|
16-Jan-2005 |
obrien |
Use >= so we can use the actual WARNS levels.
|
#
126890 |
|
12-Mar-2004 |
trhodes |
This are the build infrastructure changes to allow to use the Intel C/C++ compiler (lang/icc) to build the kernel.
The icc CPUTYPE CFLAGS use icc v7 syntax, icc v8 moans about them, but doesn't abort. They also produce CPU specific code (new instructions of the CPU, not only CPU specific scheduling), so if you get coredumps with signal 4 (SIGILL, illegal instruction) you've used the wrong CPUTYPE.
Incarnations of this patch survive gcc compiles and my make universe. I use it on my desktop.
To use it update share/mk, add /usr/local/intel/compiler70/ia32/bin (icc v7, works) or /usr/local/intel_cc_80/bin (icc v8, doesn't work) to your PATH, make sure you have a new kernel compile directory (e.g. MYKERNEL_icc) and run CFLAGS="-O2 -ip" CC=icc make depend CFLAGS="-O2 -ip" CC=icc make in it.
Don't compile with -ipo, the build infrastructure uses ld directly to link the kernel and the modules, but -ipo needs the link step to be performed with Intel's linker.
Problems with icc v8: - panic: npx0 cannot be emulated on an SMP system - UP: first start of /bin/sh results in a FP exception
Parts of this commit contains suggestions or submissions from Marius Strobl <marius@alchemy.franken.de>.
Reviewed by: silence on -arch Submitted by: netchild
|
#
125884 |
|
16-Feb-2004 |
des |
Remove -Wbad-function-cast. Its main purpose is to catch bugs that we already catch with -Wstrict-prototypes, and it causes spurious warnings for some perfectly legitimate constructs.
|
#
124372 |
|
11-Jan-2004 |
ru |
Put the warning flags to where they belong (into CWARNFLAGS). This allows us to easily override them when necessary, e.g., to selectively disable warnings in libc/ contributed sources.
|
#
116342 |
|
14-Jun-2003 |
imp |
Put on the core hat and back out all of the CSTD= changes. Core will deal with working with the parties to define a coherent definition for CSTD that doesn't break things.
Core hat seconded by: markm
|
#
116330 |
|
14-Jun-2003 |
des |
Revert to a known-good state. Anyone desiring to experiment with stricter global settings is free to do so in his or her own source tree.
|
#
116316 |
|
13-Jun-2003 |
peter |
We cannot use c99 on amd64 either due to lack of alloca(). libc:strptime() uses alloca() and alloca is impossible to implement as a callable function on amd64. It has to be a compiler builtin. Note that the bigger problem is that libc is not c99 clean internally.
|
#
115942 |
|
07-Jun-2003 |
obrien |
Be C std strict on i386 and amd64 as we can. Be loose on Alpha and ia64.
|
#
115902 |
|
06-Jun-2003 |
obrien |
Compile our code as C99 w/GNU extensions by default. We can't use straight "c99" due to the lack of alloca.S for non-i386 platforms.
|
#
115687 |
|
02-Jun-2003 |
obrien |
[rev 1.26 log cont.] I got a bazaar bug report after someone did several back to back 'make worlds'. I'm not sure how compiling /usr/src as C99 would cause this, but be cautious and affective go back to previous state until I can look into it.
|
#
115686 |
|
02-Jun-2003 |
obrien |
I got a bazzar bug report
|
#
115682 |
|
02-Jun-2003 |
obrien |
Turn back on c99, the tree should be ready for it now.
|
#
115661 |
|
01-Jun-2003 |
obrien |
To quote Tony Maher <tonymaher@optushome.com.au>, "maybe 3rd time lucky ;-)" *sigh* Just can't get a brake when trying to react too quickly and fix the build.
|
#
115656 |
|
01-Jun-2003 |
obrien |
Temperarly turn off building the tree with c99. I swore this made it thru a 'make world', but I don't know what happened.
|
#
115645 |
|
01-Jun-2003 |
obrien |
Use a bigger hammer -- keep all -std= out of CXXFLAGS. Also allow for "CSTD=" in a Makefile.
|
#
115640 |
|
01-Jun-2003 |
obrien |
Do not set a C standard for the C++ compiler.
|
#
115629 |
|
01-Jun-2003 |
obrien |
Compile our code as C99 by default.
|
#
115455 |
|
31-May-2003 |
obrien |
CSTD is virtually worthless for WARNS=2-5. Return -pedantic to WARNS=6+.
|
#
115453 |
|
31-May-2003 |
obrien |
Make CSTD style match the rest of file.
|
#
114752 |
|
05-May-2003 |
des |
Whitespace cleanup (1.15 had spaces instead of tabs)
|
#
114751 |
|
05-May-2003 |
des |
Don't use -pedantic unless we also set -std of some kind.
|
#
114419 |
|
01-May-2003 |
des |
Add a mechanism to allow Makefiles to specify the particular C dialect in which the source code is written. This is controlled by the CSTD variable, which can have one of the following values:
- "k&r" => -traditional - "c89" or "c90" => -std=iso9899:1990 - "c94" or "c95" => -std=iso9899:199409 - "c99" => -std=iso9899:1999
The corresponding option is added to CFLAGS regardless of WARNS level. This also removes -ansi from WARNS level 6, but adds -Wno-long-long to work around a weird gcc bug (-ansi, which is supposedly equivalent to -std=iso9899:1990, seems to turn long long warnings off instead of on)
If CSTD is undefined, CFLAGS are unchanged except for the -ansi / -Wno-long-long change mentioned above for WARNS level 6.
|
#
113136 |
|
05-Apr-2003 |
imp |
Migrate to a new way of dealing with building from old revisions of FreeBSD. This method attempts to centralize all the necessary hacks or work arounds in one of two places in the tree (src/Makefile.inc1 and src/tools/build). We build a small compatibility library (libbuild.a) as well as selectively installing necessary include files. We then include this directory when building host binaries.
This removes all the past release compatibilty hacks from various places in the tree. We still build on tip of stable and current. I will work with those that want to support more, although I anticipate it will just work.
Many thanks to ru@, obrien@ and jhb@ for providing valuable input at various stage of implementation, as well as for working together to positively effect a change for the better.
|
#
113066 |
|
04-Apr-2003 |
ru |
-Wall implies -Wuninitialized if -O is also in effect. -Wuninitialized does not work without -O.
This fixes the ${WARNS} > 4 compilations with -O0.
Spotted by: marcel
|
#
112869 |
|
31-Mar-2003 |
ru |
Enable cpp(1) warnings in system headers. GCC is oriented on glibc which is externally maintained, so GCC ships with these warnings turned off by default. This is also consistent with the src/contrib/gcc/c-lex.c,v 1.2 change.
|
#
106852 |
|
13-Nov-2002 |
ru |
Take __FreeBSD_version into account when BOOTSTRAPPING.
|
#
99542 |
|
07-Jul-2002 |
obrien |
Be more strict with WARNS now -- the GCC 3.1 turmoil is behind us.
|
#
96949 |
|
19-May-2002 |
obrien |
Tweak the WARNS levels a tad.
|
#
96316 |
|
09-May-2002 |
obrien |
Gcc 3.1 has different -Wx flags.
|
#
94332 |
|
10-Apr-2002 |
obrien |
Add WARNS levels 5 and 6: 5 gives us -Wuninitialized rather than -Wno-uninitialized 6 gives us full BDECFLAGS
|
#
94127 |
|
07-Apr-2002 |
ru |
FreeBSD prior to 4.5-RELEASE and older versions of 5.0-CURRENT do not have the __FBSDID() macro in <sys/cdefs.h>. Fix this once and for all for tools that need to be bootstrapped.
PR: bin/36747 MFC after: 3 days Prodded by: obrien
|
#
88936 |
|
05-Jan-2002 |
dwmalone |
Put -Wno-uninitialized at the end of the warns flags as it may be enabeled by several flags (in this case -W and -Wall).
Reviewed by: bde
|
#
87976 |
|
15-Dec-2001 |
obrien |
Add some granularity to the WARNS levels. 1: add -Werror 2: -Wall [only], as this is the most used warnings setting by developers 3: our old `1' 4: our old `2'
|
#
76863 |
|
19-May-2001 |
kris |
Only add -Werror if in fact we have set WARNS or WFORMAT to >0
|
#
76862 |
|
19-May-2001 |
kris |
(Previous commit was made prematurely before I could finish composing the log message)
Bring in the WARNS directive from NetBSD, localized in a new bsd.sys.mk to avoid polluting sys.mk. This directive controls the addition of compiler warning flags to CFLAGS in a relatively compiler-neutral manner.
The idea is that WARNS can be set in Makefile.inc or in individual Makefiles as they become clean, to prevent the introduction of new warnings in the code (-Werror is added by default when WARNS > 0).
This behaviour can be overridden with the following two knobs: NO_WARNS disables the checking of WARNS completely NO_WERROR disables the addition of -Werror to the flags.
Additionally, setting WFORMAT to 1 (in makefiles) and/or defining FORMAT_AUDIT (by the user) will enable increased checking of format string arguments.
Obtained from: NetBSD Reviewed by: peter
|
#
76861 |
|
19-May-2001 |
kris |
Bring in the WARNS directive from NetBSD, localized in a new bsd.sys.mk to avoid polluting sys.mk. This directive controls the addition of compiler warning flags to CFLAGS in a relatively compiler-neutral manner.
The idea is that WARNS can be set in Makefile.inc or in individual Makefiles as they become clean, to prevent the introduction of new warnings in the code. -Werror is added by default
|