intrinsic-test: streamline c compilation

[folkertdev]

Preparation for combining the C files. That is the biggest speedup, so I want to do that first to make later refactorings less painful.

[rustbot]

r? @sayantn

rustbot has assigned @sayantn.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tgross35]

gcc can still be used to link c++ object files right?

[folkertdev]

Well, I ran into some linker issues with it earlier, and this is the linker that is picked here (and fixed those linker issues, though maybe other fixes were possible):

stdarch/crates/intrinsic-test/src/arm/compile.rs

Lines 34 to 37 in af2aa76

	command = command
	.set_linker(
	cxx_toolchain_dir.unwrap_or("").to_string() + "/bin/aarch64_be-none-linux-gnu-g++",
	)

So this solved a problem and seemed more consistent. Are there downsides to using g++?

[tgross35]

None that I know of, I was just thinking it would be a change without any effect. Interesting that it makes a difference

edit: Oh, if it needs to link the c++ libraries then that makes more sense.

[folkertdev]

True, but on the other hand it did work up to now (and, it might still, I just had trouble with it earlier). But I figured we may as well be consistent here.

[folkertdev]

digging in a little further, this is the linker command that we execute. Apparently clang19++ cannot itself construct the final binary, so intrinsic-test-programs.cpp is first compiled to an object file by clang19++, then linked using this custom linker. With gcc this fails:

[crates/intrinsic-test/src/common/compile_c.rs:209:17] &cmd = Command {
    program: "/toolchains/arm-gnu-toolchain-14.2.rel1-x86_64-aarch64_be-none-linux-gnu/bin/aarch64_be-none-linux-gnu-gcc",
    args: [
        "/toolchains/arm-gnu-toolchain-14.2.rel1-x86_64-aarch64_be-none-linux-gnu/bin/aarch64_be-none-linux-gnu-gcc",
        "mod_0.o",
        "mod_1.o",
        "mod_2.o",
        "mod_3.o",
        "mod_4.o",
        "mod_5.o",
        "mod_6.o",
        "mod_7.o",
        "mod_8.o",
        "mod_9.o",
        "mod_10.o",
        "mod_11.o",
        "mod_12.o",
        "mod_13.o",
        "mod_14.o",
        "mod_15.o",
        "intrinsic-test-programs.o",
        "-o",
        "intrinsic-test-programs",
    ],
    cwd: Some(
        "c_programs",
    ),
    create_pidfd: false,
}

This gives errors like this

aarch64_be-none-linux-gnu/bin/ld: mod_0.o: in function run___crc32b()':
mod_0.cpp:(.text+0x1c): undefined reference to std::cout'
aarch64_be-none-linux-gnu/bin/ld: mod_0.cpp:(.text+0x2c): undefined reference to std::cout'
aarch64_be-none-linux-gnu/bin/ld: mod_0.cpp:(.text+0x5c): undefined reference to std::ctype<char>::_M_widen_init() const'
aarch64_be-none-linux-gnu/bin/ld: mod_0.cpp:(.text+0x7c): undefined reference to std::ostream::put(char)'
aarch64_be-none-linux-gnu/bin/ld: mod_0.cpp:(.text+0x80): undefined reference to std::ostream::flush()'
aarch64_be-none-linux-gnu/bin/ld: mod_0.cpp:(.text+0xa4): undefined reference to std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, long)'

So yeah, we're linking C++ now, and then using g++ seems like the best option.

[sayantn]

clang19++ cannot itself construct the final binary

that seems weird!

[folkertdev]

So, I got this to work, meaning we can drop the custom linker stuff. I've also reverted the linker change from gcc to g++ for now, it might be needed later but we can change it then.