[SH][committed] Fix PR 67260
Hi,
The attached patch(es) fix PR 67260. For details please see the
discussion in the PR log.
Tested on trunk and sh-elf with
make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,
-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
and on GCC 5 and GCC 4.9 branch with make all-gcc and compiling the
testcase.
Committed to trunk as r233399 + r233400, to GCC 5 branch as r233401 and
to GCC 4.9 branch as r233402.
Cheers,
OlegIndex: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 233399)
+++ gcc/config/sh/sh.md (working copy)
@@ -10241,12 +10241,16 @@
(const_string "single") (const_string "double")))
(set_attr "type" "jump_ind")])
+;; sibcall_value_pcrel used to have a =&k clobber for the scratch register
+;; that it needs for the branch address. This causes troubles when there
+;; is a big overlap of argument and return value registers. Hence, use a
+;; fixed call clobbered register for the address. See also PR 67260.
(define_insn_and_split "sibcall_value_pcrel"
[(set (match_operand 0 "" "=rf")
(call (mem:SI (match_operand:SI 1 "symbol_ref_operand" ""))
(match_operand 2 "" "")))
(use (reg:SI FPSCR_MODES_REG))
- (clobber (match_scratch:SI 3 "=&k"))
+ (clobber (reg:SI R1_REG))
(return)]
"TARGET_SH2"
"#"
@@ -10256,6 +10260,8 @@
rtx lab = PATTERN (gen_call_site ());
rtx call_insn;
+ operands[3] = gen_rtx_REG (SImode, R1_REG);
+
emit_insn (gen_sym_label2reg (operands[3], operands[1], lab));
call_insn = emit_call_insn (gen_sibcall_valuei_pcrel (operands[0],
operands[3],
Index: gcc/testsuite/gcc.target/sh/torture/pr67260.c
===
--- gcc/testsuite/gcc.target/sh/torture/pr67260.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/torture/pr67260.c (working copy)
@@ -0,0 +1,12 @@
+/* { dg-additional-options "-std=gnu99 -fPIC" } */
+/* { dg-do compile } */
+
+#pragma GCC visibility push(hidden)
+
+double _Complex foo (double _Complex arg);
+
+double _Complex
+bar (double _Complex arg)
+{
+ return foo (arg);
+}
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 233399)
+++ gcc/config/sh/sh.md (working copy)
@@ -9605,12 +9605,16 @@
(const_string "single") (const_string "double")))
(set_attr "type" "jump_ind")])
+;; sibcall_value_pcrel used to have a =&k clobber for the scratch register
+;; that it needs for the branch address. This causes troubles when there
+;; is a big overlap of argument and return value registers. Hence, use a
+;; fixed call clobbered register for the address. See also PR 67260.
(define_insn_and_split "sibcall_value_pcrel"
[(set (match_operand 0 "" "=rf")
(call (mem:SI (match_operand:SI 1 "symbol_ref_operand" ""))
(match_operand 2 "" "")))
(use (reg:PSI FPSCR_REG))
- (clobber (match_scratch:SI 3 "=k"))
+ (clobber (reg:SI R1_REG))
(return)]
"TARGET_SH2"
"#"
@@ -9620,6 +9624,8 @@
rtx lab = PATTERN (gen_call_site ());
rtx call_insn;
+ operands[3] = gen_rtx_REG (SImode, R1_REG);
+
emit_insn (gen_sym_label2reg (operands[3], operands[1], lab));
call_insn = emit_call_insn (gen_sibcall_valuei_pcrel (operands[0],
operands[3],
Index: gcc/testsuite/gcc.target/sh/torture/pr67260.c
===
--- gcc/testsuite/gcc.target/sh/torture/pr67260.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/torture/pr67260.c (working copy)
@@ -0,0 +1,12 @@
+/* { dg-additional-options "-std=gnu99 -fPIC" } */
+/* { dg-do compile } */
+
+#pragma GCC visibility push(hidden)
+
+double _Complex foo (double _Complex arg);
+
+double _Complex
+bar (double _Complex arg)
+{
+ return foo (arg);
+}
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 233397)
+++ gcc/config/sh/sh.md (working copy)
@@ -10476,12 +10476,16 @@
(const_string "single") (const_string "double")))
(set_attr "type" "jump_ind")])
+;; sibcall_value_pcrel used to have a =&k clobber for the scratch register
+;; that it needs for the branch address. This causes troubles when there
+;; is a big overlap of argument and return value registers. Hence, use a
+;; fixed call clobbered register for the address. See also PR 67260.
(define_insn_and_split "sibcall_value_pcrel"
[(set (match_operand 0 "" "=rf")
(call (mem:SI (match_operand:SI 1 "symbol_ref_operand" ""))
(match_operand 2 "" "")))
(use (reg:SI FPSCR_MODES_REG))
- (clobber (match_scratch:SI 3 "=&k"))
+ (clobber (reg:SI R1_REG))
(return)]
"TARGET_SH2 && !TARGET_FDPIC"
"#"
@@ -10491,6 +10495,8 @@
rtx lab = PATTERN (gen_call_site ());
rtx call_insn;
+ operands[3] = gen_rtx_REG (SImode, R1_REG);
+
sh_expand_sym_label2reg (operands[3], operands[1], lab, true);
call_insn = e
Re: [patch, Fortran] Fix PR 60526, variable name has already been declared as a type
Am 12.02.2016 um 11:42 schrieb Janne Blomqvist:
On Fri, Feb 12, 2016 at 12:16 PM, Andre Vehreschild wrote:
The proposed alloca() call
has according to the documentation of libc some availability issues on
certain platforms, too.
These availablity issues cannot be too serious, or we would be having
trouble already:
ig25@linux-fd1f:~/Gcc/trunk/gcc/fortran> fgrep -H -n 'alloca (' *.c
cpp.c:839: to_file_quoted = (unsigned char *) alloca (to_file_len *
4 + 1);
cpp.c:1079: (unsigned char *) alloca (to_file_len * 4 + 1);
error.c:898: buffer = (char *) alloca (strlen (msg) + strlen (msg2) + 2);
module.c:6042: filename = (char *) alloca (n);
module.c:6048: filename = (char *) alloca (n);
module.c:6058: filename_tmp = (char *) alloca (n + 1);
options.c:267: source_path = (char *) alloca (i + 1);
primary.c:214: buffer = (char *) alloca (length + 1);
primary.c:438: buffer = (char *) alloca (length + 1);
primary.c:600: buffer = (char *) alloca (count + 1);
scanner.c:321: q = (char *) alloca (len + 1);
simplify.c:6381: buffer = (unsigned char*)alloca (buffer_size);
target-memory.c:674: buffer = (unsigned char*)alloca (len);
target-memory.c:781: buffer = (unsigned char*)alloca (buffer_size);
Therefore why not going with the fixed size
stack array and adding a check for possible overflow to it and be done?
Yes, I agree. That sounds like the best approach in this case.
OK, here is the final version of the patch. I'd like to get this
committed so I can turn to PR 69742.
Regards
Thomas
2016-02-03 Thomas Koenig
PR fortran/60526
* decl.c (build_sym): If the name has already been defined as a
type, issue error and return false.
2016-02-03 Thomas Koenig
PR fortran/60526
* gfortran.dg/type_decl_4.f90: New test.
Index: decl.c
===
--- decl.c (Revision 232864)
+++ decl.c (Arbeitskopie)
@@ -1215,10 +1215,30 @@ build_sym (const char *name, gfc_charlen *cl, bool
{
symbol_attribute attr;
gfc_symbol *sym;
+ int nlen;
+ char u_name[GFC_MAX_SYMBOL_LEN + 1];
+ gfc_symtree *st;
if (gfc_get_symbol (name, NULL, &sym))
return false;
+ /* Check if the name has already been defined as a type. The
+ first letter of the symtree will be in upper case then. */
+
+ nlen = strlen(name);
+ gcc_assert (nlen <= GFC_MAX_SYMBOL_LEN);
+ strncpy (u_name, name, nlen + 1);
+ u_name[0] = TOUPPER(u_name[0]);
+
+ st = gfc_find_symtree (gfc_current_ns->sym_root, u_name);
+
+ if (st != 0)
+{
+ gfc_error ("Symbol %qs at %C also declared as a type at %L", name,
+ &st->n.sym->declared_at);
+ return false;
+}
+
/* Start updating the symbol table. Add basic type attribute if present. */
if (current_ts.type != BT_UNKNOWN
&& (sym->attr.implicit_type == 0
! { dg-do compile }
program main
type Xx ! { dg-error "Symbol 'xx' at .1. also declared as a type at .2." }
end type Xx
real :: Xx ! { dg-error "Symbol 'xx' at .1. also declared as a type at .2." }
end program main
[Patch, regex, libstdc++/69794] Unify special character parsing
I did it wrong in r227289 - I ignored the "\n" special case in grep.
Turns out using code to handle special cases is error prone, so I
turned to use data (_M_grep_spec_char and _M_egrep_spec_char).
Bootstrapped and tested on x86_64-pc-linux-gnu.
Thanks!
--
Regards,
Tim Shen
commit 03e651ef56e516f1bc7b0d041d93ef657af54791
Author: Tim Shen
Date: Sat Feb 13 10:55:38 2016 -0800
PR libstdc++/69794
* include/bits/regex_scanner.h: Add different special character
sets for grep and egrep regex.
* include/bits/regex_scanner.tcc: Use _M_spec_char more unifiedly.
* testsuite/28_regex/regression.cc: Add new testcase.
diff --git a/libstdc++-v3/include/bits/regex_scanner.h
b/libstdc++-v3/include/bits/regex_scanner.h
index bff7366..16071da 100644
--- a/libstdc++-v3/include/bits/regex_scanner.h
+++ b/libstdc++-v3/include/bits/regex_scanner.h
@@ -95,11 +95,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
: _M_awk_escape_tbl),
_M_spec_char(_M_is_ecma()
? _M_ecma_spec_char
-: _M_is_basic()
+: _M_flags & regex_constants::basic
? _M_basic_spec_char
-: _M_extended_spec_char),
+: _M_flags & regex_constants::extended
+? _M_extended_spec_char
+: _M_flags & regex_constants::grep
+? _M_grep_spec_char
+: _M_flags & regex_constants::egrep
+? _M_egrep_spec_char
+: _M_flags & regex_constants::awk
+? _M_extended_spec_char
+: nullptr),
_M_at_bracket_start(false)
-{ }
+{ __glibcxx_assert(_M_spec_char); }
protected:
const char*
@@ -177,6 +185,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
const char* _M_ecma_spec_char = "^$\\.*+?()[]{}|";
const char* _M_basic_spec_char = ".[\\*^$";
const char* _M_extended_spec_char = ".[\\()*+?{|^$";
+const char* _M_grep_spec_char = ".[\\*^$\n";
+const char* _M_egrep_spec_char = ".[\\()*+?{|^$\n";
_StateT _M_state;
_FlagT_M_flags;
diff --git a/libstdc++-v3/include/bits/regex_scanner.tcc
b/libstdc++-v3/include/bits/regex_scanner.tcc
index 920cb14..fedba09 100644
--- a/libstdc++-v3/include/bits/regex_scanner.tcc
+++ b/libstdc++-v3/include/bits/regex_scanner.tcc
@@ -97,9 +97,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_scan_normal()
{
auto __c = *_M_current++;
- const char* __pos;
- if (std::strchr(_M_spec_char, _M_ctype.narrow(__c, '\0')) == nullptr)
+ if (std::strchr(_M_spec_char, _M_ctype.narrow(__c, ' ')) == nullptr)
{
_M_token = _S_token_ord_char;
_M_value.assign(1, __c);
@@ -177,12 +176,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_M_state = _S_state_in_brace;
_M_token = _S_token_interval_begin;
}
- else if (((__pos = std::strchr(_M_spec_char, _M_ctype.narrow(__c, '\0')))
- != nullptr
- && *__pos != '\0'
- && __c != ']'
- && __c != '}')
- || (_M_is_grep() && __c == '\n'))
+ else if (__c != ']' && __c != '}')
{
auto __it = _M_token_tbl;
auto __narrowc = _M_ctype.narrow(__c, '\0');
diff --git a/libstdc++-v3/testsuite/28_regex/regression.cc
b/libstdc++-v3/testsuite/28_regex/regression.cc
index f95bef9..c9a3402 100644
--- a/libstdc++-v3/testsuite/28_regex/regression.cc
+++ b/libstdc++-v3/testsuite/28_regex/regression.cc
@@ -33,10 +33,26 @@ test01()
regex re("((.)", regex_constants::basic);
}
+void
+test02()
+{
+ bool test __attribute__((unused)) = true;
+
+ std::string re_str
+{
+ "/abcd" "\n"
+ "/aecf" "\n"
+ "/ghci"
+};
+ auto rx = std::regex(re_str, std::regex_constants::grep |
std::regex_constants::icase);
+ VERIFY(std::regex_search("/abcd", rx));
+}
+
int
main()
{
test01();
+ test02();
return 0;
}
[PATCH] 69759 - document __builtin_alloca and __builtin_alloca_with_align
The __builtin_alloca intrinsic is mentioned in the GCC manual but
its GCC-specific properties are not documented. The Linux man
page for the alloca() function briefly mentions __builtin_alloca
in the NOTES section but cautions that the function is "machine-
and compiler-dependent" without providing any details.
http://man7.org/linux/man-pages/man3/alloca.3.html
The __builtin_alloca_with_align function isn't mentioned in the
GCC manual at all.
Both built-ins are being relied on by user programs and both seem
to be poorly understood and occasionally causing problems. See
for example:
https://bugzilla.mozilla.org/show_bug.cgi?id=355
__builtin_alloca_with_align() is also tricky to use and subject
to bugs (see PR/69780).
I spent some time experimenting with and debugging the two builtins
to get a better understanding of their constraints and guarantees.
The attached documentation-only patch adds a description of each
to the GCC manual as a starting point. If there are additional
details that could or should be mentioned (or cautionary statements)
I'd be grateful to hear them and happy to add them.
Martin
PS The __builtin_alloca_with_align optimization to release small
allocations at the end of the block as opposed to the end of the
function is safe and useful for VLAs but seems error-prone for
a general purpose utility. It might perhaps be worth changing
the builtin so as to avoid the optimization when it's used
directly (as opposed to internally by GCC).
In addition, both functions can be called at other scopes than
block scope (especially in C++). I didn't uncover any bugs in
this feature but I'm not sure it's safe (especially since there
are no test for the builtin in the test suite). If someone
feels that the functions should be callable at other scopes
it would be good to know so tests exercising it can be put in
place. Otherwise, GCC should either reject such calls or at
least issue a warning for them.
PR c/69759 - __builtin_alloca and __builtin_alloca_with_align undocumented
gcc/ChangeLog:
2016-02-13 Martin Sebor
PR c/69759
* doc/extend.texi (Other Builtins): Document __builtin_alloca and
__builtin_alloca_with_align.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 233367)
+++ gcc/doc/extend.texi (working copy)
@@ -10144,6 +10144,8 @@ in the Cilk Plus language manual which c
@node Other Builtins
@section Other Built-in Functions Provided by GCC
@cindex built-in functions
+@findex __builtin_alloca
+@findex __builtin_alloca_with_align
@findex __builtin_call_with_static_chain
@findex __builtin_fpclassify
@findex __builtin_isfinite
@@ -10690,6 +10692,92 @@ In the same fashion, GCC provides @code{
@code{__builtin_} prefixed. The @code{isinf} and @code{isnan}
built-in functions appear both with and without the @code{__builtin_} prefix.
+@deftypefn {Built-in Function} void* __builtin_alloca (size_t size)
+The @code{__builtin_alloca} function must be called at block scope.
+The function allocates an object @var{size} bytes large on the stack of
+the calling function. The object is aligned at the greatest fundametal
+alignment boundary for the target. The greatest fundametal alignment is
+the result of the @code{__BIGGEST_ALIGNMENT__ * __CHAR_BIT__} expression.
+In portable C99 and C11 (or later) programs, the value should be obtained
+by evaluating the @code{_Alignof (max_align_t)} and
+@code{alignof (std::max_align_t)} expressions, respectively. The function
+returns a pointer to the first byte of the allocated object. The lifetime
+of the allocated object ends just before the calling function returns to
+its caller. This is so even when @code{__builtin_alloca_with_align} is
+called within a nested block.
+
+For example, the following function allocates eight objects of @code{n}
+bytes each on the stack, storing a pointer to each in consecutive elements
+of the array @code{a}. It then passes the array to function @code{g()}
+which can safely use the storage pointed to by each of the array elements.
+
+@smallexample
+void f (unsigned n)
+@{
+ void *a [8];
+ for (int i = 0; i != 8; ++i)
+a [i] = __builtin_alloca (n);
+
+ g (a, n); // safe
+@}
+@end smallexample
+
+Since the @code{__builtin_alloca} function doesn't validate its arguments
+it is the responsibility of its caller to make sure the argument doesn't
+cause it doesn't exceed the stack size limit.
+The @code{__builtin_alloca} function is provided to make it possible to
+allocate arrays with a runtime bound on the stack. Since C99 variable
+length arrays offer similar functionality under a portable, more convenient,
+and safer interface they are recommended instead, in both C99 and C++
+programs where GCC provides them as an extension.
+
+@end deftypefn
+
+@deftypefn {Built-in Function} void* __builtin_alloca_with_align (size_t size, size_t align)
+The @code{__builtin_alloca_with_align} function must be called at blo
Re: [PATCH] Fix PR69595, bogus -Warray-bound warning
On Tue, 2 Feb 2016, Richard Biener wrote:
*** gcc/match.pd(revision 233067)
--- gcc/match.pd(working copy)
*** DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
*** 2094,2099
--- 2094,2117
(bit_and:c (ordered @0 @0) (ordered:c@2 @0 @1))
@2)
+ /* Simple range test simplifications. */
+ /* A < B || A >= B -> true. */
+ (for test1 (lt le ne)
+ test2 (ge gt eq)
+ (simplify
+ (bit_ior:c (test1 @0 @1) (test2 @0 @1))
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
+|| VECTOR_INTEGER_TYPE_P (TREE_TYPE (@0)))
+{ constant_boolean_node (true, type); })))
+ /* A < B && A >= B -> false. */
+ (for test1 (lt lt lt le ne eq)
+ test2 (ge gt eq gt eq gt)
The lack of symmetry between the || and && cases is surprising. Is there
any reason not to handle the pairs le/ge, le/ne and ge/ne for bit_ior?
+ (simplify
+ (bit_and:c (test1 @0 @1) (test2 @0 @1))
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
+|| VECTOR_INTEGER_TYPE_P (TREE_TYPE (@0)))
+{ constant_boolean_node (false, type); })))
+
/* -A CMP -B -> B CMP A. */
(for cmp (tcc_comparison)
scmp (swapped_tcc_comparison)
--
Marc Glisse
Re: AW: Wonly-top-basic-asm
On 2/12/2016 4:51 AM, Bernd Schmidt wrote: On 02/12/2016 08:05 AM, David Wohlferd wrote: Actually, it was my intent that this apply to v6. It's not like there is a significant change here. We're documenting long-time behavior, and adding a (disabled) warning. The doc patch (minus mentioning the warning) could go in now, but for gcc-6 we're at a stage where we're only accepting regression fixes with very few exceptions. If you can convince a RM that this is important enough then it could still go in. Understood. While I think the patch is small enough to be safe, whether it's important enough for this stage is a different question. 2) There is a significant change to this behavior being proposed for v7. When this happens, having a way to locate affected statements with features from a stable release seems desirable. I'm actually not convinced that we'll want to change much in asm behaviour. Clobbering memory, maybe, but I can't see much beyond that - there's just no gain and some risk. So I'm a little more relaxed about the whole thing. And that's the question. If you are correct that we won't be changing this, then yeah, update the docs for v6, push the code change to v7. Done. But Jeff sounded quite serious when he said "the only rational behaviour for a traditional asm is that it has to be considered a use/clobber of memory and hard registers." If indeed that is the plan for v7, then having this warning available in v6 to allow people to prepare becomes important. Jeff Law: If you are listening, care to share your plans here? Let's let Sandra have the last word [about the docs]. Good plan. dw
Re: AW: Wonly-top-basic-asm
On 2/12/2016 5:03 PM, Sandra Loosemore wrote: On 02/12/2016 05:51 AM, Bernd Schmidt wrote: On 02/12/2016 08:05 AM, David Wohlferd wrote: Actually, it was my intent that this apply to v6. It's not like there is a significant change here. We're documenting long-time behavior, and adding a (disabled) warning. The doc patch (minus mentioning the warning) could go in now, but for gcc-6 we're at a stage where we're only accepting regression fixes with very few exceptions. If you can convince a RM that this is important enough then it could still go in. I looked at the last version of the patch I saw and this is my conclusion as well. If you would like me to commit just the doc change (minus the references to the new warning) now, please split the patch and I will do that. But, I cannot commit the change to add the new warning during Stage 4 without approval from a RM. Fair enough. Committing what we can right now sounds like a good plan. Bernd and I have both posted alternate text to what was in the last patch (see https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00861.html). He proposed (and I agreed) that having you make the call about which was better might be reasonable way to finalize this. If you want to pick one, I'll remove the Wbasic-asm and turn it into a doc-only patch. Or maybe you'd rather scrap them both and propose your own? I'm flexible here. There are important concepts that need to be conveyed. Doesn't much matter to me who writes them. dw
RE: [Patch X86_64]: Minor changes to znver1 pipe reservations.
Hi Uros, > -Original Message- > From: Uros Bizjak [mailto:ubiz...@gmail.com] > Sent: Friday, February 12, 2016 11:06 PM > To: Kumar, Venkataramanan > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [Patch X86_64]: Minor changes to znver1 pipe reservations. > > On Fri, Feb 12, 2016 at 5:31 PM, Kumar, Venkataramanan > wrote: > > Hi Maintainers, > > > > Below patch does some minor changes to pipe reservations in znver1.md. > > GCC bootstrap completed. > > > > GCC regression testing underway. Ok for trunk if the testing passes? > > > > > > ChangeLog > > - > > 2016-02-12 Venkataramanan Kumar > > > > * config/i386/znver1.md > > (znver1_pop, znver1_pop_mem, > > znver1_load_imov_double_store, > > znver1_load_imov_direct_store, > > znver1_load_imov_direct_load, > > znver1_load_imov_double_load): Add new. > > (znver1_insn, znver1_insn_load): Add icmov type. > > (znver1_sseavx_fma, > > znver1_sseavx_fma_load, > > znver1_avx256_fma, > > znver1_avx256_fma_load): Fix pipe usage. > > OK for mainline. > Thank you. I up-streamed the patch Ref https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=233409 > Thanks, > Uros. > > > --- Patch --- > > diff --git a/gcc/config/i386/znver1.md b/gcc/config/i386/znver1.md > > index b7fcf6c..e6babc7 100644 > > --- a/gcc/config/i386/znver1.md > > +++ b/gcc/config/i386/znver1.md > > @@ -102,6 +102,18 @@ > >(eq_attr "memory" "both"))) > > "znver1-direct,znver1-load,znver1-store") > > > > +(define_insn_reservation "znver1_pop" 4 > > +(and (eq_attr "cpu" "znver1") > > + (and (eq_attr "type" "pop") > > + (eq_attr "memory" "load"))) > > +"znver1-direct,znver1-load") > > + > > +(define_insn_reservation "znver1_pop_mem" 4 > > +(and (eq_attr "cpu" "znver1") > > + (and (eq_attr "type" "pop") > > + (eq_attr "memory" "both"))) > > +"znver1-direct,znver1-load,znver1-store") > > + > > ;; Leave > > (define_insn_reservation "znver1_leave" 1 > > (and (eq_attr "cpu" "znver1") @@ -194,26 > > +206,52 @@ > > (and (eq_attr "cpu" "znver1") > > (and (eq_attr "znver1_decode" "double") > >(and (eq_attr "type" "imovx") > > - (eq_attr "memory" "none,load" > > + (eq_attr "memory" "none" > > "znver1-double,znver1-ieu") > > > > (define_insn_reservation "znver1_load_imov_direct" 1 > > (and (eq_attr "cpu" "znver1") > > (and (eq_attr "type" "imov,imovx") > > - (eq_attr "memory" "none,load"))) > > + (eq_attr "memory" "none"))) > > "znver1-direct,znver1-ieu") > > > > +(define_insn_reservation "znver1_load_imov_double_store" 2 > > +(and (eq_attr "cpu" "znver1") > > + (and (eq_attr "znver1_decode" "double") > > + (and (eq_attr "type" "imovx") > > + (eq_attr "memory" "store" > > +"znver1-double,znver1-ieu,znver1-store") > > + > > +(define_insn_reservation "znver1_load_imov_direct_store" 1 > > +(and (eq_attr "cpu" "znver1") > > + (and (eq_attr "type" "imov,imovx") > > + (eq_attr "memory" "store"))) > > + > > +"znver1-direct,znver1-ieu,znver1-store") > > + > > +(define_insn_reservation "znver1_load_imov_double_load" 6 > > +(and (eq_attr "cpu" "znver1") > > + (and (eq_attr "znver1_decode" "double") > > + (and (eq_attr "type" "imovx") > > + (eq_attr "memory" "load" > > +"znver1-double,znver1-load,znver1-ieu") > > + > > +(define_insn_reservation "znver1_load_imov_direct_load" 5 > > +(and (eq_attr "cpu" "znver1") > > + (and (eq_attr "type" "imov,imovx") > > + (eq_attr "memory" "load"))) > > +"znver1-direct,znver1-load,znver1-ieu") > > + > > ;; INTEGER/GENERAL instructions > > ;; register/imm operands only: ALU, ICMP, NEG, NOT, ROTATE, ISHIFT, > > TEST (define_insn_reservation "znver1_insn" 1 > > (and (eq_attr "cpu" "znver1") > > - (and (eq_attr "type" > "alu,icmp,negnot,rotate,rotate1,ishift,ishift1,test,setcc,incdec") > > +
