On Mon, May 02, 2016 at 12:54:43PM +0200, Bernd Schmidt wrote: > On 04/30/2016 06:00 PM, Segher Boessenkool wrote: > >On Fri, Apr 29, 2016 at 04:51:27PM -0400, Michael Meissner wrote: > >>2016-04-29 Michael Meissner > >> > >> * config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Add > >> support for __float128 complex datatypes. > >> (rs6000_hard_regno_mode_ok): Likewise. > >> (rs6000_setup_reg_addr_masks): Likewise. > >> (rs6000_complex_function_value): Likewise. > >> * config/rs6000/rs6000.h (FLOAT128_IEEE_P): Likewise. > >> __float128 and __ibm128 complex. > >> (FLOAT128_IBM_P): Likewise. > >> (ALTIVEC_ARG_MAX_RETURN): Likewise. > >> * doc/extend.texi (Additional Floating Types): Document that > >> -mfloat128 must be used to enable __float128. Document complex > >> __float128 and __ibm128 support. > >> > >>[gcc/testsuite] > >>2016-04-29 Michael Meissner > >> > >> * gcc.target/powerpc/float128-complex-1.c: New tests for complex > >> __float128. > >> * gcc.target/powerpc/float128-complex-2.c: Likewise. > > > >The powerpc parts are okay for trunk. Thank you! > > Ok for the other parts as well. Although I wonder: > > >+ /* build_complex_type has set the expected mode to allow having multiple > >+ complex types for multiple floating point types that have the same > >+ size such as the PowerPC with __ibm128 and __float128. If this was > >+ not set, figure out the mode manually. */ > >+ if (TYPE_MODE (type) == VOIDmode) > >+ { > >+ unsigned int precision = TYPE_PRECISION (TREE_TYPE (type)); > >+ enum mode_class mclass = (TREE_CODE (TREE_TYPE (type)) == REAL_TYPE > >+ ? MODE_COMPLEX_FLOAT : MODE_COMPLEX_INT); > >+ SET_TYPE_MODE (type, mode_for_size (2 * precision, mclass, 0)); > >+ } > > What happens if you assert that it isn't VOIDmode? On the PowerPC, I did a full boostrap with the code changed to a gcc_assert, and it didn't trigger. However, in looking at it further, there are only two places that layout_type is called after making a complex node. The first is build_complex_type that I provided a patch for. The other is a similar function in the Fortran front end (gfc_build_complex_type). Now, assuming you only use the 3 standard floating point modes (float_type_node, double_type_node, and long_double_type_node) you wouldn't notice any problem. But if somehow Fortran can create a __float128 type, it would trigger the assertion (in the new patches) or generate the wrong type (in the previous patches). So I would like to commit the following changes (assuming they bootstrap and have no regressions) instead. Are these patches ok for the trunk, and eventually the gcc 6.2 branch if they don't break other back ends? Fortran people, I'm adding you to the To: list, because of the Fortran change. What the problem is the current layout_type uses 2*size of the base type to create the complex type. However, in the current PowerPC, we are transitioning from using IBM extended double format (pair of doubles to give more mantissa bits, but no extra exponent range) to IEEE 128-bit format, and we have two 128-bit complex types. You get all sorts of errors if you want to use the REAL or IMAGINARY parts and you get the wrong type. The patch builds a table that maps a given base mode to the complex mode that uses the base mode as the two elements (i.e. GET_MODE_COMPLEX_MODE (DFmode) would return DCmode. The machine independent changes are in the gcc-stage7.patch003b, and the PowerPC specific changes are in gcc-stage7.patch003c. [gcc] 2016-05-02 Michael Meissner * machmode.h (mode_complex): Add support to give the complex mode for a given mode. (GET_MODE_COMPLEX_MODE): Likewise. * stor-layout.c (layout_type): For COMPLEX_TYPE, use the mode stored by build_complex_type and gfc_build_complex_type instead of trying to figure out the appropriate mode based on the size. Raise an assertion error, if the type was not set. * genmodes.c (struct mode_data): Add field for the complex type of the given type. (blank_mode): Likewise. (make_complex_modes): Remember the complex mode created in the base type. (emit_mode_complex): Write out the mode_complex array to map a type mode to the complex version. (emit_insn_modes_c): Likewise. * tree.c (build_complex_type): Set the complex type to use before calling layout_type. * config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Add support for __float128 complex datatypes. (rs6000_hard_regno_mode_ok): Likewise. (rs6000_setup_reg_addr_masks): Likewise. (rs6000_complex_function_value): Likewise. * config/rs6000/rs6000.h (FLOAT128_IEEE_P): Likewise. __float128 and __ibm128 complex. (FLOAT128_IBM_P): Likewise. (ALTIVEC_ARG_MAX_RETURN): Likewise. * doc/extend.texi (Additional Floating Types): Document that -mfloat128 must be used to enable __float128. Document complex __float128 and __ibm128 support. [gcc/fortran] 2016-05-02 Michael Meissner * trans-types.c (gfc_build_complex_type): [gcc/testsuite] 2016-05-02 Michael Meissner * gcc.target/powerpc/float128-complex-1.c: New tests for complex __float128. * gcc.target/powerpc/float128-complex-2.c: Likewise. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797