[llvm-commits] [llvm] r123990 - in /llvm/trunk: include/llvm/ADT/Triple.h lib/Support/Triple.cpp unittests/ADT/TripleTest.cpp

[Renato Golin]

On 21/01/11 20:53, Duncan Sands wrote:
> if there is no vendor then you could just output nothing, resulting
> in triples like eg x86_64--linux-gnu
> However if triples with "none" are floating around in the real world then
> this is OK.

Hi Duncan,

Indeed, I completely agree with you, but the way gcc computes the
triples for ARM is to use the "none" when nothing is in there. So, if
the Triples class reports "arm--eabi", it'll never find the
"arm--eabi-gcc" in the path...

This patch is by no means complete and was working around some
deficiencies of the triple mechanism (gcc-wise) not to break all the
other tests.


> I don't think you should be doing this either. Why do you touch this? It
> seems
> quite wrong to me. If you want to do special case logic don't do it
> here, do it
> below at the point that says:
>
> // Special case logic goes here. At this point Arch, Vendor and OS have the
> // correct values for the computed components.

Long story short, all the kludge added to the triple was to make up for
the fact that GCC puts environment in the place of OS (eabi in the third
slot) and the validation of the triple is done while building it.

Meaning that validation will fail if I don't change it on the fly, which
is the same as not doing the change at all. And by putting the code in
the special area below means I'll have to re-normalize after that.



> This is a sign that something is wrong - I suspect this fix is a bandaid
> and the problem would go away if you removed the logic trying to relate OS
> and environment earlier in the normalization logic.

The normalization logic does not know that environment went in the slot
of the OS, and that's why you need the empty bucket to put it in, just
in case. (I agree it's not the best solution, but it was a first step).


> In short, I think you should at most just add NoOs and NoVendor in a trivial
> way, without poking at Parse or Normalize at all. At worst any special case
> logic (and why do you need any?) should go at the point I mentioned above.

Fair enough, but for that I need the validation to be a separate pass,
after the normalization.

That way, I can have a failed OS and Environment, use the special region
to do the env->os logic and only validate after that. Because, according
to GCC, "arm-none-eabi" is a valid triple (widely used as well), but
EABI is not the OS and "none" can mean several things...

If that's ok, I can work on decouple the normalization from the
validation and put the special section in between them two.

cheers,
--renato

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.