[Mesa-dev] [RFC] travis: lower SWR requirement to GCC 4.8, aka std=c++11

[Rowley, Timothy O]

On Jul 6, 2017, at 5:39 AM, Emil Velikov <emil.l.velikov at gmail.com<mailto:emil.l.velikov at gmail.com>> wrote:

On 5 July 2017 at 19:28, Rowley, Timothy O <timothy.o.rowley at intel.com<mailto:timothy.o.rowley at intel.com>> wrote:

On Jul 4, 2017, at 12:01 PM, Emil Velikov <emil.l.velikov at gmail.com<mailto:emil.l.velikov at gmail.com>> wrote:

From: Emil Velikov <emil.velikov at collabora.com<mailto:emil.velikov at 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.rowley at intel.com<mailto:timothy.o.rowley at intel.com>
Fixes: 0b80b025021 ("swr: relax c++ requirement from c++14 to c++11")
Signed-off-by: Emil Velikov <emil.velikov at collabora.com<mailto:emil.velikov at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170706/25d2f551/attachment-0001.html>