On Wed, 2 Nov 2016, James Greenhalgh wrote:
> OK, I've reworked the patch along those lines. I noticed that the original
> logic looked for
>
> && TARGET_FLT_EVAL_METHOD != 0
>
> And I no longer make that check. Is that something I need to reinstate?
No, the replacement logic should imply that previously supported cases
with TARGET_FLT_EVAL_METHOD == 0 will pass as being IEEE-compatible.
> I didn't find any reference to excess precision in Annex F, so I'd guess
> not?
There are references, e.g. F.6 requiring that the return statement removes
excess precision (but that's something done in the front end, nothing to
do with this patch).
> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
> index 547bab2..507967d 100644
> --- a/gcc/c-family/c-common.h
> +++ b/gcc/c-family/c-common.h
> @@ -1314,6 +1314,8 @@ c_tree_chain_next (tree t)
> #define TM_STMT_ATTR_ATOMIC 4
> #define TM_STMT_ATTR_RELAXED 8
>
> +extern int parse_tm_stmt_attr (tree, int);
> +
> /* Mask used by tm_attr_to_mask and tm_mask_to_attr. Note that these
> are ordered specifically such that more restrictive attributes are
> at lower bit positions. This fact is known by the C++ tm attribute
> @@ -1325,6 +1327,10 @@ c_tree_chain_next (tree t)
> #define TM_ATTR_IRREVOCABLE 8
> #define TM_ATTR_MAY_CANCEL_OUTER 16
>
> +extern int tm_attr_to_mask (tree);
> +extern tree tm_mask_to_attr (int);
> +extern tree find_tm_attribute (tree);
> +
> /* A suffix-identifier value doublet that represents user-defined literals
> for C++-0x. */
> enum overflow_type {
These changes to c-common.h are nothing to do with the subject of the
patch.
The patch is OK with those changes removed. If there are other changes in
this series still needing review, please repost the whole series
identifying what patches still need review. (I think the ARM _Float16
support still needs the testsuite changes to ensure that
architecture-specific options to enable _FloatN / _FloatNx support are
used when testing if the types are supported, so that the _Float16 tests
are actually run in that case.)
--
Joseph S. Myers
jos...@codesourcery.com
