-m option is not ignored when is immediately preceded by -o option

[Quuxplusone]

Bugzilla Link	PR52583
Status	RESOLVED FIXED
Importance	P enhancement
Reported by	Egor Suvorov (egor.suvorov@gmail.com)
Reported on	2021-11-22 09:26:57 -0800
Last modified on	2021-11-23 07:48:33 -0800
Version	unspecified
Hardware	PC Windows NT
CC	craig.topper@gmail.com, htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org, neeilans@live.com, richard-llvm@metafoo.co.uk
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also	https://sourceware.org/bugzilla/show_bug.cgi?id=28619

Here is an issue that one of my students encountered today with GCC, but Clang is also affected: https://stackoverflow.com/questions/70069809/unrecognized-emulation-mode-ain-when-compiling-with-gcc-on-ubuntu/70069810

Consider any simple C++ program in a file named main.cpp. I compile it with clang++ main.cpp -o main, but I accidentally add a dash before main:

clang++ main.cpp -o -main

Expected behavior: the program is compiled to a file named -main.

Real behavior: /usr/bin/ld: unrecognised emulation mode: ain Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 elf_iamcu elf_l1om elf_k1om i386pep i386pe clang: error: linker command failed with exit code 1 (use -v to see invocation)

My understanding: Clang treats -main as both -m option (targeting some unexisting ain architecture) AND name for the output file.

For example, on my 64-bit Ubuntu I can write

clang++ main.cpp -o -melf_x86_64

and it will produce a binary named -melf_x86_64. However, the following command fails because I don't have 32-bit standard library installed:

clang++ main.cpp -o -melf_i386

yields:

/usr/bin/ld: skipping incompatible /usr/bin/../lib/gcc/x86_64-linux-gnu/10/libstdc++.so when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/bin/../lib/gcc/x86_64-linux-gnu/10/libstdc++.a when searching for -lstdc++ /usr/bin/ld: cannot find -lstdc++ /usr/bin/ld: skipping incompatible /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libm.a when searching for -lm /usr/bin/ld: cannot find -lm /usr/bin/ld: skipping incompatible /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libgcc_s.so.1 when searching for libgcc_s.so.1 /usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libgcc_s.so.1 when searching for libgcc_s.so.1 /usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 when searching for libgcc_s.so.1 /usr/bin/ld: skipping incompatible /usr/bin/../lib/gcc/x86_64-linux-gnu/10/libgcc.a when searching for -lgcc /usr/bin/ld: cannot find -lgcc clang: error: linker command failed with exit code 1 (use -v to see invocation)

I suspect some other options may be be affected as well. -m here is special only because main start with m.

Being able to read the option in two different ways simultaneously looks like a bug in my world.

I can reproduce the behavior on a wide range of OSes: LLVM on Windows 10 (clang++ version 13.0.0 Target: x86_64-w64-windows-gnu by msys2 project), clang++ 10.0.0-4ubuntu1 on 64-bit Ubuntu 20.04.3 LTS, as well as trunk version on Godbolt.

[Quuxplusone]

Re-checking after GCC's response at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103362#c1

Here is the last command that Clang runs on my machine:

"/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o -main /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crt1.o /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crti.o /usr/bin/../lib/gcc/x86_64-linux-gnu/10/crtbegin.o -L/usr/bin/../lib/gcc/x86_64-linux-gnu/10 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu -L/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/usr/lib/x86_64-linux-gnu/../../lib64 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../.. -L/usr/lib/llvm-10/bin/../lib -L/lib -L/usr/lib /tmp/a-cee2d8.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/bin/../lib/gcc/x86_64-linux-gnu/10/crtend.o /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/crtn.o

Looks like a correct behavior on Clang's part, so it looks like ld bug. Resolving for now in favor of ld's bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=28619

[Quuxplusone]

Should this have been resolved as INVALID rather than FIXED? Nothing changed in clang right?

[Quuxplusone]

Affirmative, nothing has changed in clang. Feel free to adjust, I'm not familiar with Bugzilla statuses.