[Bug driver/66849] Incorrect multilib chosen with -mthumb -mfloat-abi=hard

["simon at pushface dot org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66849

--- Comment #3 from simon at pushface dot org ---
(In reply to Ramana Radhakrishnan from comment #2)
> (In reply to simon from comment #0)
> > Having configured with
> > 
> >   --target=arm-eabi
> >   --with-arch=armv7
> >   --with-mode=thumb
> 
> If you are interested in armv7-m, please use --with-arch=armv7-m firstly.

I did this; it made no difference at all.

> > I made an overriding specs file,
> > 
> > *multilib:
> > . !marm !mthumb !mfloat-abi=hard;
> > arm marm !mthumb !mfloat-abi=hard;
> > thumb !marm mthumb !mfloat-abi=hard;
> > fpu !marm mthumb mfloat-abi=hard;
> > fpu !marm !mthumb mfloat-abi=hard;
> > arm/fpu marm !mthumb mfloat-abi=hard;
> > 
> > which appears to have done the trick.

This minimal overriding spec works for me:

*multilib:
. !mfloat-abi=hard;
fpu mfloat-abi=hard;

(for reference, donât use multiple spaces in a specs file!)

> Next if you want separate multilibs for float-abi=hard you may want to look
> at some of the commented bits in t-arm to see how to do this or indeed into
> how --with-multilib-list=aprofile works.

GCC has already built separate multilibs!

   . contains -mfloat-abi=soft
   thumb likewise - ??
   fpu -mfloat-abi-hard

Itâs just that GCC doesnât select the right one at link time. I donât see how
this can be "resolved invalidâ?

> Alternatively I do think there's something with the M profile libs that can
> be used today but with some obvious munging to make this work on trunk.
> 
> https://gcc.gnu.org/ml/gcc-patches/2013-07/msg01072.html

Thanks for that. Later, perhaps.