On 6/7/22 17:41, Thomas Schwinge wrote:
Subject:
[PING] nvptx: forward '-v' command-line option to assembler, linker
From:
Thomas Schwinge <tho...@codesourcery.com>
Date:
6/7/22, 17:41
To:
Tobias Burnus <tob...@codesourcery.com>, <gcc-patches@gcc.gnu.org>, "Tom
de Vries" <tdevr...@suse.de>
Hi!
On 2022-05-30T09:06:21+0200, Tobias Burnus<tob...@codesourcery.com> wrote:
On 29.05.22 22:49, Thomas Schwinge wrote:
Not sure if that's what you had in mind, but what do you think about the
attached "nvptx: forward '-v' command-line option to assembler, linker"?
OK to push to GCC master branch (after merging
<https://github.com/MentorEmbedded/nvptx-tools/pull/37>
"Put '-v' verbose output onto stderr instead of stdout")?
I was mainly thinking of some way to have it available — which
'-foffload-options=-Wa,-v' already permits on the GCC side. (Once the
nvptx-tools patch actually makes use of the '-v'.)
(Merged a week ago.)
If I understand your patch correctly, this patch now causes 'gcc -v' to
imply 'gcc -v -Wa,-v'. I think that's okay, since 'gcc -v' already
outputs a lot of lines and those lines can be helpful to understand what
happens and what not.
ACK.
Tom, your thoughts on this?
Ping.
Grüße
Thomas
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
0001-nvptx-forward-v-command-line-option-to-assembler-lin.patch
From 17c35607d4927299b0c4bd19dd6fd205c85c4a4b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge<tho...@codesourcery.com>
Date: Sun, 29 May 2022 22:31:43 +0200
Subject: [PATCH] nvptx: forward '-v' command-line option to assembler, linker
For example, for offloading compilation with '-save-temps -v', before vs. after
word-diff then looks like:
[...]
[...]/build-gcc-offload-nvptx-none/gcc/as {+-v -v+} -o
./a.xnvptx-none.mkoffload.o ./a.xnvptx-none.mkoffload.s
{+Verifying sm_30 code with sm_35 code generation.+}
{+ ptxas -c -o /dev/null ./a.xnvptx-none.mkoffload.o --gpu-name sm_35 -O0+}
[...]
[...]/build-gcc-offload-nvptx-none/gcc/collect2 {+-v -v+} -o
./a.xnvptx-none.mkoffload [...] @./a.xnvptx-none.mkoffload.args.1 -lgomp -lgcc
-lc -lgcc
{+collect2 version 12.0.1 20220428 (experimental)+}
{+[...]/build-gcc-offload-nvptx-none/gcc/collect-ld -v -v -o
./a.xnvptx-none.mkoffload [...] ./a.xnvptx-none.mkoffload.o -lgomp -lgcc -lc
-lgcc+}
{+Linking ./a.xnvptx-none.mkoffload.o as 0+}
{+trying lib libc.a+}
{+trying lib libgcc.a+}
{+trying lib libgomp.a+}
{+Resolving abort+}
{+Resolving acc_on_device+}
{+Linking libgomp.a::oacc-init.o/ as 1+}
{+Linking libc.a::lib_a-abort.o/ as 2+}
[...]
(This depends on<https://github.com/MentorEmbedded/nvptx-tools/pull/37>
"Put '-v' verbose output onto stderr instead of stdout".)
Ack, I see that has been merged.
The ASM_SPEC part LGTM.
The LINK_SPEC part results looked very verbose to me at first glance,
given that it prints info that with gnu ld we'd only see with
-Wl,-trace. But I suppose that's more of a question of what we print
with nvptx-none-ld -v.
Still, I wonder, normally we don't pass -v to ld, and need -Wl,-v for
that. So, any particular reason why we would do things differently for
nvptx?
Thanks,
- Tom
gcc/
* config/nvptx/nvptx.h (ASM_SPEC, LINK_SPEC): Define.
---
gcc/config/nvptx/nvptx.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index ed72c253191..b184f1d0150 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -27,6 +27,13 @@
/* Run-time Target. */
+/* Assembler supports '-v' option; handle similar to
+ '../../gcc.cc:asm_options', 'HAVE_GNU_AS'. */
+#define ASM_SPEC "%{v}"
+
+/* Linker supports '-v' option. */
+#define LINK_SPEC "%{v}"
+
#define STARTFILE_SPEC "%{mmainkernel:crt0.o}"
#define TARGET_CPU_CPP_BUILTINS() nvptx_cpu_cpp_builtins ()
-- 2.25.1
Attachments:
0001-nvptx-forward-v-command-line-option-to-assembler-lin.patch 2.0 KB
