On 03/04/2024 10:27, Jakub Jelinek wrote:
On Wed, Apr 03, 2024 at 11:09:19AM +0200, Tobias Burnus wrote:@@ -3954,8 +3956,8 @@ on the GPU. To enable support for GCN3 Fiji devices (gfx803), GCC has to be configured with @option{--with-arch=@code{fiji}} or @option{--with-multilib-list=@code{fiji},...}. Note that support for Fiji -devices has been removed in ROCm 4.0 and support in LLVM is deprecated and will -be removed in LLVM 18. +devices has been removed in ROCm 4.0 and support in LLVM is deprecated and has +been removed in LLVM 18.Shouldn't we at configure time then detect the case where fiji can't be supported and either error if it is included explicitly in multilib list, or implicitly take it out from that list and arrange error to be emitted when using -march=fiji/gfx803 ? Sure, if one configures against LLVM 17 and then updates LLVM to 18, it will still result in weird errors/LLVM ICEs, but at least in the common case when one configures GCC 14 against LLVM 18 one won't suffer from those ICEs and get clear diagnostics that fiji is sadly no longer supported.
One additional point: since our departure from Siemens, we no longer have access to any Fiji devices ourselves. I plan to rip that stuff out the first chance I get (not necessarily very soon).
In the meantime, Fiji is not included in the default configuration of GCC 14, so anyone enabling it is doing so explicitly and a) will have read the documentation, and b) would be surprised if Fiji were automatically excluded.
We could emit an error at configure time if an unsuitable LLVM is detected, but I don't think it's worth the effort for what is a niche product that requires drivers so old they were only supported on now-EOL OS versions.
I'm happy with Tobias's patch with s/LLVM is deprecated/LLVM was deprecated/. The Newlib versions are a bit awkward, but we can't recommend 4.5 until it exists.
Andrew
