On Jul 6, 2017, at 5:39 AM, Emil Velikov <emil.l.veli...@gmail.com<mailto:emil.l.veli...@gmail.com>> wrote:
On 5 July 2017 at 19:28, Rowley, Timothy O <timothy.o.row...@intel.com<mailto:timothy.o.row...@intel.com>> wrote: On Jul 4, 2017, at 12:01 PM, Emil Velikov <emil.l.veli...@gmail.com<mailto:emil.l.veli...@gmail.com>> wrote: From: Emil Velikov <emil.veli...@collabora.com<mailto:emil.veli...@collabora.com>> With ealier commit we relaxed the requirement from C++14 to C++11. Update the build script so that it Cc: Tim Rowley <timothy.o.row...@intel.com<mailto:timothy.o.row...@intel.com> Fixes: 0b80b025021 ("swr: relax c++ requirement from c++14 to c++11") Signed-off-by: Emil Velikov <emil.veli...@collabora.com<mailto:emil.veli...@collabora.com>> --- Tim, this does _not_ quite work, hence I'm sending it as RFC. The current build failures can be seen here Autotools https://travis-ci.org/evelikov/Mesa/jobs/250043586 Scons https://travis-ci.org/evelikov/Mesa/jobs/250043595 gcc-4.8 is throwing up some issues; I’ve patched them in the submission I just made to mesa-stable (swr: modifications to allow gcc-4.8 compilation). Still get a weird link problem (undefined reference to llvm::RTDyldMemoryManager::getSymbolAddressInProcess), but that looks to be more of a core gallium problem. Can we have the GCC 4.8 fix in master first? On the linking issue - I recall similar one, and updating LLVM solved it. Let me see if I can dig up some details. mesa-master swr intrinsic usage has changed a fair bit with the switchover to simdlib - half the patch proposed for mesa-stable still applies, with one other change needed. Both of these have been sent to mesa-dev for review. LLVM linkage continues to be a problem for gcc-4.8 on mesa-master. Although I expect additional issues, since w/o the patch a local build throws the following: src/gallium/drivers/swr/rasterizer/core/api.cpp: In function ‘void* SwrCreateContext(SWR_CREATECONTEXT_INFO*)’: src/gallium/drivers/swr/rasterizer/core/api.cpp:111:64: warning: ‘new’ of type ‘SWR_STATS’ with extended alignment 64 [-Waligned-new=] pContext->pStats = new SWR_STATS[pContext->NumWorkerThreads]; ^ src/gallium/drivers/swr/rasterizer/core/api.cpp:111:64: note: uses ‘void* operator new [](std::size_t)’, which does not have an alignment parameter src/gallium/drivers/swr/rasterizer/core/api.cpp:111:64: note: use ‘-faligned-new’ to enable C++17 over-aligned new support src/gallium/drivers/swr/rasterizer/core/threads.cpp: In function ‘void CreateThreadPool(SWR_CONTEXT*, THREAD_POOL*)’: src/gallium/drivers/swr/rasterizer/core/threads.cpp:989:72: warning: ‘new’ of type ‘SWR_STATS’ with extended alignment 64 [-Waligned-new=] pContext->dcRing[dc].dynState.pStats = new SWR_STATS[numThreads]; ^ src/gallium/drivers/swr/rasterizer/core/threads.cpp:989:72: note: uses ‘void* operator new [](std::size_t)’, which does not have an alignment parameter src/gallium/drivers/swr/rasterizer/core/threads.cpp:989:72: note: use ‘-faligned-new’ to enable C++17 over-aligned new support These are curious - I’m not seeing warnings like this on gcc-4.8.5. Using gcc (GCC) 7.1.1 20170528, but I've seen it with earlier GCC 7 versions. Checking SWR_STATS and expanding all the macros gives us: struct __attribute__((aligned(64))) SWR_STATS { uint64_t DepthPassCount; uint64_t PsInvocations; uint64_t CsInvocations; }; ... which strictly speaking one does not even need the aligned bits. Dropping the ALIGN bits may lead to breakage later on. Which one should be able to catch at compile time via a combination of static_assert and sizeof/offsetof. Installed gcc-7.1 and now see these warnings. Alignment was intentionally added to the stats structure and gave a good speedup with msvc at the time (a bit more than a year ago). Investigating if this is still the case and if so what the clean c++11 friendly solution is. Thanks Emil
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
