This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, rs6000, C/C++] Fix PR target/86324: divkc3-1.c FAILs when compiling with -mabi=ieeelongdouble


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]