On 03/04/2024 10:05, Tobias Burnus wrote:
This patch handles --with-arch= in GCN's mkoffload.cc
While mkoffload mostly does not know this and passes it through to the
GCN lto1 compiler,
it writes an .o file with debug information - and here the -march= in
the ELF flags must
agree with the one in the other files. Hence, it uses now the
--with-arch= config argument.
Doing so, there is now a diagnostic if the -march= or --with-arch= is
unknown. While the
latter should be rejected at GCC compile time, the latter was not
diagnosed in mkoffload
but only later in GCN's compiler.
But as there is now a fatal_error in mkoffload, which comes before the
GCN-compiler call,
the 'note:' which devices are available were lost. This has been
reinstated by using
the multilib settings. (That's not identical to the compiler supported
flags the output
is reasonable, arguable better or worse than lto1.)
Advantage: The output is less cluttered than a later fail.
To make mkoffload errors - and especially this one - more useful, it now
also initializes
the colorization / bold.
OK for mainline?
OK. Thanks for fixing this.
Andrew
* * *
Example error:
gcn mkoffload: error: unrecognized argument in option '-march=gfx1111'
gcn mkoffload: note: valid arguments to '-march=' are: gfx906, gfx908,
gfx90a, gfx1030, gfx1036, gfx1100, gfx1103
where on my TERM=xterm-256color, 'gcn mkoffload:' and the quoted texts
are in bold,
'error:' is red and 'note:' is cyan.
Compared to cc1, the 'note:' lacks 'fiji', the list is separated by ', '
instead of ' ', and cc1 has a "; did you mean 'gfx1100'?".
And the program name is 'gcn mkoffload' instead of 'cc1'.
Tobias
PS: The generated multilib list could be later changed to be based on
the gcn-.def file;
or we just keep the multiconfig variant of this patch.
I think a .def file would be more future-proof if we ever have multilibs
for options other than -march, but this works for now.
Andrew
