This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, rs6000, C/C++] Fix PR target/86324: divkc3-1.c FAILs when compiling with -mabi=ieeelongdouble
- From: Segher Boessenkool <segher at kernel dot crashing dot org>
- To: Peter Bergner <bergner at linux dot ibm dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, Jonathan Wakely <jwakely at redhat dot com>, Bill Schmidt <wschmidt at linux dot ibm dot com>, Michael Meissner <meissner at linux dot ibm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 27 Jun 2018 16:35:23 -0500
- Subject: Re: [PATCH, rs6000, C/C++] Fix PR target/86324: divkc3-1.c FAILs when compiling with -mabi=ieeelongdouble
- References: <bcca27f4-571b-025a-bc8f-fec4944f3ba4@linux.ibm.com>
On Wed, Jun 27, 2018 at 03:26:42PM -0500, Peter Bergner wrote:
> The test case in PR86324 exposes a problem when long double is the same as
> __ieee128 and we attempt to use the KC mode attribute. A complimentary
> problem exists when long double is the same as __ibm128 and we try to use
> the IC mode attribute. The problem is that for the type that long double
> is set to, we always use internally the long double type and TFmode/TCmode
> rather than __ieee128/K[FC]mode or __ibm128/I[FC]mode, so we have problems
> when looking up the unused modes during attribute processing.
>
> Talking with Joseph offline, he suggested to add a hook that allows the
> target to translate mode attributes like the above into the mode that
> should be used. The patch below implements that suggestion and it fixes
> the problem test cases.
>
> This passed bootstrap and regtesting with no regressions on powerpc64le-linux.
> Ok for trunk?
>
> This is also broken in GCC 8, is this ok to backport once it has has baked
> on trunk for a few days and assuming testing comes out clean?
>
> The pr86324-2.c test case is also broken in GCC 7, but it looks like that
> has been broken forever, so I'm not sure I'm inclined to want to backport
> this that far. Thoughts?
This is all okay with me, if someone approves the generic parts.
One thing:
> --- gcc/target.def (revision 262159)
> +++ gcc/target.def (working copy)
> @@ -3310,6 +3310,16 @@ constants can be done inline. The funct
> HOST_WIDE_INT, (const_tree constant, HOST_WIDE_INT basic_align),
> default_constant_alignment)
>
> +DEFHOOK
> +(translate_mode_attribute,
> + "Define this hook if the port should translate machine_mode @var{mode}\n\
> +to another mode. For example, rs6000's @code{KFmode}, when it is the same\n\
> +as @code{TFmode}.\n\
> +\n\
> +The default version of the hook returns that mode that was passed in.",
> + machine_mode, (machine_mode mode),
> + default_translate_mode_attribute)
It isn't clear here when this hook is called. Is the idea to use it
everywhere where modes are created, or only where it is used now (the arg
to a "mode" attribute)? Probably the latter, but it's not really clear
from the text.
Thanks,
Segher