Created attachment 917567 [details] Modified ebuild While the source code does seem to require graphite-specific loop optimizations via "#pragma GCC optimize ...", the package builds and seems to run fine without them. It doesn't look like GCC is going to incorporate graphite any time soon, so its not reasonable to require it for a package. The attached ebuild builds darktable with gcc without graphite. It does that by removing the offending graphite-specific optimizations in the source code. The attached patch file shows the differences between the ebuild and the one currently in portage.
Created attachment 917568 [details, diff] Patch showing differences from current ebuild
(In reply to Vincent Reher from comment #0) > Created attachment 917567 [details] > Modified ebuild > > While the source code does seem to require graphite-specific loop > optimizations via "#pragma GCC optimize ...", the package builds and seems > to run fine without them. It doesn't look like GCC is going to incorporate > graphite any time soon, so its not reasonable to require it for a package. > Well, it is incorporated, it's just an optional component, which is why we have it under a USE flag. But yes, it's a pain for people as it's not default-enabled. (In reply to Vincent Reher from comment #0) > Created attachment 917567 [details] > Modified ebuild > > While the source code does seem to require graphite-specific loop > optimizations via "#pragma GCC optimize ...", the package builds and seems > to run fine without them. It doesn't look like GCC is going to incorporate > graphite any time soon, so its not reasonable to require it for a package. > The risk with this is people making upstream performance complaints but it may be fine, especially given graphite-style improvements have made their way into the rest of GCC (not everything but some).
I think this is arguably really a dupe of bug 925209 but I guess it's fine to have it separate to discuss the patching angle.
(In reply to Sam James from comment #2) > The risk with this is people making upstream performance complaints but it > may be fine, especially given graphite-style improvements have made their > way into the rest of GCC (not everything but some). When I first encountered this (Nov 2023), I ran across a seemingly authoritative message somewhere stating that graphite was not likely to ever be incorporated into mainstream gcc code. But honestly, I cannot remember where I saw that. It is certainly possible that some of what I determined at that time as graphite-specific optimizations may have made their way into GCC.
graphite itself has been part of GCC for a long time (2008 or so?), but some (not all) of the things it did are now implemented as non-graphite passes as well (I think, though no examples come to mind right now, but I'm also trying to stay awake :)).
