From: Andrew Stubbs <ams@baylibre.com>
To: Jakub Jelinek <jakub@redhat.com>, Tobias Burnus <tburnus@baylibre.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [Patch] GCN: install.texi update for Newlib change and LLVM 18 release
Date: Wed, 3 Apr 2024 12:22:35 +0100 [thread overview]
Message-ID: <73eb907a-f234-43bf-97f2-782ebb14c6ac@baylibre.com> (raw)
In-Reply-To: <Zg0hGTE125S/tw0q@tucnak>
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
prev parent reply other threads:[~2024-04-03 11:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-03 9:09 Tobias Burnus
2024-04-03 9:27 ` Jakub Jelinek
2024-04-03 10:33 ` Tobias Burnus
2024-04-03 11:22 ` Andrew Stubbs [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=73eb907a-f234-43bf-97f2-782ebb14c6ac@baylibre.com \
--to=ams@baylibre.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=tburnus@baylibre.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).