On Wed, 4 Jan 2023, Tamar Christina wrote: >> -----Original Message----- >> From: Martin Storsjö >> Sent: Wednesday, January 4, 2023 11:00 AM >> To: Tamar Christina >> Cc: nickc@redhat.com; Mark Harmstone ; Andrew >> Pinski ; Richard Earnshaw >> ; NightStrike ; >> wej22007@outlook.com; zac.walker@linaro.org; binutils >> >> Subject: RE: [PATCH 1/8] ld: Rename aarch64pe emulation target to arm64pe >> >> On Wed, 4 Jan 2023, Tamar Christina wrote: >> >>> To be clear, GCC will very likely reject any port upstreaming that >>> uses >>> Arm64 for the same reason. And GCC is a lot more tightly controlled. >>> At least if you want upstream support. >>> >>> Believe it or not I'm actually trying to help you here, the fact that >>> clang has called it arm64 is why we want to allow the alias. As I >>> mentioned before, it just can't be the main name. >> >> Right - but in the case of GCC, it wouldn't be the name of a new port - it >> would only be a single word in a file for passing linker arguments. Just like >> how "-m i386pep" is passed for x86_64 today here: >> https://github.com/gcc- >> mirror/gcc/blob/345dffd0d4ebff7e705dfff1a8a72017a167120a/gcc/config/i38 >> 6/mingw-w64.h#L74 >> >> So regardless of the binutils discussion, are you saying that GCC would reject >> a patch that adds such an occurance that would pass "-m arm64pe", in a >> patch that otherwise consistently calls the port "aarch64"? > > If it's driver only and has no source implications then It might be ok. > But look at this patch, it's not driver only. By renaming the emulation > target it also renamed the internal macros. It makes us have to > maintain the name "arm64" in the source code along with what everything > else calls aarch64 and this has more implications. Ok, thanks for clarifying the concern - I see your point now. // Martin