On 6/23/14, 8:31 AM, David Chisnall wrote:
On 23 Jun 2014, at 15:13, Renato Golin <[email protected]> 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
[email protected]
CodeSourcery / Mentor Embedded
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
