This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add support for ARM embedded multilibs
- From: Ramana Radhakrishnan <ramana dot radhakrishnan at foss dot arm dot com>
- To: "Jasmin J." <jasmin at anw dot at>, Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Tejas Belagod <Tejas dot Belagod at arm dot com>
- Date: Wed, 4 Nov 2015 09:43:49 +0000
- Subject: Re: [PATCH] Add support for ARM embedded multilibs
- Authentication-results: sourceware.org; auth=none
- References: <56395178 dot 8000006 at anw dot at> <CAJA7tRbQPN2HDtP3HjASn6W5s=Lg83k9+DDDJ92_GjDAs95BBw at mail dot gmail dot com> <5639C54F dot 5070700 at anw dot at>
On 04/11/15 08:43, Jasmin J. wrote:
> Hello Ramana!
>
>> Thank you for your patch - In this case before you make any more
>> changes to this patch - comparing your patch and Terry's patch here
>> https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00729.html shows no real
>> differences
> As I wrote in the patch, it is a port from the embedded-4_9-branch and it
> is exactly what Terry did. I didn't know this patch. I extracted it from
> the branch.
>
> All other stuff required to build a gcc for the ARM embedded CPUs are already
> on gcc trunk. This last piece is missing to get rid of the embedded-X_X-branch!
> I would love to see it in mainline GCC.
CC'ing Tejas as he now looks after this branch internally at ARM. There are usually features on the embedded-X_X-branch used to create releases that may not be on an FSF release branch.
>
>> I would like to ask if you have a copyright assignment on file with the FSF
> I will do that.
So, you don't have one ? In which case it may make more sense for Tejas to deal with this given he can handle it under ARM's copyright assignment. If you make changes to this without a copyright assignment on file and submit it, it may be difficult to review this from a copyright position.
>
>> How was your patch tested
> The patch is old an doesn't contain any real GCC change, but support for the
> library building process only. This was used since 15 months by many people
> and I used it to build an ARM embedded compiler based on gcc-5-branch.
Changing the way in which you build GCC is a real change to GCC that affects many developers. Not testing your change by building and checking that it does what it says on the tin is unacceptable.
>
>> see for example how I added t-aprofile to the backend and the kind of
>> testing it underwent
> I will look on that, if it is really required.
>
>>> * configure.ac (with_multilib_list): Export for being used in arm
>>> embedded multilib fragment.
>>> * Makefile.in (with_multilib_list): Import for being used in
>>> multilib fragment.
>>
>> This is already being used in config.gcc - why do you need this
>> additional hunk ?
> To be hones, I ported the patch and checked if it works. I will analyse it more
> detailed, if this is really required.
>
>> The t-rmprofile file will need updating to newer values for -mcpu and
>> march as well as comments up top to explain what multilibs are being
>> built .
> Where can I find them?
gcc/doc/invoke.texi should document the rest.. I think mapping all the remaining -mcpu=cortex-a* cores and -mcpu=cortex-m* cores in there would be a sensible first step.
regards
Ramana
>
> BR
> Jasmin
>