Ping? Best regards,
Thomas On 24/10/16 09:07, Thomas Preudhomme wrote:
Ping? Best regards, Thomas On 13/10/16 16:35, Thomas Preudhomme wrote:Hi ARM maintainers, This patchset aims at adding multilib support for R and M profile ARM architectures and allowing it to be built alongside multilib for A profile ARM architectures. This specific patch is concerned with the latter. The patch works by moving the bits shared by both aprofile and rmprofile multilib build (variable initilization as well as ISA and float ABI to build multilib for) to a new t-multilib file. Then, based on which profile was requested in --with-multilib-list option, that files includes t-aprofile and/or t-rmprofile where the architecture and FPU to build the multilib for are specified. Unfortunately the duplication of CPU to A profile architectures could not be avoided because substitution due to MULTILIB_MATCHES are not transitive. Therefore, mapping armv7-a to armv7 for rmprofile multilib build does not have the expected effect. Two patches were written to allow this using 2 different approaches but I decided against it because this is not the right solution IMO. See caveats below for what I believe is the correct approach. *** combined build caveats *** As the documentation in this patch warns, there is a few caveats to using a combined multilib build due to the way the multilib framework works. 1) For instance, when using only rmprofile the combination of options -mthumb -march=armv7 -mfpu=neon the thumb/-march=armv7 multilib but in a combined multilib build the default multilib would be used. This is because in the rmprofile build -mfpu=neon is not specified in MULTILIB_OPTION and thus the option is ignored when considering MULTILIB_REQUIRED entries. 2) Another issue is the fact that aprofile and rmprofile multilib build have some conflicting requirements in terms of how to map options for which no multilib is built to another option. (i) A first example of this is the difference of CPU to architecture mapping mentionned above: rmprofile multilib build needs A profile CPUs and architectures to be mapped down to ARMv7 so that one of the v7-ar multilib gets chosen in such a case but aprofile needs A profile architectures to stand on their own because multilibs are built for several architectures. (ii) Another example of this is that in aprofile multilib build no multilib is built with -mfpu=fpv5-d16 but some multilibs are built with -mfpu=fpv4-d16. Therefore, aprofile defines a match rule to map fpv5-d16 onto fpv4-d16. However, rmprofile multilib profile *does* build some multilibs with -mfpu=fpv5-d16. This has the consequence that when building for -mthumb -march=armv7e-m -mfpu=fpv5-d16 -mfloat-abi=hard the default multilib is chosen because this is rewritten into -mthumb -march=armv7e-m -mfpu=fpv5-d16 -mfloat-abi=hard and there is no multilib for that. Both of these issues could be handled by using MULTILIB_REUSE instead of MULTILIB_MATCHES but this would require a large set of rules. I believe instead the right approach is to create a new mechanism to inform GCC on how options can be down mapped _when no multilib can be found_ which would require a smaller set of rules and would make it explicit that the options are not equivalent. A patch will be posted to this effect at a later time. ChangeLog entry is as follows: *** gcc/ChangeLog *** 2016-10-03 Thomas Preud'homme <thomas.preudho...@arm.com> * config.gcc: Allow combinations of aprofile and rmprofile values for --with-multilib-list. * config/arm/t-multilib: New file. * config/arm/t-aprofile: Remove initialization of MULTILIB_* variables. Remove setting of ISA and floating-point ABI in MULTILIB_OPTIONS and MULTILIB_DIRNAMES. Set architecture and FPU in MULTI_ARCH_OPTS_A and MULTI_ARCH_DIRS_A rather than MULTILIB_OPTIONS and MULTILIB_DIRNAMES respectively. Add comment to introduce all matches. Add architecture matches for marvel-pj4 and generic-armv7-a CPU options. * config/arm/t-rmprofile: Likewise except for the matches changes. * doc/install.texi (--with-multilib-list): Document the combination of aprofile and rmprofile values and warn about pitfalls in doing that. Testing: * "tree install/lib/gcc/arm-none-eabi/7.0.0" is the same before and after the patchset for both aprofile and rmprofile * "tree install/lib/gcc/arm-none-eabi/7.0.0" is the same for aprofile,rmprofile and rmprofile,aprofile * default spec (gcc -dumpspecs) is the same for aprofile,rmprofile and rmprofile,aprofile * Difference in --print-multi-directory between aprofile or rmprofile and aprofile,rmprofile for all combination of ISA (ARM/Thumb), architecture, CPU, FPU and float ABI is as expected (best multilib for the combination is chosen), modulo the caveat mentionned above and the new marvel-pj4 and generic-armv7-a CPU to architecture mapping. Is this ok for master? Best regards, Thomas
