This seems to not actually have any function. The OpenCL API test
passes without it, and the way it's produced is problematic.
Change-Id: I384bfa01dee7023484348b184ddd1b2d44a91f7d
[ROCm/clr commit: cfed3f310d]
There weren't all that many to fix, and it's not even the most
prevalent warning.
Change-Id: I286aaa42e3c4e305b1e1918f302bbf71e41dd47d
[ROCm/clr commit: 3a564bc6cb]
Currently the opencl build hardcodes the path and directly includes
amdvdi_staticTargets.cmake. The proper way to find this is through
find_package, so start exporting the expected format.
Change-Id: Ic960a2dd467d57867cb96ab831dbd85bca336535
[ROCm/clr commit: 8988f34935]
These are unnecessary and an obstacle to producing a relocatable
package.
Change-Id: I0059bf7a2d11fcece0cd7ab47d7545d0df4d7099
[ROCm/clr commit: 1d267c9c08]
Eliminates most of the global include_directories. The install header
paths are different from the build directory, so we have to separate
those for the exported target include paths.
Change-Id: I13e4c56c1218cb31c29a316422dc5fd1d09d8b1b
[ROCm/clr commit: 3a7f2e3682]
This partially avoids a difference in the include paths between a
build and install tree, and simplifies the install configuration.
Change-Id: If8119507594e0d284ac08c141c6c51c88ec619ef
[ROCm/clr commit: 199f6114d0]
Object libraries are weird, and producing a library by using the
target objects from them doesn't automatically import the interface
properties of the linked targets. These object libraries only have
single uses, so just directly create the final library from the
sources.
Leaves libelf as an object library, since there seems to be some cmake
oddity when trying to link an unexported target to an exported one.
Change-Id: Ic379612c89340c40085c9862cfe111fa4bbff425
[ROCm/clr commit: cba7a4d20e]
There's a lot of unnecessary system configuration junk here which
isn't used, and is already available through compiler predefines. This
is also blindly placed without really checking the host architecture.
-DLINUX is unused.
-D__AMD64__ is predefined by the compiler, and is also redundant with
__x86_64__ and ATI_BITS_64.
__x86_64__ should also be removed. It's used in libelf, but I'm not
sure if msvc predefines this or not.
-DqLittleEndian is unused, and also doesn't follow macro naming
conventions (plus compilers have their own predefines for checking
this).
Change-Id: I89f6fc4c88e861623be7f32df41aecbb4e9009ab
[ROCm/clr commit: e7d6a5e5a6]
This should allow the cmake build for the opencl runtime to work
without manually adding these definitions. The PAL build also adds
these as private defines in its build, so change rocm to match. This
should probably be including these a config header to benefit other
builds, but this will at least avoid some clutter in the opencl build
for now.
Change-Id: I1044984b87ba3fc72e280e255ceea2dd9e3337ff
[ROCm/clr commit: c60d7d860d]
Use target specific forms for define/include. Don't set
CMAKE_CXX_FLAGS for the standard, which is already implied from the
parent build.
Change-Id: I4000893376d6685e9889b66ad8451fc493020272
[ROCm/clr commit: 815198bec9]
Don't use find_path on the header, it's redundant with the interface
include directories on the imported target. Use the target specific
forms for including and linking it.
Change-Id: I3923143c992888ee7d5ee1130084ac2e5eaa0f3a
[ROCm/clr commit: 83455f36c5]
This is almost never the correct thing to use since it breaks adding
this as a subproject build in a larger build. Switch to refer to
CMAKE_CURRENT_SOURCE_DIR, which is equivalent in a standalone build.
Change-Id: Ib8dbbc0668491f4227389b9a5b27da770b3bc5ce
[ROCm/clr commit: a36f19df51]
e.g.:
warning: expression does not compute the number of elements in this
array; element type is '__cpu_mask' (aka 'unsigned long'), not
'uint32_t' (aka 'unsigned int') [-Wsizeof-array-div]
for (uint i = 0; i < sizeof(mask_.__bits) / sizeof(uint32_t); ++i) {
__bits is a __cpu_mask, which is a 64-bit type. These were accessed
through uint32_t pointers so the loop bound should have been
correct. These operations can be done directly on the 64-bit type so
we can leave the array size pattern, and eliminate the casts.
The case in getNextSet should probably be rephrased in terms of
__cpu_mask to avoid the pointer casting, but this is tricker than the
other cases so I used the easy option to quiet the warning.
Change-Id: I1332584fad58439ccd9d369589519a9918e1678e
[ROCm/clr commit: 72c435ea35]
Matt Arsenault