| Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
GCC_NO_FORMAT_TRUNCATION -Wno-format-truncation (GCC 7/8)
GCC_NO_STRINGOP_TRUNCATION -Wno-stringop-truncation (GCC 8)
GCC_NO_STRINGOP_OVERFLOW -Wno-stringop-overflow (GCC 8)
GCC_NO_CAST_FUNCTION_TYPE -Wno-cast-function-type (GCC 8)
use these to turn off warnings for most GCC-8 complaints. many
of these are false positives, most of the real bugs are already
commited, or are yet to come.
we plan to introduce versions of (some?) of these that use the
"-Wno-error=" form, which still displays the warnings but does
not make it an error, and all of the above will be re-considered
as either being "fix me" (warning still displayed) or "warning
is wrong."
|
|
- file has looks bogus maybe-uninitialized
- llvm triggers an attribute violation:
ScheduleDAGInstrs.cpp:1430:14: error: declaration of
'llvm::raw_ostream& llvm::operator<<(llvm::raw_ostream&, const llvm::ILPValue&)'
with attribute 'noinline' follows inline declaration [-Werror=attributes]
- ntp and pkg_install have obvious restrict violations, should be
fixed but i'm avoiding patching upstream code in this pass
- tftp has an array bounds that doesn't seem real issue
- sysinst's partman.c has major problem with passing the same
string as source and dest in snprintf, as a way to strcat
with formatting which trip restrict violations. non trivial
to fix so for now the warning is elided.
- Xext's XEVI.c has similar issue as partman.c
everyone and GCC 8 gets these warnings turned off for now:
-Wno-format-truncation
-Wno-stringop-overflow
-Wno-stringop-truncation
-Wno-cast-function-type
as they trip a large amount of code. most of them should be
investigated, but the few i looked at were not finding actually
real bugs, vs instances of poor coding, so skipping for now.
|
|
not just radeon. should fix build issues reported:
AArch64BaseInfo.h:297:12: fatal error:
AArch64GenSystemOperands.inc: No such file or directory
|
|
they're not linked into gallium, so avoid building them.
|
|
previously, this was attempting to emit x86 code on arm.
thanks joerg@ for pointing me in the right place.
|
|
|
|
|
|
Hook up AMDGPU backend for clang.
|
|
|
|
- only build clang or clang-tblgen if MKLLVMCMDS != "no"
- move HAVE_MESA_VER earlier so we can detect mesa 18 and enable
MKLLVM on platforms that need it
- move the clang commands and headers into llvmcmds group
- only build the clang specific LLVM libraries if MKLLVMCMDS != "no"
much of this work came from maya@'s github commit
f90685c11d4460d3098fa35f48b58d1893e974e0, reworked for HAVE_MESA_VER
and llvmcmds vs MKCLANG.
build tested on several platforms and on amd64 and i386 with several
different build options (clang build, gcc build, gcc build with llvm
libs).
|
|
|
|
touch the build. this comes from:
commit f90685c11d4460d3098fa35f48b58d1893e974e0
Author: Maya Rashish <maya@NetBSD.org>
Date: Sat Feb 23 09:46:14 2019 +0200
Separate MKCLANG from MKLLVM.
build LLVM libraries as PIC.
Add AMDGPU target, and adjust tools accordingly.
|
|
This avoids the need for a .WAIT here, and later makes it possible
for non-llvm things to not worry about llvm includes not being created
yet (as includes runs before a lot of other things)
suggested by mrg, build-tested by agc, thanks!
|
|
|
|
This is missing some generated files, llvm/include/IR/*.inc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
before the removal, updated to match current cmake.
|
|
|
|
|
|
|
|
|
|
NetBSD are driver logic for PIE linkage and a number of SPARC fixes.
|
|
|
|
|
|
|
|
|