Re: [PATCH i386 AVX512] [31/n] Update float unspec namely storeu,rcp14,rsqrt14,scalef,getexp,fixupimm,rndscale,getmant.
On Fri, Aug 29, 2014 at 3:23 PM, Kirill Yukhin wrote:
> Hello,
> Patch in the bottom updates few UNSPEC insn patterns w/ new
> mode iterator. Additionally names were slightly changed.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/i386.c
> (avx512f_getmantv2df_round): Rename to ...
> (avx512f_vgetmantv2df_round): this.
> (avx512f_getmantv4sf_round): Rename to ...
> (avx512f_vgetmantv4sf_round): this.
> (ix86_expand_args_builtin): Handle avx512vl_getmantv8sf_mask,
> avx512vl_getmantv4df_mask, avx512vl_getmantv4sf_mask,
> avx512vl_getmantv2df_mask.
> (ix86_expand_round_builtin): Handle avx512f_vgetmantv2df_round,
> avx512f_vgetmantv4sf_round.
> * config/i386/sse.md
> (define_insn "avx512f_storeu512_mask"): Delete.
> (define_insn "_storeu_mask"):
> New.
> (define_insn "rcp14"): Use VF_AVX512VL.
> (define_insn "rsqrt14"): Ditto.
> (define_insn "avx512f_scalef"): Delete.
> (define_insn "_scalef"): New.
> (define_insn "avx512f_getexp"):
> Delete.
> (define_insn "_getexp"):
> New.
> (define_expand
> "avx512f_fixupimm_maskz"): Delete.
> (define_expand
> "_fixupimm_maskz"): New.
> (define_insn
> "avx512f_fixupimm"): Delete.
> (define_insn
> "_fixupimm"): New.
> (define_insn "avx512f_fixupimm_mask"):
> Delete.
> (define_insn "_fixupimm_mask"): New.
> (define_insn "avx512f_rndscale"):
> Delete.
> (define_insn
> "_rndscale"): New.
> (define_insn "avx512f_getmant"):
> Delete.
> (define_insn "_getmant"):
> New.
> (define_insn "avx512f_getmant"): Rename to
> ...
> (define_insn "avx512f_vgetmant"): this.
Please change ChangeLog entries to mention that these patterns are
*renamed*, not *deleted*. So, something like:
("new pattern"): Rename from "old pattern" and use VF_AVX512VL mode iterator.
Otherwise, nice patch that actually shows the power of mode iterators
and mode attributes!
OK with updated ChangeLog.
Thanks,
Uros.
Re: [PATCH i386 AVX512] [32/n] Add reduce,range,fpclass.
On Fri, Aug 29, 2014 at 3:55 PM, Kirill Yukhin wrote:
> Patch in the bottom adds support for reduce,range,fpclass.
>
> Bootstrapped.
> AVX-512* tests on top of patch-set all pass
> under simulator.
>
> Is it ok for trunk?
>
> gcc/
> * config/i386/i386.c
> (ix86_expand_args_builtin): Handle avx512dq_rangepv8df_mask_round,
> avx512dq_rangepv16sf_mask_round, avx512dq_rangepv4df_mask,
> avx512dq_rangepv8sf_mask, avx512dq_rangepv2df_mask,
> avx512dq_rangepv4sf_mask.
> * config/i386/sse.md
> (define_c_enum "unspec"): Add UNSPEC_REDUCE, UNSPEC_FPCLASS,
> UNSPEC_FPCLASS_SCALAR, UNSPEC_RANGE, UNSPEC_RANGE_SCALAR.
> (define_insn "reducep"): New.
> (define_insn "reduces"): Ditto.
> (define_insn "avx512dq_rangep"):
> Ditto.
> (define_insn "avx512dq_ranges"): Ditto.
> (define_insn "avx512dq_fpclass"): Ditto.
> (define_insn "avx512dq_vmfpclass"): Ditto.
>
> --
> Thanks, K
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index ff37ffe..15cdb5e 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -34114,6 +34114,12 @@ ix86_expand_args_builtin (const struct
> builtin_description *d,
> case CODE_FOR_avx512vl_getmantv4df_mask:
> case CODE_FOR_avx512vl_getmantv4sf_mask:
> case CODE_FOR_avx512vl_getmantv2df_mask:
> + case CODE_FOR_avx512dq_rangepv8df_mask_round:
> + case CODE_FOR_avx512dq_rangepv16sf_mask_round:
> + case CODE_FOR_avx512dq_rangepv4df_mask:
> + case CODE_FOR_avx512dq_rangepv8sf_mask:
> + case CODE_FOR_avx512dq_rangepv2df_mask:
> + case CODE_FOR_avx512dq_rangepv4sf_mask:
> error ("the last argument must be a 4-bit immediate");
> return const0_rtx;
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index d85f9a4..c505526 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -128,6 +128,13 @@
>UNSPEC_SHA256MSG1
>UNSPEC_SHA256MSG2
>UNSPEC_SHA256RNDS2
> +
> + ;; For AVX512DQ support
> + UNSPEC_REDUCE
> + UNSPEC_FPCLASS
> + UNSPEC_FPCLASS_SCALAR
> + UNSPEC_RANGE
> + UNSPEC_RANGE_SCALAR
> ])
It looks to me that _SCALAR unspecs are redundant, and should be
possible to use UNSPEC_REDUCE for all patterns without unwanted
matching.
Uros.
Re: [PATCH i386 AVX512] [33/n] Add patterns for compress, expand.
On Fri, Aug 29, 2014 at 4:00 PM, Kirill Yukhin wrote: > Patch in the bottom extends support of compress and expand > insns. > > Bootstrapped. > AVX-512* tests on top of patch-set all pass > under simulator. > > Is it ok for trunk? > > gcc/ > * config/i386/sse.md > (define_mode_iterator VI48F): New. > (define_insn "avx512f_compress_mask"): Delete. > (define_insn "_compress_mask"): New. > (define_insn "avx512f_compressstore_mask"): Delete. > (define_insn "_compressstore_mask"): New. > (define_expand "avx512f_expand_maskz"): Delete. > (define_expand "_expand_maskz"): New. > (define_insn "avx512f_expand_mask"): Delete. > (define_insn "_expand_mask"): New. Again, rename instead of delete/new. The patch is OK. Please note that you can use UNSPEC_COMPRESS everywhere, there is no need for UNSPEC_COMPRESS_STORE and can be deleted. On a related note, it looks to me that UNSPEC_COMPRESS patterns can be merged together by using nonimmediate operand 0 and matched memory. Please see the last constraint of sse_movhlps for example. This can be a follow-up patch. Thanks, Uros.
Re: [Patch, Fortran] CAF dep (1/3): PR62278 - improve dependency.c's gfc_check_dependency's check (missed-optimization)
Dear Tobias, Given Dominques news that this fixes a golden oldie that drove me to madness and PR60593 - OK for trunk, 4.8 and 4.9 Many thanks for the patch Paul On 27 August 2014 22:59, Tobias Burnus wrote: > The current gfc_check_dependency check always looked at the pointer > attribute - and assumed the worst, if either the LHS or the RHS was true. > > Thus, it claimed that "a" and "b" alias for the following definition: > integer, pointer :: p; integer :: a. However, as "a" has no target (or > pointer) attribute, that's not possible. Additionally, "class(t) :: a" has > internally the "pointer" attribute (but CLASS_DATA(sym)->attr.class_pointer > == 0), however, in the Fortran sense, "a" is not a pointer and cannot alias. > > I do not have a good example for the test case, except for a similar one as > above using "a[i] = p" and looking at the dump; but that requires patch 3/3 > of this series. > > Build and regtested on x86-64-gnu-linux. (I do get a failure for > gfortran.dg/graphite/pr42393.f90, but only with -O1 -fgraphite-identity and > also without the patch.) > > OK for the trunk? > > Tobias -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Make many more options use CPP()
This converts almost all remaining CPP options to use CPP() in the
*.opt files. Following your comment here
(https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02499.html) several
options now use explicit Init().
The only test I needed to tweak was gcc.dg/cpp/endif-pedantic2.c,
which tests that "-Wno-endif-labels -pedantic-errors" gives errors for
-Wendif-labels warnings. This might be the original intention
(https://gcc.gnu.org/ml/gcc-patches/2002-03/msg01732.html) but it is
at odds with how other -Wno-* flags work.
The current behavior enforced by the automatic machinery is that more
specific options have priority over more general options,
independently of the order. Although this is not documented in the
manual, it has been the consensus of several recent discussions (and
not so recent ones https://gcc.gnu.org/ml/gcc/2007-05/msg00720.html).
It would be a burden to special-case -Wno-endif-labels just for
keeping backwards compatibility. The affected users are likely very
few (if any): those that expect "-Wno-endif-labels -pedantic" to give
-Wendif-labels warnings. The effect on those users would be that they
won't get the warnings they expect until they remove -Wno-endif-labels
or append an explicit -Wendif-labels.
The two remaining options are a bit problematic:
1) -Wall enables warn_sign_change, which does not have a -W* flag. I
could simply add one but perhaps it would be better under an already
existing flag.
2) -Wnormalized requires a bit more of special handling. I will try to
use the Enum() facility in the *.opt file if possible.
Bootstrapped and regression tested on x86_64-linux-gnu.
OK?
gcc/ChangeLog:
2014-08-30 Manuel López-Ibáñez
* doc/options.texi: Document that Var and Init are required if CPP
is given.
* optc-gen.awk: Require Var and Init if CPP is given.
* common.opt (Wpedantic): Use Init.
libcpp/ChangeLog:
2014-08-30 Manuel López-Ibáñez
* macro.c (replace_args): Use cpp_pedwarning, cpp_warning and
CPP_W flags.
* include/cpplib.h: Add CPP_W_C90_C99_COMPAT and CPP_W_PEDANTIC.
* init.c (cpp_create_reader): Do not init to -1 here.
* expr.c (num_binary_op): Use cpp_pedwarning.
gcc/c-family/ChangeLog:
2014-08-30 Manuel López-Ibáñez
* c.opt (Wc90-c99-compat,Wc++-compat,Wcomment,Wendif-labels,
Winvalid-pch,Wlong-long,Wmissing-include-dirs,Wmultichar,Wpedantic,
(Wdate-time,Wtraditional,Wundef,Wvariadic-macros): Add CPP, Var
and Init.
* c-opts.c (c_common_handle_option): Do not handle here.
(sanitize_cpp_opts): Likewise.
* c-common.c (struct reason_option_codes_t): Handle
CPP_W_C90_C99_COMPAT and CPP_W_PEDANTIC.
gcc/testsuite/ChangeLog:
2014-08-30 Manuel López-Ibáñez
* gcc.dg/cpp/endif-pedantic2.c: More general options do not
override specific ones, but specific ones do.
Index: gcc/doc/options.texi
===
--- gcc/doc/options.texi(revision 214735)
+++ gcc/doc/options.texi(working copy)
@@ -483,8 +483,9 @@ The option is omitted from the producer
Even if this is a target option, this option will not be recorded / compared
to determine if a precompiled header file matches.
@item CPP(@var{var})
The state of this option should be kept in sync with the preprocessor
-option @var{var}.
+option @var{var}. If this property is set, then properties @code{Var}
+and @code{Init} must be set as well.
@end table
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt (revision 214735)
+++ gcc/c-family/c.opt (working copy)
@@ -294,19 +294,19 @@ Warn about boolean expression compared w
Wbuiltin-macro-redefined
C ObjC C++ ObjC++ CPP(warn_builtin_macro_redefined)
Var(cpp_warn_builtin_macro_redefined) Init(1) Warning
Warn when a built-in preprocessor macro is undefined or redefined
Wc90-c99-compat
-C ObjC Var(warn_c90_c99_compat) Init(-1) Warning
+C ObjC CPP(cpp_warn_c90_c99_compat) Var(warn_c90_c99_compat) Init(-1) Warning
Warn about features not present in ISO C90, but present in ISO C99
Wc99-c11-compat
C ObjC Var(warn_c99_c11_compat) Init(-1) Warning
Warn about features not present in ISO C99, but present in ISO C11
Wc++-compat
-C ObjC Var(warn_cxx_compat) Warning
+C ObjC Var(warn_cxx_compat) CPP(warn_cxx_operator_names) Init(0) Warning
Warn about C constructs that are not in the common subset of C and C++
Wc++0x-compat
C++ ObjC++ Var(warn_cxx0x_compat) Warning LangEnabledBy(C++ ObjC++,Wall)
Deprecated in favor of -Wc++11-compat
@@ -326,11 +326,11 @@ Warn about subscripts whose type is \"ch
Wclobbered
C ObjC C++ ObjC++ Var(warn_clobbered) Warning EnabledBy(Wextra)
Warn about variables that might be changed by \"longjmp\" or \"vfork\"
Wcomment
-C ObjC C++ ObjC++ CPP(warn_comments) Var(cpp_warn_comment) Warning
LangEnabledBy(C ObjC C++ ObjC++,Wall)
+C ObjC C++ ObjC++ CPP(warn_comments) Var(cpp_warn_comment) Init(0) Warning
LangEnabledBy(C
Re: [PATCH v2] Re: PR62304 (was Re: (Still) ICE for cris-elf at r214710)
On Fri, 2014-08-29 at 23:41 -0600, Jeff Law wrote: > On 08/29/14 12:07, David Malcolm wrote: > > > > > Yes: I made various mistakes in reorg.c and resource.c where I assumed > > that a JUMP_LABEL(insn) was an insn, whereas the existing code is set up > > to handle RETURN nodes. > Well, it would seem to me that reorg is being totally braindead in > mixing and matching these two nodes. In particular whatever code is > passing around a RETURN rtx into places that normally accept some kind > of INSN would appear to be broken. > > > > > It eliminates all uses of JUMP_LABEL_AS_INSN from reorg.c, and indeed > > after that there are only 6 uses in the tree (including config subdirs). > Good to some extent as I see JUMP_LABEL_AS_INSN as papering over bugs > elsewhere, but this patch is also a step backwards as we're papering > over a mess in reorg.c. > > > > > > 2014-08-29 David Malcolm > > > > PR bootstrap/62304 > > > > * gcc/reorg.c (skip_consecutive_labels): Convert return type and > > param back from rtx_insn * to rtx. Rename param from "label" to > > "label_or_return", reintroducing "label" as an rtx_insn * after > > we've ensured it's not a RETURN. > > (first_active_target_insn): Likewise for return type and param; > > add a checked cast to rtx_insn * once we've ensured "insn" is not > > a RETURN. > > (steal_delay_list_from_target): Convert param "pnew_thread" back > > from rtx_insn ** to rtx *. Replace use of JUMP_LABEL_AS_INSN > > with JUMP_LABEL. > > (own_thread_p): Convert param "thread" back from an rtx_insn * to > > an rtx. Introduce local rtx_insn * "thread_insn" with a checked > > cast once we've established we're not dealing with a RETURN, > > renaming subsequent uses of "thread" to "thread_insn". > > (fill_simple_delay_slots): Convert uses of JUMP_LABEL_AS_INSN back > > to JUMP_LABEL. > > (follow_jumps): Convert return type and param "label" from > > rtx_insn * back to rtx. Move initialization of "value" to after > > the handling for ANY_RETURN_P, adding a checked cast there to > > rtx_insn *. Convert local rtx_insn * "this_label" to an rtx and > > rename to "this_label_or_return", reintroducing "this_label" as > > an rtx_insn * once we've handled the case where it could be an > > ANY_RETURN_P. > > (fill_slots_from_thread): Rename param "thread" to > > "thread_or_return", converting from an rtx_insn * back to an rtx. > > Reintroduce name "thread" as an rtx_insn * local with a checked > > cast once we've handled the case of it being an ANY_RETURN_P. > > Convert local "new_thread" from an rtx_insn * back to an rtx. > > Add a checked cast when assigning to "trial" from "new_thread". > > Convert use of JUMP_LABEL_AS_INSN back to JUMP_LABEL. Add a > > checked cast to rtx_insn * from "new_thread" when invoking > > get_label_before. > > (fill_eager_delay_slots): Convert locals "target_label", > > "insn_at_target" from rtx_insn * back to rtx. > > Convert uses of JUMP_LABEL_AS_INSN back to JUMP_LABEL. > > (relax_delay_slots): Convert locals "trial", "target_label" from > > rtx_insn * back to rtx. Convert uses of JUMP_LABEL_AS_INSN back > > to JUMP_LABEL. Add a checked cast to rtx_insn * on "trial" when > > invoking update_block. > > (dbr_schedule): Convert use of JUMP_LABEL_AS_INSN back to > > JUMP_LABEL; this removes all JUMP_LABEL_AS_INSN from reorg.c. > > > > * resource.h (mark_target_live_regs): Undo erroneous conversion > > of second param of r214693, converting it back from rtx_insn * to > > rtx, since it could be a RETURN. > > > > * resource.c (find_dead_or_set_registers): Similarly, convert > > param "jump_target" back from an rtx_insn ** to an rtx *, as we > > could be writing back a RETURN. Rename local rtx_insn * "next" to > > "next_insn", and introduce "lab_or_return" as a local rtx, > > handling the case where JUMP_LABEL (this_jump_insn) is a RETURN. > > (mark_target_live_regs): Undo erroneous conversion > > of second param of r214693, converting it back from rtx_insn * to > > rtx, since it could be a RETURN. Rename it from "target" to > > "target_maybe_return", reintroducing the name "target" as a local > > rtx_insn * with a checked cast, after we've handled the case of > > ANY_RETURN_P. > I'll OK as a means to restore the trunk to working order, but let's add > a follow-up item to track down places where we're passing things like a > RETURN rtx in places where we really are expecting insns. Thanks; bootstrapped on x86_64 and ppc (gcc110); committed to trunk as r214752. I plan to have a close look at everywhere that JUMP_LABEL is not an insn, though I may wait to after current stage1 to do that; for this stage1 my primary objective for rtx-classes is to use them to document the existing status quo, and I hope to context-switch back to trying to me
[committed] Update libstdc++ baseline symbols on hppa-linux
We now have support for "future" on hppa-linux. The attached change updates the baseline symbols for it. Tested on hppa-unknown-linux-gnu. Committed to trunk. Dave -- John David Anglin dave.ang...@bell.net 2014-08-30 John David Anglin * config/abi/post/hppa-linux-gnu/baseline_symbols.txt: Update. Index: config/abi/post/hppa-linux-gnu/baseline_symbols.txt === --- config/abi/post/hppa-linux-gnu/baseline_symbols.txt (revision 214556) +++ config/abi/post/hppa-linux-gnu/baseline_symbols.txt (working copy) @@ -384,6 +384,9 @@ FUNC:_ZNKSt14error_category10equivalentERKSt10error_codei@@GLIBCXX_3.4.11 FUNC:_ZNKSt14error_category10equivalentEiRKSt15error_condition@@GLIBCXX_3.4.11 FUNC:_ZNKSt14error_category23default_error_conditionEi@@GLIBCXX_3.4.11 +FUNC:_ZNKSt15__exception_ptr13exception_ptr20__cxa_exception_typeEv@@CXXABI_1.3.3 +FUNC:_ZNKSt15__exception_ptr13exception_ptrcvMS0_FvvEEv@@CXXABI_1.3.3 +FUNC:_ZNKSt15__exception_ptr13exception_ptrntEv@@CXXABI_1.3.3 FUNC:_ZNKSt15basic_streambufIcSt11char_traitsIcEE4gptrEv@@GLIBCXX_3.4 FUNC:_ZNKSt15basic_streambufIcSt11char_traitsIcEE4pptrEv@@GLIBCXX_3.4 FUNC:_ZNKSt15basic_streambufIcSt11char_traitsIcEE5ebackEv@@GLIBCXX_3.4 @@ -1207,6 +1210,7 @@ FUNC:_ZNSt11range_errorD1Ev@@GLIBCXX_3.4 FUNC:_ZNSt11range_errorD2Ev@@GLIBCXX_3.4.15 FUNC:_ZNSt11regex_errorC1ENSt15regex_constants10error_typeE@@GLIBCXX_3.4.20 +FUNC:_ZNSt11regex_errorC2ENSt15regex_constants10error_typeE@@GLIBCXX_3.4.21 FUNC:_ZNSt11regex_errorD0Ev@@GLIBCXX_3.4.15 FUNC:_ZNSt11regex_errorD1Ev@@GLIBCXX_3.4.15 FUNC:_ZNSt11regex_errorD2Ev@@GLIBCXX_3.4.15 @@ -1291,6 +1295,17 @@ FUNC:_ZNSt12system_errorD0Ev@@GLIBCXX_3.4.11 FUNC:_ZNSt12system_errorD1Ev@@GLIBCXX_3.4.11 FUNC:_ZNSt12system_errorD2Ev@@GLIBCXX_3.4.11 +FUNC:_ZNSt13__future_base11_State_baseD0Ev@@GLIBCXX_3.4.15 +FUNC:_ZNSt13__future_base11_State_baseD1Ev@@GLIBCXX_3.4.15 +FUNC:_ZNSt13__future_base11_State_baseD2Ev@@GLIBCXX_3.4.15 +FUNC:_ZNSt13__future_base12_Result_baseC1Ev@@GLIBCXX_3.4.15 +FUNC:_ZNSt13__future_base12_Result_baseC2Ev@@GLIBCXX_3.4.15 +FUNC:_ZNSt13__future_base12_Result_baseD0Ev@@GLIBCXX_3.4.15 +FUNC:_ZNSt13__future_base12_Result_baseD1Ev@@GLIBCXX_3.4.15 +FUNC:_ZNSt13__future_base12_Result_baseD2Ev@@GLIBCXX_3.4.15 +FUNC:_ZNSt13__future_base19_Async_state_commonD0Ev@@GLIBCXX_3.4.17 +FUNC:_ZNSt13__future_base19_Async_state_commonD1Ev@@GLIBCXX_3.4.17 +FUNC:_ZNSt13__future_base19_Async_state_commonD2Ev@@GLIBCXX_3.4.17 FUNC:_ZNSt13bad_exceptionD0Ev@@GLIBCXX_3.4 FUNC:_ZNSt13bad_exceptionD1Ev@@GLIBCXX_3.4 FUNC:_ZNSt13bad_exceptionD2Ev@@GLIBCXX_3.4 @@ -1586,6 +1601,18 @@ FUNC:_ZNSt15_List_node_base7reverseEv@@GLIBCXX_3.4 FUNC:_ZNSt15_List_node_base8transferEPS_S0_@@GLIBCXX_3.4 FUNC:_ZNSt15_List_node_base9_M_unhookEv@@GLIBCXX_3.4.14 +FUNC:_ZNSt15__exception_ptr13exception_ptr4swapERS0_@@CXXABI_1.3.3 +FUNC:_ZNSt15__exception_ptr13exception_ptrC1EMS0_FvvE@@CXXABI_1.3.3 +FUNC:_ZNSt15__exception_ptr13exception_ptrC1ERKS0_@@CXXABI_1.3.3 +FUNC:_ZNSt15__exception_ptr13exception_ptrC1Ev@@CXXABI_1.3.3 +FUNC:_ZNSt15__exception_ptr13exception_ptrC2EMS0_FvvE@@CXXABI_1.3.3 +FUNC:_ZNSt15__exception_ptr13exception_ptrC2ERKS0_@@CXXABI_1.3.3 +FUNC:_ZNSt15__exception_ptr13exception_ptrC2Ev@@CXXABI_1.3.3 +FUNC:_ZNSt15__exception_ptr13exception_ptrD1Ev@@CXXABI_1.3.3 +FUNC:_ZNSt15__exception_ptr13exception_ptrD2Ev@@CXXABI_1.3.3 +FUNC:_ZNSt15__exception_ptr13exception_ptraSERKS0_@@CXXABI_1.3.3 +FUNC:_ZNSt15__exception_ptreqERKNS_13exception_ptrES2_@@CXXABI_1.3.3 +FUNC:_ZNSt15__exception_ptrneERKNS_13exception_ptrES2_@@CXXABI_1.3.3 FUNC:_ZNSt15basic_streambufIcSt11char_traitsIcEE10pubseekoffExSt12_Ios_SeekdirSt13_Ios_Openmode@@GLIBCXX_3.4 FUNC:_ZNSt15basic_streambufIcSt11char_traitsIcEE10pubseekposESt4fposI11__mbstate_tESt13_Ios_Openmode@@GLIBCXX_3.4 FUNC:_ZNSt15basic_streambufIcSt11char_traitsIcEE12__safe_gbumpEi@@GLIBCXX_3.4.16 @@ -1769,6 +1796,9 @@ FUNC:_ZNSt16invalid_argumentD0Ev@@GLIBCXX_3.4 FUNC:_ZNSt16invalid_argumentD1Ev@@GLIBCXX_3.4 FUNC:_ZNSt16invalid_argumentD2Ev@@GLIBCXX_3.4.15 +FUNC:_ZNSt16nested_exceptionD0Ev@@CXXABI_1.3.5 +FUNC:_ZNSt16nested_exceptionD1Ev@@CXXABI_1.3.5 +FUNC:_ZNSt16nested_exceptionD2Ev@@CXXABI_1.3.5 FUNC:_ZNSt17__timepunct_cacheIcEC1Ej@@GLIBCXX_3.4 FUNC:_ZNSt17__timepunct_cacheIcEC2Ej@@GLIBCXX_3.4 FUNC:_ZNSt17__timepunct_cacheIcED0Ev@@GLIBCXX_3.4 @@ -1963,6 +1993,7 @@ FUNC:_ZNSt6localeD2Ev@@GLIBCXX_3.4 FUNC:_ZNSt6localeaSERKS_@@GLIBCXX_3.4 FUNC:_ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEE@@GLIBCXX_3.4.11 +FUNC:_ZNSt6thread15_M_start_threadESt10shared_ptrINS_10_Impl_baseEEPFvvE@@GLIBCXX_3.4.21 FUNC:_ZNSt6thread20hardware_concurrencyEv@@GLIBCXX_3.4.17 FUNC:_ZNSt6thread4joinEv@@GLIBCXX_3.4.11 FUNC:_ZNSt6thread6detachEv@@GLIBCXX_3.4.11 @@ -2214,6 +2245,8 @@ FUNC:_ZSt17__copy_streambufsIwSt11char_traitsIwEEiPSt15basic_streambufIT_T0_ES6_@@GLIBCXX_3.4.6 FUNC:_ZSt17__throw_bad_allocv@@GLIBCXX_3.4 FUNC:
[committed] Don't request function descriptors when generating fast indirect calls on hppa
The attached change fixes a rather old regression. The code that is
generated with fast
indirect calls assumes that a function pointer points directly at the
function being called,
not a procedure descriptor.
Tested on hppa-unknown-linux-gnu and hppa2.0w-hp-hpux11.11. Committed
to trunk,
4.9 and 4.8.
Dave
--
John David Anglin dave.ang...@bell.net
2014-08-30 John David Anglin
* config/pa/pa.c (pa_assemble_integer): Don't add PLABEL relocation
prefix to function labels when generating fast indirect calls.
Index: config/pa/pa.c
===
--- config/pa/pa.c (revision 214400)
+++ config/pa/pa.c (working copy)
@@ -3217,7 +3217,12 @@
&& aligned_p
&& function_label_operand (x, VOIDmode))
{
- fputs (size == 8? "\t.dword\tP%" : "\t.word\tP%", asm_out_file);
+ fputs (size == 8? "\t.dword\t" : "\t.word\t", asm_out_file);
+
+ /* We don't want an OPD when generating fast indirect calls. */
+ if (!TARGET_FAST_INDIRECT_CALLS)
+ fputs ("P%", asm_out_file);
+
output_addr_const (asm_out_file, x);
fputc ('\n', asm_out_file);
return true;
Re: [Patch, Fortran] CAF dep (2/3): Move code around, prepare for more locking support
Dear Tobias, Obviously there is no problem with this - OK for trunk Cheers Paul On 27 August 2014 23:37, Tobias Burnus wrote: > I claim that it is part 2 of 3 of the "CAF dep" series, but the patch has > nothing to do with it, except that it is in the way. > > Technically, it just moves code from trans-intrinsic.c to trans-expr.c and > makes it available. Additionally, I support the case "offset == NULL_TREE", > which is supposed to be used with lock variables, where we know that the > coarray offset is always zero. That's used by my incomplete local lock > patch. > > Build and regtested (as part of the series) on x86-64-gnu-linux. > OK for the trunk? > > Tobias -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
Re: [PING^3] Re: [PATCH 1/2] Add -B support to gcc-ar/ranlib/nm
Hi Richard,
On Thu, Aug 28, 2014 at 10:18:22AM +0200, Richard Biener wrote:
> This also matches joined -B/foo
>
> >>> +{
> >>> + const char *arg = av[i] + 2;
> >>> + const char *end;
> >>> +
> >>> + memmove (av + i, av + i + 1, sizeof (char *) * ((ac + 1) - i));
> >>> + ac--;
> >>> + if (*arg == 0)
> >>> +{
> >>> + arg = av[i + 1];
> >>> + if (!arg)
> >>> +{
>
> But this doesn't handle it? common.opt has -B as Joined Separate option
> thus allowing both.
I believe it handles both cases. For the joined case (*arg == 0) is
false and the earlier (arg = av[i] + 2) assignment is used.
>
> >>> + fprintf (stderr, "Usage: gcc-ar [-B prefix] ar arguments
> >>> ...\n");
> >>> + exit (EXIT_FAILURE);
> >>> +}
> >>> + memmove (av + i, av + i + 1, sizeof (char *) * ((ac + 1) - i));
> >>> + ac--;
> >>> + i++;
> >>> +}
> >>> +
> >>> + for (end = arg; *end; end++)
> >>> +;
> >>> + end--;
> >>> + if (end > arg && *end != '/')
> >>> +{
> >>> + char *newarg = (char *)xmalloc (strlen(arg) + 2);
> >>> +
> >>> + strcpy (newarg, arg);
> >>> + strcat (newarg, "/");
> >>> + arg = newarg;
> >>> +}
>
> Why the above? And why open-coded instead of using strlen?
I assume you mean the for loop.
I always had strange errors later if the paths were not ending
with /, so I'm force adding it.
> >>> +
> >>> + add_prefix (&path, arg);
> >>> + add_prefix (&target_path, arg);
>
> This adds the -B path to the _end_ of the prefix list. Does that match
> gcc driver behavior? The gcc driver uses PREFIX_PRIORITY_B_OPT
> as argument to add_prefix which ends up adding -B prefixes to the
> beginning of the prefix list.
Ok.
-andi
[RFC/PATCH] More precise diagnostic locations: dynamic locations for columns vs explicit offset
In some situations, we would like to point to a location which was not
encoded when tokenizing. This happens, for example, in two prominent
cases:
1) To get precise locations within strings
(https://gcc.gnu.org/PR52952) for example, for Wformat warnings.
2) In the Fortran FE, which gives quite precise location information
by tracking the characters that it wants to warn about instead of
relying on the line-map machinery.
The most straightforward way to implement this is by adding variants
of diagnostic functions that take an explicit "offset" argument and
pass this offset through the whole diagnostics machinery. This is what
I implemented in the patch format_offset.diff attached. The downside
is that we would need to add even more variants (with/without offset)
of various diagnostic functions and track the offset/no-offset cases
explicitly.
The nicer/cleaner alternative is to somehow (re)compute a single
location value from a given location plus the new offset. This is what
I implemented in patch fortran-diagnostics-part3.diff in
linemap_redo_position_for_column(). As far as I understand, this
method only works reliably if the location+offset does not jump to a
different line map, that is, if to_column < (1u <<
map->d.ordinary.column_bits). Otherwise, we may need to recompute all
successive line-maps to accommodate the new location. The best way to
do the latter (or to work-around that issue) is not clear to me at the
moment.
Thus, I am putting forward these two alternative implementations and
seeking comments/advice/help in deciding what would be the best way to
fix this key missing piece of GCC diagnostics.
Related to this, perhaps I should make a more general call for help.
Despite the heroic, constant torrent of diagnostic fixes by Paolo,
Marek and others, I have not seen much progress on the key
infrastructure issues in the roadmap
(https://gcc.gnu.org/wiki/Better_Diagnostics). We have had at least
one major item per release since GCC 4.5, but I don't see any
particular item being tackled for GCC 5.0. Are you planning to tackle
any of them?
I have a simple patch to implement Fix-it hints but it needs more
work. Unfortunately, I have very little free time to dedicate to GCC
nowadays, so I'm afraid I might not even be able to finish this in
time. Any item in that list would be a nice major feature for GCC 5.0.
Perhaps we need to ask for help in gcc/gcc-help or some other forum.
Cheers,
Manuel.
Index: gcc/c-family/c-format.c
===
--- gcc/c-family/c-format.c (revision 197155)
+++ gcc/c-family/c-format.c (working copy)
@@ -377,10 +377,11 @@ typedef struct format_wanted_type
int format_length;
/* The actual parameter to check against the wanted type. */
tree param;
/* The argument number of that parameter. */
int arg_num;
+ int offset_loc;
/* The next type to check for this format conversion, or NULL if none. */
struct format_wanted_type *next;
} format_wanted_type;
/* Convenience macro for format_length_info meaning unused. */
@@ -903,10 +904,11 @@ typedef struct
/* Number of leaves of the format argument that were unterminated
strings. */
int number_unterminated;
/* Number of leaves of the format argument that were not counted above. */
int number_other;
+ location_t loc;
} format_check_results;
typedef struct
{
format_check_results *res;
@@ -996,11 +998,11 @@ check_function_format (tree attrs, int n
{
if (is_attribute_p ("format", TREE_PURPOSE (a)))
{
/* Yup; check it. */
function_format_info info;
- decode_format_attr (TREE_VALUE (a), &info, 1);
+ decode_format_attr (TREE_VALUE (a), &info, /*validated=*/true);
if (warn_format)
{
/* FIXME: Rewrite all the internal functions in this file
to use the ARGARRAY directly instead of constructing this
temporary list. */
@@ -1465,10 +1467,11 @@ check_format_arg (void *ctx, tree format
if (TREE_CODE (format_tree) != ADDR_EXPR)
{
res->number_non_literal++;
return;
}
+ res->loc = EXPR_LOCATION(format_tree);
format_tree = TREE_OPERAND (format_tree, 0);
if (format_types[info->format_type].flags
& (int) FMT_FLAG_PARSE_ARG_CONVERT_EXTERNAL)
{
bool objc_str = (info->format_type == gcc_objc_string_format_type);
@@ -1637,11 +1640,13 @@ check_format_info_main (format_check_res
if (*format_chars++ != '%')
continue;
if (*format_chars == 0)
{
- warning (OPT_Wformat_, "spurious trailing %<%%%> in format");
+ warning_at (res->loc ? res->loc : input_location,
+ format_chars - orig_format_chars,
+ OPT_Wformat_, "spurious trailing %<%%%> in format");
continue;
}
if (*format_chars == '%')
{
++format_chars;
@@ -2449,10 +2454,11 @@ format
Re: [patch] No allocation for empty unordered containers
Any news for my patch proposals ? Regarding documentation of default minimum number of buckets, I don't know where it has been documented but why do we need to document it separately ? Could it be taken care by Doxygen ? Can't it get the default value from the code itself ? If not we could document it ourself next to the code rather than in a distinct file. François On 14/08/2014 21:22, François Dumont wrote: On 13/08/2014 11:50, Jonathan Wakely wrote: Yes you can, it's conforming to replace a (non-virtual) member function with default arguments by two or more member functions. We do it all the time. See 17.6.5.5 [member.functions] p2. You should have told it sooner ! But of course no-one is supposed to ignore the Standard :-). Then here is the patch to introduce default constructor with compiler computed noexcept qualification. Note that I also made allocator aware default constructor allocation free however noexcept qualification has to be manually written which I find quite a burden. Do you think we shall do so now ? 2014-08-14 François Dumont * include/bits/hashtable_policy.h (_Prime_rehash_policy): Qualify constructor noexcept. (_Hash_code_base<>): All specialization default constructible if possible. (_Hashtable_base<>): Likewise. * include/bits/hashtable.h (_Hashtable<>()): Implementation defaulted. * include/bits/unordered_map.h (unordered_map<>::unordered_map()): New, implementation defaulted. (unordered_multimap<>::unordered_multimap()): Likewise. * include/bits/unordered_set.h (unordered_set<>::unordered_set()): Likewise. (unordered_multiset<>::unordered_multiset()): Likewise. * include/debug/unordered_map: Likewise. * include/debug/unordered_set: Likewise. * testsuite/23_containers/unordered_map/allocator/noexcept.cc (test04()): New. * testsuite/23_containers/unordered_multimap/allocator/noexcept.cc (test04()): New. * testsuite/23_containers/unordered_set/allocator/noexcept.cc (test04()): New. * testsuite/23_containers/unordered_multiset/allocator/noexcept.cc (test04()): New. I am preparing a patch for profile mode so I will submit modification for this mode with this big patch. Tested under Linux x86_64. Ok to commit ? François
Re: [PATCH] Add support for GNU/Hurd in gnat-4.9
Am 20.08.2014 um 22:12 schrieb Svante Signell: > On Wed, 2014-05-21 at 10:48 +0200, Samuel Thibault wrote: >> Svante Signell, le Wed 21 May 2014 10:44:54 +0200, a écrit : >>> On Wed, 2014-05-21 at 10:33 +0200, Arnaud Charlet wrote: >> I think the majority of work has bee done, Now that patch will change >> slightly for every missing feature added to Hurd. > > Then it's all good, it's a matter of what I said above. Don't forget also the part where general changes are done in GNAT which require update to target specific files: these typically require someone to regularly test each port to detect any missing update, and report/fix them, even if GNU/Hurd hasn't changed itself. >>> >>> With the help from the dabian-ada people, especially Ludovic Brenta, >>> gnat has been running on GNU/Hurd in Debian since gcc/gnat-4.6.3. >> >> Then it's all good. Just say that you wish to continue maintaining >> things like this, and upstream will be happy. > > Attached is the updated ada-hurd.diff patch for GNU/Hurd. It builds fine > with gnat-4.9.1-1 and gcc-4.9.1-7. This patch now has the same amount of > files as the kFreeBSD patch. Hopefully it can be material for upstream, > but at least in Debian the Hurd port would be on par with kFreeBSD. > Regarding remaining code commented out or irrelevant comments in the new > file s-osinte-gnu.ads, please help me to iron out the left-overs. the patch is at least missing the ChangeLog entry. Also it is only tested using the Debian package based on the 4.9 branch, and which includes a bunch of local ada patches which are not forwarded upstream for years. Please prepare and test your patch with current trunk for upstream submission. > Ludovic, can you consider using this file as ada-hurd.diff for next > upload of Debian gnat-4.9? > > For clarity: I wish to continue to maintain the Ada port for Hurd, with > the help of the Debian Ada and Hurd people, with or without being > imported upstream. I disagree. Debian's current local ada patches are a mess, and no effort is made to cleanup these and forward these upstream. If the Debian Ada people can't do this, please do it yourself. Matthias
Re: [Patch, Fortran] CAF dep (3/3): coarrays - pass may_require_tmp informtion for CAF_get/send/sendget to the library
Dear Tobias,
This looks fine to me - OK for trunk.
Thanks for this massive effort!
Paul
On 28 August 2014 08:13, Tobias Burnus wrote:
> This patch is based on 1/2 and 2/2 on the series. When the patch is
> approved, OpenCoarrays needs to be adapted; however, as surplus arguments of
> the callee are ignored, no immediate action is required. (And some delay
> avoids issues with compilers being older than the library.)
>
> The issue comes up in the context of having a coarray access on the same
> image, e.g. "a[this_image()] = a", where alias questions play a role. While
> one can leave the general handling to the library - such as switching to
> memmove in case of local memory access, this patch tries to help the library
> to decide whether it has to create a temporary variable or not. For that
> reason, it passes an may_require_temporary argument to the library.
>
> may_require_temporary is false if the source and target variables are
> disjunct, or if they are such overlapping that walking them in element order
> will not require a temporary (special case: identical). If the compiler
> cannot tell at compile time, the value is always one. Of course, if the
> memory access is for a different image than the current image (or for
> sendget: when the two image indexes are for different images), the library
> can ignore the argument "may_require_temporary" and use the normal remote
> memory access.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
> Tobias
>
> PS: I image code like the following in the library:
>
> if (image_index == this_image)
> {
> if (contiguous LHS and RHS):
> use memmove
> // With special case: LHS and RHS identical
> if (!may_require_temporary)
> for-loop assigning
> LHS = RHS in element order
> else
> {
> tmp = malloc()
> if (RHS contiguous or scalar)
> tmp = memcpy(RHS)
> else
> for loop assigning RHS to tmp
> if (LHS contiguous)
> LHS = memcpy(tmp)
> else
> for loop assigning tmp to LHS
> }
> } else {
> do normal remote-image assignment
> }
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
[Comitted] Add testcase for some miscompile in older versions of GCC
Hi,
In some versions of GCC with AARCH64 backported, I got a miscompile
of a shift that involved a load which had a post increment of the
address. This adds the testcase I created for that case.
Comitted after a quick test on x86_64-linux-gnu of the testcase. I
had meant to commit this two days which is why the testcase is dated
two days ago.
Thanks,
Andrew Pinski
ChangeLog:
* gcc.c-torture/execute/20140828-1.c: New testcase.
Index: gcc.c-torture/execute/20140828-1.c
===
--- gcc.c-torture/execute/20140828-1.c (revision 0)
+++ gcc.c-torture/execute/20140828-1.c (revision 0)
@@ -0,0 +1,22 @@
+short *f(short *a, int b, int *d) __attribute__((noinline,noclone));
+
+short *f(short *a, int b, int *d)
+{
+ short c = *a;
+ a++;
+ c = b << c;
+ *d = c;
+ return a;
+}
+
+int main(void)
+{
+ int d;
+ short a[2];
+ a[0] = 0;
+ if (f(a, 1, &d) != &a[1])
+__builtin_abort ();
+ if (d != 1)
+__builtin_abort ();
+ return 0;
+}
Re: [PATCH] GCC/test: Disable loop-19.c for classic FPU Power
On Fri, Aug 29, 2014 at 10:46 PM, Maciej W. Rozycki
wrote:
> Hi,
>
> The loop-19.c test case has regressed from 4.8 to 4.9 and trunk on
> classic FPU Power targets, these failures are now seen:
>
> FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times optimized "MEM.(base:
> &|symbol: )a," 2
> FAIL: gcc.dg/tree-ssa/loop-19.c scan-tree-dump-times optimized "MEM.(base:
> &|symbol: )c," 2
>
> However upon the inpection of generated code it is obvious that its
> quality has improved, the autoincrement rather than indexed addressing
> mode is now used in the loop produced, reducing the number of instructions
> in the loop from 4 to 3 and also removing another instruction from outside
> the loop, i.e. (new code):
>
> .globl tuned_STREAM_Copy
> .type tuned_STREAM_Copy, @function
> tuned_STREAM_Copy:
> lis 8,0x1e
> lis 10,a-8@ha
> ori 8,8,33920
> lis 9,c-8@ha
> mtctr 8
> la 10,a-8@l(10)
> la 9,c-8@l(9)
> .L2:
> lfdu 0,8(10)
> stfdu 0,8(9)
> bdnz .L2
> blr
> .size tuned_STREAM_Copy, .-tuned_STREAM_Copy
>
> vs (old code):
>
> .globl tuned_STREAM_Copy
> .type tuned_STREAM_Copy, @function
> tuned_STREAM_Copy:
> lis 7,0x1e
> ori 7,7,33920
> mtctr 7
> lis 8,c@ha
> lis 10,a@ha
> li 9,0
> la 8,c@l(8)
> la 10,a@l(10)
> .L3:
> lfdx 0,10,9
> stfdx 0,8,9
> addi 9,9,8
> bdnz .L3
> blr
> .size tuned_STREAM_Copy,.-tuned_STREAM_Copy
>
> The only Power targets that still pass this test are e500v2 ones such as
> `-mcpu=8548 -mfloat-gprs=double -mspe=yes -mabi=spe' that use the SPE unit
> for FP operations, because the indexed mode is still used (there's no
> autoincrement addressing mode available for the memory access instructions
> concerned):
>
> .globl tuned_STREAM_Copy
> .type tuned_STREAM_Copy, @function
> tuned_STREAM_Copy:
> lis 10,0x1e
> lis 7,c@ha
> lis 8,a@ha
> ori 10,10,0x8480
> li 9,0
> la 7,c@l(7)
> la 8,a@l(8)
> mtctr 10
> .L2:
> evlddx 10,8,9
> evstddx 10,7,9
> addi 9,9,8
> bdnz .L2
> blr
> .size tuned_STREAM_Copy,.-tuned_STREAM_Copy
>
> [I have removed "-fno-common" from the current test flags for the purpose
> of this consideration to compare apples to apples; 4.8 didn't have it.
> The presence or absence of this flag does not appear to make a difference
> for this test case for Power targets.]
>
> The obvious reason of the failure is the offset of -8 now seen in new
> classic FP code for preinitialising the pointers before entering the loop.
> The initial offset is needed so that it is cancelled by the offset of 8
> used in the loop itself to autoincrement these pointers. So the new code
> not only is better, but it actually has to use these offsets as well or
> autoincrementation would not work.
>
> Therefore I think at this point the test case is invalid for classic FP
> Power, so I propose that we exclude it from testing here, only leaving SPE
> FP Power for whatever value the test case may have for it, and especially
> x86 variants where there's actual code size penalty for using an immediate
> offset (displacement) in addition to a base register.
>
> For the record here are the optimization dumps examined by the test case,
> for the old generated code that passes:
>
> ;; Function tuned_STREAM_Copy (tuned_STREAM_Copy, funcdef_no=0,
> decl_uid=1382, cgraph_uid=0)
>
> tuned_STREAM_Copy ()
> {
> sizetype ivtmp.10;
> double _4;
>
> :
>
> :
> # ivtmp.10_8 = PHI
> _4 = MEM[symbol: a, index: ivtmp.10_8, offset: 0B];
> MEM[symbol: c, index: ivtmp.10_8, offset: 0B] = _4;
> ivtmp.10_2 = ivtmp.10_8 + 8;
> if (ivtmp.10_2 != 1600)
> goto ;
> else
> goto ;
>
> :
> goto ;
>
> :
> return;
>
> }
>
> and for the new code that fails:
>
> ;; Function tuned_STREAM_Copy (tuned_STREAM_Copy, funcdef_no=0,
> decl_uid=2191, symbol_order=2)
>
> Removing basic block 5
> tuned_STREAM_Copy ()
> {
> unsigned int ivtmp.13;
> unsigned int ivtmp.9;
> double _4;
> void * _15;
> void * _16;
> unsigned int _17;
>
> :
> ivtmp.9_11 = (unsigned int) &MEM[(void *)&a + 4294967288B];
> ivtmp.13_14 = (unsigned int) &MEM[(void *)&c + 4294967288B];
> _17 = (unsigned int) &MEM[(void *)&a + 1592B];
>
> :
> # ivtmp.9_8 = PHI
> # ivtmp.13_12 = PHI
> ivtmp.9_2 = ivtmp.9_8 + 8;
> _15 = (void *) ivtmp.9_2;
> _4 = MEM[base: _15, offset: 0B];
> ivtmp.13_13 = ivtmp.13_12 + 8;
> _16 = (void *) ivtmp.13_13;
> MEM[base: _16, offset: 0B] = _4;
> if (ivtmp.9_2 != _17)
> goto ;
> else
> goto ;
>
> :
> return;
>
> }
>
> Tested with the following powerpc-gnu-linux multilibs with the respective
> results noted on the right:
>
> -mcpu=603e UNSUPPO
Re: [PATCH, rs6000] A few more vector builtins
On Fri, Aug 29, 2014 at 2:28 PM, Bill Schmidt wrote: > Hi, > > This is the last in the current series of new vector built-ins. This > group adds vec_ctf, vec_cts, and vec_ctu for vector double and vector > long long. Additionally, it adds documentation for the built-ins added > in my last patch, since I forgot to add it then... /oops > > Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no > regressions. Ok for trunk? > > Thanks, > Bill > > > [gcc] > > 2014-08-29 Bill Schmidt > > * config/rs6000/rs6000-builtin.def (XVCVSXDDP_SCALE): New > built-in definition. > (XVCVUXDDP_SCALE): Likewise. > (XVCVDPSXDS_SCALE): Likewise. > (XVCVDPUXDS_SCALE): Likewise. > * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add > entries for VSX_BUILTIN_XVCVSXDDP_SCALE, > VSX_BUILTIN_XVCVUXDDP_SCALE, VSX_BUILTIN_XVCVDPSXDS_SCALE, and > VSX_BUILTIN_XVCVDPUXDS_SCALE. > * config/rs6000/rs6000-protos.h (rs6000_scale_v2df): New > prototype. > * config/rs6000/rs6000.c (real.h): New include. > (rs6000_scale_v2df): New function. > * config/rs6000/vsx.md (UNSPEC_VSX_XVCVSXDDP): New unspec. > (UNSPEC_VSX_XVCVUXDDP): Likewise. > (UNSPEC_VSX_XVCVDPSXDS): Likewise. > (UNSPEC_VSX_XVCVDPUXDS): Likewise. > (vsx_xvcvsxddp_scale): New define_expand. > (vsx_xvcvsxddp): New define_insn. > (vsx_xvcvuxddp_scale): New define_expand. > (vsx_xvcvuxddp): New define_insn. > (vsx_xvcvdpsxds_scale): New define_expand. > (vsx_xvcvdpsxds): New define_insn. > (vsx_xvcvdpuxds_scale): New define_expand. > (vsx_xvcvdpuxds): New define_insn. > * doc/extend.texi (vec_ctf): Add new prototypes. > (vec_cts): Likewise. > (vec_ctu): Likewise. > (vec_splat): Likewise. > (vec_div): Likewise. > (vec_mul): Likewise. > > [gcc/testsuite] > > 2014-08-29 Bill Schmidt > > * gcc.target/powerpc/builtins-1.c: Add tests for vec_ctf, > vec_cts, and vec_ctu. > * gcc.target/powerpc/builtins-2.c: Likewise. Okay. Thanks, David
