<div dir="ltr">Hi All,
<div><br></div><div>I am working on a problem where it does not seem possible to</div><div>compile code for ARM at an architecture level.  For example,</div><div>compiling:</div><div><br></div><div>  $ clang -target arm-none-eabi -mthumb -march=armv7 -o - -S test.c | grep '\.cpu'</div><div>      .cpu<span class="">     </span>cortex-a8</div><div><br></div><div>However, I don't want the code locked to a Cortex-A8 CPU.  In fact, for this particular</div><div>example it can cause problems because I would like to create an ARMv7 Thumb static</div><div>library that can be used with both ARMv7 A and M profiles.</div><div><br></div><div>GCC has logic to produce a .arch directive when -march is used:</div><div><br></div><div>  $ arm-none-eabi-gcc -mthumb -march=armv7 -S -o - test.c | grep '\.cpu'</div><div>  $ arm-none-eabi-gcc -mthumb -march=armv7 -S -o - test.c | grep '\.arch'</div><div>      .arch armv7</div><div><br></div><div>I would like similar behavior in Clang.</div><div><br></div><div>From working through the various toolchains and options in the driver code I</div><div>see two immediate approaches:</div><div><br></div><div>   1. When -mcpu is not specified, don't generate -target-cpu for the CC1 invocation</div><div>       and derive the architecture information from the triple (I did find it somewhat</div><div>       surprising the architecture version info in embedded in the triple).  Wether or</div><div>       not the CPU string is empty will detail if .cpu or .arch should be generated.</div><div><br></div><div>   2. Add driver support for the GCC ARM -mcpu=generic-arch option form.  Then</div><div>       we can still always generate -target-cpu still and make decisions on whether</div><div>       to generate .cpu or .arch from the "generic-" part.</div><div><br></div><div>Have other run into this and consider it a problem?  Other solutions?</div><div><br></div><div>-- Meador</div></div>