public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tobias Burnus <tburnus@baylibre.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, Andrew Stubbs <ams@baylibre.com>
Subject: Re: [Patch] GCN: install.texi update for Newlib change and LLVM 18 release
Date: Wed, 3 Apr 2024 12:33:32 +0200	[thread overview]
Message-ID: <03c3f28b-4f3f-49e1-9f58-acaf3187d236@baylibre.com> (raw)
In-Reply-To: <Zg0hGTE125S/tw0q@tucnak>

Hi Jakub, hello world

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 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 ?

I am not sure that it is really needed for the reasons given below.
And while it would help some specific use (having LLVM 17 and wanting to use Fiji),
it will also cause some confusion as GCC 14 will magically behave differently
depending how build.

Additionally:

* I bet most use gcc/config.gcc which works in most cases just fine
   (LLVM >= 17; enabling all but Fiji)

* Fiji itself is old – removed from recent ROCm and LLVM >= 18,
   which also implies that it is seen as not seeing a lot of use

While there is no configure-time check, using Fiji with LLVM 18 will
fail with a semi-clear compile-time error when doing the in-tree newlib
build or the libgomp build.
(This shows up by default as issue with LLVM 18 + GCC 12/13;
  see https://gcc.gnu.org/PR114419)

Likewise, it will fail with LLVM < 15 when building gfx1100/gfx1103.

* * *

Note: The compiler itself is perfectly happy to handle fiji and gfx1100 itself,
just the LLVM MC assembler doesn't support one [< 15] or the other [>=LLVM 18].

* * *

For those tracking GCC or caring, the documentation at
   https://gcc.gnu.org/gcc-14/changes.html#amdgcn
and
   https://gcc.gnu.org/install/specific.html#amdgcn-x-amdhsa
provides some glory details.

And it is also mentioned at https://gcc.gnu.org/wiki/Offloading


Tobias


  reply	other threads:[~2024-04-03 10:33 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 [this message]
2024-04-03 11:22   ` Andrew Stubbs

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=03c3f28b-4f3f-49e1-9f58-acaf3187d236@baylibre.com \
    --to=tburnus@baylibre.com \
    --cc=ams@baylibre.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.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).