Triplet for ARM Linux HardFP ABI, again

[Guillem Jover]

Hi!

This was already discussed in this list some time ago [0]. But it came
up again when restarting the discussion for the proposed new armhf port
for Debian.

  [0] <http://gcc.gnu.org/ml/gcc/2010-07/msg00179.html>

My arguments for why a distinct triplet is needed can be found in [1],
it's a big long though. Most of the points there revolve around the
fact that we rely on the toolchains as configured by _default_ to
produce the expected output targetting a concrete architecture, it
also has implications for the file system paths.

  [1] <http://lists.debian.org/debian-dpkg/2011/02/msg00039.html>

It seems from reading the past discussion on this list that the main
objection was that the triplet should not be used to decide what
floating point ABI to use in gcc. No problem with that!

So, given the arguments put forward in [1], which I think are quite
compelling (but then I guess I'm obviously biased), I was wondering
if you'd consider accepting something ressembling the attached patch
(completely untested, though), which would seem like a compromise we
all might be able to live with, and which would allows us to use a
unique triplet, w/o needing to abuse the vendor field, while gcc would
not need to do anything based on that, our Debian gcc packaging
would choose the floating point ABI depending on the target Debian
architecture, in the same way we do other ABI selections independently
from the triplet.

thanks,
guillem
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-eabi-supermatch.patch
Type: text/x-diff
Size: 6392 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20110221/ec889e06/attachment.bin>