search for: mips64r5

The term "target" is somewhat overloaded. When llvm-config tells you it was built with the X86 target, that actually includes a variety of closely related architectures, such as x86_64, i386, and so on. Within the x86_64 architecture, there are many individual processor implementations that LLVM understands, such as Skylake, Bulldozer, and many many more. What *clang* means by

I'm cross-compiling for MIPS. The test-case is as simple as it can be: void foo() {} $clang -target mips64-octeon-linux -c -B path/to/cross/compiled/mips/assembler a.c And then I look at the object file: $ nm a.o 0000000000000020 t $tmp0 0000000000000000 T foo I would like to know what "$tmp0" is. Furthermore, if I pass -g to clang, I see a whole bunch of such symbols. Some of

...s list can be found in the "clang/lib/Basic/Targets/Mips.cpp". mips1 and mips5 accepted by Clang, but unsupported by code generator. I'm going to remove them from this list. mips1, mips2, mips3, mips4, mips5, mips32, mips32r2, mips32r3, mips32r5, mips32r6, mips64, mips64r2, mips64r3, mips64r5, mips64r6, octeon, octeon+, p5600 R3000 is a CPU implements mips1 instruction set architecture. Unfortunately you cannot generate a code for this CPU using Clang. -- Simon Atanasyan Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr....

...You're probably thinking something like "mips32r2 little endian, obviously" but this is not actually correct all the time. The true answer is 'whatever I (the person who built the toolchain) want it to mean'. It could be mips32r6, it could be mips4, it could even be big-endian mips64r5 with nan2008 and msa. It could even be octeon or p5600. In GCC toolchains, distributors routinely use configure-time options to define the triple they wish to use. Nothing is stopping anyone using the same string for completely different meanings and indeed conflicting definitions are very common....

I think we need to take a step further back and re-enter from the right starting point. The thing that's bothering me about the push back so far is that it's trying to discuss and understand the consequences of resolving the core problem while seemingly ignoring the core problem itself. The reason I've been steering everything back to GNU Triple's being ambiguous and inconsistent