Created attachment 23384 [details] Testcase
Confirmed.
For this to be fixed we'd need something similar to COLLECT_GCC_OPTIONS, COLLECT_AS_OPTIONS for example, and lto-wrapper passing those on via -Wa to the link-time driver.
This causes compilation of AVX code using GCC 4.9 to fail on OS X Mavericks; any plans to fix?
*** Bug 61168 has been marked as a duplicate of this bug. ***
> This causes compilation of AVX code using GCC 4.9 to fail on OS X Mavericks; ... Exactly why I have opened pr61168!-(still not fixed).
Confirmed as still not fixed in 4.9.1 (with Yocto 1.8)
Another instance on x86_64-apple-darwin14 with Xcode 7 [Book15] f90/bug% gcc6 /opt/gcc/_clean/gcc/testsuite/gcc.dg/debug/pr41893-1.c -gstabs1 -Wa,-Q -flto -fwhole-program -O /opt/gcc/_clean/gcc/testsuite/gcc.dg/debug/pr41893-2.c /var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//ccJ7keUF.s:1:9: error: unsupported directive '.stabs' .stabs "/var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//ccnRWDSD.ltrans0.o",100,0,0,Ltext0 ^ /var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//ccJ7keUF.s:4:9: error: unsupported directive '.stabs' .stabs "gcc2_compiled.",60,0,0,0 ^ /var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//ccJ7keUF.s:8:9: error: unsupported directive '.stabs' .stabs "/opt/gcc/_clean/gcc/testsuite/gcc.dg/debug/pr41893-1.c",132,0,0,Ltext1 ^ /var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//ccJ7keUF.s:10:2: error: unknown directive .stabd 68,0,16 ^ /var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//ccJ7keUF.s:13:2: error: unknown directive .stabd 68,0,16 ^ /var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//ccJ7keUF.s:17:9: error: unsupported directive '.stabs' .stabs "main:F(0,1)=r(0,1);-2147483648;2147483647;",36,0,0,_main ^ /var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//ccJ7keUF.s:22:2: error: unknown directive .stabd 68,0,12 ^ /var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//ccJ7keUF.s:27:9: error: unsupported directive '.stabs' .stabs "func1:F(0,2)=(0,2)",36,0,0,_func1 ^ /var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//ccJ7keUF.s:72:9: error: unsupported directive '.stabs' .stabs "",100,0,0,Letext0 ^ lto-wrapper: fatal error: gcc6 returned 1 exit status compilation terminated. collect2: fatal error: lto-wrapper returned 1 exit status compilation terminated.
*** Bug 68788 has been marked as a duplicate of this bug. ***
*** Bug 70415 has been marked as a duplicate of this bug. ***
*** Bug 78353 has been marked as a duplicate of this bug. ***
*** Bug 84230 has been marked as a duplicate of this bug. ***
*** Bug 88250 has been marked as a duplicate of this bug. ***
Note the proposed solution only works for uniform -Wa options across all TUs participating in the optimizing link. Otherwise partitioning can merge parts of TUs with different flags and there is (IIRC) no way to annotate parts of an assembly file with different assembler flags. Supporting non-uniform -Wa flags would require either adjusting partitioning according to flags (disliked by some folks but also would help in other cases), or emitting multiple object files (assembler files) from a single LTRANS CU. Note there's the question if it is valid to inline across -Wa flag differences as well. For the specific case of -Wa,-msse2avx target maintainers might consider adding a -msse2avx compiler flag triggering the assembler flag via specs processing.
A patch for this is posted at https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01471.html
We need to also handle -Xassembler? Since -Wa, doesn't work with comma in assembler options, like -mfoo=foo1,foo2, one needs to use -Xassembler -mfoo=foo1,foo2 to pass -mfoo=foo1,foo2 to assembler.
(In reply to H.J. Lu from comment #15) > We need to also handle -Xassembler? Since -Wa, doesn't work with comma in > assembler options, like -mfoo=foo1,foo2, one needs to use > > -Xassembler -mfoo=foo1,foo2 > > to pass -mfoo=foo1,foo2 to assembler. We may also have -Xassembler -mfoo=foo1,foo2 -Wa,-mbar
The master branch has been updated by Prathamesh Kulkarni <prathamesh3492@gcc.gnu.org>: https://gcc.gnu.org/g:f1a681a174cdfb82e62c246d6f4add9a25fc2e43 commit r10-6807-gf1a681a174cdfb82e62c246d6f4add9a25fc2e43 Author: Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org> Date: Mon Feb 24 11:55:45 2020 +0530 PR47785: Add support for handling Xassembler/Wa options with LTO. 2020-02-24 Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org> Kugan Vivekandarajah <kugan.vivekanandarajah@linaro.org> PR driver/47785 * gcc.c (putenv_COLLECT_AS_OPTIONS): New function. (driver::main): Call putenv_COLLECT_AS_OPTIONS. * opts-common.c (parse_options_from_collect_gcc_options): New function. (prepend_xassembler_to_collect_as_options): Likewise. * opts.h (parse_options_from_collect_gcc_options): Declare prototype. (prepend_xassembler_to_collect_as_options): Likewise. * lto-opts.c (lto_write_options): Stream assembler options in COLLECT_AS_OPTIONS. * lto-wrapper.c (xassembler_options_error): New static variable. (get_options_from_collect_gcc_options): Move parsing options code to parse_options_from_collect_gcc_options and call it. (merge_and_complain): Validate -Xassembler options. (append_compiler_options): Handle OPT_Xassembler. (run_gcc): Append command line -Xassembler options to collect_gcc_options. * doc/invoke.texi: Add documentation about using Xassembler options with LTO. testsuite/ * gcc.target/arm/pr78353-1.c: New test. * gcc.target/arm/pr78353-2.c: Likewise.
Since this patch has been included in gcc10 (I verified it works now, but fails with gcc9) can this issue be closed? Or does it need backporting to earlier versions?
I'd like to backport it to GCC 9.
The releases/gcc-9 branch has been updated by H.J. Lu <hjl@gcc.gnu.org>: https://gcc.gnu.org/g:ecdb697389b284a0f3912932e0a440c1071fbadd commit r9-9344-gecdb697389b284a0f3912932e0a440c1071fbadd Author: Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org> Date: Mon Feb 24 11:55:45 2020 +0530 PR47785: Add support for handling Xassembler/Wa options with LTO. Skip the test if arm7a is not supported at link time. This is the case if the toolchain targets an M-profile CPU by default and does not have A-profile multilib: the link step fails because it tries to mix M-profile startup files with A-profile testcase. gcc/ 2020-02-24 Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org> Kugan Vivekandarajah <kugan.vivekanandarajah@linaro.org> PR driver/47785 * gcc.c (putenv_COLLECT_AS_OPTIONS): New function. (driver::main): Call putenv_COLLECT_AS_OPTIONS. * opts-common.c (parse_options_from_collect_gcc_options): New function. (prepend_xassembler_to_collect_as_options): Likewise. * opts.h (parse_options_from_collect_gcc_options): Declare prototype. (prepend_xassembler_to_collect_as_options): Likewise. * lto-opts.c (lto_write_options): Stream assembler options in COLLECT_AS_OPTIONS. * lto-wrapper.c (xassembler_options_error): New static variable. (get_options_from_collect_gcc_options): Move parsing options code to parse_options_from_collect_gcc_options and call it. (merge_and_complain): Validate -Xassembler options. (append_compiler_options): Handle OPT_Xassembler. (run_gcc): Append command line -Xassembler options to collect_gcc_options. * doc/invoke.texi: Add documentation about using Xassembler options with LTO. gcc/testsuite/ 2020-02-24 Christophe Lyon <christophe.lyon@linaro.org> PR lto/78353 * gcc.target/arm/pr78353-1.c: Add arm_arch_v7a_multilib effective target. * gcc.target/arm/pr78353-2.c: Likewise. 2020-02-24 Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org> Kugan Vivekandarajah <kugan.vivekanandarajah@linaro.org> * gcc.target/arm/pr78353-1.c: New test. * gcc.target/arm/pr78353-2.c: Likewise. (cherry picked from commit f1a681a174cdfb82e62c246d6f4add9a25fc2e43)
The commited fix produces false positives for assembler options that do not influence the compilation output directly. For example "-a=$FILE" to create assembler listings. (Whose target files have to differ between different input files by design.)
Fix for GCC 10 and GCC 9.4.