On 6/23/14, 8:31 AM, David Chisnall wrote:> On 23 Jun 2014, at 15:13, Renato Golin <renato.golin at linaro.org> wrote: > >> The main issue with your patch is that it can change user expected >> behaviour, and I can't tell you what is the expected behaviour in >> Darwin or BSD. If people usually use "unknown" in triples, this will >> break their builds. If not, this could break the build of someone who >> does.Renato, I would like to go this route, providing I can get support from the community that this is the direction we'd all like to take... I'd rather not make triples more complicated by introducing lots of special cases. Do you know who the right folks are to ask about the SPIR triples? Tim, This patch changes behavior a little for macho_embedded targets (i.e. from OSType::Unknown to OSType::NoneOS). I see that there is existing code to transform triples from things like thumbv7-apple-darwin into thumbv7m-apple-unknown-macho. Do you have an expectation to support users who are using the latter form of triples who would be surprised by the change from thumbv7m-apple-unknown-macho to thumbv7m-apple-none-macho (i.e. their thumbv7m-apple-unknown-macho builds no longer work)? Is this a case where all three triples are to mean the same thing?> > I think (Hat: FreeBSD) we only expect to see unknown in the vendor field (e.g. i386-unknown-freebsd). If the OS field is unknown, rather than freebsd, then it's not one of ours and we aren't likely to care. I don't really like the way that we conflate OS with ABI, but then I don't really like anything about triples...David, thanks! Cheers, Jon> > David >-- Jon Roelofs jonathan at codesourcery.com CodeSourcery / Mentor Embedded
Hi Jon, On 24 June 2014 14:58, Jonathan Roelofs <jonathan at codesourcery.com> wrote:> This patch changes behavior a little for macho_embedded targets (i.e. from > OSType::Unknown to OSType::NoneOS). I see that there is existing code to > transform triples from things like thumbv7-apple-darwin into > thumbv7m-apple-unknown-macho. Do you have an expectation to support users > who are using the latter form of triples who would be surprised by the > change from thumbv7m-apple-unknown-macho to thumbv7m-apple-none-macho (i.e. > their thumbv7m-apple-unknown-macho builds no longer work)?Mostly people should be getting these triples (from out perspective) via "-arch armv7m" and similar, so things should just work for them.> Is this a case where all three triples are to mean the same thing?Well, "-darwin" is different, but that's already taken care of in the driver. I'm actually still a little hazy on when the two being disambiguated would ever be treated differently. But no doubt someone has plans, so I'll watch with interest. Cheers. Tim.
Hi Jon, This looks reasonable to me. Cheers, Amara On 24 June 2014 14:58, Jonathan Roelofs <jonathan at codesourcery.com> wrote:> > > On 6/23/14, 8:31 AM, David Chisnall wrote: >> >> On 23 Jun 2014, at 15:13, Renato Golin <renato.golin at linaro.org> wrote: >> >>> The main issue with your patch is that it can change user expected >>> behaviour, and I can't tell you what is the expected behaviour in >>> Darwin or BSD. If people usually use "unknown" in triples, this will >>> break their builds. If not, this could break the build of someone who >>> does. > > Renato, > > I would like to go this route, providing I can get support from the > community that this is the direction we'd all like to take... I'd rather not > make triples more complicated by introducing lots of special cases. > > Do you know who the right folks are to ask about the SPIR triples? > > > Tim, > > This patch changes behavior a little for macho_embedded targets (i.e. from > OSType::Unknown to OSType::NoneOS). I see that there is existing code to > transform triples from things like thumbv7-apple-darwin into > thumbv7m-apple-unknown-macho. Do you have an expectation to support users > who are using the latter form of triples who would be surprised by the > change from thumbv7m-apple-unknown-macho to thumbv7m-apple-none-macho (i.e. > their thumbv7m-apple-unknown-macho builds no longer work)? Is this a case > where all three triples are to mean the same thing? > > >> >> I think (Hat: FreeBSD) we only expect to see unknown in the vendor field >> (e.g. i386-unknown-freebsd). If the OS field is unknown, rather than >> freebsd, then it's not one of ours and we aren't likely to care. I don't >> really like the way that we conflate OS with ABI, but then I don't really >> like anything about triples... > > David, thanks! > > > Cheers, > Jon > >> >> David >> > > -- > Jon Roelofs > jonathan at codesourcery.com > CodeSourcery / Mentor Embedded > _______________________________________________ > cfe-commits mailing list > cfe-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
Hi Jonathan, This looks a bit odd. Any reason for the unknown->none conflating in this way? For most (all) of the ports unknown-elf works the same as none-elf. I'm also not sure if someone decided to have, arm-codesourcery-elf that this would still work with the patch. Thoughts? -eric On Tue, Jun 24, 2014 at 7:35 AM, Amara Emerson <amara.emerson at gmail.com> wrote:> Hi Jon, > > This looks reasonable to me. > > Cheers, > Amara > > On 24 June 2014 14:58, Jonathan Roelofs <jonathan at codesourcery.com> wrote: >> >> >> On 6/23/14, 8:31 AM, David Chisnall wrote: >>> >>> On 23 Jun 2014, at 15:13, Renato Golin <renato.golin at linaro.org> wrote: >>> >>>> The main issue with your patch is that it can change user expected >>>> behaviour, and I can't tell you what is the expected behaviour in >>>> Darwin or BSD. If people usually use "unknown" in triples, this will >>>> break their builds. If not, this could break the build of someone who >>>> does. >> >> Renato, >> >> I would like to go this route, providing I can get support from the >> community that this is the direction we'd all like to take... I'd rather not >> make triples more complicated by introducing lots of special cases. >> >> Do you know who the right folks are to ask about the SPIR triples? >> >> >> Tim, >> >> This patch changes behavior a little for macho_embedded targets (i.e. from >> OSType::Unknown to OSType::NoneOS). I see that there is existing code to >> transform triples from things like thumbv7-apple-darwin into >> thumbv7m-apple-unknown-macho. Do you have an expectation to support users >> who are using the latter form of triples who would be surprised by the >> change from thumbv7m-apple-unknown-macho to thumbv7m-apple-none-macho (i.e. >> their thumbv7m-apple-unknown-macho builds no longer work)? Is this a case >> where all three triples are to mean the same thing? >> >> >>> >>> I think (Hat: FreeBSD) we only expect to see unknown in the vendor field >>> (e.g. i386-unknown-freebsd). If the OS field is unknown, rather than >>> freebsd, then it's not one of ours and we aren't likely to care. I don't >>> really like the way that we conflate OS with ABI, but then I don't really >>> like anything about triples... >> >> David, thanks! >> >> >> Cheers, >> Jon >> >>> >>> David >>> >> >> -- >> Jon Roelofs >> jonathan at codesourcery.com >> CodeSourcery / Mentor Embedded >> _______________________________________________ >> cfe-commits mailing list >> cfe-commits at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > _______________________________________________ > cfe-commits mailing list > cfe-commits at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
On 24 June 2014 14:58, Jonathan Roelofs <jonathan at codesourcery.com> wrote:> I would like to go this route, providing I can get support from the > community that this is the direction we'd all like to take... I'd rather not > make triples more complicated by introducing lots of special cases.Hi Jonathan, I love breaking legacy stuff, but this is not just up to me. There are a lot of odd triples (quadruples, quintuples and the like) out there that will defy any logic, and they "seem" to work on LLVM as well as GCC (maybe not in the same way) because people can't distinguish or detect the problems well enough. Having said that, Eric raised the same concern I did, which is that unknown != none. Empty string (ex. arm-eabi) defaults to "unknown", and only "none" is NoneOS. That, I think, is paramount because it gives a robust mechanism to reason about triples. Completely orthogonal is what to do when you're facing an empty string or "unknown". My view is that there should be a mechanism, per { target / OS / env }, that would decide, based on the other values, what to do with that. Of course, this mechanism has to be lazily evaluated, so that you have information about the environment while deciding what to do with the OS. Completely bogus examples would be: arm-eabi -> arm-none-eabi arm-gnueabi -> arm-linux-gnueabi arm-elf -> arm-freebsd-elf arm-apple -> arm-apple-darwin and the mapping of what goes where will depend on FreeBSD, Darwin, Linux, etc. for OS, and ARM, x86, PPC, MIPS for the architecture/vendor, etc.> Do you know who the right folks are to ask about the SPIR triples?Tim, David and Eric are already sharing their opinions, which is great.>From an EABI point of view, unknown == none == <empty>. I'm not sosure about the gnueabi/hf, which I'd assume would default to Linux, but would be glad to learn I'm wrong. But, perhaps more importantly, we need to be at least reasonably close to GCC's behaviour. This is a particularly troubling issue on build systems, when the triple is already broken enough to make anyone cramp for weeks, and behaving erratically will only make it less likely that people will try Clang/LLVM in place of GCC in the future. Thread lightly, double check with GCC and make sure triple parsing is orthogonal to triple default behaviour. We already have problems in the parser because the triple changes under the parser's feet. cheers, --renato