On Thu, Dec 13, 2018 at 5:26 AM Alan Modra <amo...@gmail.com> wrote: > > On Wed, Nov 14, 2018 at 01:43:57PM +1030, Alan Modra wrote: > > On Tue, Nov 13, 2018 at 05:17:41AM -0600, Segher Boessenkool wrote: > > > On Tue, Nov 13, 2018 at 12:02:55PM +1030, Alan Modra wrote: > > > > OK, fair enough. Another option is to just disable -many when gcc is > > > > in development, like we enable checking. > > > > > > That is a good plan for GCC 9 at least. > > > > Here's the patch. Bootstrapped etc. powerpc64le-linux with resultant > > fail of clone2 test as already noted. > > Revised again, with a bunch of related issues solved. Bootstrapped > etc. powerpc64le-linux with no regressions. OK to apply mainline? > > --- > I'd like to remove -many from the options passed by default to the > assembler, on the grounds that a gcc bug in instruction selection (eg. > emitting a power9 insn for -mcpu=power8) is better found at assembly > time than run time. > > For now, just do this when --enable-checking or gcc is not a release. > > In contrast to the previous patch, I haven't changed any of the AIX > header files in this patch. So AIX gcc will continue to pass -many to > their assembler until someone else (David?) makes that change. This > patch also emits .machine assembler directives for ELF targets when > functions are compiled for different cpus via attributes or pragmas. > That's necessary when the initial -m<cpu> option passed to the > assembler doesn't enable the superset of all opcodes emitted, as seen > by the earlier failure of gcc.target/powerpc/clone2.c (without > .machine) when building gcc for power8.
The AIX release schedule and numbering of releases to support new processors is making it impossible to reliably predict which directives (processor names) will be supported on a system on which GCC is installed. It's safer to hide the problem on AIX with the use of -many. Thanks, David
