[PATCH v3] c++: Fix parsing of invalid enum specifiers [PR90995]
On Mon, Mar 16, 2020 at 06:01:25PM -0400, Jason Merrill wrote:
> > - type = NULL_TREE;
> > - goto out;
> > + error_at (cp_lexer_peek_token (parser->lexer)->location,
> > + "expected %<;%> or %<{%>");
> > + return NULL_TREE;
>
> Hmm, what happens if we commit_to_tentative_parse before the cp_parser_error
> if has_underlying_type? That would also get us a diagnostic in this case
> even in enclosing tentative context.
>
> And yes, I think returning error_mark_node seems appropriate; this is an
> enum-specifier, just an ill-formed one.
Seems to work too. Bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2020-03-17 Jakub Jelinek
PR c++/90995
* parser.c (cp_parser_enum_specifier): Use temp_override for
parser->colon_corrects_to_scope_p, replace goto out with return.
If scoped enum or enum with underlying type is not followed by
{ or ;, call cp_parser_commit_to_tentative_parse before calling
cp_parser_error and make sure to return error_mark_node instead of
NULL_TREE. Formatting fixes.
* g++.dg/cpp0x/enum40.C: New test.
--- gcc/cp/parser.c.jj 2020-03-14 08:14:47.125740994 +0100
+++ gcc/cp/parser.c 2020-03-17 07:57:19.195642249 +0100
@@ -19001,9 +19001,7 @@ cp_parser_enum_specifier (cp_parser* par
bool is_unnamed = false;
tree underlying_type = NULL_TREE;
cp_token *type_start_token = NULL;
- bool saved_colon_corrects_to_scope_p = parser->colon_corrects_to_scope_p;
-
- parser->colon_corrects_to_scope_p = false;
+ temp_override cleanup (parser->colon_corrects_to_scope_p, false);
/* Parse tentatively so that we can back up if we don't find a
enum-specifier. */
@@ -19043,24 +19041,24 @@ cp_parser_enum_specifier (cp_parser* par
push_deferring_access_checks (dk_no_check);
nested_name_specifier
- = cp_parser_nested_name_specifier_opt (parser,
-/*typename_keyword_p=*/true,
-/*check_dependency_p=*/false,
-/*type_p=*/false,
-/*is_declaration=*/false);
+= cp_parser_nested_name_specifier_opt (parser,
+ /*typename_keyword_p=*/true,
+ /*check_dependency_p=*/false,
+ /*type_p=*/false,
+ /*is_declaration=*/false);
if (nested_name_specifier)
{
tree name;
identifier = cp_parser_identifier (parser);
- name = cp_parser_lookup_name (parser, identifier,
-enum_type,
-/*is_template=*/false,
-/*is_namespace=*/false,
-/*check_dependency=*/true,
-/*ambiguous_decls=*/NULL,
-input_location);
+ name = cp_parser_lookup_name (parser, identifier,
+ enum_type,
+ /*is_template=*/false,
+ /*is_namespace=*/false,
+ /*check_dependency=*/true,
+ /*ambiguous_decls=*/NULL,
+ input_location);
if (name && name != error_mark_node)
{
type = TREE_TYPE (name);
@@ -19140,23 +19138,21 @@ cp_parser_enum_specifier (cp_parser* par
{
if (cxx_dialect < cxx11 || (!scoped_enum_p && !underlying_type))
{
+ if (has_underlying_type)
+ cp_parser_commit_to_tentative_parse (parser);
cp_parser_error (parser, "expected %<{%>");
if (has_underlying_type)
- {
- type = NULL_TREE;
- goto out;
- }
+ return error_mark_node;
}
/* An opaque-enum-specifier must have a ';' here. */
if ((scoped_enum_p || underlying_type)
&& cp_lexer_next_token_is_not (parser->lexer, CPP_SEMICOLON))
{
+ if (has_underlying_type)
+ cp_parser_commit_to_tentative_parse (parser);
cp_parser_error (parser, "expected %<;%> or %<{%>");
if (has_underlying_type)
- {
- type = NULL_TREE;
- goto out;
- }
+ return error_mark_node;
}
}
@@ -19172,9 +19168,7 @@ cp_parser_enum_specifier (cp_parser* par
push_scope (nested_name_specifier);
}
else if (TREE_CODE (nested_name_specifier) == NAMESPACE_DECL)
- {
- push_nested_namespace (nested_name_specifier);
- }
+ push_nested_namespace (nested_name_specifier);
}
/* Issue an error message if type-definitions are forbidden here. */
@@ -19334,12 +19328,8 @@ cp_parser_enum_sp
[PATCH] expand: Don't depend on warning flags in code generation of strnlen [PR94189]
Hi!
The following testcase FAILs with -O2 -fcompare-debug, but the reason isn't
that we'd emit different code based on -g or non-debug, but rather that
we emit different code depending on whether -w is used or not (or e.g.
-Wno-stringop-overflow or whether some other pass emitted some other warning
already on the call).
Code generation shouldn't depend on whether we emit a warning or not if at
all possible.
The following patch punts (i.e. doesn't optimize the strnlen call to a
constant value) if we would emit the warning if it was enabled.
In the PR there is an alternate patch which does optimize the strnlen call
no matter if we emit the warning or not, though I think I prefer the version
below, e.g. the strnlen call might be crossing field boundaries, which is in
strict reading undefined, but I'd be afraid people do that in the real
world programs.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2020-03-17 Jakub Jelinek
PR middle-end/94189
* builtins.c (expand_builtin_strnlen): Do return NULL_RTX if we would
emit a warning if it was enabled and don't depend on TREE_NO_WARNING
for code-generation.
* gcc.dg/pr94189.c: New test.
--- gcc/builtins.c.jj 2020-01-12 11:54:36.198416652 +0100
+++ gcc/builtins.c 2020-03-16 11:39:02.400537378 +0100
@@ -3142,27 +3142,25 @@ expand_builtin_strnlen (tree exp, rtx ta
return NULL_RTX;
}
- if (lendata.decl
- && !TREE_NO_WARNING (exp)
- && ((tree_int_cst_lt (len, bound))
- || !exact))
+ if (lendata.decl && (tree_int_cst_lt (len, bound) || !exact))
{
location_t warnloc
= expansion_point_location_if_in_system_header (loc);
- if (warning_at (warnloc, OPT_Wstringop_overflow_,
- exact
- ? G_("%K%qD specified bound %E exceeds the size %E "
- "of unterminated array")
- : G_("%K%qD specified bound %E may exceed the size "
- "of at most %E of unterminated array"),
- exp, func, bound, len))
+ if (!TREE_NO_WARNING (exp)
+ && warning_at (warnloc, OPT_Wstringop_overflow_,
+exact
+? G_("%K%qD specified bound %E exceeds the size "
+ "%E of unterminated array")
+: G_("%K%qD specified bound %E may exceed the "
+ "size of at most %E of unterminated array"),
+exp, func, bound, len))
{
inform (DECL_SOURCE_LOCATION (lendata.decl),
"referenced argument declared here");
TREE_NO_WARNING (exp) = true;
- return NULL_RTX;
}
+ return NULL_RTX;
}
if (!len)
--- gcc/testsuite/gcc.dg/pr94189.c.jj 2020-03-16 11:32:17.785541399 +0100
+++ gcc/testsuite/gcc.dg/pr94189.c 2020-03-16 11:31:43.257053763 +0100
@@ -0,0 +1,11 @@
+/* PR middle-end/94189 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fcompare-debug" } */
+
+const char a[] = { 'a', 'b', 'c', 'd' };/* { dg-message "declared here" } */
+
+int
+foo (void)
+{
+ return __builtin_strnlen (a, 5); /* { dg-warning "specified bound 5
exceeds the size 4 of unterminated array" } */
+}
Jakub
[PATCH] strlen: Punt on UB reads past end of string literal [PR94187]
Hi!
The gcc.dg/pr68785.c test which contains:
int
foo (void)
{
return *(int *) "";
}
has UB in the program if it is ever called, but causes UB in the compiler
as well as at least in theory non-reproduceable code generation.
The problem is that nbytes is in this case 4, prep is the
TREE_STRING_POINTER of a "" string literal with TREE_STRING_LENGTH of 1 and
we do:
4890 for (const char *p = prep; p != prep + nbytes; ++p)
4891if (*p)
4892 {
4893*allnul = false;
4894break;
4895 }
and so read the bytes after the STRING_CST payload, which can be random.
I think we should just punt in this case.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2020-03-16 Jakub Jelinek
PR tree-optimization/94187
* tree-ssa-strlen.c (count_nonzero_bytes): Punt if
nchars - offset < nbytes.
--- gcc/tree-ssa-strlen.c.jj2020-03-14 08:14:47.034742349 +0100
+++ gcc/tree-ssa-strlen.c 2020-03-16 12:23:57.523534887 +0100
@@ -4822,6 +4822,8 @@ count_nonzero_bytes (tree exp, unsigned
of the access), set it here to the size of the string, including
all internal and trailing nuls if the string has any. */
nbytes = nchars - offset;
+ else if (nchars - offset < nbytes)
+ return false;
prep = TREE_STRING_POINTER (exp) + offset;
}
Jakub
Re: [PATCH] Add new wa_noexecstack testsuite effective target.
Seems to me obvious, installed as ecf2b69a629d4f79efe3c103fe54040437ea18a6. Martin
[PATCH] c++: Diagnose a deduction guide in a wrong scope [PR91759]
Hi!
The following testcase is accepts-invalid since r7-6608-ga56c0ac08242269b.
Before that change we had this
"deduction guide %qD must be declared in the same scope as %qT"
diagnostics for it, after the change it is expected to be diagnosed
in set_decl_namespace at the not_found: label in there. On this testcase
nothing is diagnosed though, because set_decl_namespace isn't called at all,
as in_namespace is NULL.
The following patch restores the old warning but does it only in case we
don't call set_decl_namespace.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or do you prefer something different?
2020-03-17 Jakub Jelinek
PR c++/91759
* decl.c (grokfndecl): Restore old diagnostics about deduction
guide declared in different scope if in_namespace is NULL_TREE.
* g++.dg/cpp1z/class-deduction72.C: New test.
--- gcc/cp/decl.c.jj2020-03-12 08:26:23.0 +0100
+++ gcc/cp/decl.c 2020-03-16 16:25:02.142867924 +0100
@@ -9644,6 +9644,15 @@ grokfndecl (tree ctype,
"namespace scope", decl);
return NULL_TREE;
}
+ tree type = TREE_TYPE (DECL_NAME (decl));
+ if (in_namespace == NULL_TREE
+ && CP_DECL_CONTEXT (decl) != CP_TYPE_CONTEXT (type))
+ {
+ error_at (location, "deduction guide %qD must be declared in the "
+ "same scope as %qT", decl, type);
+ inform (location_of (type), " declared here");
+ return NULL_TREE;
+ }
if (funcdef_flag)
error_at (location,
"deduction guide %qD must not have a function body", decl);
--- gcc/testsuite/g++.dg/cpp1z/class-deduction72.C.jj 2020-03-16
16:27:03.997068510 +0100
+++ gcc/testsuite/g++.dg/cpp1z/class-deduction72.C 2020-03-16
16:28:21.241927835 +0100
@@ -0,0 +1,11 @@
+// PR c++/91759
+// { dg-do compile { target c++17 } }
+
+namespace N {
+ template
+ struct X{ X(int); }; // { dg-message "declared here" }
+}
+
+using N::X;
+
+X(int) -> X; // { dg-error "must be declared in the same scope as" }
Jakub
[PATCH] c: Handle C_TYPE_INCOMPLETE_VARS even for ENUMERAL_TYPEs [PR94172]
Hi!
The following testcases ICE, because they contain extern variable
declarations with incomplete enum types that is later completed and after
that those variables are accessed. The ICEs are because the vars then may have
incorrect DECL_MODE etc., e.g. in the first case the var has SImode
DECL_MODE (the guessed mode for the enum), but the enum then actually has
DImode because its enumerators don't fit into unsigned int.
The following patch fixes it by using C_TYPE_INCOMPLETE_VARS not just on
incomplete struct/union types, but also incomplete enum types.
TYPE_VFIELD can't be used as it is TYPE_MIN_VALUE on ENUMERAL_TYPE,
thankfully TYPE_LANG_SLOT_1 has been used in the C FE only on
FUNCTION_TYPEs.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2020-03-16 Jakub Jelinek
PR c/94172
* c-tree.h (C_TYPE_INCOMPLETE_VARS): Define to TYPE_LANG_SLOT_1
instead of TYPE_VFIELD, and support it on {RECORD,UNION,ENUMERAL}_TYPE.
(TYPE_ACTUAL_ARG_TYPES): Check that it is only used on FUNCTION_TYPEs.
* c-decl.c (pushdecl): Push C_TYPE_INCOMPLETE_VARS also to
ENUMERAL_TYPEs.
(finish_incomplete_vars): New function, moved from finish_struct. Use
relayout_decl instead of layout_decl.
(finish_struct): Remove obsolete comment about C_TYPE_INCOMPLETE_VARS
being TYPE_VFIELD. Use finish_incomplete_vars.
(finish_enum): Clear C_TYPE_INCOMPLETE_VARS. Call
finish_incomplete_vars.
* c-typeck.c (c_build_qualified_type): Clear C_TYPE_INCOMPLETE_VARS
also on ENUMERAL_TYPEs.
* gcc.dg/pr94172-1.c: New test.
* gcc.dg/pr94172-2.c: New test.
--- gcc/c/c-tree.h.jj 2020-01-12 11:54:36.211416456 +0100
+++ gcc/c/c-tree.h 2020-03-16 18:18:52.035213367 +0100
@@ -38,9 +38,12 @@ along with GCC; see the file COPYING3.
nonzero if the definition of the type has already started. */
#define C_TYPE_BEING_DEFINED(TYPE) TYPE_LANG_FLAG_0 (TYPE)
-/* In an incomplete RECORD_TYPE or UNION_TYPE, a list of variable
- declarations whose type would be completed by completing that type. */
-#define C_TYPE_INCOMPLETE_VARS(TYPE) TYPE_VFIELD (TYPE)
+/* In an incomplete RECORD_TYPE, UNION_TYPE or ENUMERAL_TYPE, a list of
+ variable declarations whose type would be completed by completing
+ that type. */
+#define C_TYPE_INCOMPLETE_VARS(TYPE) \
+ TYPE_LANG_SLOT_1 (TREE_CHECK4 (TYPE, RECORD_TYPE, UNION_TYPE, \
+QUAL_UNION_TYPE, ENUMERAL_TYPE))
/* In an IDENTIFIER_NODE, nonzero if this identifier is actually a
keyword. C_RID_CODE (node) is then the RID_* value of the keyword. */
@@ -108,7 +111,8 @@ along with GCC; see the file COPYING3.
/* For FUNCTION_TYPE, a hidden list of types of arguments. The same as
TYPE_ARG_TYPES for functions with prototypes, but created for functions
without prototypes. */
-#define TYPE_ACTUAL_ARG_TYPES(NODE) TYPE_LANG_SLOT_1 (NODE)
+#define TYPE_ACTUAL_ARG_TYPES(NODE) \
+ TYPE_LANG_SLOT_1 (FUNCTION_TYPE_CHECK (NODE))
/* For a CONSTRUCTOR, whether some initializer contains a
subexpression meaning it is not a constant expression. */
--- gcc/c/c-decl.c.jj 2020-03-14 08:11:44.983452312 +0100
+++ gcc/c/c-decl.c 2020-03-16 18:29:56.999458487 +0100
@@ -3312,7 +3312,8 @@ pushdecl (tree x)
element = TREE_TYPE (element);
element = TYPE_MAIN_VARIANT (element);
- if (RECORD_OR_UNION_TYPE_P (element)
+ if ((RECORD_OR_UNION_TYPE_P (element)
+ || TREE_CODE (element) == ENUMERAL_TYPE)
&& (TREE_CODE (x) != TYPE_DECL
|| TREE_CODE (TREE_TYPE (x)) == ARRAY_TYPE)
&& !COMPLETE_TYPE_P (element))
@@ -8354,6 +8355,26 @@ field_decl_cmp (const void *x_p, const v
return 1;
}
+/* If this structure or union completes the type of any previous
+ variable declaration, lay it out and output its rtl. */
+static void
+finish_incomplete_vars (tree incomplete_vars, bool toplevel)
+{
+ for (tree x = incomplete_vars; x; x = TREE_CHAIN (x))
+{
+ tree decl = TREE_VALUE (x);
+ if (TREE_CODE (TREE_TYPE (decl)) == ARRAY_TYPE)
+ layout_array_type (TREE_TYPE (decl));
+ if (TREE_CODE (decl) != TYPE_DECL)
+ {
+ relayout_decl (decl);
+ if (c_dialect_objc ())
+ objc_check_decl (decl);
+ rest_of_decl_compilation (decl, toplevel, 0);
+ }
+}
+}
+
/* Fill in the fields of a RECORD_TYPE or UNION_TYPE node, T.
LOC is the location of the RECORD_TYPE or UNION_TYPE's definition.
FIELDLIST is a chain of FIELD_DECL nodes for the fields.
@@ -8612,13 +8633,6 @@ finish_struct (location_t loc, tree t, t
warning_at (loc, 0, "union cannot be made transparent");
}
- /* Note: C_TYPE_INCOMPLETE_VARS overloads TYPE_VFIELD which is used
- in dwarf2out via rest_of_decl_compilation below and means
- something totally different. Since we will be clearing
- C_TYPE_INCOMPLETE_VARS shortly
Re: [PATCH] expand: Don't depend on warning flags in code generation of strnlen [PR94189]
On Tue, Mar 17, 2020 at 9:35 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The following testcase FAILs with -O2 -fcompare-debug, but the reason isn't
> that we'd emit different code based on -g or non-debug, but rather that
> we emit different code depending on whether -w is used or not (or e.g.
> -Wno-stringop-overflow or whether some other pass emitted some other warning
> already on the call).
>
> Code generation shouldn't depend on whether we emit a warning or not if at
> all possible.
>
> The following patch punts (i.e. doesn't optimize the strnlen call to a
> constant value) if we would emit the warning if it was enabled.
> In the PR there is an alternate patch which does optimize the strnlen call
> no matter if we emit the warning or not, though I think I prefer the version
> below, e.g. the strnlen call might be crossing field boundaries, which is in
> strict reading undefined, but I'd be afraid people do that in the real
> world programs.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
> 2020-03-17 Jakub Jelinek
>
> PR middle-end/94189
> * builtins.c (expand_builtin_strnlen): Do return NULL_RTX if we would
> emit a warning if it was enabled and don't depend on TREE_NO_WARNING
> for code-generation.
>
> * gcc.dg/pr94189.c: New test.
>
> --- gcc/builtins.c.jj 2020-01-12 11:54:36.198416652 +0100
> +++ gcc/builtins.c 2020-03-16 11:39:02.400537378 +0100
> @@ -3142,27 +3142,25 @@ expand_builtin_strnlen (tree exp, rtx ta
> return NULL_RTX;
> }
>
> - if (lendata.decl
> - && !TREE_NO_WARNING (exp)
> - && ((tree_int_cst_lt (len, bound))
> - || !exact))
> + if (lendata.decl && (tree_int_cst_lt (len, bound) || !exact))
> {
> location_t warnloc
> = expansion_point_location_if_in_system_header (loc);
>
> - if (warning_at (warnloc, OPT_Wstringop_overflow_,
> - exact
> - ? G_("%K%qD specified bound %E exceeds the size %E "
> - "of unterminated array")
> - : G_("%K%qD specified bound %E may exceed the size "
> - "of at most %E of unterminated array"),
> - exp, func, bound, len))
> + if (!TREE_NO_WARNING (exp)
> + && warning_at (warnloc, OPT_Wstringop_overflow_,
> +exact
> +? G_("%K%qD specified bound %E exceeds the size "
> + "%E of unterminated array")
> +: G_("%K%qD specified bound %E may exceed the "
> + "size of at most %E of unterminated array"),
> +exp, func, bound, len))
> {
> inform (DECL_SOURCE_LOCATION (lendata.decl),
> "referenced argument declared here");
> TREE_NO_WARNING (exp) = true;
> - return NULL_RTX;
> }
> + return NULL_RTX;
> }
>
>if (!len)
> --- gcc/testsuite/gcc.dg/pr94189.c.jj 2020-03-16 11:32:17.785541399 +0100
> +++ gcc/testsuite/gcc.dg/pr94189.c 2020-03-16 11:31:43.257053763 +0100
> @@ -0,0 +1,11 @@
> +/* PR middle-end/94189 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fcompare-debug" } */
> +
> +const char a[] = { 'a', 'b', 'c', 'd' };/* { dg-message "declared here" } */
> +
> +int
> +foo (void)
> +{
> + return __builtin_strnlen (a, 5); /* { dg-warning "specified bound 5
> exceeds the size 4 of unterminated array" } */
> +}
>
> Jakub
>
Re: [PATCH] strlen: Punt on UB reads past end of string literal [PR94187]
On Tue, Mar 17, 2020 at 9:40 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The gcc.dg/pr68785.c test which contains:
> int
> foo (void)
> {
> return *(int *) "";
> }
> has UB in the program if it is ever called, but causes UB in the compiler
> as well as at least in theory non-reproduceable code generation.
> The problem is that nbytes is in this case 4, prep is the
> TREE_STRING_POINTER of a "" string literal with TREE_STRING_LENGTH of 1 and
> we do:
> 4890 for (const char *p = prep; p != prep + nbytes; ++p)
> 4891if (*p)
> 4892 {
> 4893*allnul = false;
> 4894break;
> 4895 }
> and so read the bytes after the STRING_CST payload, which can be random.
> I think we should just punt in this case.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Richard.
> 2020-03-16 Jakub Jelinek
>
> PR tree-optimization/94187
> * tree-ssa-strlen.c (count_nonzero_bytes): Punt if
> nchars - offset < nbytes.
>
> --- gcc/tree-ssa-strlen.c.jj2020-03-14 08:14:47.034742349 +0100
> +++ gcc/tree-ssa-strlen.c 2020-03-16 12:23:57.523534887 +0100
> @@ -4822,6 +4822,8 @@ count_nonzero_bytes (tree exp, unsigned
>of the access), set it here to the size of the string, including
>all internal and trailing nuls if the string has any. */
> nbytes = nchars - offset;
> + else if (nchars - offset < nbytes)
> + return false;
>
>prep = TREE_STRING_POINTER (exp) + offset;
> }
>
>
> Jakub
>
[PATCH] Fix up duplicated duplicated words mostly in comments
Hi! In the r10-7197-gbae7b38cf8a21e068ad5c0bab089dedb78af3346 commit I've noticed duplicated word in a message, which lead me to grep for those and we have a tons of them. I've used grep -v 'long long\|optab optab\|template template\|double double' *.[chS] */*.[chS] *.def config/*/* 2>/dev/null | grep ' \([a-zA-Z]\+\) \1 ' Note, the command will not detect the doubled words at the start or end of line or when one of the words is at the end of line and the next one at the start of another one. Some of it is fairly obvious, e.g. all the "the the" cases which is something I've posted and committed patch for already e.g. in 2016, other cases are often valid, e.g. "that that" seems to look mostly ok to me. Some cases are quite hard to figure out, I've left out some of them from the patch (e.g. "and and" in some cases isn't talking about bitwise/logical and and so looks incorrect, but in other cases it is talking about those operations). In most cases the right solution seems to be to remove one of the duplicated words, but not always. I think most important are the ones with user visible messages (in the patch 3 of the first 4 hunks), the rest is just comments (and internal documentation; for that see the doc/tm.texi changes). Shall I split the patch somehow for easier review, or is it ok as is? Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2020-03-17 Jakub Jelinek * lra-spills.c (remove_pseudos): Fix up duplicated word issue in a dump message. * tree-sra.c (create_access_replacement): Fix up duplicated word issue in a comment. * read-rtl-function.c (find_param_by_name, function_reader::parse_enum_value, function_reader::get_insn_by_uid): Likewise. * spellcheck.c (get_edit_distance_cutoff): Likewise. * tree-data-ref.c (create_ifn_alias_checks): Likewise. * tree.def (SWITCH_EXPR): Likewise. * selftest.c (assert_str_contains): Likewise. * ipa-param-manipulation.h (class ipa_param_body_adjustments): Likewise. * tree-ssa-math-opts.c (convert_expand_mult_copysign): Likewise. * tree-ssa-loop-split.c (find_vdef_in_loop): Likewise. * langhooks.h (struct lang_hooks_for_decls): Likewise. * ipa-prop.h (struct ipa_param_descriptor): Likewise. * tree-ssa-strlen.c (handle_builtin_string_cmp, handle_store): Likewise. * tree-ssa-dom.c (simplify_stmt_for_jump_threading): Likewise. * tree-ssa-reassoc.c (reassociate_bb): Likewise. * tree.c (component_ref_size): Likewise. * hsa-common.c (hsa_init_compilation_unit_data): Likewise. * gimple-ssa-sprintf.c (get_string_length, format_string, format_directive): Likewise. * omp-grid.c (grid_process_kernel_body_copy): Likewise. * input.c (string_concat_db::get_string_concatenation, test_lexer_string_locations_ucn4): Likewise. * cfgexpand.c (pass_expand::execute): Likewise. * gimple-ssa-warn-restrict.c (builtin_memref::offset_out_of_bounds, maybe_diag_overlap): Likewise. * rtl.c (RTX_CODE_HWINT_P_1): Likewise. * shrink-wrap.c (spread_components): Likewise. * tree-ssa-dse.c (initialize_ao_ref_for_dse, valid_ao_ref_for_dse): Likewise. * tree-call-cdce.c (shrink_wrap_one_built_in_call_with_conds): Likewise. * dwarf2out.c (dwarf2out_early_finish): Likewise. * gimple-ssa-store-merging.c: Likewise. * ira-costs.c (record_operand_costs): Likewise. * tree-vect-loop.c (vectorizable_reduction): Likewise. * target.def (dispatch): Likewise. (validate_dims, gen_ccmp_first): Fix up duplicated word issue in documentation text. * doc/tm.texi: Regenerated. * config/i386/x86-tune.def (X86_TUNE_PARTIAL_FLAG_REG_STALL): Fix up duplicated word issue in a comment. * config/i386/i386.c (ix86_test_loading_unspec): Likewise. * config/i386/i386-features.c (remove_partial_avx_dependency): Likewise. * config/msp430/msp430.c (msp430_select_section): Likewise. * config/gcn/gcn-run.c (load_image): Likewise. * config/aarch64/aarch64-sve.md (sve_ld1r): Likewise. * config/aarch64/aarch64.c (aarch64_gen_adjusted_ldpstp): Likewise. * config/aarch64/falkor-tag-collision-avoidance.c (single_dest_per_chain): Likewise. * config/nvptx/nvptx.c (nvptx_record_fndecl): Likewise. * config/fr30/fr30.c (fr30_arg_partial_bytes): Likewise. * config/rs6000/rs6000-string.c (expand_cmp_vec_sequence): Likewise. * config/rs6000/rs6000-p8swap.c (replace_swapped_load_constant): Likewise. * config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Likewise. * config/rs6000/rs6000.c (rs6000_option_override_internal): Likewise. * config/rs6000/rs6000-logue.c (rs6000_emit_probe_stack_range_stack_clash): Likewis
Re: [PATCH] LRA: fix for PR94185
>The following committed patch solves
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94185
>
>The patch was successfully bootstrapped and tested on x86-64.
This patch creates unoptimal sequence in reload:
(insn 64 63 248 10 (set (reg:DI 0 ax [161])
(zero_extend:DI (mem/c:SI (plus:DI (reg/f:DI 6 bp)
(const_int -2152 [0xf798])) [7
%sfp+-2104 S4 A64]))) "pr94185.C":25:7 114 {*zero_extendsidi2}
(nil))
(insn 248 64 65 10 (set (mem/c:DI (plus:DI (reg/f:DI 6 bp)
(const_int -2152 [0xf798])) [7 %sfp+-2104 S8 A64])
(reg:DI 0 ax [161])) "pr94185.C":25:7 66 {*movdi_internal}
(nil))
using a temporary reg, resulting in:
movl-2152(%rbp), %eax# 64[c=9 l=6] *zero_extendsidi2/3
movq%rax, -2152(%rbp)# 248[c=4 l=7] *movdi_internal/5
Please note that the insn pattern could handle matched offsetable
memory in alternative 4:
(define_insn "*zero_extendsidi2"
[(set (match_operand:DI 0 "nonimmediate_operand"
"=r,?r,?o,r ,o,?*y,?!*y,$r,$v,$x,*x,*v,*r,*k")
(zero_extend:DI
(match_operand:SI 1 "x86_64_zext_operand"
"0 ,rm,r ,rmWz,0,r ,m ,v ,r ,m ,*x,*v,*k,*km")))]
memory operand is later split with:
(define_split
[(set (match_operand:DI 0 "memory_operand")
(zero_extend:DI (match_operand:SI 1 "memory_operand")))]
"reload_completed"
[(set (match_dup 4) (const_int 0))]
"split_double_mode (DImode, &operands[0], 1, &operands[3], &operands[4]);")
And would result in a single SImode move of 0 to the high part of the
memory location.
Uros.
Re: [PATCH] LRA: fix for PR94185
On Tue, Mar 17, 2020 at 10:40:00AM +0100, Uros Bizjak via Gcc-patches wrote: > (define_split > [(set (match_operand:DI 0 "memory_operand") > (zero_extend:DI (match_operand:SI 1 "memory_operand")))] > "reload_completed" > [(set (match_dup 4) (const_int 0))] > "split_double_mode (DImode, &operands[0], 1, &operands[3], &operands[4]);") > > And would result in a single SImode move of 0 to the high part of the > memory location. Shouldn't that be something done in the generic code so that it benefits all targets? If we have a zero extension from memory to matching memory (according to endianity), then storing 0 to the other part is probably a win (almost) everywhere. So, if e.g. simplify-rtx.c does that and combine then checks if the target has corresponding store instruction... Jakub
Re: c: ignore initializers for elements of variable-size types [PR93577]
On Mon, 16 Mar 2020 at 19:59, Richard Sandiford
wrote:
>
> Christophe Lyon via Gcc-patches writes:
> > On Wed, 11 Mar 2020 at 00:37, Joseph Myers wrote:
> >>
> >> On Tue, 10 Mar 2020, Christophe Lyon wrote:
> >>
> >> > sizeless-1.c and sizeless-2.c have the same code, but the latter is
> >> > compiled with -msve-vector-bits=256 and expects different
> >> > warnings/errors.
> >> > For line 33:
> >> > svint8_t *invalid_sve_sc_ptr = &(svint8_t) { *global_sve_sc_ptr };
> >> > we now have:
> >> > sizeless-1.c:33:44: error: empty scalar initializer
> >> > sizeless-1.c:33:44: note: (near initialization for '(anonymous)')
> >> > and
> >> > sizeless-2.c:33:44: error: initializer element is not constant
> >> > sizeless-2.c:33:44: note: (near initialization for 'invalid_sve_sc_ptr')
> >> > sizeless-2.c:33:44: error: SVE type 'svint8_t' does not have a fixed size
> >> > so I think the error comes from the compound literal being treated
> >> > differently with -msve-vector-bits=256
> >>
> >> I think the sizeless-2.c diagnostics are correct while there's a problem
> >> in the sizeless-1.c case (the initializer is not empty, so it should not
> >> be diagnosed as such).
> >>
> >> Does the process_init_element code
> >>
> >> /* Ignore elements of an initializer for a variable-size type.
> >> Those are diagnosed in digest_init. */
> >> if (COMPLETE_TYPE_P (constructor_type)
> >> && TREE_CODE (TYPE_SIZE (constructor_type)) != INTEGER_CST)
> >> return;
> >>
> >> fire for the sizeless-1.c case? If so, maybe it needs to be restricted in
> >> some way to apply only to variable size structs / unions / arrays rather
> >> than whatever kind of variable-size type the SVE types are.
> >
> > It does. Type_size has POLY_INT_CST type.
> >
> > The attached small patch fixes the problem (tested on arm and aarch64).
> > OK?
>
> Thanks for doing this. I'd wondered whether it should be based on
> this or on VECTOR_TYPE_P, but FWIW, I agree basing it on this is best.
>
> > diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
> > index d8025de..1302486 100644
> > --- a/gcc/c/c-typeck.c
> > +++ b/gcc/c/c-typeck.c
> > @@ -9968,7 +9968,8 @@ process_init_element (location_t loc, struct
> > c_expr value, bool implicit,
> >/* Ignore elements of an initializer for a variable-size type.
> > Those are diagnosed in digest_init. */
> >if (COMPLETE_TYPE_P (constructor_type)
> > - && TREE_CODE (TYPE_SIZE (constructor_type)) != INTEGER_CST)
> > + && TREE_CODE (TYPE_SIZE (constructor_type)) != INTEGER_CST
> > + && TREE_CODE (TYPE_SIZE (constructor_type)) != POLY_INT_CST)
>
> Not worth respinning over, but since it hasn't been applied yet:
> a shorter alternative is to replace the != INTEGER_CST test with
> !poly_int_tree_p.
Thanks for the hint.
Now pushed as r10-7208-gfd857de80705be937d9780dbd394d006151713fe
Christophe
>
> > diff --git
> > a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> > b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> > index ec892a3..e53b871 100644
> > --- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> > +++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> > @@ -83,7 +83,6 @@ statements (int n)
> >svint8_t array[2]; /* { dg-error {array elements cannot have SVE
> > type 'svint8_t'} } */
> >svint8_t zero_length_array[0]; /* { dg-error {array elements cannot
> > have SVE type 'svint8_t'} } */
> >svint8_t empty_init_array[] = {}; /* { dg-error {array elements
> > cannot have SVE type 'svint8_t'} } */
> > - /* { dg-error {empty scalar
> > initializer} "" { target *-*-* } .-1 } */
> >typedef svint8_t vla_type[n]; /* { dg-error {array elements cannot
> > have SVE type 'svint8_t'} } */
> >
> >/* Assignment. */
> > diff --git
> > a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> > b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> > index 7174393..9986d27 100644
> > --- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> > +++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> > @@ -83,7 +83,6 @@ statements (int n)
> >svint8_t array[2]; /* { dg-error {array elements cannot have SVE
> > type 'svint8_t'} } */
> >svint8_t zero_length_array[0]; /* { dg-error {array elements cannot
> > have SVE type 'svint8_t'} } */
> >svint8_t empty_init_array[] = {}; /* { dg-error {array elements
> > cannot have SVE type 'svint8_t'} } */
> > - /* { dg-error {empty scalar
> > initializer} "" { target *-*-* } .-1 } */
> >typedef svint8_t vla_type[n]; /* { dg-error {array elements cannot
> > have SVE type 'svint8_t'} } */
> >
> >/* Assignment. */
>
> Jeff pointed out off-list that using:
>
>N: ... /* { dg-error {...} } */
> N+1: /* { dg-error {...} "" { target *-*-* } .-1 } */
>
> led to two identical test names for line N. This was causing t
[committed] testsuite: Fix pr94185.C testcase on i686-linux with C++98 [PR94185]
Hi!
On Mon, Mar 16, 2020 at 04:47:05PM -0400, Vladimir Makarov via Gcc-patches
wrote:
> The following committed patch solves
I'm getting on i686-linux
FAIL: g++.target/i386/pr94185.C -std=gnu++98 (test for excess errors)
This is because of a diagnostic that 4294967295 is unsigned only in ISO C90.
Adding U suffix fixes it and the testcase still ICEs with unfixed gcc and
passes with current trunk.
Tested on x86_64-linux with
check-c++-all RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} i386.exp=pr94185.C'
both using older GCC where it ICEs and current where it now all PASSes,
committed to trunk as obvious.
2020-03-17 Jakub Jelinek
PR target/94185
* g++.target/i386/pr94185.C (l): Use 4294967295U instead of 4294967295
to avoid FAIL with -m32 -std=c++98.
--- gcc/testsuite/g++.target/i386/pr94185.C.jj 2020-03-16 22:56:55.0
+0100
+++ gcc/testsuite/g++.target/i386/pr94185.C 2020-03-17 11:11:10.158846926
+0100
@@ -22,7 +22,7 @@ int d;
void l(char *, ar m, long n) {
switch (m.au[d])
case 0:
-n &= 4294967295;
+n &= 4294967295U;
bb.h(0).g(n);
}
void o() {
Jakub
Re: [PATCH PR94201] aarch64：ICE in tiny code model for ilp32
"duanbo (C)" writes:
> Hi
> The testcase pr78255.c triggers ice when testing GCC trunk on aarch64 with
> -mabi=ilp32 -fPIC.
> Case path: gcc/testsuite/gcc.target/aarch64/pr78255.c
>
> The ICE is caused by insufficient support for the tiny code model under ilp32
> mode with fPIC option, where a SI mode register might be used for the ldr
> instruction.
> However, current md pattern for UNSPEC_GOTTINYPIC only support DI mode
> register as its operator.
>
> A simple solution is to add the pattern in tiny code model to support ilp32
> mode.
> Attached please find the proposed patch.
> Newly add test fail without the patch and pass after applying the patch.
> Bootstrap and tested on aarch64 Linux platform. No new regression witnessed.
> Any suggestion?
Thanks for doing this. The patch looks good, but some minor comments below.
However, the test fails for me on aarch64-linux-gnu:
FAIL: gcc.target/aarch64/pr94201.c scan-assembler ldr w0, \\s+a
FAIL: gcc.target/aarch64/pr94201.c scan-assembler b\\s+bar
Could you double-check your set-up to make sure that it's running the
testsuite correctly? With scan-assembler tests, it can be useful to
introduce a deliberate typo and check that the test fails, then remove
the typo and check that the test passes.
You probably already know, but it's possible to run just the new
test by adding:
RUNTESTFLAGS=aarch64.exp=pr94201.c
to the "make check-gcc" command line. The final patch still needs to be
tested against the full testsuite of course, but using RUNTESTFLAGS can
save time while developing the patch.
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index b0cbb6e2d55..c56ed733e19 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -2739,8 +2739,26 @@ aarch64_load_symref_appropriately (rtx dest, rtx imm,
>}
>
> case SYMBOL_TINY_GOT:
> - emit_insn (gen_ldr_got_tiny (dest, imm));
> - return;
> + {
> + rtx insn;
> + machine_mode mode = GET_MODE (dest);
> +
> + if (mode == ptr_mode)
> + {
> + if (mode == DImode)
> + insn = gen_ldr_got_tiny_di (dest, imm);
> + else
> + insn = gen_ldr_got_tiny_si (dest, imm);
> + }
With the .md change mentioned below, we can instead use:
if (mode == ptr_mode)
insn = gen_ldr_got_tiny (mode, dest, imm);
> + else
> + {
> + gcc_assert (mode == Pmode);
> + insn = gen_ldr_got_tiny_sidi (dest, imm);
> + }
> +
> + emit_insn (insn);
> + return;
> + }
>
> case SYMBOL_TINY_TLSIE:
>{
> diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
> index 7ad4e918578..debc6656670 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -6766,13 +6766,23 @@
>[(set_attr "type" "load_4")]
> )
>
> -(define_insn "ldr_got_tiny"
> - [(set (match_operand:DI 0 "register_operand" "=r")
> - (unspec:DI [(match_operand:DI 1 "aarch64_valid_symref" "S")]
> -UNSPEC_GOTTINYPIC))]
> +(define_insn "ldr_got_tiny_"
Making this "@ldr_got_tiny_" creates a gen_ldr_got_tiny
function that takes the mode as the first argument. We can then
use this function in the aarch64.c code above.
> + [(set (match_operand:PTR 0 "register_operand" "=r")
> + (unspec:PTR [(match_operand:PTR 1 "aarch64_valid_symref" "S")]
> + UNSPEC_GOTTINYPIC))]
Very minor formatting issue, but: the usual style in the aarch64 port
is to indent the unspec name to the same column as the "[", like the
original pattern did.
>""
> - "ldr\\t%0, %L1"
> - [(set_attr "type" "load_8")]
> + "ldr\\t%0, %L1"
Pre-existing, not your fault, but: there only needs to be a single
backslash here.
> + [(set_attr "type" "load_")]
> +)
> +
> +(define_insn "ldr_got_tiny_sidi"
> + [(set (match_operand:DI 0 "register_operand" "=r")
> + (zero_extend:DI
> + (unspec:SI [(match_operand:DI 1 "aarch64_valid_symref" "S")]
> + UNSPEC_GOTTINYPIC)))]
Same unspec formatting comment as above. Also, the usual style
in the aarch64 port is to indent the operand of something like
(zero_extend by two extra spaces, giving:
(define_insn "ldr_got_tiny_sidi"
[(set (match_operand:DI 0 "register_operand" "=r")
(zero_extend:DI
(unspec:SI [(match_operand:DI 1 "aarch64_valid_symref" "S")]
UNSPEC_GOTTINYPIC)))]
(but with 8 spaces converted to tabs).
> + "TARGET_ILP32"
> + "ldr\\t%w0, %L1"
We only need a single backslash here too.
Thanks,
Richard
> + [(set_attr "type" "load_4")]
> )
>
> (define_insn "aarch64_load_tp_hard"
> diff --git a/gcc/testsuite/gcc.target/aarch64/pr94201.c
> b/gcc/testsuite/gcc.target/aarch64/pr94201.c
> new file mode 100644
> index 000..f822ddea7bd
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/pr94201.c
> @@ -0,0 +1,15 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mcmodel=tiny -mabi=ilp32 -fPIC"
Re: [PATCH 2/2] [aarch64] Rework fpcr fpsr getter/setter builtins
Andrea Corallo writes: > Hi all, > > second and last patch of the two reworking FPCR and FPSR builtins. > > This rework __builtin_aarch64_set_fpcr (unsigned) and > __builtin_aarch64_set_fpsr (unsigned) to emit a read-modify-sequences > as: > > mrs x1, fpsr > bfi x1, x0, 0, 32 > msr fpsr, x1 > > This in order to preserve the original high 32 bits of the system > register. Both FPSR and FPCR became 64bit regs with armv8.1. > > Bootstrapped on aarch64-linux-gnu, does not introduce regressions. > > Regards > > Andrea > > gcc/ChangeLog: > > 2020-??-?? Andrea Corallo > > * config/aarch64/aarch64.md (insv_reg): Pattern renamed. > (set_fpcr, set_fpsr): Pattern modified for read-modify-write > sequence respecting high 32bit register content. > > gcc/testsuite/ChangeLog: > > 2020-??-?? Andrea Corallo > > * gcc.target/aarch64/set_fpcr.c: New test. > * gcc.target/aarch64/get_fpcr.c: New test. > * gcc.target/aarch64/set_fpsr.c: New test. > * gcc.target/aarch64/get_fpsr.c: New test. Ping, please let me know if these are okay for trunk. Thanks Andrea
Re: [committed] libstdc++: Add default constructor to net::service_already_exists (PR 94199)
Hi, On Mon, 16 Mar 2020 at 23:54, Jonathan Wakely via Gcc-patches wrote: > > The service_already_exists exception type specified in the TS doesn't > have any constructors defined. Since its base class isn't default > constructible, that means has no usable constructors. This may be a > defect in the TS. > > This patch fixes it by adding a default constructor, but making it > private. The make_service function is declared as a friend to be able to > call that private constructor. > > PR libstdc++/94199 > * include/experimental/executor (service_already_exists): Add default > constructor. Declare make_service to be a friend. > * testsuite/experimental/net/execution_context/make_service.cc: New > test. > The new test fails on arm-eabi / aarch64-elf (aka bare-metal / newlib targets), because: /arm-none-eabi/libstdc++-v3/include/experimental/executor:514: error: 'mutex' in namespace 'std' does not name a type /arm-none-eabi/libstdc++-v3/include/experimental/executor:561: error: 'mutex' is not a member of 'std' [...] I don't remember what's the usual "fix" for this Thanks, Christophe > Tested powerpc64le-linux, committed to master. > > I'll backport it to gcc-9 too. >
RE: [PATCH v2][ARM][GCC][4/x]: MVE ACLE vector interleaving store intrinsics.
Hi Srinath,
Thanks, I've pushed this to master.
Kyrill
-Original Message-
From: Srinath Parvathaneni
Sent: 10 March 2020 18:20
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: [PATCH v2][ARM][GCC][4/x]: MVE ACLE vector interleaving store
intrinsics.
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534328.html
Hello,
This patch supports MVE ACLE intrinsics vst4q_s8, vst4q_s16, vst4q_s32,
vst4q_u8, vst4q_u16, vst4q_u32, vst4q_f16 and vst4q_f32.
In this patch arm_mve_builtins.def file is added to the source code in which
the builtins for MVE ACLE intrinsics are defined using builtin qualifiers.
Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more
details.
[1]
https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/mve-intrinsics
Regression tested on target arm-none-eabi and armeb-none-eabi and found no
regressions.
Ok for trunk?
Thanks,
Srinath.
gcc/ChangeLog:
2020-03-06 Andre Vieira
Mihail Ionescu
Srinath Parvathaneni
* config/arm/arm-builtins.c (CF): Define mve_builtin_data.
(VAR1): Define.
(ARM_BUILTIN_MVE_PATTERN_START): Define.
(arm_init_mve_builtins): Define function.
(arm_init_builtins): Add TARGET_HAVE_MVE check.
(arm_expand_builtin_1): Check the range of fcode.
(arm_expand_mve_builtin): Define function to expand MVE builtins.
(arm_expand_builtin): Check the range of fcode.
* config/arm/arm_mve.h (__ARM_FEATURE_MVE): Define MVE floating point
types.
(__ARM_MVE_PRESERVE_USER_NAMESPACE): Define to protect user namespace.
(vst4q_s8): Define macro.
(vst4q_s16): Likewise.
(vst4q_s32): Likewise.
(vst4q_u8): Likewise.
(vst4q_u16): Likewise.
(vst4q_u32): Likewise.
(vst4q_f16): Likewise.
(vst4q_f32): Likewise.
(__arm_vst4q_s8): Define inline builtin.
(__arm_vst4q_s16): Likewise.
(__arm_vst4q_s32): Likewise.
(__arm_vst4q_u8): Likewise.
(__arm_vst4q_u16): Likewise.
(__arm_vst4q_u32): Likewise.
(__arm_vst4q_f16): Likewise.
(__arm_vst4q_f32): Likewise.
(__ARM_mve_typeid): Define macro with MVE types.
(__ARM_mve_coerce): Define macro with _Generic feature.
(vst4q): Define polymorphic variant for different vst4q builtins.
* config/arm/arm_mve_builtins.def: New file.
* config/arm/iterators.md (VSTRUCT): Modify to allow XI and OI
modes in MVE.
* config/arm/mve.md (MVE_VLD_ST): Define iterator.
(unspec): Define unspec.
(mve_vst4q): Define RTL pattern.
* config/arm/neon.md (mov): Modify expand to allow XI and OI
modes in MVE.
(neon_mov): Modify RTL define_insn to allow XI and OI modes
in MVE.
(define_split): Allow OI mode split for MVE after reload.
(define_split): Allow XI mode split for MVE after reload.
* config/arm/t-arm (arm.o): Add entry for arm_mve_builtins.def.
(arm-builtins.o): Likewise.
gcc/testsuite/ChangeLog:
2020-03-06 Andre Vieira
Mihail Ionescu
Srinath Parvathaneni
* gcc.target/arm/mve/intrinsics/vst4q_f16.c: New test.
* gcc.target/arm/mve/intrinsics/vst4q_f32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vst4q_s16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vst4q_s32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vst4q_s8.c: Likewise.
* gcc.target/arm/mve/intrinsics/vst4q_u16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vst4q_u32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vst4q_u8.c: Likewise.
### Attachment also inlined for ease of reply###
diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index
28917363eeae51b7cc39576f3c3e77a0350b8877..b9ee45d5950ac9c1e12d88cd7d3ece1953dc51d0
100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -432,6 +432,13 @@ static arm_builtin_datum neon_builtin_data[] = };
#undef CF
+#define CF(N,X) CODE_FOR_mve_##N##X
+static arm_builtin_datum mve_builtin_data[] = { #include
+"arm_mve_builtins.def"
+};
+
+#undef CF
#undef VAR1
#define VAR1(T, N, A) \
{#N, UP (A), CODE_FOR_arm_##N, 0, T##_QUALIFIERS}, @@ -736,6 +743,13 @@ enum
arm_builtins
#include "arm_acle_builtins.def"
+ ARM_BUILTIN_MVE_BASE,
+
+#undef VAR1
+#define VAR1(T, N, X) \
+ ARM_BUILTIN_MVE_##N##X,
+#include "arm_mve_builtins.def"
+
ARM_BUILTIN_MAX
};
@@ -745,6 +759,9 @@ enum arm_builtins
#define ARM_BUILTIN_NEON_PATTERN_START \
(ARM_BUILTIN_NEON_BASE + 1)
+#define ARM_BUILTIN_MVE_PATTERN_START \
+ (ARM_BUILTIN_MVE_BASE + 1)
+
#define ARM_BUILTIN_ACLE_PATTERN_START \
(ARM_BUILTIN_ACLE_BASE + 1)
@@ -1276,6 +1293,22 @@ arm_init_acle_builtins (void)
}
}
+
Re: [committed] libstdc++: Add default constructor to net::service_already_exists (PR 94199)
On 17/03/20 12:01 +0100, Christophe Lyon wrote: Hi, On Mon, 16 Mar 2020 at 23:54, Jonathan Wakely via Gcc-patches wrote: The service_already_exists exception type specified in the TS doesn't have any constructors defined. Since its base class isn't default constructible, that means has no usable constructors. This may be a defect in the TS. This patch fixes it by adding a default constructor, but making it private. The make_service function is declared as a friend to be able to call that private constructor. PR libstdc++/94199 * include/experimental/executor (service_already_exists): Add default constructor. Declare make_service to be a friend. * testsuite/experimental/net/execution_context/make_service.cc: New test. The new test fails on arm-eabi / aarch64-elf (aka bare-metal / newlib targets), because: /arm-none-eabi/libstdc++-v3/include/experimental/executor:514: error: 'mutex' in namespace 'std' does not name a type /arm-none-eabi/libstdc++-v3/include/experimental/executor:561: error: 'mutex' is not a member of 'std' [...] I don't remember what's the usual "fix" for this I think they are just failing on some targets: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89760
Re: [PATCH] driver: Improve the generated help text for alias options with arguments
Lewis Hyatt writes: > On Mon, Mar 16, 2020 at 06:11:08PM +, Richard Sandiford wrote: >> Lewis Hyatt via Gcc-patches writes: > ... >> > FWIW there are three other options currently affected by this change >> > (-Wimplicit-fallthrough, -fcf-protection, and -flive-patching). The change >> > for >> > -Wimplicit-fallthrough I think is particularly helpful: >> > >> > -Wimplicit-fallthrough Same as -Wimplicit-fallthrough=. Use the >> > latter option instead. >> > becomes >> > -Wimplicit-fallthrough Same as -Wimplicit-fallthrough=3 (or, in >> > negated form, -Wimplicit-fallthrough=0). >> >> I also see: >> >> - -ftail-call-workaround Same as -ftail-call-workaround=. Use the >> latter option instead. >> + -ftail-call-workaround Same as -ftail-call-workaround=1 (or, in >> negated form, -ftail-call-workaround=0). >>-ftail-call-workaround=<0,2> Disallow tail call optimization when a >> calling routine may have omitted character lengths. >> ... >>--imacros Same as -imacros. Use the latter option >> instead. >>--imacros= Same as -imacros. Use the latter option >> instead. >>--include Same as -include. Use the latter option >> instead. >> - --include-barrier Same as -I. Use the latter option instead. >> + --include-barrier Same as -I-. >>--include-directory Same as -I. Use the latter option instead. >>--include-directory-after Same as -idirafter. Use the latter option >> instead. >>--include-directory-after= Same as -idirafter. Use the latter option >> instead. >> ... >> - -WnormalizedSame as -Wnormalized=. Use the latter option >> instead. >> + -WnormalizedSame as -Wnormalized=nfc (or, in negated >> form, -Wnormalized=none). >>-Wnormalized=[none|id|nfc|nfkc] Warn about non-normalized Unicode strings. >> >> I agree all of these look like improvements, especially the >> --include-barrier one. But I think the include ones also show >> that the "Use the latter option instead." decision is independent >> of whether the option is defined to be an alias. Gah, I meant an Alias() with an argument here. >> >> FWIW, there's also: >> >> Wmissing-format-attribute >> C ObjC C++ ObjC++ Warning Alias(Wsuggest-attribute=format) >> ; >> >> which still ends up as: >> >> -Wmissing-format-attribute Same as -Wsuggest-attribute=format. Use the >> latter option instead. >> >> Not really my area though, so I don't have any specific suggestion >> about how to separate the cases. >> > > Right, sorry, in my first email I only mentioned the options output by > --help=common, but there were a few more as well. Thanks very much for trying > it out and for the feedback. > > The rule I implemented was to change the help output for all alias options > with no documentation if they also specify the extra 2nd option (or 2nd and > 3rd options) to the Alias directive. For example, -include-barrier is like > this: > > -include-barrier C ObjC C++ ObjC++ Alias(I, -) > > It serves to provide the argument '-' to the option '-I', so it is eligible > for > the new text. The others are like this one: > > -include-directory-after C ObjC C++ ObjC++ Separate Alias(idirafter) > MissingArgError(missing path after %qs) > > Since that one doesn't pass the extra args to Alias, I interpreted it to > mean this is the case for which the "Use the latter option" directive was > intended to apply. (-idirafter has been designated as preferable to > -include-directory-after). Yeah, I get why you did it like this. It's just that the end effect is to make --include-barrier seem less disparaged than the other --include-* options, but I'm not sure there's supposed to be any difference between them in that respect. Perhaps we should drop the "Use the latter option instead." thing altogether for aliases. I'm not sure that it really helps, and this thread shows that adding it automatically can lead to some odd corner cases. In practice we shouldn't remove any of these aliases unless we're also removing the option that they're an alias of. And if we do that, the options should go through the usual deprecation cycle, just like options without aliases. If there are specific options that we want to steer users away from without deprecation, then we should probably have a specific tag for that. Thanks, Richard
RE: [PATCH v2][ARM][GCC][1/1x]: Patch to support MVE ACLE intrinsics with unary operand.
Hi Srinath, Thanks, I've pushed this to master. Kyrill -Original Message- From: Srinath Parvathaneni Sent: 10 March 2020 18:21 To: gcc-patches@gcc.gnu.org Cc: Kyrylo Tkachov Subject: [PATCH v2][ARM][GCC][1/1x]: Patch to support MVE ACLE intrinsics with unary operand. Hello Kyrill, Following patch is the rebased version of v1. (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534343.html Hello, This patch supports MVE ACLE intrinsics vcvtq_f16_s16, vcvtq_f32_s32, vcvtq_f16_u16, vcvtq_f32_u32n vrndxq_f16, vrndxq_f32, vrndq_f16, vrndq_f32, vrndpq_f16, vrndpq_f32, vrndnq_f16, vrndnq_f32, vrndmq_f16, vrndmq_f32, vrndaq_f16, vrndaq_f32, vrev64q_f16, vrev64q_f32, vnegq_f16, vnegq_f32, vdupq_n_f16, vdupq_n_f32, vabsq_f16, vabsq_f32, vrev32q_f16, vcvttq_f32_f16, vcvtbq_f32_f16. Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more details. [1] https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/mve-intrinsics Regression tested on target arm-none-eabi and armeb-none-eabi and found no regressions. Ok for trunk? Thanks, Srinath. gcc/ChangeLog: 2020-03-06 Andre Vieira Mihail Ionescu Srinath Parvathaneni * config/arm/arm-builtins.c (UNOP_NONE_NONE_QUALIFIERS): Define macro. (UNOP_NONE_SNONE_QUALIFIERS): Likewise. (UNOP_NONE_UNONE_QUALIFIERS): Likewise. * config/arm/arm_mve.h (vrndxq_f16): Define macro. (vrndxq_f32): Likewise. (vrndq_f16) Likewise.: (vrndq_f32): Likewise. (vrndpq_f16): Likewise. (vrndpq_f32): Likewise. (vrndnq_f16): Likewise. (vrndnq_f32): Likewise. (vrndmq_f16): Likewise. (vrndmq_f32): Likewise. (vrndaq_f16): Likewise. (vrndaq_f32): Likewise. (vrev64q_f16): Likewise. (vrev64q_f32): Likewise. (vnegq_f16): Likewise. (vnegq_f32): Likewise. (vdupq_n_f16): Likewise. (vdupq_n_f32): Likewise. (vabsq_f16): Likewise. (vabsq_f32): Likewise. (vrev32q_f16): Likewise. (vcvttq_f32_f16): Likewise. (vcvtbq_f32_f16): Likewise. (vcvtq_f16_s16): Likewise. (vcvtq_f32_s32): Likewise. (vcvtq_f16_u16): Likewise. (vcvtq_f32_u32): Likewise. (__arm_vrndxq_f16): Define intrinsic. (__arm_vrndxq_f32): Likewise. (__arm_vrndq_f16): Likewise. (__arm_vrndq_f32): Likewise. (__arm_vrndpq_f16): Likewise. (__arm_vrndpq_f32): Likewise. (__arm_vrndnq_f16): Likewise. (__arm_vrndnq_f32): Likewise. (__arm_vrndmq_f16): Likewise. (__arm_vrndmq_f32): Likewise. (__arm_vrndaq_f16): Likewise. (__arm_vrndaq_f32): Likewise. (__arm_vrev64q_f16): Likewise. (__arm_vrev64q_f32): Likewise. (__arm_vnegq_f16): Likewise. (__arm_vnegq_f32): Likewise. (__arm_vdupq_n_f16): Likewise. (__arm_vdupq_n_f32): Likewise. (__arm_vabsq_f16): Likewise. (__arm_vabsq_f32): Likewise. (__arm_vrev32q_f16): Likewise. (__arm_vcvttq_f32_f16): Likewise. (__arm_vcvtbq_f32_f16): Likewise. (__arm_vcvtq_f16_s16): Likewise. (__arm_vcvtq_f32_s32): Likewise. (__arm_vcvtq_f16_u16): Likewise. (__arm_vcvtq_f32_u32): Likewise. (vrndxq): Define polymorphic variants. (vrndq): Likewise. (vrndpq): Likewise. (vrndnq): Likewise. (vrndmq): Likewise. (vrndaq): Likewise. (vrev64q): Likewise. (vnegq): Likewise. (vabsq): Likewise. (vrev32q): Likewise. (vcvtbq_f32): Likewise. (vcvttq_f32): Likewise. (vcvtq): Likewise. * config/arm/arm_mve_builtins.def (VAR2): Define. (VAR1): Define. * config/arm/mve.md (mve_vrndxq_f): Add RTL pattern. (mve_vrndq_f): Likewise. (mve_vrndpq_f): Likewise. (mve_vrndnq_f): Likewise. (mve_vrndmq_f): Likewise. (mve_vrndaq_f): Likewise. (mve_vrev64q_f): Likewise. (mve_vnegq_f): Likewise. (mve_vdupq_n_f): Likewise. (mve_vabsq_f): Likewise. (mve_vrev32q_fv8hf): Likewise. (mve_vcvttq_f32_f16v4sf): Likewise. (mve_vcvtbq_f32_f16v4sf): Likewise. (mve_vcvtq_to_f_): Likewise. gcc/testsuite/ChangeLog: 2020-03-06 Andre Vieira Mihail Ionescu Srinath Parvathaneni * gcc.target/arm/mve/intrinsics/vabsq_f16.c: New test. * gcc.target/arm/mve/intrinsics/vabsq_f32.c: Likewise. * gcc.target/arm/mve/intrinsics/vcvtbq_f32_f16.c: Likewise. * gcc.target/arm/mve/intrinsics/vcvtq_f16_s16.c: Likewise. * gcc.target/arm/mve/intrinsics/vcvtq_f16_u16.c: Likewise. * gcc.target/arm/mve/intrinsics/vcvtq_f32_s32.c: Likewise. * gcc.target/arm/mve/intrinsics/vcvtq_f32_u32.c: Likewise. * gcc.target/arm/mve/intr
RE: [PATCH v2][ARM][GCC][1/1x]: Patch to support MVE ACLE intrinsics with unary operand.
Hi Srinath, Thanks, I've pushed this to master. Kyrill -Original Message- From: Srinath Parvathaneni Sent: 10 March 2020 18:21 To: gcc-patches@gcc.gnu.org Cc: Kyrylo Tkachov Subject: [PATCH v2][ARM][GCC][1/1x]: Patch to support MVE ACLE intrinsics with unary operand. Hello Kyrill, Following patch is the rebased version of v1. (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534343.html Hello, This patch supports MVE ACLE intrinsics vcvtq_f16_s16, vcvtq_f32_s32, vcvtq_f16_u16, vcvtq_f32_u32n vrndxq_f16, vrndxq_f32, vrndq_f16, vrndq_f32, vrndpq_f16, vrndpq_f32, vrndnq_f16, vrndnq_f32, vrndmq_f16, vrndmq_f32, vrndaq_f16, vrndaq_f32, vrev64q_f16, vrev64q_f32, vnegq_f16, vnegq_f32, vdupq_n_f16, vdupq_n_f32, vabsq_f16, vabsq_f32, vrev32q_f16, vcvttq_f32_f16, vcvtbq_f32_f16. Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more details. [1] https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/mve-intrinsics Regression tested on target arm-none-eabi and armeb-none-eabi and found no regressions. Ok for trunk? Thanks, Srinath. gcc/ChangeLog: 2020-03-06 Andre Vieira Mihail Ionescu Srinath Parvathaneni * config/arm/arm-builtins.c (UNOP_NONE_NONE_QUALIFIERS): Define macro. (UNOP_NONE_SNONE_QUALIFIERS): Likewise. (UNOP_NONE_UNONE_QUALIFIERS): Likewise. * config/arm/arm_mve.h (vrndxq_f16): Define macro. (vrndxq_f32): Likewise. (vrndq_f16) Likewise.: (vrndq_f32): Likewise. (vrndpq_f16): Likewise. (vrndpq_f32): Likewise. (vrndnq_f16): Likewise. (vrndnq_f32): Likewise. (vrndmq_f16): Likewise. (vrndmq_f32): Likewise. (vrndaq_f16): Likewise. (vrndaq_f32): Likewise. (vrev64q_f16): Likewise. (vrev64q_f32): Likewise. (vnegq_f16): Likewise. (vnegq_f32): Likewise. (vdupq_n_f16): Likewise. (vdupq_n_f32): Likewise. (vabsq_f16): Likewise. (vabsq_f32): Likewise. (vrev32q_f16): Likewise. (vcvttq_f32_f16): Likewise. (vcvtbq_f32_f16): Likewise. (vcvtq_f16_s16): Likewise. (vcvtq_f32_s32): Likewise. (vcvtq_f16_u16): Likewise. (vcvtq_f32_u32): Likewise. (__arm_vrndxq_f16): Define intrinsic. (__arm_vrndxq_f32): Likewise. (__arm_vrndq_f16): Likewise. (__arm_vrndq_f32): Likewise. (__arm_vrndpq_f16): Likewise. (__arm_vrndpq_f32): Likewise. (__arm_vrndnq_f16): Likewise. (__arm_vrndnq_f32): Likewise. (__arm_vrndmq_f16): Likewise. (__arm_vrndmq_f32): Likewise. (__arm_vrndaq_f16): Likewise. (__arm_vrndaq_f32): Likewise. (__arm_vrev64q_f16): Likewise. (__arm_vrev64q_f32): Likewise. (__arm_vnegq_f16): Likewise. (__arm_vnegq_f32): Likewise. (__arm_vdupq_n_f16): Likewise. (__arm_vdupq_n_f32): Likewise. (__arm_vabsq_f16): Likewise. (__arm_vabsq_f32): Likewise. (__arm_vrev32q_f16): Likewise. (__arm_vcvttq_f32_f16): Likewise. (__arm_vcvtbq_f32_f16): Likewise. (__arm_vcvtq_f16_s16): Likewise. (__arm_vcvtq_f32_s32): Likewise. (__arm_vcvtq_f16_u16): Likewise. (__arm_vcvtq_f32_u32): Likewise. (vrndxq): Define polymorphic variants. (vrndq): Likewise. (vrndpq): Likewise. (vrndnq): Likewise. (vrndmq): Likewise. (vrndaq): Likewise. (vrev64q): Likewise. (vnegq): Likewise. (vabsq): Likewise. (vrev32q): Likewise. (vcvtbq_f32): Likewise. (vcvttq_f32): Likewise. (vcvtq): Likewise. * config/arm/arm_mve_builtins.def (VAR2): Define. (VAR1): Define. * config/arm/mve.md (mve_vrndxq_f): Add RTL pattern. (mve_vrndq_f): Likewise. (mve_vrndpq_f): Likewise. (mve_vrndnq_f): Likewise. (mve_vrndmq_f): Likewise. (mve_vrndaq_f): Likewise. (mve_vrev64q_f): Likewise. (mve_vnegq_f): Likewise. (mve_vdupq_n_f): Likewise. (mve_vabsq_f): Likewise. (mve_vrev32q_fv8hf): Likewise. (mve_vcvttq_f32_f16v4sf): Likewise. (mve_vcvtbq_f32_f16v4sf): Likewise. (mve_vcvtq_to_f_): Likewise. gcc/testsuite/ChangeLog: 2020-03-06 Andre Vieira Mihail Ionescu Srinath Parvathaneni * gcc.target/arm/mve/intrinsics/vabsq_f16.c: New test. * gcc.target/arm/mve/intrinsics/vabsq_f32.c: Likewise. * gcc.target/arm/mve/intrinsics/vcvtbq_f32_f16.c: Likewise. * gcc.target/arm/mve/intrinsics/vcvtq_f16_s16.c: Likewise. * gcc.target/arm/mve/intrinsics/vcvtq_f16_u16.c: Likewise. * gcc.target/arm/mve/intrinsics/vcvtq_f32_s32.c: Likewise. * gcc.target/arm/mve/intrinsics/vcvtq_f32_u32.c: Likewise. * gcc.target/arm/mve/intr
Re: [PATCH v3][ARM][GCC][1/x]: MVE ACLE intrinsics framework patch.
On Mon, 16 Mar 2020 at 18:41, Kyrylo Tkachov wrote: > > Hi Srinath, > > I've pushed the first three of the patches for you to master: > [ARM][GCC][3/x]: MVE ACLE intrinsics framework patch. > [ARM][GCC][2/x]: MVE ACLE intrinsics framework patch. > [ARM][GCC][1/x]: MVE ACLE intrinsics framework patch. > > For this first one I adjusted the add_options directives for mve to actually > add armv8.1-m.main+mve or armv8.1-m.main+mve.fp to the march line so that the > tests don't appear as UNSUPPORTED when running the testsuite without any > explicit options specified. > Please keep an eye out for any fallout in the coming days (though I've smoked > tested the patches myself before committing) > Hi, I've noticed regressions on arm-none-linux-gnueabihf --with-mode arm --with-cpu cortex-a9 --with-fpu neon-fp16 (--with-mode arm is important, or force -marm when running the tests) FAIL: gcc.target/arm/neon-cond-1.c execution test FAIL: gfortran.dg/array_constructor_7.f90 -O3 -g execution test FAIL: gfortran.dg/complex_intrinsic_5.f90 -O0 execution test FAIL: gfortran.dg/complex_intrinsic_5.f90 -O1 execution test FAIL: gfortran.dg/complex_intrinsic_5.f90 -O2 execution test FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -g execution test FAIL: gfortran.dg/complex_intrinsic_5.f90 -Os execution test Christophe > Thanks, > Kyrill > > -Original Message- > From: Gcc-patches On Behalf Of Srinath > Parvathaneni > Sent: 16 March 2020 10:53 > To: Kyrill Tkachov ; gcc-patches@gcc.gnu.org > Subject: Re: [PATCH v3][ARM][GCC][1/x]: MVE ACLE intrinsics framework patch. > > Hi Kyrill, > > > This is ok but please bootstrap it on arm-none-linux-gnueabihf as well. > > I have bootstrapped this patch on arm-none-linux-gnueabihf and found no > issues. > There is problem with git commit rights, could you commit this patch on my > behalf. > > Regards > SRI > > From: Kyrill Tkachov > Sent: 12 March 2020 11:15 > To: Srinath Parvathaneni ; > gcc-patches@gcc.gnu.org > Subject: Re: [PATCH v3][ARM][GCC][1/x]: MVE ACLE intrinsics framework patch. > > Hi Srinath, > > On 3/10/20 6:19 PM, Srinath Parvathaneni wrote: > > Hello Kyrill, > > > > This patch addresses all the comments in patch version v2. > > (version v2) > > https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540415.html > > > > > > > > Hello, > > > > This patch creates the required framework for MVE ACLE intrinsics. > > > > The following changes are done in this patch to support MVE ACLE > > intrinsics. > > > > Header file arm_mve.h is added to source code, which contains the > > definitions of MVE ACLE intrinsics and different data types used in > > MVE. Machine description file mve.md is also added which contains the > > RTL patterns defined for MVE. > > > > A new reigster "p0" is added which is used in by MVE predicated > > patterns. A new register class "VPR_REG" > > is added and its contents are defined in REG_CLASS_CONTENTS. > > > > The vec-common.md file is modified to support the standard move > > patterns. The prefix of neon functions which are also used by MVE is > > changed from "neon_" to "simd_". > > eg: neon_immediate_valid_for_move changed to > > simd_immediate_valid_for_move. > > > > In the patch standard patterns mve_move, mve_store and move_load for > > MVE are added and neon.md and vfp.md files are modified to support > > this common patterns. > > > > Please refer to Arm reference manual [1] for more details. > > > > [1] https://developer.arm.com/docs/ddi0553/latest > > > > Regression tested on target arm-none-eabi and armeb-none-eabi and > > found no regressions. > > > > Ok for trunk? > > > This is ok but please bootstrap it on arm-none-linux-gnueabihf as well. > > Thanks, > > Kyrill > > > > > > Thanks, > > Srinath > > > > gcc/ChangeLog: > > > > 2020-03-06 Andre Vieira > > Mihail Ionescu > > Srinath Parvathaneni > > > > * config.gcc (arm_mve.h): Include mve intrinsics header file. > > * config/arm/aout.h (p0): Add new register name for MVE predicated > > cases. > > * config/arm-builtins.c (ARM_BUILTIN_SIMD_LANE_CHECK): Define > > macro > > common to Neon and MVE. > > (ARM_BUILTIN_NEON_LANE_CHECK): Renamed to > > ARM_BUILTIN_SIMD_LANE_CHECK. > > (arm_init_simd_builtin_types): Disable poly types for MVE. > > (arm_init_neon_builtins): Move a check to arm_init_builtins > > function. > > (arm_init_builtins): Use ARM_BUILTIN_SIMD_LANE_CHECK instead of > > ARM_BUILTIN_NEON_LANE_CHECK. > > (mve_dereference_pointer): Add function. > > (arm_expand_builtin_args): Call to mve_dereference_pointer > > when MVE is > > enabled. > > (arm_expand_neon_builtin): Moved to arm_expand_builtin function. > > (arm_expand_builtin)
RE: [PATCH v2][ARM][GCC][2/1x]: MVE intrinsics with unary operand.
Hi Srinath,
Thanks, I've pushed this to master.
Kyrill
-Original Message-
From: Srinath Parvathaneni
Sent: 10 March 2020 18:21
To: gcc-patches@gcc.gnu.org
Cc: Kyrylo Tkachov
Subject: [PATCH v2][ARM][GCC][2/1x]: MVE intrinsics with unary operand.
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534326.html
Hello,
This patch supports following MVE ACLE intrinsics with unary operand.
vmvnq_n_s16, vmvnq_n_s32, vrev64q_s8, vrev64q_s16, vrev64q_s32, vcvtq_s16_f16,
vcvtq_s32_f32, vrev64q_u8, vrev64q_u16, vrev64q_u32, vmvnq_n_u16, vmvnq_n_u32,
vcvtq_u16_f16, vcvtq_u32_f32, vrev64q.
Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more
details.
[1]
https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/mve-intrinsics
Regression tested on target arm-none-eabi and armeb-none-eabi and found no
regressions.
Ok for trunk?
Thanks,
Srinath.
gcc/ChangeLog:
2020-03-06 Andre Vieira
Mihail Ionescu
Srinath Parvathaneni
* config/arm/arm-builtins.c (UNOP_SNONE_SNONE_QUALIFIERS): Define.
(UNOP_SNONE_NONE_QUALIFIERS): Likewise.
(UNOP_SNONE_IMM_QUALIFIERS): Likewise.
(UNOP_UNONE_NONE_QUALIFIERS): Likewise.
(UNOP_UNONE_UNONE_QUALIFIERS): Likewise.
(UNOP_UNONE_IMM_QUALIFIERS): Likewise.
* config/arm/arm_mve.h (vmvnq_n_s16): Define macro.
(vmvnq_n_s32): Likewise.
(vrev64q_s8): Likewise.
(vrev64q_s16): Likewise.
(vrev64q_s32): Likewise.
(vcvtq_s16_f16): Likewise.
(vcvtq_s32_f32): Likewise.
(vrev64q_u8): Likewise.
(vrev64q_u16): Likewise.
(vrev64q_u32): Likewise.
(vmvnq_n_u16): Likewise.
(vmvnq_n_u32): Likewise.
(vcvtq_u16_f16): Likewise.
(vcvtq_u32_f32): Likewise.
(__arm_vmvnq_n_s16): Define intrinsic.
(__arm_vmvnq_n_s32): Likewise.
(__arm_vrev64q_s8): Likewise.
(__arm_vrev64q_s16): Likewise.
(__arm_vrev64q_s32): Likewise.
(__arm_vrev64q_u8): Likewise.
(__arm_vrev64q_u16): Likewise.
(__arm_vrev64q_u32): Likewise.
(__arm_vmvnq_n_u16): Likewise.
(__arm_vmvnq_n_u32): Likewise.
(__arm_vcvtq_s16_f16): Likewise.
(__arm_vcvtq_s32_f32): Likewise.
(__arm_vcvtq_u16_f16): Likewise.
(__arm_vcvtq_u32_f32): Likewise.
(vrev64q): Define polymorphic variant.
* config/arm/arm_mve_builtins.def (UNOP_SNONE_SNONE): Use it.
(UNOP_SNONE_NONE): Likewise.
(UNOP_SNONE_IMM): Likewise.
(UNOP_UNONE_UNONE): Likewise.
(UNOP_UNONE_NONE): Likewise.
(UNOP_UNONE_IMM): Likewise.
* config/arm/mve.md (mve_vrev64q_): Define RTL pattern.
(mve_vcvtq_from_f_): Likewise.
(mve_vmvnq_n_): Likewise.
gcc/testsuite/ChangeLog:
2020-03-06 Andre Vieira
Mihail Ionescu
Srinath Parvathaneni
* gcc.target/arm/mve/intrinsics/vcvtq_s16_f16.c: New test.
* gcc.target/arm/mve/intrinsics/vcvtq_s32_f32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcvtq_u16_f16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vcvtq_u32_f32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vmvnq_n_s16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vmvnq_n_s32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vmvnq_n_u16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vmvnq_n_u32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vrev64q_s16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vrev64q_s32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vrev64q_s8.c: Likewise.
* gcc.target/arm/mve/intrinsics/vrev64q_u16.c: Likewise.
* gcc.target/arm/mve/intrinsics/vrev64q_u32.c: Likewise.
* gcc.target/arm/mve/intrinsics/vrev64q_u8.c: Likewise.
### Attachment also inlined for ease of reply###
diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index
7bf5ef5479722a6cb08cc030e1aa7d6d7fad4599..97354c245ff42e7db2934e1045b8707033511e11
100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -337,6 +337,42 @@ arm_unop_none_unone_qualifiers[SIMD_MAX_BUILTIN_ARGS]
#define UNOP_NONE_UNONE_QUALIFIERS \
(arm_unop_none_unone_qualifiers)
+static enum arm_type_qualifiers
+arm_unop_snone_snone_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+ = { qualifier_none, qualifier_none }; #define
+UNOP_SNONE_SNONE_QUALIFIERS \
+ (arm_unop_snone_snone_qualifiers)
+
+static enum arm_type_qualifiers
+arm_unop_snone_none_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+ = { qualifier_none, qualifier_none }; #define
+UNOP_SNONE_NONE_QUALIFIERS \
+ (arm_unop_snone_none_qualifiers)
+
+static enum arm_type_qualifiers
+arm_unop_snone_imm_qualifiers[SIMD_MAX_BUILTIN_ARGS]
+ = { qualifier_none, qualifier_immediate }; #define
+UNOP_SNONE_IMM_Q
Patch ping^2
Hi! I'd like to ping this patch again: On Tue, Mar 10, 2020 at 01:28:19PM +0100, Jakub Jelinek wrote: > I'd like to ping the > https://gcc.gnu.org/legacy-ml/gcc-patches/2020-03/msg00154.html > P1 PR94015 > patch, with the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94015#c5 > testcase instead of the one sent in the patch, so that it FAILs without the > fix on more targets and more reliably. Jakub
Re: Patch ping^2
On Tue, 17 Mar 2020, Jakub Jelinek wrote: > Hi! > > I'd like to ping this patch again: OK. Thanks, Richard. > On Tue, Mar 10, 2020 at 01:28:19PM +0100, Jakub Jelinek wrote: > > I'd like to ping the > > https://gcc.gnu.org/legacy-ml/gcc-patches/2020-03/msg00154.html > > P1 PR94015 > > patch, with the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94015#c5 > > testcase instead of the one sent in the patch, so that it FAILs without the > > fix on more targets and more reliably.
Re: [PATCH 2/2] [aarch64] Rework fpcr fpsr getter/setter builtins
Hi Andrea, I think the first part is fine when approved, but the 2nd part is problematic like Szabolcs already pointed out. We can't just change the ABI or semantics, and these builtins are critical for GLIBC performance. We would first need to change GLIBC back to using inline assembler so it will still write zeroes in the top 32 bits (since that is the current ABI). Cheers, Wilco
Re: [PATCH] Fix up duplicated duplicated words mostly in comments
On Tue, Mar 17, 2020 at 10:37 AM Jakub Jelinek via Gcc-patches wrote: > > Hi! > > In the r10-7197-gbae7b38cf8a21e068ad5c0bab089dedb78af3346 commit I've > noticed duplicated word in a message, which lead me to grep for those and > we have a tons of them. > I've used > grep -v 'long long\|optab optab\|template template\|double double' *.[chS] > */*.[chS] *.def config/*/* 2>/dev/null | grep ' \([a-zA-Z]\+\) \1 ' > Note, the command will not detect the doubled words at the start or end of > line or when one of the words is at the end of line and the next one at the > start of another one. > Some of it is fairly obvious, e.g. all the "the the" cases which is > something I've posted and committed patch for already e.g. in 2016, > other cases are often valid, e.g. "that that" seems to look mostly ok to me. > Some cases are quite hard to figure out, I've left out some of them from the > patch (e.g. "and and" in some cases isn't talking about bitwise/logical and > and so looks incorrect, but in other cases it is talking about those > operations). > In most cases the right solution seems to be to remove one of the duplicated > words, but not always. > > I think most important are the ones with user visible messages (in the patch > 3 of the first 4 hunks), the rest is just comments (and internal > documentation; for that see the doc/tm.texi changes). > > Shall I split the patch somehow for easier review, or is it ok as is? > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. > 2020-03-17 Jakub Jelinek > > * lra-spills.c (remove_pseudos): Fix up duplicated word issue in > a dump message. > * tree-sra.c (create_access_replacement): Fix up duplicated word issue > in a comment. > * read-rtl-function.c (find_param_by_name, > function_reader::parse_enum_value, function_reader::get_insn_by_uid): > Likewise. > * spellcheck.c (get_edit_distance_cutoff): Likewise. > * tree-data-ref.c (create_ifn_alias_checks): Likewise. > * tree.def (SWITCH_EXPR): Likewise. > * selftest.c (assert_str_contains): Likewise. > * ipa-param-manipulation.h (class ipa_param_body_adjustments): > Likewise. > * tree-ssa-math-opts.c (convert_expand_mult_copysign): Likewise. > * tree-ssa-loop-split.c (find_vdef_in_loop): Likewise. > * langhooks.h (struct lang_hooks_for_decls): Likewise. > * ipa-prop.h (struct ipa_param_descriptor): Likewise. > * tree-ssa-strlen.c (handle_builtin_string_cmp, handle_store): > Likewise. > * tree-ssa-dom.c (simplify_stmt_for_jump_threading): Likewise. > * tree-ssa-reassoc.c (reassociate_bb): Likewise. > * tree.c (component_ref_size): Likewise. > * hsa-common.c (hsa_init_compilation_unit_data): Likewise. > * gimple-ssa-sprintf.c (get_string_length, format_string, > format_directive): Likewise. > * omp-grid.c (grid_process_kernel_body_copy): Likewise. > * input.c (string_concat_db::get_string_concatenation, > test_lexer_string_locations_ucn4): Likewise. > * cfgexpand.c (pass_expand::execute): Likewise. > * gimple-ssa-warn-restrict.c (builtin_memref::offset_out_of_bounds, > maybe_diag_overlap): Likewise. > * rtl.c (RTX_CODE_HWINT_P_1): Likewise. > * shrink-wrap.c (spread_components): Likewise. > * tree-ssa-dse.c (initialize_ao_ref_for_dse, valid_ao_ref_for_dse): > Likewise. > * tree-call-cdce.c (shrink_wrap_one_built_in_call_with_conds): > Likewise. > * dwarf2out.c (dwarf2out_early_finish): Likewise. > * gimple-ssa-store-merging.c: Likewise. > * ira-costs.c (record_operand_costs): Likewise. > * tree-vect-loop.c (vectorizable_reduction): Likewise. > * target.def (dispatch): Likewise. > (validate_dims, gen_ccmp_first): Fix up duplicated word issue > in documentation text. > * doc/tm.texi: Regenerated. > * config/i386/x86-tune.def (X86_TUNE_PARTIAL_FLAG_REG_STALL): Fix up > duplicated word issue in a comment. > * config/i386/i386.c (ix86_test_loading_unspec): Likewise. > * config/i386/i386-features.c (remove_partial_avx_dependency): > Likewise. > * config/msp430/msp430.c (msp430_select_section): Likewise. > * config/gcn/gcn-run.c (load_image): Likewise. > * config/aarch64/aarch64-sve.md (sve_ld1r): Likewise. > * config/aarch64/aarch64.c (aarch64_gen_adjusted_ldpstp): Likewise. > * config/aarch64/falkor-tag-collision-avoidance.c > (single_dest_per_chain): Likewise. > * config/nvptx/nvptx.c (nvptx_record_fndecl): Likewise. > * config/fr30/fr30.c (fr30_arg_partial_bytes): Likewise. > * config/rs6000/rs6000-string.c (expand_cmp_vec_sequence): Likewise. > * config/rs6000/rs6000-p8swap.c (replace_swapped_load_constant): > Likewise.
Re: [PATCH] c++: Fix access checking for __is_assignable and __is_constructible (c++/94197)
Shouldn't the test use { dg-do compile { target c++11 } } instead of:
+// { dg-do compile }
+// { dg-options "-std=c++11" }
?
Re: [PATCH] c++: Fix access checking for __is_assignable and __is_constructible (c++/94197)
On 17/03/20 13:02 +, Jonathan Wakely wrote:
Shouldn't the test use { dg-do compile { target c++11 } } instead of:
+// { dg-do compile }
+// { dg-options "-std=c++11" }
?
With that change I see:
UNSUPPORTED: g++.dg/ext/pr94197.C -std=c++98
PASS: g++.dg/ext/pr94197.C -std=c++14 (test for excess errors)
PASS: g++.dg/ext/pr94197.C -std=c++17 (test for excess errors)
PASS: g++.dg/ext/pr94197.C -std=c++2a (test for excess errors)
rather than:
PASS: g++.dg/ext/pr94197.C (test for excess errors)
Re: c: ignore initializers for elements of variable-size types [PR93577]
On Mon, 16 Mar 2020 at 19:59, Richard Sandiford
wrote:
>
> Christophe Lyon via Gcc-patches writes:
> > On Wed, 11 Mar 2020 at 00:37, Joseph Myers wrote:
> >>
> >> On Tue, 10 Mar 2020, Christophe Lyon wrote:
> >>
> >> > sizeless-1.c and sizeless-2.c have the same code, but the latter is
> >> > compiled with -msve-vector-bits=256 and expects different
> >> > warnings/errors.
> >> > For line 33:
> >> > svint8_t *invalid_sve_sc_ptr = &(svint8_t) { *global_sve_sc_ptr };
> >> > we now have:
> >> > sizeless-1.c:33:44: error: empty scalar initializer
> >> > sizeless-1.c:33:44: note: (near initialization for '(anonymous)')
> >> > and
> >> > sizeless-2.c:33:44: error: initializer element is not constant
> >> > sizeless-2.c:33:44: note: (near initialization for 'invalid_sve_sc_ptr')
> >> > sizeless-2.c:33:44: error: SVE type 'svint8_t' does not have a fixed size
> >> > so I think the error comes from the compound literal being treated
> >> > differently with -msve-vector-bits=256
> >>
> >> I think the sizeless-2.c diagnostics are correct while there's a problem
> >> in the sizeless-1.c case (the initializer is not empty, so it should not
> >> be diagnosed as such).
> >>
> >> Does the process_init_element code
> >>
> >> /* Ignore elements of an initializer for a variable-size type.
> >> Those are diagnosed in digest_init. */
> >> if (COMPLETE_TYPE_P (constructor_type)
> >> && TREE_CODE (TYPE_SIZE (constructor_type)) != INTEGER_CST)
> >> return;
> >>
> >> fire for the sizeless-1.c case? If so, maybe it needs to be restricted in
> >> some way to apply only to variable size structs / unions / arrays rather
> >> than whatever kind of variable-size type the SVE types are.
> >
> > It does. Type_size has POLY_INT_CST type.
> >
> > The attached small patch fixes the problem (tested on arm and aarch64).
> > OK?
>
> Thanks for doing this. I'd wondered whether it should be based on
> this or on VECTOR_TYPE_P, but FWIW, I agree basing it on this is best.
>
> > diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
> > index d8025de..1302486 100644
> > --- a/gcc/c/c-typeck.c
> > +++ b/gcc/c/c-typeck.c
> > @@ -9968,7 +9968,8 @@ process_init_element (location_t loc, struct
> > c_expr value, bool implicit,
> >/* Ignore elements of an initializer for a variable-size type.
> > Those are diagnosed in digest_init. */
> >if (COMPLETE_TYPE_P (constructor_type)
> > - && TREE_CODE (TYPE_SIZE (constructor_type)) != INTEGER_CST)
> > + && TREE_CODE (TYPE_SIZE (constructor_type)) != INTEGER_CST
> > + && TREE_CODE (TYPE_SIZE (constructor_type)) != POLY_INT_CST)
>
> Not worth respinning over, but since it hasn't been applied yet:
> a shorter alternative is to replace the != INTEGER_CST test with
> !poly_int_tree_p.
>
> > diff --git
> > a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> > b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> > index ec892a3..e53b871 100644
> > --- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> > +++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-1.c
> > @@ -83,7 +83,6 @@ statements (int n)
> >svint8_t array[2]; /* { dg-error {array elements cannot have SVE
> > type 'svint8_t'} } */
> >svint8_t zero_length_array[0]; /* { dg-error {array elements cannot
> > have SVE type 'svint8_t'} } */
> >svint8_t empty_init_array[] = {}; /* { dg-error {array elements
> > cannot have SVE type 'svint8_t'} } */
> > - /* { dg-error {empty scalar
> > initializer} "" { target *-*-* } .-1 } */
> >typedef svint8_t vla_type[n]; /* { dg-error {array elements cannot
> > have SVE type 'svint8_t'} } */
> >
> >/* Assignment. */
> > diff --git
> > a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> > b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> > index 7174393..9986d27 100644
> > --- a/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> > +++ b/gcc/testsuite/gcc.target/aarch64/sve/acle/general-c/sizeless-2.c
> > @@ -83,7 +83,6 @@ statements (int n)
> >svint8_t array[2]; /* { dg-error {array elements cannot have SVE
> > type 'svint8_t'} } */
> >svint8_t zero_length_array[0]; /* { dg-error {array elements cannot
> > have SVE type 'svint8_t'} } */
> >svint8_t empty_init_array[] = {}; /* { dg-error {array elements
> > cannot have SVE type 'svint8_t'} } */
> > - /* { dg-error {empty scalar
> > initializer} "" { target *-*-* } .-1 } */
> >typedef svint8_t vla_type[n]; /* { dg-error {array elements cannot
> > have SVE type 'svint8_t'} } */
> >
> >/* Assignment. */
>
> Jeff pointed out off-list that using:
>
>N: ... /* { dg-error {...} } */
> N+1: /* { dg-error {...} "" { target *-*-* } .-1 } */
>
> led to two identical test names for line N. This was causing the
> results to fluctuate when using contrib/compare_tests (which I admit
> I don't do, so hadn't no
RE: [PATCH v2][ARM][GCC][3/1x]: MVE intrinsics with unary operand.
Hi Srinath, Thanks, I've pushed this patch to master. Kyrill -Original Message- From: Srinath Parvathaneni Sent: 10 March 2020 18:21 To: gcc-patches@gcc.gnu.org Cc: Kyrylo Tkachov Subject: [PATCH v2][ARM][GCC][3/1x]: MVE intrinsics with unary operand. Hello Kyrill, Following patch is the rebased version of v1. (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534321.html Hello, This patch supports following MVE ACLE intrinsics with unary operand. vdupq_n_s8, vdupq_n_s16, vdupq_n_s32, vabsq_s8, vabsq_s16, vabsq_s32, vclsq_s8, vclsq_s16, vclsq_s32, vclzq_s8, vclzq_s16, vclzq_s32, vnegq_s8, vnegq_s16, vnegq_s32, vaddlvq_s32, vaddvq_s8, vaddvq_s16, vaddvq_s32, vmovlbq_s8, vmovlbq_s16, vmovltq_s8, vmovltq_s16, vmvnq_s8, vmvnq_s16, vmvnq_s32, vrev16q_s8, vrev32q_s8, vrev32q_s16, vqabsq_s8, vqabsq_s16, vqabsq_s32, vqnegq_s8, vqnegq_s16, vqnegq_s32, vcvtaq_s16_f16, vcvtaq_s32_f32, vcvtnq_s16_f16, vcvtnq_s32_f32, vcvtpq_s16_f16, vcvtpq_s32_f32, vcvtmq_s16_f16, vcvtmq_s32_f32, vmvnq_u8, vmvnq_u16, vmvnq_u32, vdupq_n_u8, vdupq_n_u16, vdupq_n_u32, vclzq_u8, vclzq_u16, vclzq_u32, vaddvq_u8, vaddvq_u16, vaddvq_u32, vrev32q_u8, vrev32q_u16, vmovltq_u8, vmovltq_u16, vmovlbq_u8, vmovlbq_u16, vrev16q_u8, vaddlvq_u32, vcvtpq_u16_f16, vcvtpq_u32_f32, vcvtnq_u16_f16, vcvtmq_u16_f16, vcvtmq_u32_f32, vcvtaq_u16_f16, vcvtaq_u32_f32, vdupq_n, vabsq, vclsq, vclzq, vnegq, vaddlvq, vaddvq, vmovlbq, vmovltq, vmvnq, vrev16q, vrev32q, vqabsq, vqneg q. A new register class "EVEN_REGS" which allows only even registers is added in this patch. The new constraint "e" allows only reigsters of EVEN_REGS class. Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more details. [1] https://developer.arm.com/architectures/instruction-sets/simd-isas/helium/mve-intrinsics Regression tested on target arm-none-eabi and armeb-none-eabi and found no regressions. Ok for trunk? Thanks, Srinath. gcc/ChangeLog: 2020-03-06 Andre Vieira Mihail Ionescu Srinath Parvathaneni * config/arm/arm.h (enum reg_class): Define new class EVEN_REGS. * config/arm/arm_mve.h (vdupq_n_s8): Define macro. (vdupq_n_s16): Likewise. (vdupq_n_s32): Likewise. (vabsq_s8): Likewise. (vabsq_s16): Likewise. (vabsq_s32): Likewise. (vclsq_s8): Likewise. (vclsq_s16): Likewise. (vclsq_s32): Likewise. (vclzq_s8): Likewise. (vclzq_s16): Likewise. (vclzq_s32): Likewise. (vnegq_s8): Likewise. (vnegq_s16): Likewise. (vnegq_s32): Likewise. (vaddlvq_s32): Likewise. (vaddvq_s8): Likewise. (vaddvq_s16): Likewise. (vaddvq_s32): Likewise. (vmovlbq_s8): Likewise. (vmovlbq_s16): Likewise. (vmovltq_s8): Likewise. (vmovltq_s16): Likewise. (vmvnq_s8): Likewise. (vmvnq_s16): Likewise. (vmvnq_s32): Likewise. (vrev16q_s8): Likewise. (vrev32q_s8): Likewise. (vrev32q_s16): Likewise. (vqabsq_s8): Likewise. (vqabsq_s16): Likewise. (vqabsq_s32): Likewise. (vqnegq_s8): Likewise. (vqnegq_s16): Likewise. (vqnegq_s32): Likewise. (vcvtaq_s16_f16): Likewise. (vcvtaq_s32_f32): Likewise. (vcvtnq_s16_f16): Likewise. (vcvtnq_s32_f32): Likewise. (vcvtpq_s16_f16): Likewise. (vcvtpq_s32_f32): Likewise. (vcvtmq_s16_f16): Likewise. (vcvtmq_s32_f32): Likewise. (vmvnq_u8): Likewise. (vmvnq_u16): Likewise. (vmvnq_u32): Likewise. (vdupq_n_u8): Likewise. (vdupq_n_u16): Likewise. (vdupq_n_u32): Likewise. (vclzq_u8): Likewise. (vclzq_u16): Likewise. (vclzq_u32): Likewise. (vaddvq_u8): Likewise. (vaddvq_u16): Likewise. (vaddvq_u32): Likewise. (vrev32q_u8): Likewise. (vrev32q_u16): Likewise. (vmovltq_u8): Likewise. (vmovltq_u16): Likewise. (vmovlbq_u8): Likewise. (vmovlbq_u16): Likewise. (vrev16q_u8): Likewise. (vaddlvq_u32): Likewise. (vcvtpq_u16_f16): Likewise. (vcvtpq_u32_f32): Likewise. (vcvtnq_u16_f16): Likewise. (vcvtmq_u16_f16): Likewise. (vcvtmq_u32_f32): Likewise. (vcvtaq_u16_f16): Likewise. (vcvtaq_u32_f32): Likewise. (__arm_vdupq_n_s8): Define intrinsic. (__arm_vdupq_n_s16): Likewise. (__arm_vdupq_n_s32): Likewise. (__arm_vabsq_s8): Likewise. (__arm_vabsq_s16): Likewise. (__arm_vabsq_s32): Likewise. (__arm_vclsq_s8): Likewise. (__arm_vclsq_s16): Likewise. (__arm_vclsq_s32): Likewise. (__arm_vclzq_s8): Likewise. (__arm_vclzq_s16): Likewise. (__arm_vclzq_s32): Likewise. (__arm_vnegq_s8): Likewise. (__arm_vnegq_s16): Likewise. (__arm_vne
[stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.
Hi. I'm sending enhanced patch that makes the following changes: - a new option -frecord-gcc-switches-format is added; the option selects format (processed, driver) for all options that record GCC command line - Dwarf gen_produce_string is now used in -fverbose-asm - The .s file is affected in the following way: BEFORE: # GNU C17 (SUSE Linux) version 9.2.1 20200128 [revision 83f65674e78d97d27537361de1a9d74067ff228d] (x86_64-suse-linux) # compiled by GNU C version 9.2.1 20200128 [revision 83f65674e78d97d27537361de1a9d74067ff228d], GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP # GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 # options passed: -fpreprocessed test.i -march=znver1 -mmmx -mno-3dnow # -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -msha # -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx # -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 # -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw # -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd # -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves # -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi # -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mmwaitx -mclzero -mno-pku # -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni # -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b # -mno-waitpkg -mno-cldemote -mno-ptwrite --param l1-cache-size=32 # --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=znver1 # -grecord-gcc-switches -g -fverbose-asm -frecord-gcc-switches # options enabled: -faggressive-loop-optimizations -fassume-phsa # -fasynchronous-unwind-tables -fauto-inc-dec -fcommon # -fdelete-null-pointer-checks -fdwarf2-cfi-asm -fearly-inlining # -feliminate-unused-debug-types -ffp-int-builtin-inexact -ffunction-cse # -fgcse-lm -fgnu-runtime -fgnu-unique -fident -finline-atomics # -fipa-stack-alignment -fira-hoist-pressure -fira-share-save-slots # -fira-share-spill-slots -fivopts -fkeep-static-consts # -fleading-underscore -flifetime-dse -flto-odr-type-merging -fmath-errno # -fmerge-debug-strings -fpeephole -fplt -fprefetch-loop-arrays # -frecord-gcc-switches -freg-struct-return -fsched-critical-path-heuristic # -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock # -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec # -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fschedule-fusion # -fsemantic-interposition -fshow-column -fshrink-wrap-separate # -fsigned-zeros -fsplit-ivs-in-unroller -fssa-backprop -fstdarg-opt # -fstrict-volatile-bitfields -fsync-libcalls -ftrapping-math -ftree-cselim # -ftree-forwprop -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon # -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop # -ftree-reassoc -ftree-scev-cprop -funit-at-a-time -funwind-tables # -fverbose-asm -fzero-initialized-in-bss -m128bit-long-double -m64 -m80387 # -mabm -madx -maes -malign-stringops -mavx -mavx2 # -mavx256-split-unaligned-store -mbmi -mbmi2 -mclflushopt -mclzero -mcx16 # -mf16c -mfancy-math-387 -mfma -mfp-ret-in-387 -mfsgsbase -mfxsr -mglibc # -mieee-fp -mlong-double-80 -mlzcnt -mmmx -mmovbe -mmwaitx -mpclmul # -mpopcnt -mprfchw -mpush-args -mrdrnd -mrdseed -mred-zone -msahf -msha # -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2 -msse4a -mssse3 -mstv # -mtls-direct-seg-refs -mvzeroupper -mxsave -mxsavec -mxsaveopt -mxsaves AFTER: # GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 # GNU C17 10.0.1 20200317 (experimental) -march=znver1 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -msha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mmwaitx -mclzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b -mno-waitpkg -mno-cldemote -mno-ptwrite -mno-avx512bf16 -mno-enqcmd -mno-avx512vp2intersect --param=l1-cache-size=32 --param=l1-cache-line-size=64 --param=l2-cache-size=512 -mtune=znver1 -g That's the biggest change I made, but I hope it's acceptable. Apart from that the patch simplifies and unifies places where save_decoded_options options are transformed back to string representation. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed in next stage1? Thank
RE: [PATCH v2][ARM][GCC][4/1x]: MVE intrinsics with unary operand.
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 10 March 2020 18:21
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][4/1x]: MVE intrinsics with unary operand.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
> (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-
> November/534342.html
>
>
>
>
> Hello,
>
> This patch supports following MVE ACLE intrinsics with unary operand.
>
> vctp16q, vctp32q, vctp64q, vctp8q, vpnot.
>
> Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more
> details.
> [1] https://developer.arm.com/architectures/instruction-sets/simd-
> isas/helium/mve-intrinsics
>
> There are few conflicts in defining the machine registers, resolved by re-
> ordering VPR_REGNUM, APSRQ_REGNUM and APSRGE_REGNUM.
>
> Regression tested on target arm-none-eabi and armeb-none-eabi and found
> no regressions.
>
>
> Ok for trunk?
Thanks, I've pushed this to master.
Kyrill
>
> Thanks,
> Srinath.
>
> gcc/ChangeLog:
>
> 2020-03-06 Andre Vieira
> Mihail Ionescu
> Srinath Parvathaneni
>
> * config/arm/arm-builtins.c (hi_UP): Define mode.
> * config/arm/arm.h (IS_VPR_REGNUM): Move.
> * config/arm/arm.md (VPR_REGNUM): Define before
> APSRQ_REGNUM.
> (APSRQ_REGNUM): Modify.
> (APSRGE_REGNUM): Modify.
> * config/arm/arm_mve.h (vctp16q): Define macro.
> (vctp32q): Likewise.
> (vctp64q): Likewise.
> (vctp8q): Likewise.
> (vpnot): Likewise.
> (__arm_vctp16q): Define intrinsic.
> (__arm_vctp32q): Likewise.
> (__arm_vctp64q): Likewise.
> (__arm_vctp8q): Likewise.
> (__arm_vpnot): Likewise.
> * config/arm/arm_mve_builtins.def (UNOP_UNONE_UNONE): Use
> builtin
> qualifier.
> * config/arm/mve.md (mve_vctpqhi): Define RTL pattern.
> (mve_vpnothi): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> 2020-03-06 Andre Vieira
> Mihail Ionescu
> Srinath Parvathaneni
>
> * gcc.target/arm/mve/intrinsics/vctp16q.c: New test.
> * gcc.target/arm/mve/intrinsics/vctp32q.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vctp64q.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vctp8q.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vpnot.c: Likewise.
>
>
> ### Attachment also inlined for ease of reply
> ###
>
>
> diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
> index
> 0d5da5ea3133ca39b55b4ca76507e01956997c03..fd449458bcb1f9a899a16e4
> 32aa015d48b665868 100644
> --- a/gcc/config/arm/arm-builtins.c
> +++ b/gcc/config/arm/arm-builtins.c
> @@ -415,6 +415,7 @@ arm_set_sat_qualifiers[SIMD_MAX_BUILTIN_ARGS]
> #define hf_UP E_HFmode
> #define bf_UPE_BFmode
> #define si_UP E_SImode
> +#define hi_UPE_HImode
> #define void_UP E_VOIDmode
> #define sf_UP E_SFmode
> #define UP(X) X##_UP
> diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h index
> 912849f0acd36e9c8c3a00f4253a691b7085e72d..7f94e11c0ea23dfbdb7e64faf
> bdfc68d83411865 100644
> --- a/gcc/config/arm/arm_mve.h
> +++ b/gcc/config/arm/arm_mve.h
> @@ -192,6 +192,11 @@ typedef struct { uint8x16_t val[4]; } uint8x16x4_t;
> #define vcvtmq_u32_f32(__a) __arm_vcvtmq_u32_f32(__a) #define
> vcvtaq_u16_f16(__a) __arm_vcvtaq_u16_f16(__a) #define
> vcvtaq_u32_f32(__a) __arm_vcvtaq_u32_f32(__a)
> +#define vctp16q(__a) __arm_vctp16q(__a) #define vctp32q(__a)
> +__arm_vctp32q(__a) #define vctp64q(__a) __arm_vctp64q(__a) #define
> +vctp8q(__a) __arm_vctp8q(__a) #define vpnot(__a) __arm_vpnot(__a)
> #endif
>
> __extension__ extern __inline void
> @@ -703,6 +708,41 @@ __arm_vaddlvq_u32 (uint32x4_t __a)
>return __builtin_mve_vaddlvq_uv4si (__a); }
>
> +__extension__ extern __inline int64_t
> +__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
> +__arm_vctp16q (uint32_t __a) {
> + return __builtin_mve_vctp16qhi (__a); }
> +
> +__extension__ extern __inline mve_pred16_t __attribute__
> +((__always_inline__, __gnu_inline__, __artificial__)) __arm_vctp32q
> +(uint32_t __a) {
> + return __builtin_mve_vctp32qhi (__a); }
> +
> +__extension__ extern __inline mve_pred16_t __attribute__
> +((__always_inline__, __gnu_inline__, __artificial__)) __arm_vctp64q
> +(uint32_t __a) {
> + return __builtin_mve_vctp64qhi (__a); }
> +
> +__extension__ extern __inline mve_pred16_t __attribute__
> +((__always_inline__, __gnu_inline__, __artificial__)) __arm_vctp8q
> +(uint32_t __a) {
> + return __builtin_mve_vctp8qhi (__a);
> +}
> +
> +__extension__ extern __inline mve_pred16_t __attribute__
> +((__always_inline__, __gnu_inline__, __artificial__)) __arm_vpnot
> +(mve_pred16_t __a) {
> + return __builtin_mve_vpnothi (__a);
> +}
> +
> #if (__ARM_FEATURE_MVE & 2) /* MVE Floating point. */
>
> __extension__ extern __inline void
> diff --git a/gcc/config/arm/arm_mve_builtin
[PATCH] middle-end/94188 fix fold of addr expression generation
This adds a missing type conversion to build_fold_addr_expr and adjusts
fallout - build_fold_addr_expr was used as a convenience to build an
ADDR_EXPR but some callers do not expect the result to be simplified
to something else.
Bootstrapped on x86_64-unknown-linux-gnu, testin in progress.
This is the 3rd or 4th attempt and I hope to have catched all fallout
with this. I think it's inevitable we fix the mistake in
build_fold_addr_expr.
Richard.
2020-03-17 Richard Biener
PR middle-end/94188
* fold-const.c (build_fold_addr_expr): Convert address to
correct type.
* asan.c (maybe_create_ssa_name): Strip useless type conversions.
* gimple-fold.c (gimple_fold_stmt_to_constant_1): Use build1
to build the ADDR_EXPR which we don't really want to simplify.
* tree-ssa-dom.c (record_equivalences_from_stmt): Likewise.
* tree-ssa-loop-im.c (gather_mem_refs_stmt): Likewise.
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Likewise.
(simplify_builtin_call): Strip useless type conversions.
* tree-ssa-strlen.c (new_strinfo): Likewise.
* gcc.dg/pr94188.c: New testcase.
---
gcc/asan.c | 5 +++--
gcc/fold-const.c | 7 ++-
gcc/gimple-fold.c | 4 ++--
gcc/testsuite/gcc.dg/pr94188.c | 10 ++
gcc/tree-ssa-dom.c | 9 -
gcc/tree-ssa-forwprop.c| 11 ++-
gcc/tree-ssa-loop-im.c | 3 ++-
gcc/tree-ssa-strlen.c | 3 ++-
8 files changed, 35 insertions(+), 17 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr94188.c
diff --git a/gcc/asan.c b/gcc/asan.c
index 05f8b63139c..00d0e678a0e 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -62,6 +62,7 @@ along with GCC; see the file COPYING3. If not see
#include "builtins.h"
#include "fnmatch.h"
#include "tree-inline.h"
+#include "tree-ssa.h"
/* AddressSanitizer finds out-of-bounds and use-after-free bugs
with <2x slowdown on average.
@@ -2061,10 +2062,10 @@ static tree
maybe_create_ssa_name (location_t loc, tree base, gimple_stmt_iterator *iter,
bool before_p)
{
+ STRIP_USELESS_TYPE_CONVERSION (base);
if (TREE_CODE (base) == SSA_NAME)
return base;
- gimple *g = gimple_build_assign (make_ssa_name (TREE_TYPE (base)),
- TREE_CODE (base), base);
+ gimple *g = gimple_build_assign (make_ssa_name (TREE_TYPE (base)), base);
gimple_set_location (g, loc);
if (before_p)
gsi_insert_before (iter, g, GSI_SAME_STMT);
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 71a1d3eb735..3ab1a9adcdf 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -8523,7 +8523,12 @@ build_fold_addr_expr_with_type_loc (location_t loc, tree
t, tree ptrtype)
}
else if (TREE_CODE (t) == MEM_REF
&& integer_zerop (TREE_OPERAND (t, 1)))
-return TREE_OPERAND (t, 0);
+{
+ t = TREE_OPERAND (t, 0);
+
+ if (TREE_TYPE (t) != ptrtype)
+ t = fold_convert_loc (loc, ptrtype, t);
+}
else if (TREE_CODE (t) == MEM_REF
&& TREE_CODE (TREE_OPERAND (t, 0)) == INTEGER_CST)
return fold_binary (POINTER_PLUS_EXPR, ptrtype,
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 9e45cc55df4..3f17de974ed 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -6413,8 +6413,8 @@ gimple_fold_stmt_to_constant_1 (gimple *stmt, tree
(*valueize) (tree),
&& TREE_CODE (op1) == INTEGER_CST)
{
tree off = fold_convert (ptr_type_node, op1);
- return build_fold_addr_expr_loc
- (loc,
+ return build1_loc
+ (loc, ADDR_EXPR, TREE_TYPE (op0),
fold_build2 (MEM_REF,
TREE_TYPE (TREE_TYPE (op0)),
unshare_expr (op0), off));
diff --git a/gcc/testsuite/gcc.dg/pr94188.c b/gcc/testsuite/gcc.dg/pr94188.c
new file mode 100644
index 000..7a73c1bc071
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr94188.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+
+struct dm_tree_link {
+int list;
+int node;
+};
+void fn1(void *p)
+{
+ 0 ? ((struct dm_tree_link *)((char *)p - (char *)&((struct dm_tree_link
*)0)->list))->node : 0;
+}
diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index eea494c8a96..7742d75d2f5 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -1725,11 +1725,10 @@ record_equivalences_from_stmt (gimple *stmt, int
may_optimize_p,
tree op0 = gimple_assign_rhs1 (stmt);
tree op1 = gimple_assign_rhs2 (stmt);
tree new_rhs
- = build_fold_addr_expr (fold_build2 (MEM_REF,
-TREE_TYPE (TREE_TYPE (op0)),
-unshare_expr (op0),
-fold_convert (ptr_type_node,
-
Re: [PATCH] c++: Fix access checking for __is_assignable and __is_constructible (c++/94197)
On 3/17/20 9:04 AM, Jonathan Wakely wrote:
On 17/03/20 13:02 +, Jonathan Wakely wrote:
Shouldn't the test use { dg-do compile { target c++11 } } instead of:
+// { dg-do compile }
+// { dg-options "-std=c++11" }
?
With that change I see:
UNSUPPORTED: g++.dg/ext/pr94197.C -std=c++98
PASS: g++.dg/ext/pr94197.C -std=c++14 (test for excess errors)
PASS: g++.dg/ext/pr94197.C -std=c++17 (test for excess errors)
PASS: g++.dg/ext/pr94197.C -std=c++2a (test for excess errors)
rather than:
PASS: g++.dg/ext/pr94197.C (test for excess errors)
Yes, good point.
Jason
Re: [PATCH 2/2] [aarch64] Rework fpcr fpsr getter/setter builtins
On 17/03/2020 12:34, Wilco Dijkstra wrote: Hi Andrea, I think the first part is fine when approved, but the 2nd part is problematic like Szabolcs already pointed out. We can't just change the ABI or semantics, and these builtins are critical for GLIBC performance. We would first need to change GLIBC back to using inline assembler so it will still write zeroes in the top 32 bits (since that is the current ABI). Cheers, Wilco No, you shouldn't ever arbitrarily write zeros to the upper bits (or even worse, write garbage as we do now). That's the whole point of these patches. R.
Re: [PATCH] c++: Fix access checking for __is_assignable and __is_constructible (c++/94197)
On Tue, 17 Mar 2020 at 16:42, Jason Merrill wrote:
>
> On 3/17/20 9:04 AM, Jonathan Wakely wrote:
> > On 17/03/20 13:02 +, Jonathan Wakely wrote:
> >> Shouldn't the test use { dg-do compile { target c++11 } } instead of:
> >>
> >> +// { dg-do compile }
> >> +// { dg-options "-std=c++11" }
>
> Yes, good point.
Ack, changing to { dg-do compile { target c++11 } } and committing
with the (correct :P) expectation that
the change is still ok with that change.
RE: [PATCH v2][ARM][GCC][1/2x]: MVE intrinsics with binary operands.
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 10 March 2020 18:22
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][1/2x]: MVE intrinsics with binary operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
> (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-
> November/534331.html
>
>
>
>
> Hello,
>
> This patch supports following MVE ACLE intrinsics with binary operand.
>
> vsubq_n_f16, vsubq_n_f32, vbrsrq_n_f16, vbrsrq_n_f32, vcvtq_n_f16_s16,
> vcvtq_n_f32_s32, vcvtq_n_f16_u16, vcvtq_n_f32_u32, vcreateq_f16,
> vcreateq_f32.
>
> Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more
> details.
> [1] https://developer.arm.com/architectures/instruction-sets/simd-
> isas/helium/mve-intrinsics
>
> In this patch new constraint "Rd" is added, which checks the constant is with
> in the range of 1 to 16.
> Also a new predicate "mve_imm_16" is added, to check the the matching
> constraint Rd.
>
> Regression tested on target arm-none-eabi and armeb-none-eabi and found
> no regressions.
>
> Ok for trunk?
Thanks, I've pushed this patch to master.
Kyrill
>
> Thanks,
> Srinath.
>
> gcc/ChangeLog:
>
> 2019-10-21 Andre Vieira
> Mihail Ionescu
> Srinath Parvathaneni
>
> * config/arm/arm-builtins.c
> (BINOP_NONE_NONE_NONE_QUALIFIERS): Define
> qualifier for binary operands.
> (BINOP_NONE_NONE_IMM_QUALIFIERS): Likewise.
> (BINOP_NONE_UNONE_IMM_QUALIFIERS): Likewise.
> (BINOP_NONE_UNONE_UNONE_QUALIFIERS): Likewise.
> * config/arm/arm_mve.h (vsubq_n_f16): Define macro.
> (vsubq_n_f32): Likewise.
> (vbrsrq_n_f16): Likewise.
> (vbrsrq_n_f32): Likewise.
> (vcvtq_n_f16_s16): Likewise.
> (vcvtq_n_f32_s32): Likewise.
> (vcvtq_n_f16_u16): Likewise.
> (vcvtq_n_f32_u32): Likewise.
> (vcreateq_f16): Likewise.
> (vcreateq_f32): Likewise.
> (__arm_vsubq_n_f16): Define intrinsic.
> (__arm_vsubq_n_f32): Likewise.
> (__arm_vbrsrq_n_f16): Likewise.
> (__arm_vbrsrq_n_f32): Likewise.
> (__arm_vcvtq_n_f16_s16): Likewise.
> (__arm_vcvtq_n_f32_s32): Likewise.
> (__arm_vcvtq_n_f16_u16): Likewise.
> (__arm_vcvtq_n_f32_u32): Likewise.
> (__arm_vcreateq_f16): Likewise.
> (__arm_vcreateq_f32): Likewise.
> (vsubq): Define polymorphic variant.
> (vbrsrq): Likewise.
> (vcvtq_n): Likewise.
> * config/arm/arm_mve_builtins.def
> (BINOP_NONE_NONE_NONE_QUALIFIERS): Use
> it.
> (BINOP_NONE_NONE_IMM_QUALIFIERS): Likewise.
> (BINOP_NONE_UNONE_IMM_QUALIFIERS): Likewise.
> (BINOP_NONE_UNONE_UNONE_QUALIFIERS): Likewise.
> * config/arm/constraints.md (Rd): Define constraint to check
> constant is
> in the range of 1 to 16.
> * config/arm/mve.md (mve_vsubq_n_f): Define RTL pattern.
> mve_vbrsrq_n_f: Likewise.
> mve_vcvtq_n_to_f_: Likewise.
> mve_vcreateq_f: Likewise.
> * config/arm/predicates.md (mve_imm_16): Define predicate to
> check
> the matching constraint Rd.
>
> gcc/testsuite/ChangeLog:
>
> 2019-10-21 Andre Vieira
> Mihail Ionescu
> Srinath Parvathaneni
>
> * gcc.target/arm/mve/intrinsics/vbrsrq_n_f16.c: New test.
> * gcc.target/arm/mve/intrinsics/vbrsrq_n_f32.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vcreateq_f16.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vcreateq_f32.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vcvtq_n_f16_s16.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vcvtq_n_f16_u16.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vcvtq_n_f32_s32.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vcvtq_n_f32_u32.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vsubq_n_f16.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vsubq_n_f32.c: Likewise.
>
>
> ### Attachment also inlined for ease of reply
> ###
>
>
> diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
> index
> b61094303443960bb173219e46a4d8e351deeb25..658886831ff55a6fa3350f9
> a654be4887e115bbc 100644
> --- a/gcc/config/arm/arm-builtins.c
> +++ b/gcc/config/arm/arm-builtins.c
> @@ -373,6 +373,30 @@
> arm_unop_unone_imm_qualifiers[SIMD_MAX_BUILTIN_ARGS]
> #define UNOP_UNONE_IMM_QUALIFIERS \
>(arm_unop_unone_imm_qualifiers)
>
> +static enum arm_type_qualifiers
> +arm_binop_none_none_none_qualifiers[SIMD_MAX_BUILTIN_ARGS]
> + = { qualifier_none, qualifier_none, qualifier_none }; #define
> +BINOP_NONE_NONE_NONE_QUALIFIERS \
> + (arm_binop_none_none_none_qualifiers)
> +
> +static enum arm_type_qualifiers
> +arm_binop_none_none_imm_qualifiers[SIMD_MAX_BUILTIN_ARGS]
> + = { qualifier_none, qualifier_none, qualifier_immediate }; #define
> +BINOP_NONE_NONE_IMM_QUALIFIERS \
> + (arm_binop_none_none_imm_qualifiers)
> +
> +static enum arm_t
Re: [PATCH] strlen: Punt on UB reads past end of string literal [PR94187]
On 3/17/20 2:39 AM, Jakub Jelinek wrote:
Hi!
The gcc.dg/pr68785.c test which contains:
int
foo (void)
{
return *(int *) "";
}
has UB in the program if it is ever called, but causes UB in the compiler
as well as at least in theory non-reproduceable code generation.
The problem is that nbytes is in this case 4, prep is the
TREE_STRING_POINTER of a "" string literal with TREE_STRING_LENGTH of 1
At least as important as avoiding the Valgrind error is detecting
the bug in the code. -Warray-bounds has all it needs to diagnose
it, but, regrettably, it doesn't. I raised PR 94195 to make sure
it does.
Martin
and
we do:
4890 for (const char *p = prep; p != prep + nbytes; ++p)
4891if (*p)
4892 {
4893*allnul = false;
4894break;
4895 }
and so read the bytes after the STRING_CST payload, which can be random.
I think we should just punt in this case.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2020-03-16 Jakub Jelinek
PR tree-optimization/94187
* tree-ssa-strlen.c (count_nonzero_bytes): Punt if
nchars - offset < nbytes.
--- gcc/tree-ssa-strlen.c.jj2020-03-14 08:14:47.034742349 +0100
+++ gcc/tree-ssa-strlen.c 2020-03-16 12:23:57.523534887 +0100
@@ -4822,6 +4822,8 @@ count_nonzero_bytes (tree exp, unsigned
of the access), set it here to the size of the string, including
all internal and trailing nuls if the string has any. */
nbytes = nchars - offset;
+ else if (nchars - offset < nbytes)
+ return false;
prep = TREE_STRING_POINTER (exp) + offset;
}
Jakub
RE: [PATCH v2][ARM][GCC][2/2x]: MVE intrinsics with binary operands.
Hi Srinath, > -Original Message- > From: Srinath Parvathaneni > Sent: 10 March 2020 18:22 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH v2][ARM][GCC][2/2x]: MVE intrinsics with binary operands. > > Hello Kyrill, > > Following patch is the rebased version of v1. > (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019- > November/534325.html > > > > > Hello, > > This patch supports following MVE ACLE intrinsics with binary operands. > > vcvtq_n_s16_f16, vcvtq_n_s32_f32, vcvtq_n_u16_f16, vcvtq_n_u32_f32, > vcreateq_u8, vcreateq_u16, vcreateq_u32, vcreateq_u64, vcreateq_s8, > vcreateq_s16, vcreateq_s32, vcreateq_s64, vshrq_n_s8, vshrq_n_s16, > vshrq_n_s32, vshrq_n_u8, vshrq_n_u16, vshrq_n_u32. > > Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more > details. > [1] https://developer.arm.com/architectures/instruction-sets/simd- > isas/helium/mve-intrinsics > > In this patch new constraints "Rb" and "Rf" are added, which checks the > constant is with in the range of 1 to 8 and 1 to 32 respectively. > > Also a new predicates "mve_imm_8" and "mve_imm_32" are added, to > check the the matching constraint Rb and Rf respectively. > > Regression tested on target arm-none-eabi and armeb-none-eabi and found > no regressions. > > Ok for trunk? Thanks, I've pushed this patch to master. Kyrill > > Thanks, > Srinath. > > gcc/ChangeLog: > > 2019-10-21 Andre Vieira > Mihail Ionescu > Srinath Parvathaneni > > * config/arm/arm-builtins.c > (BINOP_UNONE_UNONE_IMM_QUALIFIERS): Define > qualifier for binary operands. > (BINOP_UNONE_UNONE_UNONE_QUALIFIERS): Likewise. > (BINOP_UNONE_NONE_IMM_QUALIFIERS): Likewise. > * config/arm/arm_mve.h (vcvtq_n_s16_f16): Define macro. > (vcvtq_n_s32_f32): Likewise. > (vcvtq_n_u16_f16): Likewise. > (vcvtq_n_u32_f32): Likewise. > (vcreateq_u8): Likewise. > (vcreateq_u16): Likewise. > (vcreateq_u32): Likewise. > (vcreateq_u64): Likewise. > (vcreateq_s8): Likewise. > (vcreateq_s16): Likewise. > (vcreateq_s32): Likewise. > (vcreateq_s64): Likewise. > (vshrq_n_s8): Likewise. > (vshrq_n_s16): Likewise. > (vshrq_n_s32): Likewise. > (vshrq_n_u8): Likewise. > (vshrq_n_u16): Likewise. > (vshrq_n_u32): Likewise. > (__arm_vcreateq_u8): Define intrinsic. > (__arm_vcreateq_u16): Likewise. > (__arm_vcreateq_u32): Likewise. > (__arm_vcreateq_u64): Likewise. > (__arm_vcreateq_s8): Likewise. > (__arm_vcreateq_s16): Likewise. > (__arm_vcreateq_s32): Likewise. > (__arm_vcreateq_s64): Likewise. > (__arm_vshrq_n_s8): Likewise. > (__arm_vshrq_n_s16): Likewise. > (__arm_vshrq_n_s32): Likewise. > (__arm_vshrq_n_u8): Likewise. > (__arm_vshrq_n_u16): Likewise. > (__arm_vshrq_n_u32): Likewise. > (__arm_vcvtq_n_s16_f16): Likewise. > (__arm_vcvtq_n_s32_f32): Likewise. > (__arm_vcvtq_n_u16_f16): Likewise. > (__arm_vcvtq_n_u32_f32): Likewise. > (vshrq_n): Define polymorphic variant. > * config/arm/arm_mve_builtins.def > (BINOP_UNONE_UNONE_IMM_QUALIFIERS): > Use it. > (BINOP_UNONE_UNONE_UNONE_QUALIFIERS): Likewise. > (BINOP_UNONE_NONE_IMM_QUALIFIERS): Likewise. > * config/arm/constraints.md (Rb): Define constraint to check > constant is > in the range of 1 to 8. > (Rf): Define constraint to check constant is in the range of 1 to 32. > * config/arm/mve.md (mve_vcreateq_): Define RTL > pattern. > (mve_vshrq_n_): Likewise. > (mve_vcvtq_n_from_f_): Likewise. > * config/arm/predicates.md (mve_imm_8): Define predicate to check > the matching constraint Rb. > (mve_imm_32): Define predicate to check the matching constraint Rf. > > gcc/testsuite/ChangeLog: > > 2019-10-21 Andre Vieira > Mihail Ionescu > Srinath Parvathaneni > > * gcc.target/arm/mve/intrinsics/vcreateq_s16.c: New test. > * gcc.target/arm/mve/intrinsics/vcreateq_s32.c: Likewise. > * gcc.target/arm/mve/intrinsics/vcreateq_s64.c: Likewise. > * gcc.target/arm/mve/intrinsics/vcreateq_s8.c: Likewise. > * gcc.target/arm/mve/intrinsics/vcreateq_u16.c: Likewise. > * gcc.target/arm/mve/intrinsics/vcreateq_u32.c: Likewise. > * gcc.target/arm/mve/intrinsics/vcreateq_u64.c: Likewise. > * gcc.target/arm/mve/intrinsics/vcreateq_u8.c: Likewise. > * gcc.target/arm/mve/intrinsics/vcvtq_n_s16_f16.c: Likewise. > * gcc.target/arm/mve/intrinsics/vcvtq_n_s32_f32.c: Likewise. > * gcc.target/arm/mve/intrinsics/vcvtq_n_u16_f16.c: Likewise. > * gcc.target/arm/mve/intrinsics/vcvtq_n_u32_f32.c: Likewise. > * gcc.target/arm/mve/intrinsics/vshrq_n_s16.c: Likewise. > * gcc.target/arm/mve/intrinsics/vshrq_n_s32.c: Likewise. > * gcc.target/arm/mve/intrinsic
RE: [PATCH v2][ARM][GCC][3/2x]: MVE intrinsics with binary operands.
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 10 March 2020 18:23
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][3/2x]: MVE intrinsics with binary operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
> (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-
> November/534329.html
>
>
>
>
> Hello,
>
> This patch supports following MVE ACLE intrinsics with binary operands.
>
> vaddlvq_p_s32, vaddlvq_p_u32, vcmpneq_s8, vcmpneq_s16, vcmpneq_s32,
> vcmpneq_u8, vcmpneq_u16, vcmpneq_u32, vshlq_s8, vshlq_s16, vshlq_s32,
> vshlq_u8, vshlq_u16, vshlq_u32.
>
> Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more
> details.
> [1] https://developer.arm.com/architectures/instruction-sets/simd-
> isas/helium/mve-intrinsics
>
> Regression tested on target arm-none-eabi and armeb-none-eabi and found
> no regressions.
>
> Ok for trunk?
Thanks, I pushed the patch to master.
Kyrill
>
> Thanks,
> Srinath.
>
> gcc/ChangeLog:
>
> 2019-10-21 Andre Vieira
> Mihail Ionescu
> Srinath Parvathaneni
>
> * config/arm/arm-builtins.c
> (BINOP_NONE_NONE_UNONE_QUALIFIERS): Define
> qualifier for binary operands.
> (BINOP_UNONE_NONE_NONE_QUALIFIERS): Likewise.
> (BINOP_UNONE_UNONE_NONE_QUALIFIERS): Likewise.
> * config/arm/arm_mve.h (vaddlvq_p_s32): Define macro.
> (vaddlvq_p_u32): Likewise.
> (vcmpneq_s8): Likewise.
> (vcmpneq_s16): Likewise.
> (vcmpneq_s32): Likewise.
> (vcmpneq_u8): Likewise.
> (vcmpneq_u16): Likewise.
> (vcmpneq_u32): Likewise.
> (vshlq_s8): Likewise.
> (vshlq_s16): Likewise.
> (vshlq_s32): Likewise.
> (vshlq_u8): Likewise.
> (vshlq_u16): Likewise.
> (vshlq_u32): Likewise.
> (__arm_vaddlvq_p_s32): Define intrinsic.
> (__arm_vaddlvq_p_u32): Likewise.
> (__arm_vcmpneq_s8): Likewise.
> (__arm_vcmpneq_s16): Likewise.
> (__arm_vcmpneq_s32): Likewise.
> (__arm_vcmpneq_u8): Likewise.
> (__arm_vcmpneq_u16): Likewise.
> (__arm_vcmpneq_u32): Likewise.
> (__arm_vshlq_s8): Likewise.
> (__arm_vshlq_s16): Likewise.
> (__arm_vshlq_s32): Likewise.
> (__arm_vshlq_u8): Likewise.
> (__arm_vshlq_u16): Likewise.
> (__arm_vshlq_u32): Likewise.
> (vaddlvq_p): Define polymorphic variant.
> (vcmpneq): Likewise.
> (vshlq): Likewise.
> * config/arm/arm_mve_builtins.def
> (BINOP_NONE_NONE_UNONE_QUALIFIERS):
> Use it.
> (BINOP_UNONE_NONE_NONE_QUALIFIERS): Likewise.
> (BINOP_UNONE_UNONE_NONE_QUALIFIERS): Likewise.
> * config/arm/mve.md (mve_vaddlvq_p_v4si): Define RTL
> pattern.
> (mve_vcmpneq_): Likewise.
> (mve_vshlq_): Likewise.
>
> gcc/testsuite/ChangeLog:
>
> 2019-10-21 Andre Vieira
> Mihail Ionescu
> Srinath Parvathaneni
>
> * gcc.target/arm/mve/intrinsics/vaddlvq_p_s32.c: New test.
> * gcc.target/arm/mve/intrinsics/vaddlvq_p_u32.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vcmpneq_s16.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vcmpneq_s32.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vcmpneq_s8.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vcmpneq_u16.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vcmpneq_u32.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vcmpneq_u8.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vshlq_s16.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vshlq_s32.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vshlq_s8.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vshlq_u16.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vshlq_u32.c: Likewise.
> * gcc.target/arm/mve/intrinsics/vshlq_u8.c: Likewise.
>
>
> ### Attachment also inlined for ease of reply
> ###
>
>
> diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
> index
> 5db4db498b71224a4b5a0f5b6aa3476b351f7fd3..264006bc8645d8e73149961
> debad8eb82bab8af0 100644
> --- a/gcc/config/arm/arm-builtins.c
> +++ b/gcc/config/arm/arm-builtins.c
> @@ -415,6 +415,24 @@
> arm_binop_unone_none_imm_qualifiers[SIMD_MAX_BUILTIN_ARGS]
> #define BINOP_UNONE_NONE_IMM_QUALIFIERS \
>(arm_binop_unone_none_imm_qualifiers)
>
> +static enum arm_type_qualifiers
> +arm_binop_none_none_unone_qualifiers[SIMD_MAX_BUILTIN_ARGS]
> + = { qualifier_none, qualifier_none, qualifier_unsigned }; #define
> +BINOP_NONE_NONE_UNONE_QUALIFIERS \
> + (arm_binop_none_none_unone_qualifiers)
> +
> +static enum arm_type_qualifiers
> +arm_binop_unone_none_none_qualifiers[SIMD_MAX_BUILTIN_ARGS]
> + = { qualifier_unsigned, qualifier_none, qualifier_none }; #define
> +BINOP_UNONE_NONE_NONE_QUALIFIERS \
> + (arm_binop_unone_none_none_qualifiers)
> +
> +static enum arm_type_qualifiers
> +arm_binop_unone_unone_none_qualifiers[SIMD_MAX
Re: [PATCH] c++: Fix access checking for __is_assignable and __is_constructible (c++/94197)
On Tue, 17 Mar 2020 at 16:52, Ville Voutilainen
wrote:
>
> On Tue, 17 Mar 2020 at 16:42, Jason Merrill wrote:
> >
> > On 3/17/20 9:04 AM, Jonathan Wakely wrote:
> > > On 17/03/20 13:02 +, Jonathan Wakely wrote:
> > >> Shouldn't the test use { dg-do compile { target c++11 } } instead of:
> > >>
> > >> +// { dg-do compile }
> > >> +// { dg-options "-std=c++11" }
> >
> > Yes, good point.
>
> Ack, changing to { dg-do compile { target c++11 } } and committing
> with the (correct :P) expectation that
> the change is still ok with that change.
Jason, are backports ok too?
Re: [PATCH v2] generate EH info for volatile asm statements (PR93981)
Hello, On Mon, 16 Mar 2020, Richard Sandiford wrote: > Segher Boessenkool writes: > > On Mon, Mar 16, 2020 at 05:47:03PM +, Richard Sandiford wrote: > >> Segher Boessenkool writes: > >> >> we do delete "x = 1" for f1. I think that's the expected behaviour. > >> >> We don't yet delete the initialisation in f2, but I think in principle > >> >> we could. > >> > > >> > Right. And this is incorrect if the asm may throw. > >> > >> Well... > >> > >> >> So the kind of contract I was advocating was: > >> >> > >> >> - the compiler can't make any assumptions about what the asm does > >> >> or doesn't do to output operands when an exception is raised > >> >> > >> >> - the source code can't make any assumption about the values bound > >> >> to output operands when an exception is raised > >> > >> ...with this interpretation, the deletions above would be correct even > >> if the asm throws. > > > > The write to "x" *before the asm* is deleted. I cannot think of any > > interpretation where that is correct (this does not involve inline asm > > at all: it is deleting an observable side effect before the exception). > > It's correct under the contract above :-) > > >> > And the easiest (and only feasible?) way to do this is for the compiler > >> > to automatically make an input for every output as well, imo. > >> > >> Modifying the asm like that feels a bit dangerous, > > > > Yes, obviously. The other option is to accept that almost all existing > > inline asm will have UB, with -fnon-call-exceptions. I think that is > > an even less desirable option. > > > >> And the other problem > >> still exists: he compiler might assume that the output isn't modified > >> unless the asm completes normally. > > > > I don't understand what this means? As far as the compiler is concerned > > any asm is just one instruction? And it all executes completely always. > > You need to do things with the constraints to tell the compiler it does > > not know some of the values around. If you have both an input and an > > output for a variable, the compiler does not know what value is written > > to it, and it might just be the one that was the input already (which is > > the same effect as not writing it at all). > > Normally, for SSA names in something like: > > _1 = foo () > > the definition of _1 does not take place when foo throws. Mostly, but maybe we need to lift this somewhen. E.g. when we support SSA form for non-registers; the actual return migth then be via invisible reference, and hence the result might be changed even if foo throws. That also could happen right now for some return types depending on the architecture (think large float types). Our workaround for some of these cases (where it's obvious that the result will lie in memory) is to put the real copy-out into an extra gimple insn and make the LHS be a temporary; but of course we don't want that with too large types. > Similarly for non-call exceptions on other statements. It sounds like > what you're describing requires the corresponding definition to happen > for memory outputs regardless of whether the asm throws or not, so that > the memory appears to change on both excecution paths. Otherwise, the > compiler would be able to assume that the memory operand still has its > original value in the exception handler. Well, it's both: on the exception path the compiler has to assume that the the value wasn't changed (so that former defines are regarded as dead) or that it already has changed (so that the effects the throwing "instruction" had on the result (if any) aren't lost). The easiest for this is to regard the result place as also being an input. (If broadened to all instructions under -fnon-call-exceptions, and not just to asms will have quite a bad effect on optimization capabilities, but I believe with enough force it's already possible now to construct miscompiling testcases with the right mixtures of return types and ABIs) Ciao, Michael.
RE: [PATCH v2][ARM][GCC][4/2x]: MVE intrinsics with binary operands.
Hi Srinath, > -Original Message- > From: Srinath Parvathaneni > Sent: 10 March 2020 18:23 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH v2][ARM][GCC][4/2x]: MVE intrinsics with binary operands. > > Hello Kyrill, > > Following patch is the rebased version of v1. > (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019- > November/534336.html > > > > > Hello, > > This patch supports following MVE ACLE intrinsics with binary operands. > > vsubq_u8, vsubq_n_u8, vrmulhq_u8, vrhaddq_u8, vqsubq_u8, vqsubq_n_u8, > vqaddq_u8, > vqaddq_n_u8, vorrq_u8, vornq_u8, vmulq_u8, vmulq_n_u8, vmulltq_int_u8, > vmullbq_int_u8, > vmulhq_u8, vmladavq_u8, vminvq_u8, vminq_u8, vmaxvq_u8, vmaxq_u8, > vhsubq_u8, vhsubq_n_u8, > vhaddq_u8, vhaddq_n_u8, veorq_u8, vcmpneq_n_u8, vcmphiq_u8, > vcmphiq_n_u8, vcmpeqq_u8, > vcmpeqq_n_u8, vcmpcsq_u8, vcmpcsq_n_u8, vcaddq_rot90_u8, > vcaddq_rot270_u8, vbicq_u8, > vandq_u8, vaddvq_p_u8, vaddvaq_u8, vaddq_n_u8, vabdq_u8, vshlq_r_u8, > vrshlq_u8, > vrshlq_n_u8, vqshlq_u8, vqshlq_r_u8, vqrshlq_u8, vqrshlq_n_u8, > vminavq_s8, vminaq_s8, > vmaxavq_s8, vmaxaq_s8, vbrsrq_n_u8, vshlq_n_u8, vrshrq_n_u8, > vqshlq_n_u8, vcmpneq_n_s8, > vcmpltq_s8, vcmpltq_n_s8, vcmpleq_s8, vcmpleq_n_s8, vcmpgtq_s8, > vcmpgtq_n_s8, vcmpgeq_s8, > vcmpgeq_n_s8, vcmpeqq_s8, vcmpeqq_n_s8, vqshluq_n_s8, vaddvq_p_s8, > vsubq_s8, vsubq_n_s8, > vshlq_r_s8, vrshlq_s8, vrshlq_n_s8, vrmulhq_s8, vrhaddq_s8, vqsubq_s8, > vqsubq_n_s8, > vqshlq_s8, vqshlq_r_s8, vqrshlq_s8, vqrshlq_n_s8, vqrdmulhq_s8, > vqrdmulhq_n_s8, vqdmulhq_s8, > vqdmulhq_n_s8, vqaddq_s8, vqaddq_n_s8, vorrq_s8, vornq_s8, vmulq_s8, > vmulq_n_s8, vmulltq_int_s8, > vmullbq_int_s8, vmulhq_s8, vmlsdavxq_s8, vmlsdavq_s8, vmladavxq_s8, > vmladavq_s8, vminvq_s8, > vminq_s8, vmaxvq_s8, vmaxq_s8, vhsubq_s8, vhsubq_n_s8, > vhcaddq_rot90_s8, vhcaddq_rot270_s8, > vhaddq_s8, vhaddq_n_s8, veorq_s8, vcaddq_rot90_s8, vcaddq_rot270_s8, > vbrsrq_n_s8, vbicq_s8, > vandq_s8, vaddvaq_s8, vaddq_n_s8, vabdq_s8, vshlq_n_s8, vrshrq_n_s8, > vqshlq_n_s8, vsubq_u16, > vsubq_n_u16, vrmulhq_u16, vrhaddq_u16, vqsubq_u16, vqsubq_n_u16, > vqaddq_u16, vqaddq_n_u16, > vorrq_u16, vornq_u16, vmulq_u16, vmulq_n_u16, vmulltq_int_u16, > vmullbq_int_u16, vmulhq_u16, > vmladavq_u16, vminvq_u16, vminq_u16, vmaxvq_u16, vmaxq_u16, > vhsubq_u16, vhsubq_n_u16, > vhaddq_u16, vhaddq_n_u16, veorq_u16, vcmpneq_n_u16, vcmphiq_u16, > vcmphiq_n_u16, vcmpeqq_u16, > vcmpeqq_n_u16, vcmpcsq_u16, vcmpcsq_n_u16, vcaddq_rot90_u16, > vcaddq_rot270_u16, vbicq_u16, > vandq_u16, vaddvq_p_u16, vaddvaq_u16, vaddq_n_u16, vabdq_u16, > vshlq_r_u16, vrshlq_u16, > vrshlq_n_u16, vqshlq_u16, vqshlq_r_u16, vqrshlq_u16, vqrshlq_n_u16, > vminavq_s16, vminaq_s16, > vmaxavq_s16, vmaxaq_s16, vbrsrq_n_u16, vshlq_n_u16, vrshrq_n_u16, > vqshlq_n_u16, vcmpneq_n_s16, > vcmpltq_s16, vcmpltq_n_s16, vcmpleq_s16, vcmpleq_n_s16, vcmpgtq_s16, > vcmpgtq_n_s16, > vcmpgeq_s16, vcmpgeq_n_s16, vcmpeqq_s16, vcmpeqq_n_s16, > vqshluq_n_s16, vaddvq_p_s16, vsubq_s16, > vsubq_n_s16, vshlq_r_s16, vrshlq_s16, vrshlq_n_s16, vrmulhq_s16, > vrhaddq_s16, vqsubq_s16, > vqsubq_n_s16, vqshlq_s16, vqshlq_r_s16, vqrshlq_s16, vqrshlq_n_s16, > vqrdmulhq_s16, > vqrdmulhq_n_s16, vqdmulhq_s16, vqdmulhq_n_s16, vqaddq_s16, > vqaddq_n_s16, vorrq_s16, vornq_s16, > vmulq_s16, vmulq_n_s16, vmulltq_int_s16, vmullbq_int_s16, vmulhq_s16, > vmlsdavxq_s16, vmlsdavq_s16, > vmladavxq_s16, vmladavq_s16, vminvq_s16, vminq_s16, vmaxvq_s16, > vmaxq_s16, vhsubq_s16, > vhsubq_n_s16, vhcaddq_rot90_s16, vhcaddq_rot270_s16, vhaddq_s16, > vhaddq_n_s16, veorq_s16, > vcaddq_rot90_s16, vcaddq_rot270_s16, vbrsrq_n_s16, vbicq_s16, vandq_s16, > vaddvaq_s16, vaddq_n_s16, > vabdq_s16, vshlq_n_s16, vrshrq_n_s16, vqshlq_n_s16, vsubq_u32, > vsubq_n_u32, vrmulhq_u32, > vrhaddq_u32, vqsubq_u32, vqsubq_n_u32, vqaddq_u32, vqaddq_n_u32, > vorrq_u32, vornq_u32, vmulq_u32, > vmulq_n_u32, vmulltq_int_u32, vmullbq_int_u32, vmulhq_u32, > vmladavq_u32, vminvq_u32, vminq_u32, > vmaxvq_u32, vmaxq_u32, vhsubq_u32, vhsubq_n_u32, vhaddq_u32, > vhaddq_n_u32, veorq_u32, vcmpneq_n_u32, > vcmphiq_u32, vcmphiq_n_u32, vcmpeqq_u32, vcmpeqq_n_u32, > vcmpcsq_u32, vcmpcsq_n_u32, > vcaddq_rot90_u32, vcaddq_rot270_u32, vbicq_u32, vandq_u32, > vaddvq_p_u32, vaddvaq_u32, vaddq_n_u32, > vabdq_u32, vshlq_r_u32, vrshlq_u32, vrshlq_n_u32, vqshlq_u32, > vqshlq_r_u32, vqrshlq_u32, vqrshlq_n_u32, > vminavq_s32, vminaq_s32, vmaxavq_s32, vmaxaq_s32, vbrsrq_n_u32, > vshlq_n_u32, vrshrq_n_u32, > vqshlq_n_u32, vcmpneq_n_s32, vcmpltq_s32, vcmpltq_n_s32, vcmpleq_s32, > vcmpleq_n_s32, vcmpgtq_s32, > vcmpgtq_n_s32, vcmpgeq_s32, vcmpgeq_n_s32, vcmpeqq_s32, > vcmpeqq_n_s32, vqshluq_n_s32, vaddvq_p_s32, > vsubq_s32, vsubq_n_s32, vshlq_r_s32, vrshlq_s32, vrshlq_n_s32, > vrmulhq_s32, vrhaddq_s32, vqsubq_s32, > vqsubq_n_s32, vqshlq_s32, vqshlq_r_s32, vqrshlq_s32, vqrshlq_n_s32, > vqrdmulhq_s32, vqrdmulhq_n_s32, > vqdmulhq_s32, vqdmulhq_n_s32, vqaddq_s32, vqaddq_n_s32, vorrq_s32, > vornq_s32, vmulq_s32, vmulq_n_s32, > v
[stage1][PATCH] optgen: make more sanity checks for enums.
Hi.
The patch is about better sanity check in option generation script.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed in stage1?
Thanks,
Martin
gcc/ChangeLog:
2020-03-17 Martin Liska
* opt-functions.awk (opt_args_non_empty): New function.
* opt-read.awk: Use the function for various option arguments.
---
gcc/opt-functions.awk | 13 +
gcc/opt-read.awk | 10 +-
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/gcc/opt-functions.awk b/gcc/opt-functions.awk
index 2f0442dc563..be4b9e66165 100644
--- a/gcc/opt-functions.awk
+++ b/gcc/opt-functions.awk
@@ -72,6 +72,19 @@ function opt_args(name, flags)
return flags
}
+# If FLAGS contains a "NAME(...argument...)" flag, return the value
+# of the argument. Print error message otherwise.
+function opt_args_non_empty(name, flags, description)
+{
+ args = opt_args(name, flags)
+ if (args == "")
+ {
+ print "Empty option argument '" name "' during parsing of: " flags >> "/dev/stderr"
+ exit 1
+ }
+ return args
+}
+
# Return the Nth comma-separated element of S. Return the empty string
# if S does not contain N elements.
function nth_arg(n, s)
diff --git a/gcc/opt-read.awk b/gcc/opt-read.awk
index a2e16f29aff..9bb9dfcf6ca 100644
--- a/gcc/opt-read.awk
+++ b/gcc/opt-read.awk
@@ -81,8 +81,8 @@ BEGIN {
}
else if ($1 == "Enum") {
props = $2
- name = opt_args("Name", props)
- type = opt_args("Type", props)
+ name = opt_args_non_empty("Name", props)
+ type = opt_args_non_empty("Type", props)
unknown_error = opt_args("UnknownError", props)
enum_names[n_enums] = name
enum_type[name] = type
@@ -93,9 +93,9 @@ BEGIN {
}
else if ($1 == "EnumValue") {
props = $2
- enum_name = opt_args("Enum", props)
- string = opt_args("String", props)
- value = opt_args("Value", props)
+ enum_name = opt_args_non_empty("Enum", props)
+ string = opt_args_non_empty("String", props)
+ value = opt_args_non_empty("Value", props)
val_flags = "0"
val_flags = val_flags \
test_flag("Canonical", props, "| CL_ENUM_CANONICAL") \
RE: [PATCH v2][ARM][GCC][5/2x]: MVE intrinsics with binary operands.
Hi Srinath, > -Original Message- > From: Srinath Parvathaneni > Sent: 10 March 2020 18:23 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH v2][ARM][GCC][5/2x]: MVE intrinsics with binary operands. > > Hello Kyrill, > > Following patch is the rebased version of v1. > (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019- > November/534330.html > > > > > Hello, > > This patch supports following MVE ACLE intrinsics with binary operands. > > vqmovntq_u16, vqmovnbq_u16, vmulltq_poly_p8, vmullbq_poly_p8, > vmovntq_u16, vmovnbq_u16, vmlaldavxq_u16, vmlaldavq_u16, > vqmovuntq_s16, vqmovunbq_s16, vshlltq_n_u8, vshllbq_n_u8, vorrq_n_u16, > vbicq_n_u16, vcmpneq_n_f16, vcmpneq_f16, vcmpltq_n_f16, vcmpltq_f16, > vcmpleq_n_f16, vcmpleq_f16, vcmpgtq_n_f16, vcmpgtq_f16, vcmpgeq_n_f16, > vcmpgeq_f16, vcmpeqq_n_f16, vcmpeqq_f16, vsubq_f16, vqmovntq_s16, > vqmovnbq_s16, vqdmulltq_s16, vqdmulltq_n_s16, vqdmullbq_s16, > vqdmullbq_n_s16, vorrq_f16, vornq_f16, vmulq_n_f16, vmulq_f16, > vmovntq_s16, vmovnbq_s16, vmlsldavxq_s16, vmlsldavq_s16, > vmlaldavxq_s16, vmlaldavq_s16, vminnmvq_f16, vminnmq_f16, > vminnmavq_f16, vminnmaq_f16, vmaxnmvq_f16, vmaxnmq_f16, > vmaxnmavq_f16, vmaxnmaq_f16, veorq_f16, vcmulq_rot90_f16, > vcmulq_rot270_f16, vcmulq_rot180_f16, vcmulq_f16, vcaddq_rot90_f16, > vcaddq_rot270_f16, vbicq_f16, vandq_f16, vaddq_n_f16, vabdq_f16, > vshlltq_n_s8, vshllbq_n_s8, vorrq_n_s16, vbicq_n_s16, vqmovntq_u32, > vqmovnbq_u32, vmulltq_poly_p16, vmullbq_poly_p16, vmovntq_u32, > vmovnbq_u32, vmlaldavxq_u32, vmlaldavq_u32, vqmovuntq_s32, > vqmovunbq_s32, vshlltq_n_u16, vshllbq_n_u16, vorrq_n_u32, vbicq_n_u32, > vcmpneq_n_f32, vcmpneq_f32, vcmpltq_n_f32, vcmpltq_f32, vcmpleq_n_f32, > vcmpleq_f32, vcmpgtq_n_f32, vcmpgtq_f32, vcmpgeq_n_f32, vcmpgeq_f32, > vcmpeqq_n_f32, vcmpeqq_f32, vsubq_f32, vqmovntq_s32, vqmovnbq_s32, > vqdmulltq_s32, vqdmulltq_n_s32, vqdmullbq_s32, vqdmullbq_n_s32, > vorrq_f32, vornq_f32, vmulq_n_f32, vmulq_f32, vmovntq_s32, > vmovnbq_s32, vmlsldavxq_s32, vmlsldavq_s32, vmlaldavxq_s32, > vmlaldavq_s32, vminnmvq_f32, vminnmq_f32, vminnmavq_f32, > vminnmaq_f32, vmaxnmvq_f32, vmaxnmq_f32, vmaxnmavq_f32, > vmaxnmaq_f32, veorq_f32, vcmulq_rot90_f32, vcmulq_rot270_f32, > vcmulq_rot180_f32, vcmulq_f32, vcaddq_rot90_f32, vcaddq_rot270_f32, > vbicq_f32, vandq_f32, vaddq_n_f32, vabdq_f32, vshlltq_n_s16, > vshllbq_n_s16, vorrq_n_s32, vbicq_n_s32, vrmlaldavhq_u32, vctp8q_m, > vctp64q_m, vctp32q_m, vctp16q_m, vaddlvaq_u32, vrmlsldavhxq_s32, > vrmlsldavhq_s32, vrmlaldavhxq_s32, vrmlaldavhq_s32, vcvttq_f16_f32, > vcvtbq_f16_f32, vaddlvaq_s32. > > Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more > details. > [1] https://developer.arm.com/architectures/instruction-sets/simd- > isas/helium/mve-intrinsics > > The above intrinsics are defined using the already defined builtin qualifiers > BINOP_NONE_NONE_IMM, BINOP_NONE_NONE_NONE, > BINOP_UNONE_NONE_NONE, BINOP_UNONE_UNONE_IMM, > BINOP_UNONE_UNONE_NONE, BINOP_UNONE_UNONE_UNONE. > > Regression tested on target arm-none-eabi and armeb-none-eabi and found > no regressions. > > Ok for trunk? > Thanks, I've pushed this patch to trunk. Kyrill > Thanks, > Srinath. > > gcc/ChangeLog: > > 2019-10-23 Andre Vieira > Mihail Ionescu > Srinath Parvathaneni > > * config/arm/arm_mve.h (vqmovntq_u16): Define macro. > (vqmovnbq_u16): Likewise. > (vmulltq_poly_p8): Likewise. > (vmullbq_poly_p8): Likewise. > (vmovntq_u16): Likewise. > (vmovnbq_u16): Likewise. > (vmlaldavxq_u16): Likewise. > (vmlaldavq_u16): Likewise. > (vqmovuntq_s16): Likewise. > (vqmovunbq_s16): Likewise. > (vshlltq_n_u8): Likewise. > (vshllbq_n_u8): Likewise. > (vorrq_n_u16): Likewise. > (vbicq_n_u16): Likewise. > (vcmpneq_n_f16): Likewise. > (vcmpneq_f16): Likewise. > (vcmpltq_n_f16): Likewise. > (vcmpltq_f16): Likewise. > (vcmpleq_n_f16): Likewise. > (vcmpleq_f16): Likewise. > (vcmpgtq_n_f16): Likewise. > (vcmpgtq_f16): Likewise. > (vcmpgeq_n_f16): Likewise. > (vcmpgeq_f16): Likewise. > (vcmpeqq_n_f16): Likewise. > (vcmpeqq_f16): Likewise. > (vsubq_f16): Likewise. > (vqmovntq_s16): Likewise. > (vqmovnbq_s16): Likewise. > (vqdmulltq_s16): Likewise. > (vqdmulltq_n_s16): Likewise. > (vqdmullbq_s16): Likewise. > (vqdmullbq_n_s16): Likewise. > (vorrq_f16): Likewise. > (vornq_f16): Likewise. > (vmulq_n_f16): Likewise. > (vmulq_f16): Likewise. > (vmovntq_s16): Likewise. > (vmovnbq_s16): Likewise. > (vmlsldavxq_s16): Likewise. > (vmlsldavq_s16): Likewise. > (vmlaldavxq_s16): Likewise. > (vmlaldavq_s16): Likewise. > (vminnmvq_f16): Likewise. > (vminnmq_f16): Likewise. > (vminnmavq_f16): Likewise. > (vminnmaq_f16): Likewise. > (vmaxnmvq_f16):
RE: [PATCH v2][ARM][GCC][1/3x]: MVE intrinsics with ternary operands.
Hi Srinath, > -Original Message- > From: Srinath Parvathaneni > Sent: 16 March 2020 12:01 > To: gcc-patches@gcc.gnu.org > Cc: Kyrylo Tkachov > Subject: [PATCH v2][ARM][GCC][1/3x]: MVE intrinsics with ternary operands. > > Hello Kyrill, > > Following patch is the rebased version of v1. > (version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019- > November/534358.html > > > > Hello, > > This patch supports following MVE ACLE intrinsics with ternary operands. > > vabavq_s8, vabavq_s16, vabavq_s32, vbicq_m_n_s16, vbicq_m_n_s32, > vbicq_m_n_u16, vbicq_m_n_u32, vcmpeqq_m_f16, vcmpeqq_m_f32, > vcvtaq_m_s16_f16, vcvtaq_m_u16_f16, vcvtaq_m_s32_f32, > vcvtaq_m_u32_f32, vcvtq_m_f16_s16, vcvtq_m_f16_u16, vcvtq_m_f32_s32, > vcvtq_m_f32_u32, vqrshrnbq_n_s16, vqrshrnbq_n_u16, vqrshrnbq_n_s32, > vqrshrnbq_n_u32, vqrshrunbq_n_s16, vqrshrunbq_n_s32, > vrmlaldavhaq_s32, vrmlaldavhaq_u32, vshlcq_s8, vshlcq_u8, vshlcq_s16, > vshlcq_u16, vshlcq_s32, vshlcq_u32, vabavq_s8, vabavq_s16, vabavq_s32. > > Please refer to M-profile Vector Extension (MVE) intrinsics [1] for more > details. > [1] https://developer.arm.com/architectures/instruction-sets/simd- > isas/helium/mve-intrinsics > > Regression tested on arm-none-eabi and found no regressions. > > Ok for trunk? I've pushed this patch to master for you. Thanks, Kyrill > > Thanks, > Srinath. > > gcc/ChangeLog: > > 2019-10-23 Andre Vieira > Mihail Ionescu > Srinath Parvathaneni > > * config/arm/arm-builtins.c > (TERNOP_UNONE_UNONE_UNONE_IMM_QUALIFIERS): > Define qualifier for ternary operands. > (TERNOP_UNONE_UNONE_NONE_NONE_QUALIFIERS): Likewise. > (TERNOP_UNONE_NONE_UNONE_IMM_QUALIFIERS): Likewise. > (TERNOP_NONE_NONE_UNONE_IMM_QUALIFIERS): Likewise. > (TERNOP_UNONE_UNONE_NONE_IMM_QUALIFIERS): Likewise. > (TERNOP_UNONE_UNONE_NONE_UNONE_QUALIFIERS): Likewise. > (TERNOP_UNONE_UNONE_IMM_UNONE_QUALIFIERS): Likewise. > (TERNOP_UNONE_NONE_NONE_UNONE_QUALIFIERS): Likewise. > (TERNOP_NONE_NONE_NONE_IMM_QUALIFIERS): Likewise. > (TERNOP_NONE_NONE_NONE_UNONE_QUALIFIERS): Likewise. > (TERNOP_NONE_NONE_IMM_UNONE_QUALIFIERS): Likewise. > (TERNOP_NONE_NONE_UNONE_UNONE_QUALIFIERS): Likewise. > (TERNOP_UNONE_UNONE_UNONE_UNONE_QUALIFIERS): Likewise. > (TERNOP_NONE_NONE_NONE_NONE_QUALIFIERS): Likewise. > * config/arm/arm_mve.h (vabavq_s8): Define macro. > (vabavq_s16): Likewise. > (vabavq_s32): Likewise. > (vbicq_m_n_s16): Likewise. > (vbicq_m_n_s32): Likewise. > (vbicq_m_n_u16): Likewise. > (vbicq_m_n_u32): Likewise. > (vcmpeqq_m_f16): Likewise. > (vcmpeqq_m_f32): Likewise. > (vcvtaq_m_s16_f16): Likewise. > (vcvtaq_m_u16_f16): Likewise. > (vcvtaq_m_s32_f32): Likewise. > (vcvtaq_m_u32_f32): Likewise. > (vcvtq_m_f16_s16): Likewise. > (vcvtq_m_f16_u16): Likewise. > (vcvtq_m_f32_s32): Likewise. > (vcvtq_m_f32_u32): Likewise. > (vqrshrnbq_n_s16): Likewise. > (vqrshrnbq_n_u16): Likewise. > (vqrshrnbq_n_s32): Likewise. > (vqrshrnbq_n_u32): Likewise. > (vqrshrunbq_n_s16): Likewise. > (vqrshrunbq_n_s32): Likewise. > (vrmlaldavhaq_s32): Likewise. > (vrmlaldavhaq_u32): Likewise. > (vshlcq_s8): Likewise. > (vshlcq_u8): Likewise. > (vshlcq_s16): Likewise. > (vshlcq_u16): Likewise. > (vshlcq_s32): Likewise. > (vshlcq_u32): Likewise. > (vabavq_u8): Likewise. > (vabavq_u16): Likewise. > (vabavq_u32): Likewise. > (__arm_vabavq_s8): Define intrinsic. > (__arm_vabavq_s16): Likewise. > (__arm_vabavq_s32): Likewise. > (__arm_vabavq_u8): Likewise. > (__arm_vabavq_u16): Likewise. > (__arm_vabavq_u32): Likewise. > (__arm_vbicq_m_n_s16): Likewise. > (__arm_vbicq_m_n_s32): Likewise. > (__arm_vbicq_m_n_u16): Likewise. > (__arm_vbicq_m_n_u32): Likewise. > (__arm_vqrshrnbq_n_s16): Likewise. > (__arm_vqrshrnbq_n_u16): Likewise. > (__arm_vqrshrnbq_n_s32): Likewise. > (__arm_vqrshrnbq_n_u32): Likewise. > (__arm_vqrshrunbq_n_s16): Likewise. > (__arm_vqrshrunbq_n_s32): Likewise. > (__arm_vrmlaldavhaq_s32): Likewise. > (__arm_vrmlaldavhaq_u32): Likewise. > (__arm_vshlcq_s8): Likewise. > (__arm_vshlcq_u8): Likewise. > (__arm_vshlcq_s16): Likewise. > (__arm_vshlcq_u16): Likewise. > (__arm_vshlcq_s32): Likewise. > (__arm_vshlcq_u32): Likewise. > (__arm_vcmpeqq_m_f16): Likewise. > (__arm_vcmpeqq_m_f32): Likewise. > (__arm_vcvtaq_m_s16_f16): Likewise. > (__arm_vcvtaq_m_u16_f16): Likewise. > (__arm_vcvtaq_m_s32_f32): Likewise. > (__arm_vcvtaq_m_u32_f32): Likewise. > (__arm_vcvtq_m_f16_s16): Likewise. > (__arm_vcvtq_m_f16_u16): Likewise. > (__arm_vcvtq_m_f32_s32): Likewise. > (__arm_vcvtq_m
[COMMITTED] coroutines, testsuite: Fix single test execution.
Hi,
As Bin noticed, invocations of the coro-torture.exp like
'coro-torture.exp=some-test.C’
were failing because DEFAULT_CXXFLAGS was undefined. Fixed by defining this
locally, if it has no pre-existing global value.
tested on x86_64-darwin, applied to mainline as obvious.
thanks
Iain
diff --git a/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp
b/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp
index d2463b27983..2246f7154be 100644
--- a/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp
+++ b/gcc/testsuite/g++.dg/coroutines/torture/coro-torture.exp
@@ -3,13 +3,19 @@
load_lib g++-dg.exp
load_lib torture-options.exp
-global DG_TORTURE_OPTIONS LTO_TORTURE_OPTIONS
+global DG_TORTURE_OPTIONS LTO_TORTURE_OPTIONS
-dg-init
-torture-init
+# If a testcase doesn't have special options, use these.
+global DEFAULT_CXXFLAGS
+if ![info exists DEFAULT_CXXFLAGS] then {
+set DEFAULT_CXXFLAGS " -pedantic-errors -Wno-long-long"
+}
set DEFAULT_COROFLAGS $DEFAULT_CXXFLAGS
-lappend DEFAULT_COROFLAGS "-std=c++17" "-fcoroutines"
+lappend DEFAULT_COROFLAGS "-fcoroutines" "-std=c++17"
+
+dg-init
+torture-init
set-torture-options [concat $DG_TORTURE_OPTIONS $LTO_TORTURE_OPTIONS]
[stage1] [PATCH] Make target_clones resolver fn static if possible.
On 1/23/20 2:09 PM, Richard Biener wrote:
The other thing looks like sth for next stage1?
Hi.
I'm sending the second part for next stage1.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed in next stage1?
Thanks,
Martin
>From 6d2113da263d7a6a0bb0adcf22edb074646f1996 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 16 Jan 2020 10:38:41 +0100
Subject: [PATCH] Make target_clones resolver fn static if possible.
gcc/ChangeLog:
2020-03-17 Martin Liska
PR target/93274
* config/i386/i386-features.c (make_resolver_func): Drop
public flag for resolver.
* config/rs6000/rs6000.c (make_resolver_func): Add comdat
group for resolver and drop public flag if possible.
gcc/testsuite/ChangeLog:
2020-03-17 Martin Liska
PR target/93274
* gcc.target/i386/pr81213-2.c: New test.
* gcc.target/i386/pr81213.c: Add additional source.
---
gcc/config/i386/i386-features.c | 3 +++
gcc/config/rs6000/rs6000.c| 12
gcc/testsuite/gcc.target/i386/pr81213-2.c | 11 +++
gcc/testsuite/gcc.target/i386/pr81213.c | 7 +--
4 files changed, 31 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr81213-2.c
diff --git a/gcc/config/i386/i386-features.c b/gcc/config/i386/i386-features.c
index 6919c839605..690e6373c27 100644
--- a/gcc/config/i386/i386-features.c
+++ b/gcc/config/i386/i386-features.c
@@ -2777,6 +2777,9 @@ make_resolver_func (const tree default_decl,
DECL_COMDAT (decl) = 1;
make_decl_one_only (decl, DECL_ASSEMBLER_NAME (decl));
}
+ else
+TREE_PUBLIC (ifunc_alias_decl) = 0;
+
/* Build result decl and add to function_decl. */
t = build_decl (UNKNOWN_LOCATION, RESULT_DECL, NULL_TREE, ptr_type_node);
DECL_CONTEXT (t) = decl;
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 5798f924472..0911ab019cd 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -23887,6 +23887,18 @@ make_resolver_func (const tree default_decl,
DECL_INITIAL (decl) = make_node (BLOCK);
DECL_STATIC_CONSTRUCTOR (decl) = 0;
+ if (DECL_COMDAT_GROUP (default_decl)
+ || TREE_PUBLIC (default_decl))
+{
+ /* In this case, each translation unit with a call to this
+ versioned function will put out a resolver. Ensure it
+ is comdat to keep just one copy. */
+ DECL_COMDAT (decl) = 1;
+ make_decl_one_only (decl, DECL_ASSEMBLER_NAME (decl));
+}
+ else
+TREE_PUBLIC (dispatch_decl) = 0;
+
/* Build result decl and add to function_decl. */
tree t = build_decl (UNKNOWN_LOCATION, RESULT_DECL, NULL_TREE, ptr_type_node);
DECL_CONTEXT (t) = decl;
diff --git a/gcc/testsuite/gcc.target/i386/pr81213-2.c b/gcc/testsuite/gcc.target/i386/pr81213-2.c
new file mode 100644
index 000..a80622cb184
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr81213-2.c
@@ -0,0 +1,11 @@
+__attribute__((target_clones("avx","arch=slm","arch=core-avx2","default")))
+static int
+foo ()
+{
+ return 2;
+}
+
+int bar()
+{
+ return foo();
+}
diff --git a/gcc/testsuite/gcc.target/i386/pr81213.c b/gcc/testsuite/gcc.target/i386/pr81213.c
index 89c47529861..334838631d0 100644
--- a/gcc/testsuite/gcc.target/i386/pr81213.c
+++ b/gcc/testsuite/gcc.target/i386/pr81213.c
@@ -1,6 +1,9 @@
/* PR ipa/81214. */
-/* { dg-do compile } */
+/* { dg-do run } */
/* { dg-require-ifunc "" } */
+/* { dg-additional-sources "pr81213-2.c" } */
+
+int bar();
__attribute__((target_clones("avx","arch=slm","arch=core-avx2","default")))
static int
@@ -11,7 +14,7 @@ foo ()
int main()
{
- return foo();
+ return foo() + bar();
}
/* { dg-final { scan-assembler "\t.globl\tfoo" } } */
--
2.25.1
[PATCH][Arm][3/4] Implement scalar Custom Datapath Extension intrinsics
Hi all, This patch introduces the scalar CDE (Custom Datapath Extension) intrinsics for the arm backend. There is nothing beyond the standard in this patch. We simply build upon what has been done by Dennis for the vector intrinsics (https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542008.html which this patch depends on). We do add `+cdecp6` to the default arguments for `target-supports.exp`, this allows for using coprocessor 6 in tests. This patch uses an alternate coprocessor to ease assembler scanning by looking for a use of coprocessor 6. We also ensure that any DImode registers are put in an even-odd register pair when compiling for a target with CDE -- this avoids faulty code generation for -Os when producing the cx*d instructions. Testing done: Bootstrapped and regtested for arm-none-linux-gnueabihf. This patch is done by Matthew. Is it OK for commit please? Cheers Dennis gcc/ChangeLog: 2020-03-03 Matthew Malcomson * config/arm/arm.c (arm_hard_regno_mode_ok): DImode registers forced into even-odd register pairs for TARGET_CDE. * config/arm/arm.h (ARM_CCDE_CONST_1): New. (ARM_CCDE_CONST_2): New. (ARM_CCDE_CONST_3): New. * config/arm/arm.md (arm_cx1si, arm_cx1di arm_cx1asi, arm_cx1adi arm_cx2si, arm_cx2di arm_cx2asi, arm_cx2adi arm_cx3si, arm_cx3di arm_cx3asi, arm_cx3adi): New patterns. * config/arm/arm_cde.h (__arm_cx1, __arm_cx1a, __arm_cx2, __arm_cx2a, __arm_cx3, __arm_cx3a, __arm_cx1d, __arm_cx1da, __arm_cx2d, __arm_cx2da, __arm_cx3d, __arm_cx3da): New ACLE function macros. * config/arm/arm_cde_builtins.def (cx1, cx1a, cx2, cx2a, cx3, cx3a): Define intrinsics. * config/arm/iterators.md (cde_suffix, cde_dest): New mode attributes. * config/arm/predicates.md (const_int_ccde1_operand, const_int_ccde2_operand, const_int_ccde3_operand): New. * config/arm/unspecs.md (UNSPEC_CDE, UNSPEC_CDEA): New. gcc/testsuite/ChangeLog: 2020-03-03 Matthew Malcomson * gcc.target/arm/acle/cde-errors.c: New test. * gcc.target/arm/acle/cde.c: New test. * lib/target-supports.exp: Update CDE flags to enable coprocessor 6.diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h index b9c55cd6f39dc4806501543ff6157ef6ba787b4a..0d31d98a670b346c9488fba292a15e45285cb1fa 100644 --- a/gcc/config/arm/arm.h +++ b/gcc/config/arm/arm.h @@ -576,6 +576,9 @@ extern int arm_arch_cde; extern int arm_arch_cde_coproc; extern const int arm_arch_cde_coproc_bits[]; #define ARM_CDE_CONST_COPROC 7 +#define ARM_CCDE_CONST_1 ((1 << 13) - 1) +#define ARM_CCDE_CONST_2 ((1 << 9 ) - 1) +#define ARM_CCDE_CONST_3 ((1 << 6 ) - 1) #define ARM_VCDE_CONST_1 ((1 << 11) - 1) #define ARM_VCDE_CONST_2 ((1 << 6 ) - 1) #define ARM_VCDE_CONST_3 ((1 << 3 ) - 1) diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index 55a4ebf5147a93ecd679c2d48c93e1441fc8c6d8..7b9e311c992a75ac7208cbf8301eb608d777a7c4 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -25066,10 +25066,11 @@ arm_hard_regno_mode_ok (unsigned int regno, machine_mode mode) if (ARM_NUM_REGS (mode) > 4) return false; - if (TARGET_THUMB2 && !TARGET_HAVE_MVE) + if (TARGET_THUMB2 && !(TARGET_HAVE_MVE || TARGET_CDE)) return true; - return !(TARGET_LDRD && GET_MODE_SIZE (mode) > 4 && (regno & 1) != 0); + return !((TARGET_LDRD || TARGET_CDE) + && GET_MODE_SIZE (mode) > 4 && (regno & 1) != 0); } if (regno == FRAME_POINTER_REGNUM diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md index 5387f972f5a864a153873f21b9423d28446daefc..9dd446fd2e97f7a608785080fef109f167961f13 100644 --- a/gcc/config/arm/arm.md +++ b/gcc/config/arm/arm.md @@ -4407,6 +4407,70 @@ (set_attr "shift" "3") (set_attr "type" "logic_shift_reg")]) +;; Custom Datapath Extension insns. +(define_insn "arm_cx1" + [(set (match_operand:SIDI 0 "s_register_operand" "=r") + (unspec:SIDI [(match_operand:SI 1 "const_int_coproc_operand" "i") + (match_operand:SI 2 "const_int_ccde1_operand" "i")] + UNSPEC_CDE))] + "TARGET_CDE" + "cx1\\tp%c1, , %2" +) + +(define_insn "arm_cx1a" + [(set (match_operand:SIDI 0 "s_register_operand" "=r") + (unspec:SIDI [(match_operand:SI 1 "const_int_coproc_operand" "i") + (match_operand:SIDI 2 "s_register_operand" "0") + (match_operand:SI 3 "const_int_ccde1_operand" "i")] + UNSPEC_CDEA))] + "TARGET_CDE" + "cx1a\\tp%c1, , %3" +) + +(define_insn "arm_cx2" + [(set (match_operand:SIDI 0 "s_register_operand" "=r") + (unspec:SIDI [(match_operand:SI 1 "const_int_coproc_operand" "i") + (match_operand:SI 2 "s_register_operand" "r") + (match_operand:SI 3 "const_int_ccde2_operand" "i")] + UNSPEC_CDE))] + "TARGET_CDE" + "cx2\\tp%c1, , %2, %3" +) + +(define_insn "arm_cx2a" + [(set (match_operand:SIDI 0 "s_register_operand" "=r") + (unspec:SIDI [(match_operand:SI 1 "cons
Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.
Hi Martin, I like the patch. It definitely serves our purposes at Oracle and provides another way to do what my previous patches did as well. 1) It keeps the backwards compatibility regarding -frecord-gcc-switches; therefore, removes my related doubts about your previous patch. 2) It still makes use of -frecord-gcc-switches. The new option is only to control the format. This addresses some previous objections to having a new option doing something similar. Now the new option controls the behaviour of the existing one and that behaviour can be further extended. 3) It uses an environment variable as Jakub suggested. The patch looks good and I confirm that it works for our purposes. Having said that, I have to ask for recognition in this patch for my and my company's contributions. Can you please keep my name and my work email in the changelog and in the commit message? Thanks Egeyar On 3/17/20 2:53 PM, Martin Liška wrote: Hi. I'm sending enhanced patch that makes the following changes: - a new option -frecord-gcc-switches-format is added; the option selects format (processed, driver) for all options that record GCC command line - Dwarf gen_produce_string is now used in -fverbose-asm - The .s file is affected in the following way: BEFORE: # GNU C17 (SUSE Linux) version 9.2.1 20200128 [revision 83f65674e78d97d27537361de1a9d74067ff228d] (x86_64-suse-linux) # compiled by GNU C version 9.2.1 20200128 [revision 83f65674e78d97d27537361de1a9d74067ff228d], GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP # GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 # options passed: -fpreprocessed test.i -march=znver1 -mmmx -mno-3dnow # -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -msha # -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx # -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 # -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw # -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd # -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves # -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi # -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mmwaitx -mclzero -mno-pku # -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni # -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b # -mno-waitpkg -mno-cldemote -mno-ptwrite --param l1-cache-size=32 # --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=znver1 # -grecord-gcc-switches -g -fverbose-asm -frecord-gcc-switches # options enabled: -faggressive-loop-optimizations -fassume-phsa # -fasynchronous-unwind-tables -fauto-inc-dec -fcommon # -fdelete-null-pointer-checks -fdwarf2-cfi-asm -fearly-inlining # -feliminate-unused-debug-types -ffp-int-builtin-inexact -ffunction-cse # -fgcse-lm -fgnu-runtime -fgnu-unique -fident -finline-atomics # -fipa-stack-alignment -fira-hoist-pressure -fira-share-save-slots # -fira-share-spill-slots -fivopts -fkeep-static-consts # -fleading-underscore -flifetime-dse -flto-odr-type-merging -fmath-errno # -fmerge-debug-strings -fpeephole -fplt -fprefetch-loop-arrays # -frecord-gcc-switches -freg-struct-return -fsched-critical-path-heuristic # -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock # -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec # -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fschedule-fusion # -fsemantic-interposition -fshow-column -fshrink-wrap-separate # -fsigned-zeros -fsplit-ivs-in-unroller -fssa-backprop -fstdarg-opt # -fstrict-volatile-bitfields -fsync-libcalls -ftrapping-math -ftree-cselim # -ftree-forwprop -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon # -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop # -ftree-reassoc -ftree-scev-cprop -funit-at-a-time -funwind-tables # -fverbose-asm -fzero-initialized-in-bss -m128bit-long-double -m64 -m80387 # -mabm -madx -maes -malign-stringops -mavx -mavx2 # -mavx256-split-unaligned-store -mbmi -mbmi2 -mclflushopt -mclzero -mcx16 # -mf16c -mfancy-math-387 -mfma -mfp-ret-in-387 -mfsgsbase -mfxsr -mglibc # -mieee-fp -mlong-double-80 -mlzcnt -mmmx -mmovbe -mmwaitx -mpclmul # -mpopcnt -mprfchw -mpush-args -mrdrnd -mrdseed -mred-zone -msahf -msha # -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2 -msse4a -mssse3 -mstv # -mtls-direct-seg-refs -mvzeroupper -mxsave -mxsavec -mxsaveopt -mxsaves AFTER: # GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 # GNU C17 10.0.1 20200317 (experimental) -march=znver1 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -msha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mpr
Backports to 9.3.1
Hi!
I've backported 14 commits from trunk to 9.3.1, bootstrapped/regtested
on x86_64-linux and i686-linux and committed to 9 branch.
Jakub
>From 5de0dc84c75a43f78a03c7cdb7e7c443c641a7fa Mon Sep 17 00:00:00 2001
From: Jakub Jelinek
Date: Wed, 4 Mar 2020 09:01:59 +0100
Subject: [PATCH] tailcall: Fix up process_assignment [PR94001]
When a function returns void or the return value is ignored, ass_var
is NULL_TREE. The tail recursion handling generally assumes DCE has been
performed and so doesn't expect to encounter useless assignments after the
call and expects them to be part of the return value adjustment that need
to be changed into tail recursion additions/multiplications.
process_assignment does some verification and has a way to tell the caller
to try to move dead or whatever other stmts that don't participate in the
return value modifications before it is returned.
For binary rhs assignments it is just fine, neither op0 nor op1 will be
NULL_TREE and thus if *ass_var is NULL_TREE, it will not match, but unary
rhs is handled by only setting op0 to rhs1 and setting op1 to NULL_TREE.
And at this point, NULL_TREE == NULL_TREE and thus we think e.g. the
c_2 = -e_3(D);
dead stmt is actually a return value modification, so we queue it as
multiplication and then create a void type SSA_NAME accumulator for it
and ICE shortly after.
Fixed by making sure op1 == *ass_var comparison is done only if *ass_var.
2020-03-04 Jakub Jelinek
PR tree-optimization/94001
* tree-tailcall.c (process_assignment): Before comparing op1 to
*ass_var, verify *ass_var is non-NULL.
* gcc.dg/pr94001.c: New test.
---
gcc/ChangeLog | 9 +
gcc/testsuite/ChangeLog| 8
gcc/testsuite/gcc.dg/pr94001.c | 11 +++
gcc/tree-tailcall.c| 3 ++-
4 files changed, 30 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/pr94001.c
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ec0284ad8be..3e93b3ae62b 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,12 @@
+2020-03-17 Jakub Jelinek
+
+ Backported from mainline
+ 2020-03-04 Jakub Jelinek
+
+ PR tree-optimization/94001
+ * tree-tailcall.c (process_assignment): Before comparing op1 to
+ *ass_var, verify *ass_var is non-NULL.
+
2020-03-13 Richard Biener
PR tree-optimization/94163
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 555d9965efd..bbc3bef437f 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,11 @@
+2020-03-17 Jakub Jelinek
+
+ Backported from mainline
+ 2020-03-04 Jakub Jelinek
+
+ PR tree-optimization/94001
+ * gcc.dg/pr94001.c: New test.
+
2020-03-17 Kewen Lin
Backport from master
diff --git a/gcc/testsuite/gcc.dg/pr94001.c b/gcc/testsuite/gcc.dg/pr94001.c
new file mode 100644
index 000..f83873fa2bd
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr94001.c
@@ -0,0 +1,11 @@
+/* PR tree-optimization/94001 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fno-tree-dce" } */
+
+void
+bar (int e)
+{
+ bar (3);
+ int c;
+ c = -e;
+}
diff --git a/gcc/tree-tailcall.c b/gcc/tree-tailcall.c
index 255575f1198..4f42817f7de 100644
--- a/gcc/tree-tailcall.c
+++ b/gcc/tree-tailcall.c
@@ -327,7 +327,8 @@ process_assignment (gassign *stmt,
&& (non_ass_var = independent_of_stmt_p (op1, stmt, call,
to_move)))
;
- else if (op1 == *ass_var
+ else if (*ass_var
+ && op1 == *ass_var
&& (non_ass_var = independent_of_stmt_p (op0, stmt, call,
to_move)))
;
--
2.20.1
>From d2a810ee83e2952bf351498cecf8f5db28860a24 Mon Sep 17 00:00:00 2001
From: Jakub Jelinek
Date: Wed, 4 Mar 2020 12:59:04 +0100
Subject: [PATCH] inliner: Copy DECL_BY_REFERENCE in copy_decl_to_var [PR93888]
In the following testcase we emit wrong debug info for the karg
parameter in the DW_TAG_inlined_subroutine into main.
The problem is that the karg PARM_DECL is DECL_BY_REFERENCE and thus
in the IL has const K & type, but in the source just const K.
When the function is inlined, we create a VAR_DECL for it, but don't
set DECL_BY_REFERENCE, so when emitting DW_AT_location, we treat it like
a const K & typed variable, but it has DW_AT_abstract_origin which has
just the const K type and thus the debugger thinks the variable has
const K type.
Fixed by copying the DECL_BY_REFERENCE flag. Not doing it in
copy_decl_for_dup_finish, because copy_decl_no_change already copies
that flag through copy_node and in copy_result_decl_to_var it is
undesirable, as we handle DECL_BY_REFERENCE in that case instead
by changing the type.
2020-03-04 Jakub Jelinek
PR debug/93888
* tree-inline.c (copy_decl_to_var): Copy DECL_BY_REFERENCE flag.
* g++.dg/guality/pr93888.C: New test.
---
gcc/ChangeLog
[committed] aarch64: Fix bf16_v(ld|st)n.c failures for big-endian
gcc.target/aarch64/advsimd-intrinsics/bf16_vldn.c and gcc.target/aarch64/advsimd-intrinsics/bf16_vstn.c were failing for big-endian targets because the in aarch64_be_ld1 and aarch64_be_st1 had no expansion for the bfloat16 modes. Tested on aarch64-linux-gnu and aarch64_be-elf, pushed. Richard 2020-03-17 Richard Sandiford gcc/ * config/aarch64/iterators.md (Vmtype): Handle V4BF and V8BF. --- gcc/config/aarch64/iterators.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/config/aarch64/iterators.md b/gcc/config/aarch64/iterators.md index 95fa3e4baa1..8e434389e59 100644 --- a/gcc/config/aarch64/iterators.md +++ b/gcc/config/aarch64/iterators.md @@ -1000,7 +1000,8 @@ (define_mode_attr Vmtype [(V8QI ".8b") (V16QI ".16b") (V4HI ".4h") (V8HI ".8h") (V2SI ".2s") (V4SI ".4s") (V2DI ".2d") (V4HF ".4h") -(V8HF ".8h") (V2SF ".2s") +(V8HF ".8h") (V4BF ".4h") +(V8BF ".8h") (V2SF ".2s") (V4SF ".4s") (V2DF ".2d") (DI "")(SI "") (HI "")(QI "")
[committed] testsuite: Fix gcc.target/aarch64/advsimd-intrinsics/bfcvt-nosimd.c
Tested on aarch64-linux-gnu and aarch64_be-elf, pushed.
Richard
2020-03-17 Richard Sandiford
gcc/testsuite/
* gcc.target/aarch64/advsimd-intrinsics/bfcvt-nosimd.c: Skip for
-fno-fat-lto-objects. Use tabs rather than spaces in the
check-function-bodies code.
---
.../gcc.target/aarch64/advsimd-intrinsics/bfcvt-nosimd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/bfcvt-nosimd.c
b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/bfcvt-nosimd.c
index 05c305840b6..a914680937d 100644
--- a/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/bfcvt-nosimd.c
+++ b/gcc/testsuite/gcc.target/aarch64/advsimd-intrinsics/bfcvt-nosimd.c
@@ -1,4 +1,5 @@
/* { dg-do assemble { target { aarch64*-*-* } } } */
+/* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } } */
/* { dg-require-effective-target aarch64_asm_bf16_ok } */
/* { dg-additional-options "-save-temps -march=armv8.2-a+bf16+nosimd" } */
/* { dg-final { check-function-bodies "**" "" {-O[^0]} } } */
@@ -7,8 +8,8 @@
/*
**test_bfcvt:
-** bfcvt h0, s0
-** ret
+** bfcvt h0, s0
+** ret
*/
bfloat16_t test_bfcvt (float32_t a)
{
[PATCH] testsuite: Tweak check-function-bodies interface
In g:2171a9207f51bc486ed9c502cb4da706f594615e I'd tried to fix various ILP32 testsuite failures by restricting some tests to LP64. Unfortunately, I messed up the check-function-bodies syntax and passed the target selector as the "option" parameter, which had the effect of disabling the tests for both ILP32 and LP64. "Oops." The fix ought to have been to add "" as the option parameter. However, check-function-bodies wasn't treating "" in the same way as an omitted argument. The easiest fix seemed to be turn the argument into a list of options, which also makes the interface a bit more general. Having done that, it seemed a good idea to check for things that look like target/xfail selectors, so that the mistake isn't silent next time. Tested on aarch64-linux-gnu and aarch64_be-elf. OK to install? Richard 2020-03-17 Richard Sandiford gcc/ * doc/sourcebuild.texi (check-function-bodies): Treat the third parameter as a list of option regexps and require each regexp to match. gcc/testsuite/ * lib/scanasm.exp (check-function-bodies): Treat the third parameter as a list of option regexps and require each regexp to match. Check for cases in which a target/xfail selector was mistakenly passed to the options argument. * gcc.target/aarch64/sve/pcs/args_1.c: Add an empty options list to the invocation of check-function-bodies. * gcc.target/aarch64/sve/pcs/args_2.c: Likewise. * gcc.target/aarch64/sve/pcs/args_3.c: Likewise. * gcc.target/aarch64/sve/pcs/args_4.c: Likewise. * gcc.target/aarch64/sve/pcs/return_1.c: Likewise. * gcc.target/aarch64/sve/pcs/return_1_1024.c: Likewise. * gcc.target/aarch64/sve/pcs/return_1_128.c: Likewise. * gcc.target/aarch64/sve/pcs/return_1_2048.c: Likewise. * gcc.target/aarch64/sve/pcs/return_1_256.c: Likewise. * gcc.target/aarch64/sve/pcs/return_1_512.c: Likewise. * gcc.target/aarch64/sve/pcs/return_2.c: Likewise. * gcc.target/aarch64/sve/pcs/return_3.c: Likewise. * gcc.target/aarch64/sve/pcs/return_4.c: Likewise. * gcc.target/aarch64/sve/pcs/return_4_1024.c: Likewise. * gcc.target/aarch64/sve/pcs/return_4_128.c: Likewise. * gcc.target/aarch64/sve/pcs/return_4_2048.c: Likewise. * gcc.target/aarch64/sve/pcs/return_4_256.c: Likewise. * gcc.target/aarch64/sve/pcs/return_4_512.c: Likewise. * gcc.target/aarch64/sve/pcs/return_5.c: Likewise. * gcc.target/aarch64/sve/pcs/return_5_1024.c: Likewise. * gcc.target/aarch64/sve/pcs/return_5_128.c: Likewise. * gcc.target/aarch64/sve/pcs/return_5_2048.c: Likewise. * gcc.target/aarch64/sve/pcs/return_5_256.c: Likewise. * gcc.target/aarch64/sve/pcs/return_5_512.c: Likewise. * gcc.target/aarch64/sve/pcs/return_6.c: Likewise. * gcc.target/aarch64/sve/pcs/return_6_1024.c: Likewise. * gcc.target/aarch64/sve/pcs/return_6_128.c: Likewise. * gcc.target/aarch64/sve/pcs/return_6_2048.c: Likewise. * gcc.target/aarch64/sve/pcs/return_6_256.c: Likewise. * gcc.target/aarch64/sve/pcs/return_6_512.c: Likewise. * gcc.target/aarch64/sve/pcs/saves_2_be_nowrap.c: Likewise. * gcc.target/aarch64/sve/pcs/saves_2_be_wrap.c: Likewise. * gcc.target/aarch64/sve/pcs/saves_2_le_nowrap.c: Likewise. * gcc.target/aarch64/sve/pcs/saves_2_le_wrap.c: Likewise. * gcc.target/aarch64/sve/pcs/saves_3.c: Likewise. * gcc.target/aarch64/sve/pcs/saves_4_be.c: Likewise. * gcc.target/aarch64/sve/pcs/saves_4_le.c: Likewise. * gcc.target/aarch64/sve/pcs/stack_clash_2_128.c: Likewise. * gcc.target/aarch64/sve/pcs/varargs_1.c: Likewise. * gcc.target/aarch64/sve/pcs/varargs_2_f16.c: Likewise. * gcc.target/aarch64/sve/pcs/varargs_2_f32.c: Likewise. * gcc.target/aarch64/sve/pcs/varargs_2_f64.c: Likewise. * gcc.target/aarch64/sve/pcs/varargs_2_s16.c: Likewise. * gcc.target/aarch64/sve/pcs/varargs_2_s32.c: Likewise. * gcc.target/aarch64/sve/pcs/varargs_2_s64.c: Likewise. * gcc.target/aarch64/sve/pcs/varargs_2_s8.c: Likewise. * gcc.target/aarch64/sve/pcs/varargs_2_u16.c: Likewise. * gcc.target/aarch64/sve/pcs/varargs_2_u32.c: Likewise. * gcc.target/aarch64/sve/pcs/varargs_2_u64.c: Likewise. * gcc.target/aarch64/sve/pcs/varargs_2_u8.c: Likewise. --- gcc/doc/sourcebuild.texi | 12 +++- .../gcc.target/aarch64/sve/pcs/args_1.c | 2 +- .../gcc.target/aarch64/sve/pcs/args_2.c | 2 +- .../gcc.target/aarch64/sve/pcs/args_3.c | 2 +- .../gcc.target/aarch64/sve/pcs/args_4.c | 2 +- .../gcc.target/aarch64/sve/pcs/return_1.c| 2 +- .../gcc.target/aarch64/sve/pcs/return_1_1024.c | 2 +- .../gcc.target/aarch64/sve/pcs/return_1_128.c| 2 +- .../gcc.target/aarch64/sve
Re: [PATCH] c++: Fix access checking for __is_assignable and __is_constructible (c++/94197)
On 3/17/20 11:25 AM, Ville Voutilainen wrote:
On Tue, 17 Mar 2020 at 16:52, Ville Voutilainen
wrote:
On Tue, 17 Mar 2020 at 16:42, Jason Merrill wrote:
On 3/17/20 9:04 AM, Jonathan Wakely wrote:
On 17/03/20 13:02 +, Jonathan Wakely wrote:
Shouldn't the test use { dg-do compile { target c++11 } } instead of:
+// { dg-do compile }
+// { dg-options "-std=c++11" }
Yes, good point.
Ack, changing to { dg-do compile { target c++11 } } and committing
with the (correct :P) expectation that
the change is still ok with that change.
Jason, are backports ok too?
Yes.
Jason
Re: [PATCH] c++: Diagnose a deduction guide in a wrong scope [PR91759]
On 3/17/20 4:49 AM, Jakub Jelinek wrote:
Hi!
The following testcase is accepts-invalid since r7-6608-ga56c0ac08242269b.
Before that change we had this
"deduction guide %qD must be declared in the same scope as %qT"
diagnostics for it, after the change it is expected to be diagnosed
in set_decl_namespace at the not_found: label in there. On this testcase
nothing is diagnosed though, because set_decl_namespace isn't called at all,
as in_namespace is NULL.
The following patch restores the old warning but does it only in case we
don't call set_decl_namespace.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or do you prefer something different?
How about always diagnosing this here, and moving the deduction guide
code in grokfndecl up above set_decl_namespace to avoid a duplicate
diagnostic?
2020-03-17 Jakub Jelinek
PR c++/91759
* decl.c (grokfndecl): Restore old diagnostics about deduction
guide declared in different scope if in_namespace is NULL_TREE.
* g++.dg/cpp1z/class-deduction72.C: New test.
--- gcc/cp/decl.c.jj2020-03-12 08:26:23.0 +0100
+++ gcc/cp/decl.c 2020-03-16 16:25:02.142867924 +0100
@@ -9644,6 +9644,15 @@ grokfndecl (tree ctype,
"namespace scope", decl);
return NULL_TREE;
}
+ tree type = TREE_TYPE (DECL_NAME (decl));
+ if (in_namespace == NULL_TREE
+ && CP_DECL_CONTEXT (decl) != CP_TYPE_CONTEXT (type))
+ {
+ error_at (location, "deduction guide %qD must be declared in the "
+ "same scope as %qT", decl, type);
+ inform (location_of (type), " declared here");
+ return NULL_TREE;
+ }
if (funcdef_flag)
error_at (location,
"deduction guide %qD must not have a function body", decl);
--- gcc/testsuite/g++.dg/cpp1z/class-deduction72.C.jj 2020-03-16
16:27:03.997068510 +0100
+++ gcc/testsuite/g++.dg/cpp1z/class-deduction72.C 2020-03-16
16:28:21.241927835 +0100
@@ -0,0 +1,11 @@
+// PR c++/91759
+// { dg-do compile { target c++17 } }
+
+namespace N {
+ template
+ struct X{ X(int); }; // { dg-message "declared here" }
+}
+
+using N::X;
+
+X(int) -> X; // { dg-error "must be declared in the same scope as" }
Jakub
Re: [PATCH v3] c++: Fix parsing of invalid enum specifiers [PR90995]
On 3/17/20 4:28 AM, Jakub Jelinek wrote:
On Mon, Mar 16, 2020 at 06:01:25PM -0400, Jason Merrill wrote:
- type = NULL_TREE;
- goto out;
+ error_at (cp_lexer_peek_token (parser->lexer)->location,
+ "expected %<;%> or %<{%>");
+ return NULL_TREE;
Hmm, what happens if we commit_to_tentative_parse before the cp_parser_error
if has_underlying_type? That would also get us a diagnostic in this case
even in enclosing tentative context.
And yes, I think returning error_mark_node seems appropriate; this is an
enum-specifier, just an ill-formed one.
Seems to work too. Bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
OK, thanks.
2020-03-17 Jakub Jelinek
PR c++/90995
* parser.c (cp_parser_enum_specifier): Use temp_override for
parser->colon_corrects_to_scope_p, replace goto out with return.
If scoped enum or enum with underlying type is not followed by
{ or ;, call cp_parser_commit_to_tentative_parse before calling
cp_parser_error and make sure to return error_mark_node instead of
NULL_TREE. Formatting fixes.
* g++.dg/cpp0x/enum40.C: New test.
--- gcc/cp/parser.c.jj 2020-03-14 08:14:47.125740994 +0100
+++ gcc/cp/parser.c 2020-03-17 07:57:19.195642249 +0100
@@ -19001,9 +19001,7 @@ cp_parser_enum_specifier (cp_parser* par
bool is_unnamed = false;
tree underlying_type = NULL_TREE;
cp_token *type_start_token = NULL;
- bool saved_colon_corrects_to_scope_p = parser->colon_corrects_to_scope_p;
-
- parser->colon_corrects_to_scope_p = false;
+ temp_override cleanup (parser->colon_corrects_to_scope_p, false);
/* Parse tentatively so that we can back up if we don't find a
enum-specifier. */
@@ -19043,24 +19041,24 @@ cp_parser_enum_specifier (cp_parser* par
push_deferring_access_checks (dk_no_check);
nested_name_specifier
- = cp_parser_nested_name_specifier_opt (parser,
-/*typename_keyword_p=*/true,
-/*check_dependency_p=*/false,
-/*type_p=*/false,
-/*is_declaration=*/false);
+= cp_parser_nested_name_specifier_opt (parser,
+ /*typename_keyword_p=*/true,
+ /*check_dependency_p=*/false,
+ /*type_p=*/false,
+ /*is_declaration=*/false);
if (nested_name_specifier)
{
tree name;
identifier = cp_parser_identifier (parser);
- name = cp_parser_lookup_name (parser, identifier,
-enum_type,
-/*is_template=*/false,
-/*is_namespace=*/false,
-/*check_dependency=*/true,
-/*ambiguous_decls=*/NULL,
-input_location);
+ name = cp_parser_lookup_name (parser, identifier,
+ enum_type,
+ /*is_template=*/false,
+ /*is_namespace=*/false,
+ /*check_dependency=*/true,
+ /*ambiguous_decls=*/NULL,
+ input_location);
if (name && name != error_mark_node)
{
type = TREE_TYPE (name);
@@ -19140,23 +19138,21 @@ cp_parser_enum_specifier (cp_parser* par
{
if (cxx_dialect < cxx11 || (!scoped_enum_p && !underlying_type))
{
+ if (has_underlying_type)
+ cp_parser_commit_to_tentative_parse (parser);
cp_parser_error (parser, "expected %<{%>");
if (has_underlying_type)
- {
- type = NULL_TREE;
- goto out;
- }
+ return error_mark_node;
}
/* An opaque-enum-specifier must have a ';' here. */
if ((scoped_enum_p || underlying_type)
&& cp_lexer_next_token_is_not (parser->lexer, CPP_SEMICOLON))
{
+ if (has_underlying_type)
+ cp_parser_commit_to_tentative_parse (parser);
cp_parser_error (parser, "expected %<;%> or %<{%>");
if (has_underlying_type)
- {
- type = NULL_TREE;
- goto out;
- }
+ return error_mark_node;
}
}
@@ -19172,9 +19168,7 @@ cp_parser_enum_specifier (cp_parser* par
push_scope (nested_name_specifier);
}
else if (TREE_CODE (nested_name_specifier) == NAMESPACE_DECL)
- {
- push_nested_namespace (nested_name_specifier);
- }
+ push_nested_namespace (nested_name_specifier);
}
/* Issue an error message if type-
Re: [PATCH v2] c++: Fix wrong no post-decrement operator error in template [PR94190]
On 3/16/20 10:01 PM, Marek Polacek wrote:
On Mon, Mar 16, 2020 at 05:12:15PM -0400, Jason Merrill wrote:
On 3/16/20 10:57 AM, Marek Polacek wrote:
Now that convert_like creates an IMPLICIT_CONV_EXPR when it converts
something that involves a class in a template, we must be prepared to
handle it. In this test, we have a class S and we're converting it
to long int& using a user-defined conversion since we're performing
-- on it. So cp_build_unary_op/POSTDECREMENT_EXPR calls
build_expr_type_conversion which gets the IMPLICIT_CONV_EXPR. Before
the convert_like change it got *S::operator long int &(&b) whose type
is long int but now it gets IMPLICIT_CONV_EXPR(b) whose type
is a reference type.
So you need to make sure that your IMPLICIT_CONV_EXPR gets
convert_from_reference'd at some point.
Perhaps like the following?
Bootstrapped/regtested on x86_64-linux, built Boost/cmcstl2.
-- >8 --
Now that convert_like creates an IMPLICIT_CONV_EXPR when it converts
something that involves a class in a template, we must be prepared to
handle it. In this test, we have a class S and we're converting it
to long int& using a user-defined conversion since we're performing
-- on it. So cp_build_unary_op/POSTDECREMENT_EXPR calls
build_expr_type_conversion which gets the IMPLICIT_CONV_EXPR. Before
the convert_like change it got *S::operator long int &(&b) whose type
is long int but now it gets IMPLICIT_CONV_EXPR(b) whose type
is a reference type. But the !MAYBE_CLASS_TYPE_P switch doesn't handle
reference types and so we complain.
Fixed by calling convert_from_reference on the result of convert_like.
PR c++/94190 - wrong no post-decrement operator error in template.
* call.c (build_new_op_1): Use convert_from_reference on the result
of convert_like.
The result of convert_like should already be dereferenced in this case.
I think convert_like should only return a bare reference for
ck_ref_bind, where we're explicitly requesting one.
* g++.dg/conversion/op7.C: New test.
---
gcc/cp/call.c | 3 +++
gcc/testsuite/g++.dg/conversion/op7.C | 22 ++
2 files changed, 25 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/conversion/op7.C
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 1715acc0ec3..d8b28573b95 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6426,6 +6426,7 @@ build_new_op_1 (const op_location_t &loc, enum tree_code
code, int flags,
{
conv = strip_standard_conversion (conv);
arg1 = convert_like (conv, arg1, complain);
+ arg1 = convert_from_reference (arg1);
}
if (arg2)
@@ -6435,6 +6436,7 @@ build_new_op_1 (const op_location_t &loc, enum tree_code
code, int flags,
{
conv = strip_standard_conversion (conv);
arg2 = convert_like (conv, arg2, complain);
+ arg2 = convert_from_reference (arg2);
}
}
@@ -6445,6 +6447,7 @@ build_new_op_1 (const op_location_t &loc, enum tree_code code, int flags,
{
conv = strip_standard_conversion (conv);
arg3 = convert_like (conv, arg3, complain);
+ arg3 = convert_from_reference (arg3);
}
}
}
diff --git a/gcc/testsuite/g++.dg/conversion/op7.C
b/gcc/testsuite/g++.dg/conversion/op7.C
new file mode 100644
index 000..c6401d109b4
--- /dev/null
+++ b/gcc/testsuite/g++.dg/conversion/op7.C
@@ -0,0 +1,22 @@
+// PR c++/94190 - wrong no post-decrement operator error in template.
+
+struct S { operator long & (); } b;
+
+template void
+foo ()
+{
+ b--;
+ ++b;
+ --b;
+ b++;
+ !b;
+ ~b;
+ +b;
+ -b;
+}
+
+void
+bar ()
+{
+ foo<0> ();
+}
base-commit: 2691ffe6dbaffb704593dd6220178c28848b3855
Re: [PATCH] Add C++2a wait/notify_one/notify_all support to std::atomic<>
Updated patch attached, addresses some minor issues I found after
sending the original version.
>From 0c677da72a058e37d0ea1975dc70e53c4308963c Mon Sep 17 00:00:00 2001
From: Thomas Rodgers
Date: Thu, 12 Mar 2020 17:50:09 -0700
Subject: [PATCH] Add C++2a wait/notify_one/notify_all support to std::atomic<>
This patch adds support for wait/notify_one/notify_all to std::atomic<>.
Support for the volatile overloads will be added in a subsequent patch.
* include/Makefile.am (bits_headers): Add new header.
* include/Mamefile.in: Regenerate.
* include/bits/atomic_base.h (__atomic_base<_Itp>:wait): Define.
(__atomic_base<_Itp>::notify_one): Likewise.
(__atomic_base<_Itp>::notify_all): Likewise.
(__atomic_base<_Ptp*>::wait): Likewise.
(__atomic_base<_Ptp*>::notify_one): Likewise.
(__atomic_base<_Ptp*>::notify_all): Likewise.
(__atomic_impl::wait): Likewise.
(__atomic_impl::notify_one): Likewise.
(__atomic_impl::notify_all): Likewise.
(__atomic_float<_Fp>::wait): Likewise.
(__atomic_float<_Fp>::notify_one): Likewise.
(__atomic_float<_Fp>::notify_all): Likewise.
(__atomic_ref<_Tp>::wait): Likewise.
(__atomic_ref<_Tp>::notify_one): Likewise.
(__atomic_ref<_Tp>::notify_all): Likewise.
(atomic_wait<_Tp>): Likewise.
(atomic_wait_explicit<_Tp>): Likewise.
(atomic_notify_one<_Tp>): Likewise.
(atomic_notify_all<_Tp>): Likewise.
* include/bits/atomic_wait.h: New file.
* include/std/atomic (atomic::wait): Define.
(atomic::wait_one): Likewise.
(atomic::wait_all): Likewise.
(atomic<_Tp>::wait): Likewise.
(atomic<_Tp>::wait_one): Likewise.
(atomic<_Tp>::wait_all): Likewise.
(atomic<_Tp*>::wait): Likewise.
(atomic<_Tp*>::wait_one): Likewise.
(atomic<_Tp*>::wait_all): Likewise.
* testsuite/29_atomic/atomic/wait_notify/atomic_refs.cc: New test.
* testsuite/29_atomic/atomic/wait_notify/bool.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/integrals.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/floats.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/pointers.cc: Likewise.
* testsuite/29_atomic/atomic/wait_notify/generic.h: New File.
---
libstdc++-v3/include/Makefile.am | 1 +
libstdc++-v3/include/Makefile.in | 2 +
libstdc++-v3/include/bits/atomic_base.h | 178 ++-
libstdc++-v3/include/bits/atomic_wait.h | 295 ++
libstdc++-v3/include/std/atomic | 61
.../atomic/wait_notify/atomic_refs.cc | 103 ++
.../29_atomics/atomic/wait_notify/bool.cc | 57
.../29_atomics/atomic/wait_notify/floats.cc | 32 ++
.../29_atomics/atomic/wait_notify/generic.h | 88 ++
.../atomic/wait_notify/integrals.cc | 56
.../29_atomics/atomic/wait_notify/pointers.cc | 59
11 files changed, 931 insertions(+), 1 deletion(-)
create mode 100644 libstdc++-v3/include/bits/atomic_wait.h
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/atomic_refs.cc
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/bool.cc
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/floats.cc
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/generic.h
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/integrals.cc
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/pointers.cc
diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 80aeb3f8959..d195a721fd5 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -100,6 +100,7 @@ bits_headers = \
${bits_srcdir}/allocated_ptr.h \
${bits_srcdir}/allocator.h \
${bits_srcdir}/atomic_base.h \
+ ${bits_srcdir}/atomic_wait.h \
${bits_srcdir}/atomic_futex.h \
${bits_srcdir}/basic_ios.h \
${bits_srcdir}/basic_ios.tcc \
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index eb437ad8d8d..4faaac5fb8d 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -445,6 +445,7 @@ bits_headers = \
${bits_srcdir}/allocated_ptr.h \
${bits_srcdir}/allocator.h \
${bits_srcdir}/atomic_base.h \
+ ${bits_srcdir}/atomic_wait.h \
${bits_srcdir}/atomic_futex.h \
${bits_srcdir}/basic_ios.h \
${bits_srcdir}/basic_ios.tcc \
@@ -526,6 +527,7 @@ bits_headers = \
${bits_srcdir}/specfun.h \
${bits_srcdir}/sstream.tcc \
${bits_srcdir}/std_abs.h \
+ ${bits_srcdir}/std_condvar.h \
${bits_srcdir}/std_function.h \
${bits_srcdir}/std_mutex.h \
${bits_srcdir}/stl_algo.h \
diff --git a/libstdc++-v3/include/bits/atomic_base.h b/libstdc++-v3/include/bits/atomic_base.h
index 87fe0bd6000..b4fbe2c6eb3 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -37,6 +37,11 @@
#include
#include
+#if __cplusplus > 201703L
+#include
+#include
+#endif
+
#ifndef _GLIBCXX_ALWAYS_INLINE
#define _GLIBCXX_ALWAYS_INLINE inline __attribute__((__always_inline__))
#end
Re: [PATCH] d: Committed fix multiple definition error when using mixins and interfaces.
Hi Iain, > When generating thunks in the D front-end, they need not necesarily be > in the same compilation unit as the module where the target function is > declared. When this happens, don't make the thunk public. Later on > expand_thunk will be called with force_gimple_thunk=true, so the thunk > can never be made weak due to differing implementations between modules. > > Bootstrapped and tested on x86_64-linux-gnu, and committed to trunk. > > Regards > Iain. > --- > gcc/d/ChangeLog: > > PR d/92216 > * decl.cc (make_thunk): Don't set TREE_PUBLIC on thunks if the target > function is external to the current compilation. > > gcc/testsuite/ChangeLog: > > PR d/92216 > * gdc.dg/imports/pr92216.d: New. > * gdc.dg/pr92216.d: New test. this new testcase FAILs on 32-bit Solaris/SPARC and x86 (and, I suppose, on every non-64-bit target): +FAIL: gdc.dg/pr92216.d -O0 scan-assembler _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] +FAIL: gdc.dg/pr92216.d -O0 -frelease scan-assembler _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] +FAIL: gdc.dg/pr92216.d -O0 -frelease -g scan-assembler _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] +FAIL: gdc.dg/pr92216.d -O0 -g scan-assembler _DT16_D7imports7pr922161B8__mixin24getSMFZPv[: \\t\\n] Same at -O[1-3s]. While the 64-bit version contains the expected _DT16_D7imports7pr922161B8__mixin24getSMFZPv the 32-bit one has _DT8_D7imports7pr922161B8__mixin24getSMFZPv I can't tell for certain if it's enough to allow for those two variants or if more is needed. Btw., I noticed that binutils 2.34 c++filt -s dlang cannot demangle those symbols. Is this expected? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] c++: Diagnose a deduction guide in a wrong scope [PR91759]
On Tue, Mar 17, 2020 at 03:54:57PM -0400, Jason Merrill via Gcc-patches wrote:
> How about always diagnosing this here, and moving the deduction guide code
> in grokfndecl up above set_decl_namespace to avoid a duplicate diagnostic?
I've tried that as:
--- gcc/cp/decl.c.jj2020-03-16 22:56:46.787172869 +0100
+++ gcc/cp/decl.c 2020-03-17 21:29:17.812732717 +0100
@@ -9506,6 +9506,27 @@ grokfndecl (tree ctype,
inlinep &= ~8;
}
+ if (deduction_guide_p (decl))
+{
+ if (!DECL_NAMESPACE_SCOPE_P (decl))
+ {
+ error_at (location, "deduction guide %qD must be declared at "
+ "namespace scope", decl);
+ return NULL_TREE;
+ }
+ tree type = TREE_TYPE (DECL_NAME (decl));
+ if (CP_DECL_CONTEXT (decl) != CP_TYPE_CONTEXT (type))
+ {
+ error_at (location, "deduction guide %qD must be declared in the "
+ "same scope as %qT", decl, type);
+ inform (location_of (type), " declared here");
+ return NULL_TREE;
+ }
+ if (funcdef_flag)
+ error_at (location,
+ "deduction guide %qD must not have a function body", decl);
+}
+
/* If this decl has namespace scope, set that up. */
if (in_namespace)
set_decl_namespace (decl, in_namespace, friendp);
@@ -9636,20 +9657,8 @@ grokfndecl (tree ctype,
}
}
- if (deduction_guide_p (decl))
-{
- if (!DECL_NAMESPACE_SCOPE_P (decl))
- {
- error_at (location, "deduction guide %qD must be declared at "
- "namespace scope", decl);
- return NULL_TREE;
- }
- if (funcdef_flag)
- error_at (location,
- "deduction guide %qD must not have a function body", decl);
-}
- else if (IDENTIFIER_ANY_OP_P (DECL_NAME (decl))
- && !grok_op_properties (decl, /*complain=*/true))
+ if (IDENTIFIER_ANY_OP_P (DECL_NAME (decl))
+ && !grok_op_properties (decl, /*complain=*/true))
return NULL_TREE;
else if (UDLIT_OPER_P (DECL_NAME (decl)))
{
--- gcc/testsuite/g++.dg/cpp1z/class-deduction9.C.jj2020-01-12
11:54:37.126402652 +0100
+++ gcc/testsuite/g++.dg/cpp1z/class-deduction9.C 2020-03-17
21:29:53.842207083 +0100
@@ -10,7 +10,7 @@ namespace N {
}
template
-N::A(T) -> N::A; // { dg-error "should have been declared inside .N" }
+N::A(T) -> N::A; // { dg-error "must be declared in the same scope as"
}
namespace N {
template
--- gcc/testsuite/g++.dg/cpp1z/class-deduction72.C.jj 2020-03-17
21:26:00.566610331 +0100
+++ gcc/testsuite/g++.dg/cpp1z/class-deduction72.C 2020-03-17
21:26:00.566610331 +0100
@@ -0,0 +1,11 @@
+// PR c++/91759
+// { dg-do compile { target c++17 } }
+
+namespace N {
+ template
+ struct X{ X(int); }; // { dg-message "declared here" }
+}
+
+using N::X;
+
+X(int) -> X; // { dg-error "must be declared in the same scope as" }
but that fails with
Excess errors:
/usr/src/gcc/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:459:40:
error: deduction guide 'pair(_T1, _T2)-> std::pair<_T1, _T2>' must be declared
in the same scope as 'std::pair<_T1, _T2>'
/usr/src/gcc/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:1873:5:
error: deduction guide 'vector(_InputIterator, _InputIterator, _Allocator)->
std::vector<_ValT, _Allocator>' must be declared in the same scope as
'std::vector<_Tp, _Alloc>'
on various testcases.
I've tried next:
--- gcc/cp/decl.c.jj2020-03-16 22:56:46.787172869 +0100
+++ gcc/cp/decl.c 2020-03-17 22:00:13.897648589 +0100
@@ -9506,6 +9506,36 @@ grokfndecl (tree ctype,
inlinep &= ~8;
}
+ if (deduction_guide_p (decl))
+{
+ if (!DECL_NAMESPACE_SCOPE_P (decl))
+ {
+ error_at (location, "deduction guide %qD must be declared at "
+ "namespace scope", decl);
+ return NULL_TREE;
+ }
+ tree type = TREE_TYPE (DECL_NAME (decl));
+ tree ctx = NULL_TREE;
+ if (in_namespace)
+ ctx = ORIGINAL_NAMESPACE (in_namespace);
+ else if (!ctype)
+ ctx = current_decl_namespace ();
+ if (ctx)
+ ctx = FROB_CONTEXT (ctx);
+ if (SCOPE_FILE_SCOPE_P (ctx))
+ ctx = global_namespace;
+ if (CP_TYPE_CONTEXT (type) != ctx)
+ {
+ error_at (location, "deduction guide %qD must be declared in the "
+ "same scope as %qT", decl, type);
+ inform (location_of (type), " declared here");
+ return NULL_TREE;
+ }
+ if (funcdef_flag)
+ error_at (location,
+ "deduction guide %qD must not have a function body", decl);
+}
+
/* If this decl has namespace scope, set that up. */
if (in_namespace)
set_decl_namespace (decl, in_namespace, friendp);
@@ -9636,20 +9666,8 @@ grokfndecl (tree ctype,
}
}
- if (deduction_guide_p (decl))
-{
- if (!DECL_NAMESPACE_SCOPE_P (decl))
- {
- er
Re: [PATCH] c++: Fix constexpr evaluation of self-modifying CONSTRUCTORs [PR94066]
On 3/16/20 1:39 PM, Patrick Palka wrote:
In this PR, we are performing constexpr evaluation of a CONSTRUCTOR of type
union U which looks like
{.a=foo (&)}.
Since the function foo takes a reference to the CONSTRUCTOR we're building, it
could potentially modify the CONSTRUCTOR from under us. In particular since U
is a union, the evaluation of a's initializer could change the active member
from a to another member -- something which cxx_eval_bare_aggregate doesn't
expect to happen.
Upon further investigation, it turns out this issue is not limited to
constructors of UNION_TYPE and not limited to cxx_eval_bare_aggregate either.
For example, within cxx_eval_store_expression we may be evaluating an assignment
such as (this comes from the test pr94066-2.C):
((union U *) this)->a = TARGET_EXPR ;
I assume this is actually an INIT_EXPR, or we would have preevaluated
and not had this problem.
where evaluation of foo could change the active member of *this, which was set
earlier in cxx_eval_store_expression to 'a'. And if U is a RECORD_TYPE, then
evaluation of foo could add new fields to *this, thereby making stale the 'valp'
pointer to the target constructor_elt through which we're later assigning.
So in short, it seems that both cxx_eval_bare_aggregate and
cxx_eval_store_expression do not anticipate that a constructor_elt's initializer
could modify the underlying CONSTRUCTOR as a side-effect.
Oof. If this is well-formed, it's because initialization of a doesn't
actually start until the return statement of foo, so we're probably
wrong to create a CONSTRUCTOR to hold the value of 'a' before evaluating
foo. Perhaps init_subob_ctx shouldn't preemptively create a
CONSTRUCTOR, and similarly for the cxx_eval_store_expression !preeval code.
To fix this problem, this patch makes cxx_eval_bare_aggregate and
cxx_eval_store_expression recompute the pointer to the constructor_elt through
which we're assigning, after the initializer has been evaluated.
I am worried that the use of get_or_insert_ctor_field in cxx_eval_bare_aggregate
might introduce quadratic behavior where there wasn't before. I wonder if
there's a cheap heuristic we can use in cxx_eval_bare_aggregate to determine
whether "self-modification" took place, and in which case we could avoid calling
get_or_insert_ctor_field and do the fast thing we that we were doing before the
patch.
We could remember the (integer) index of the constructor element and
verify that our sub-ctors are still at those indices before doing a new
search.
Tested on x86_64-pc-linux-gnu, but a full bootstrap is in progress. Does this
look like the right approach?
gcc/cp/ChangeLog:
PR c++/94066
* constexpr.c (get_or_insert_ctor_field): Split out (while adding
handling for VECTOR_TYPEs) from ...
(cxx_eval_store_expression): ... here. Record the sequence of indexes
into INDEXES that yields the suboject we're assigning to. After
evaluating the initializer of the store expression, recompute valp using
INDEXES.
(cxx_eval_bare_aggregate): Use get_or_insert_ctor_field to recompute the
pointer to the constructor_elt we're assigning through after evaluating
each initializer.
gcc/testsuite/ChangeLog:
PR c++/94066
* g++.dg/cpp1y/pr94066.C: New test.
* g++.dg/cpp1y/pr94066-2.C: New test.
* g++.dg/cpp1y/pr94066-3.C: New test.
* g++.dg/cpp1y/pr94066-4.C: New test.
* g++.dg/cpp1y/pr94066-5.C: New test.
---
gcc/cp/constexpr.c | 184 +++--
gcc/testsuite/g++.dg/cpp1y/pr94066-2.C | 21 +++
gcc/testsuite/g++.dg/cpp1y/pr94066-3.C | 21 +++
gcc/testsuite/g++.dg/cpp1y/pr94066-4.C | 22 +++
gcc/testsuite/g++.dg/cpp1y/pr94066-5.C | 18 +++
gcc/testsuite/g++.dg/cpp1y/pr94066.C | 20 +++
6 files changed, 210 insertions(+), 76 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr94066-2.C
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr94066-3.C
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr94066-4.C
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr94066-5.C
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr94066.C
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 192face9a3a..9fcf9f33457 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3144,6 +3144,88 @@ find_array_ctor_elt (tree ary, tree dindex, bool insert)
return -1;
}
+/* Return a pointer to the constructor_elt of CTOR which matches INDEX. If no
+ matching constructor_elt exists, then add it to CTOR. Emit an appropriate
+ diagnostic if CTOR constructs a UNION_TYPE and adding INDEX would change the
+ active member of the union, unless QUIET is true. */
+
+static constructor_elt *
+get_or_insert_ctor_field (tree ctor, tree index,
+ bool quiet, bool *non_constant_p)
+{
+ tree type = TREE_TYPE (ctor);
+ if (TREE_CODE (type) == VECTOR_TYPE && index == NULL_TREE)
+
Re: [PATCH] c: Handle C_TYPE_INCOMPLETE_VARS even for ENUMERAL_TYPEs [PR94172]
On Tue, 17 Mar 2020, Jakub Jelinek via Gcc-patches wrote: > Hi! > > The following testcases ICE, because they contain extern variable > declarations with incomplete enum types that is later completed and after > that those variables are accessed. The ICEs are because the vars then may > have > incorrect DECL_MODE etc., e.g. in the first case the var has SImode > DECL_MODE (the guessed mode for the enum), but the enum then actually has > DImode because its enumerators don't fit into unsigned int. > > The following patch fixes it by using C_TYPE_INCOMPLETE_VARS not just on > incomplete struct/union types, but also incomplete enum types. > TYPE_VFIELD can't be used as it is TYPE_MIN_VALUE on ENUMERAL_TYPE, > thankfully TYPE_LANG_SLOT_1 has been used in the C FE only on > FUNCTION_TYPEs. > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [stage1][PATCH] optgen: make more sanity checks for enums.
On Tue, 17 Mar 2020, Martin Liška wrote: > Hi. > > The patch is about better sanity check in option generation script. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > Ready to be installed in stage1? OK. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] c++: Diagnose a deduction guide in a wrong scope [PR91759]
On 3/17/20 5:06 PM, Jakub Jelinek wrote:
On Tue, Mar 17, 2020 at 03:54:57PM -0400, Jason Merrill via Gcc-patches wrote:
How about always diagnosing this here, and moving the deduction guide code
in grokfndecl up above set_decl_namespace to avoid a duplicate diagnostic?
I've tried that as:
--- gcc/cp/decl.c.jj2020-03-16 22:56:46.787172869 +0100
+++ gcc/cp/decl.c 2020-03-17 21:29:17.812732717 +0100
@@ -9506,6 +9506,27 @@ grokfndecl (tree ctype,
inlinep &= ~8;
}
+ if (deduction_guide_p (decl))
+{
+ if (!DECL_NAMESPACE_SCOPE_P (decl))
+ {
+ error_at (location, "deduction guide %qD must be declared at "
+ "namespace scope", decl);
+ return NULL_TREE;
+ }
+ tree type = TREE_TYPE (DECL_NAME (decl));
+ if (CP_DECL_CONTEXT (decl) != CP_TYPE_CONTEXT (type))
+ {
+ error_at (location, "deduction guide %qD must be declared in the "
+ "same scope as %qT", decl, type);
+ inform (location_of (type), " declared here");
+ return NULL_TREE;
+ }
+ if (funcdef_flag)
+ error_at (location,
+ "deduction guide %qD must not have a function body", decl);
+}
+
/* If this decl has namespace scope, set that up. */
if (in_namespace)
set_decl_namespace (decl, in_namespace, friendp);
@@ -9636,20 +9657,8 @@ grokfndecl (tree ctype,
}
}
- if (deduction_guide_p (decl))
-{
- if (!DECL_NAMESPACE_SCOPE_P (decl))
- {
- error_at (location, "deduction guide %qD must be declared at "
- "namespace scope", decl);
- return NULL_TREE;
- }
- if (funcdef_flag)
- error_at (location,
- "deduction guide %qD must not have a function body", decl);
-}
- else if (IDENTIFIER_ANY_OP_P (DECL_NAME (decl))
- && !grok_op_properties (decl, /*complain=*/true))
+ if (IDENTIFIER_ANY_OP_P (DECL_NAME (decl))
+ && !grok_op_properties (decl, /*complain=*/true))
return NULL_TREE;
else if (UDLIT_OPER_P (DECL_NAME (decl)))
{
--- gcc/testsuite/g++.dg/cpp1z/class-deduction9.C.jj2020-01-12
11:54:37.126402652 +0100
+++ gcc/testsuite/g++.dg/cpp1z/class-deduction9.C 2020-03-17
21:29:53.842207083 +0100
@@ -10,7 +10,7 @@ namespace N {
}
template
-N::A(T) -> N::A; // { dg-error "should have been declared inside .N" }
+N::A(T) -> N::A; // { dg-error "must be declared in the same scope as" }
namespace N {
template
--- gcc/testsuite/g++.dg/cpp1z/class-deduction72.C.jj 2020-03-17
21:26:00.566610331 +0100
+++ gcc/testsuite/g++.dg/cpp1z/class-deduction72.C 2020-03-17
21:26:00.566610331 +0100
@@ -0,0 +1,11 @@
+// PR c++/91759
+// { dg-do compile { target c++17 } }
+
+namespace N {
+ template
+ struct X{ X(int); }; // { dg-message "declared here" }
+}
+
+using N::X;
+
+X(int) -> X; // { dg-error "must be declared in the same scope as" }
but that fails with
Excess errors:
/usr/src/gcc/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:459:40: error:
deduction guide 'pair(_T1, _T2)-> std::pair<_T1, _T2>' must be declared in the same
scope as 'std::pair<_T1, _T2>'
/usr/src/gcc/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:1873:5: error:
deduction guide 'vector(_InputIterator, _InputIterator, _Allocator)-> std::vector<_ValT,
_Allocator>' must be declared in the same scope as 'std::vector<_Tp, _Alloc>'
on various testcases.
I've tried next:
--- gcc/cp/decl.c.jj2020-03-16 22:56:46.787172869 +0100
+++ gcc/cp/decl.c 2020-03-17 22:00:13.897648589 +0100
@@ -9506,6 +9506,36 @@ grokfndecl (tree ctype,
inlinep &= ~8;
}
+ if (deduction_guide_p (decl))
+{
+ if (!DECL_NAMESPACE_SCOPE_P (decl))
+ {
+ error_at (location, "deduction guide %qD must be declared at "
+ "namespace scope", decl);
+ return NULL_TREE;
+ }
+ tree type = TREE_TYPE (DECL_NAME (decl));
+ tree ctx = NULL_TREE;
+ if (in_namespace)
+ ctx = ORIGINAL_NAMESPACE (in_namespace);
+ else if (!ctype)
+ ctx = current_decl_namespace ();
+ if (ctx)
+ ctx = FROB_CONTEXT (ctx);
+ if (SCOPE_FILE_SCOPE_P (ctx))
+ ctx = global_namespace;
+ if (CP_TYPE_CONTEXT (type) != ctx)
+ {
+ error_at (location, "deduction guide %qD must be declared in the "
+ "same scope as %qT", decl, type);
+ inform (location_of (type), " declared here");
+ return NULL_TREE;
+ }
+ if (funcdef_flag)
+ error_at (location,
+ "deduction guide %qD must not have a function body", decl);
+}
+
/* If this decl has namespace scope, set that up. */
if (in_namespace)
set_decl_namespace (decl, in_namespace, friendp);
@@ -9636,20 +9666,8 @@ grokfndecl (tree ctype,
}
}
- if (deduction_guide_p (decl))
-
Re: [PATCH] RISC-V: Using fmv.x.w/fmv.w.x rather than fmv.x.s/fmv.s.x
On Tue, 18 Feb 2020, Kito Cheng wrote: > - fmv.x.s/fmv.s.x renamed to fmv.x.w/fmv.w.x in the latest RISC-V ISA >manual. The new mnemonics have been supported by GAS for a little while now and the old ones have been retained, however this is still a change that breaks backwards compatibility. So I wonder if we shouldn't have an autoconf test included for this feature, and either resort to wiring GCC to keep using the old mnemonics or bail out at GCC compilation time if GAS is found not to handle the new ones. At the very least I think we ought to document the minimum version of binutils now required by GCC for RISC-V support. Maciej
Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot
On Fri, 28 Feb 2020, H.J. Lu wrote: > > > > However that hack has been actually made to address this very problem > > > > discussed with this submission, so why not simply sync our copy of > > > > libffi > > > > with the upstream version? Then we can decide if changing the hack into > > > > something cleaner is worth the hassle. > > > > > > I'd love to sync with upstream libffi. In fact, I have done it on my > > > users/hjl/cet/master > > > branch: > > > > > > https://gitlab.com/x86-gcc/gcc/-/commit/9090e840b8464ce0f684e305eb75ff4655d05deb > > I think we'd like to update as well, but isn't there an ABI change in libffi > > that has to be fixed first? > > Libffi 3.4 ABI was changed to support CET. But it isn't the first > time ABI change for libffi, Have we made any conclusions WRT the way to move forward with this stuff? Things remain broken and I'd prefer to get the issues off the plate while the stuff is hot, or at least mildly warm. I'm about to get distracted with other work. Maciej
[committed] testsuite: Fix g++.dg/debug/dwarf2/const2b.C target selector
2020-03-17 Uroš Bizjak
* g++.dg/debug/dwarf2/const2b.C (dg-do): Fix target selector.
Tested on x86_64-linux-gnu {,-m32}.
Uros.
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/const2b.C
b/gcc/testsuite/g++.dg/debug/dwarf2/const2b.C
index 3ad1c080945..681ad721dd7 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/const2b.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/const2b.C
@@ -1,4 +1,4 @@
-/* { dg-do compile { target i386*-*-* x86_64-*-* } } */
+/* { dg-do compile { target i?86-*-* x86_64-*-* } } */
/* { dg-options "-O -gdwarf-2 -dA -msse" } */
/* { dg-require-effective-target sse } */
/* { dg-final { scan-assembler "DW_AT_const_value" } } */
Re: [stage1][PATCH] optgen: make more sanity checks for enums.
On 3/17/20 9:46 AM, Martin Liška wrote:
Hi.
The patch is about better sanity check in option generation script.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed in stage1?
@@ -72,6 +72,19 @@ function opt_args(name, flags)
return flags
}
+# If FLAGS contains a "NAME(...argument...)" flag, return the value
+# of the argument. Print error message otherwise.
+function opt_args_non_empty(name, flags, description)
+{
+ args = opt_args(name, flags)
+ if (args == "")
+ {
+ print "Empty option argument '" name "' during parsing of: " flags >>
"/dev/stderr"
The script reports errors by emitting them as #error directives into
standard output (so they cause the build to fail). Should this new
routine do the same thing? (/dev/stderr is also not available on all
flavors of UNIX but I'm not sure how much that matters here.)
Martin
+ exit 1
+ }
+ return args
+}
Thanks,
Martin
gcc/ChangeLog:
2020-03-17 Martin Liska
* opt-functions.awk (opt_args_non_empty): New function.
* opt-read.awk: Use the function for various option arguments.
---
gcc/opt-functions.awk | 13 +
gcc/opt-read.awk | 10 +-
2 files changed, 18 insertions(+), 5 deletions(-)
Re: [PATCH][RFC] API extension for binutils (type of symbols).
> Hi.
>
> There's updated version of the patch.
> Changes from the previous version:
> - comment added to ld_plugin_symbol
> - new section renamed to ext_symtab
> - assert added for loop iterations in produce_symtab and
> produce_symtab_extension
Hi,
I hope this is last version of the patch.
>
> 2020-03-12 Martin Liska
>
> * lto-section-in.c: Add extension_symtab.
ext_symtab :)
> diff --git a/gcc/lto-section-in.c b/gcc/lto-section-in.c
> index c17dd69dbdd..78b015be696 100644
> --- a/gcc/lto-section-in.c
> +++ b/gcc/lto-section-in.c
> @@ -54,7 +54,8 @@ const char *lto_section_name[LTO_N_SECTION_TYPES] =
>"mode_table",
>"hsa",
>"lto",
> - "ipa_sra"
> + "ipa_sra",
> + "ext_symtab"
I would move ext_symtab next to symtab so the sections remains at least
bit reasonably ordered.
>
> +/* Write extension information for symbols (symbol type, section flags). */
> +
> +static void
> +write_symbol_extension_info (tree t)
> +{
> + unsigned char c;
Do we still use vertical whitespace after decls per GNU coding style?
> diff --git a/gcc/lto-streamer.h b/gcc/lto-streamer.h
> index 25bf6c468f7..4f82b439360 100644
> --- a/gcc/lto-streamer.h
> +++ b/gcc/lto-streamer.h
> @@ -236,6 +236,7 @@ enum lto_section_type
>LTO_section_ipa_hsa,
>LTO_section_lto,
>LTO_section_ipa_sra,
> + LTO_section_symtab_extension,
I guess symtab_ext to match the actual section name?
>LTO_N_SECTION_TYPES/* Must be last. */
> };
>
> diff --git a/include/lto-symtab.h b/include/lto-symtab.h
> index 0ce0de10121..47f0ff27df8 100644
> --- a/include/lto-symtab.h
> +++ b/include/lto-symtab.h
> @@ -38,4 +38,16 @@ enum gcc_plugin_symbol_visibility
> GCCPV_HIDDEN
>};
>
> +enum gcc_plugin_symbol_type
> +{
> + GCCST_UNKNOWN,
> + GCCST_FUNCTION,
> + GCCST_VARIABLE,
> +};
> +
> +enum gcc_plugin_symbol_section_flags
> +{
> + GCCSSS_BSS = 1
> +};
Probably comments here?
> +
> #endif /* GCC_LTO_SYMTAB_H */
> +/* Parse an entry of the IL symbol table. The data to be parsed is pointed
> + by P and the result is written in ENTRY. The slot number is stored in
> SLOT.
> + Returns the address of the next entry. */
> +
> +static char *
> +parse_table_entry_extension (char *p, struct ld_plugin_symbol *entry)
> +{
> + unsigned char t;
> + enum ld_plugin_symbol_type symbol_types[] =
> +{
> + LDST_UNKNOWN,
> + LDST_FUNCTION,
> + LDST_VARIABLE,
> +};
> +
> + t = *p;
> + check (t <= 3, LDPL_FATAL, "invalid symbol type found");
> + entry->symbol_type = symbol_types[t];
> + p++;
> + entry->section_flags = *p;
> + p++;
> +
> + return p;
> +}
I think we have chance to make some plan for future extensions without
introducing too many additional sections.
Currently there are 2 bytes per entry, while only 3 bits are actively
used of them. If we invent next flag to pass we can use unused bits
however we need a way to indicate to plugin that the bit is defined.
This could be done by a simple version byte at the beggining of
ext_symtab section which will be 0 now and once we define extra bits we
bump it up to 1.
It is not that important given that even empty file results in 2k LTO
object file, but I think it would be nicer in longer run.
> + /* This is for compatibility with older ABIs. */
Perhaps say here that this ABI defined only "int def;"
The patch look good to me. Thanks for the work!
Honza
> +#ifdef __BIG_ENDIAN__
> + char unused;
> + char section_flags;
> + char symbol_type;
> + char def;
> +#else
> + char def;
> + char symbol_type;
> + char section_flags;
> + char unused;
> +#endif
>int visibility;
>uint64_t size;
>char *comdat_key;
> @@ -123,6 +134,20 @@ enum ld_plugin_symbol_visibility
>LDPV_HIDDEN
> };
>
> +/* The type of the symbol. */
> +
> +enum ld_plugin_symbol_type
> +{
> + LDST_UNKNOWN,
> + LDST_FUNCTION,
> + LDST_VARIABLE,
> +};
> +
> +enum ld_plugin_symbol_section_flags
> +{
> + LDSSS_BSS = 1
> +};
> +
> /* How a symbol is resolved. */
>
> enum ld_plugin_symbol_resolution
> @@ -431,7 +456,9 @@ enum ld_plugin_tag
>LDPT_GET_INPUT_SECTION_ALIGNMENT = 29,
>LDPT_GET_INPUT_SECTION_SIZE = 30,
>LDPT_REGISTER_NEW_INPUT_HOOK = 31,
> - LDPT_GET_WRAP_SYMBOLS = 32
> + LDPT_GET_WRAP_SYMBOLS = 32,
> + LDPT_ADD_SYMBOLS_V2 = 33,
> + LDPT_GET_SYMBOLS_V4 = 34,
> };
>
> /* The plugin transfer vector. */
> --
> 2.25.1
>
[committed] libstdc++: Fix type-erasure in experimental::net::executor (PR 94203)
The _Tgt and _TgtImpl types that implement type-erasure didn't agree on
the virtual interface, so failed as soon as they were instantiated. With
Clang they failed even sooner. The interface was also dependent on
whether RTTI was enabled or not.
This patch fixes the broken virtual functions and makes the type work
without RTTI, by using a pointer to a specialization of a function
template (similar to the approaches in std::function and std::any).
The changes to the virtual functions would be an ABI change, except that
the previous code didn't even compile if instantiated. This is
experimental TS material anyway.
PR libstdc++/94203
* include/experimental/executor (executor::executor(Executor)): Call
make_shared directly instead of _M_create. Create _Tgt1 object.
(executor::executor(allocator_arg_t, const ProtoAlloc&, Executor)):
Call allocate_shared directly instead of _M_create. Create _Tgt2
object.
(executor::target_type): Add cast needed for new _Tgt interface.
(executor::target): Define when RTTI is disabled. Use _Tgt::_M_func.
(executor::_Tgt): Define the same interface whether RTTI is enabled or
not.
(executor::_Tgt::target_type, executor::_Tgt::target): Do not use
std::type_info in the interface.
(executor::_Tgt::_M_func): Add data member.
(executor::_TgtImpl): Replace with _Tgt1 and _Tgt2 class templates.
(executor::_Tgt1::_S_func): Define function to access target without
depending on RTTI.
(executor::_M_create): Remove.
(operator==, operator!=): Simplify comparisons for executor.
* include/experimental/socket (is_error_code_enum):
Define specialization before use.
* testsuite/experimental/net/executor/1.cc: New test.
Tested x86_64-linux, committed to master.
I plan to backport this to gcc-9 too.
commit 98f29f5638f73d8e55590eba8098a537ba746287
Author: Jonathan Wakely
Date: Wed Mar 18 00:23:39 2020 +
libstdc++: Fix type-erasure in experimental::net::executor (PR 94203)
The _Tgt and _TgtImpl types that implement type-erasure didn't agree on
the virtual interface, so failed as soon as they were instantiated. With
Clang they failed even sooner. The interface was also dependent on
whether RTTI was enabled or not.
This patch fixes the broken virtual functions and makes the type work
without RTTI, by using a pointer to a specialization of a function
template (similar to the approaches in std::function and std::any).
The changes to the virtual functions would be an ABI change, except that
the previous code didn't even compile if instantiated. This is
experimental TS material anyway.
PR libstdc++/94203
* include/experimental/executor (executor::executor(Executor)): Call
make_shared directly instead of _M_create. Create _Tgt1 object.
(executor::executor(allocator_arg_t, const ProtoAlloc&, Executor)):
Call allocate_shared directly instead of _M_create. Create _Tgt2
object.
(executor::target_type): Add cast needed for new _Tgt interface.
(executor::target): Define when RTTI is disabled. Use _Tgt::_M_func.
(executor::_Tgt): Define the same interface whether RTTI is enabled
or
not.
(executor::_Tgt::target_type, executor::_Tgt::target): Do not use
std::type_info in the interface.
(executor::_Tgt::_M_func): Add data member.
(executor::_TgtImpl): Replace with _Tgt1 and _Tgt2 class templates.
(executor::_Tgt1::_S_func): Define function to access target without
depending on RTTI.
(executor::_M_create): Remove.
(operator==, operator!=): Simplify comparisons for executor.
* include/experimental/socket (is_error_code_enum):
Define specialization before use.
* testsuite/experimental/net/executor/1.cc: New test.
diff --git a/libstdc++-v3/include/experimental/executor
b/libstdc++-v3/include/experimental/executor
index 6955ead6bf5..b5c6e18a19a 100644
--- a/libstdc++-v3/include/experimental/executor
+++ b/libstdc++-v3/include/experimental/executor
@@ -295,26 +295,22 @@ inline namespace v1
class executor;
bool
- operator==(const executor& __a, const executor& __b) noexcept;
+ operator==(const executor&, const executor&) noexcept;
bool
- operator==(const executor& __e, nullptr_t) noexcept;
+ operator==(const executor&, nullptr_t) noexcept;
- inline bool
- operator==(nullptr_t, const executor& __e) noexcept
- { return __e == nullptr; }
+ bool
+ operator==(nullptr_t, const executor&) noexcept;
- inline bool
- operator!=(const executor& __a, const executor& __b) noexcept
- { return !(__a == __b); }
+ bool
+ operator!=(const executor&, const executor&) noexcept;
- inline bool
- operator!=(const executor& _
Re: [PATCH v4] debug/93751 Generate DIEs for external variables with -g1
On 3/14/20 8:05 PM, Alexey Neyman wrote:
+ if (debug_info_level > DINFO_LEVEL_TERSE) {
{ goes on the next line.
It looks like you don't have commit access, so I committed the patch
with that change.
Thanks,
Jason
[PATCH] avoid using TYPE_SIZE unless it's constant [PR94131]
get_range_strlen() returns non-constant type sizes for VLAs that
the new get_range_strlen_dynamic() function isn't prepared to deal
with and ICEs. Extending the functions to deal with VLAs (and
other dynamically allocated objects) is on my list of things to
do for GCC 11. For GCC 10, the attached patch has both functions
fail when the size of an array isn't constant.
Martin
PR tree-optimization/94131 - ICE on printf with a VLA string and -fno-tree-ccp
gcc/testsuite/ChangeLog:
PR tree-optimization/94131
* gcc.dg/pr94131.c: New test.
gcc/ChangeLog:
PR tree-optimization/94131
* gimple-fold.c (get_range_strlen_tree): Fail for variable-length
types and decls.
* tree-ssa-strlen.c (get_range_strlen_dynamic): Avoid assuming
types have constant sizes.
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index fa7a396a361..c85b4f2662b 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -1372,7 +1372,9 @@ get_range_strlen_tree (tree arg, bitmap *visited, strlen_range_kind rkind,
/* Fail when the array bound is unknown or zero. */
val = TYPE_SIZE_UNIT (optype);
- if (!val || integer_zerop (val))
+ if (!val
+ || TREE_CODE (val) != INTEGER_CST
+ || integer_zerop (val))
return false;
val = fold_build2 (MINUS_EXPR, TREE_TYPE (val), val,
@@ -1406,7 +1408,9 @@ get_range_strlen_tree (tree arg, bitmap *visited, strlen_range_kind rkind,
/* Fail when the array bound is unknown or zero. */
val = TYPE_SIZE_UNIT (optype);
- if (!val || integer_zerop (val))
+ if (!val
+ || TREE_CODE (val) != INTEGER_CST
+ || integer_zerop (val))
return false;
val = fold_build2 (MINUS_EXPR, TREE_TYPE (val), val,
integer_one_node);
@@ -1442,7 +1446,9 @@ get_range_strlen_tree (tree arg, bitmap *visited, strlen_range_kind rkind,
/* Fail if the offset is out of bounds. Such accesses
should be diagnosed at some point. */
val = DECL_SIZE_UNIT (ref);
- if (!val || integer_zerop (val))
+ if (!val
+ || TREE_CODE (val) != INTEGER_CST
+ || integer_zerop (val))
return false;
poly_offset_int psiz = wi::to_offset (val);
diff --git a/gcc/testsuite/gcc.dg/pr84131.c b/gcc/testsuite/gcc.dg/pr84131.c
new file mode 100644
index 000..19de5685224
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr94131.c
@@ -0,0 +1,29 @@
+/* PR 94131 - ICE on printf with a VLA string and -fno-tree-ccp
+ -fno-tree-forwprop
+ { dg-do compile }
+ { dg-options "-O1 -fno-tree-ccp -fno-tree-forwprop" } */
+
+void rv1 (int n)
+{
+ char a[n];
+ __INTPTR_TYPE__ i = (__INTPTR_TYPE__ )&a[0];
+ i &= 3;
+
+ __builtin_memset (a, '\0', sizeof a);
+ __builtin_printf ("%s", i ? &a[0] : "");
+}
+
+
+void sink (void*);
+
+void rv2 (int n)
+{
+ char a[n];
+ __INTPTR_TYPE__ i = (__INTPTR_TYPE__)&a[0];
+ i &= 3;
+
+ __builtin_memset (a, '\0', sizeof a);
+ __builtin_printf ("%s", i ? &a[0] : "");
+
+ sink (a);
+}
diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 8815cdbc9ca..e1589f68806 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -1139,10 +1139,16 @@ get_range_strlen_dynamic (tree src, c_strlen_data *pdata, bitmap *visited,
{
tree basetype = TREE_TYPE (base);
tree size = TYPE_SIZE_UNIT (basetype);
- ++off; /* Increment for the terminating nul. */
- pdata->maxlen = fold_build2 (MINUS_EXPR, size_type_node, size,
- build_int_cst (size_type_node, off));
- pdata->maxbound = pdata->maxlen;
+ if (TREE_CODE (size) == INTEGER_CST)
+ {
+ ++off; /* Increment for the terminating nul. */
+ tree toffset = build_int_cst (size_type_node, off);
+ pdata->maxlen = fold_build2 (MINUS_EXPR, size_type_node, size,
+ toffset);
+ pdata->maxbound = pdata->maxlen;
+ }
+ else
+ pdata->maxlen = build_all_ones_cst (size_type_node);
}
else
pdata->maxlen = build_all_ones_cst (size_type_node);
答复: [PATCH PR94201] aarch64：ICE in tiny code model for ilp32
Thank you for your suggestions. Looks like I have pasted the wrong test case.
I'm sorry for that.
I have modified accordingly and changed to use the correct test now in my new
patch.
I have carried a full test, no new failure witnessed. Newly added test fail
without the patch and pass after applying the patch.
Attached please find the my new patch. Can you sponsor it if it's OK to go?
Thanks,
Duan bo
-邮件原件-
发件人: Richard Sandiford [mailto:richard.sandif...@arm.com]
发送时间: 2020年3月17日 18:30
收件人: duanbo (C)
抄送: gcc-patches@gcc.gnu.org
主题: Re: [PATCH PR94201] aarch64：ICE in tiny code model for ilp32
"duanbo (C)" writes:
> Hi
> The testcase pr78255.c triggers ice when testing GCC trunk on aarch64 with
> -mabi=ilp32 -fPIC.
> Case path: gcc/testsuite/gcc.target/aarch64/pr78255.c
>
> The ICE is caused by insufficient support for the tiny code model under ilp32
> mode with fPIC option, where a SI mode register might be used for the ldr
> instruction.
> However, current md pattern for UNSPEC_GOTTINYPIC only support DI mode
> register as its operator.
>
> A simple solution is to add the pattern in tiny code model to support ilp32
> mode.
> Attached please find the proposed patch.
> Newly add test fail without the patch and pass after applying the patch.
> Bootstrap and tested on aarch64 Linux platform. No new regression witnessed.
> Any suggestion?
Thanks for doing this. The patch looks good, but some minor comments below.
However, the test fails for me on aarch64-linux-gnu:
FAIL: gcc.target/aarch64/pr94201.c scan-assembler ldr w0, \\s+a
FAIL: gcc.target/aarch64/pr94201.c scan-assembler b\\s+bar
Could you double-check your set-up to make sure that it's running the testsuite
correctly? With scan-assembler tests, it can be useful to introduce a
deliberate typo and check that the test fails, then remove the typo and check
that the test passes.
You probably already know, but it's possible to run just the new test by adding:
RUNTESTFLAGS=aarch64.exp=pr94201.c
to the "make check-gcc" command line. The final patch still needs to be tested
against the full testsuite of course, but using RUNTESTFLAGS can save time
while developing the patch.
> diff --git a/gcc/config/aarch64/aarch64.c
> b/gcc/config/aarch64/aarch64.c index b0cbb6e2d55..c56ed733e19 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -2739,8 +2739,26 @@ aarch64_load_symref_appropriately (rtx dest, rtx imm,
>}
>
> case SYMBOL_TINY_GOT:
> - emit_insn (gen_ldr_got_tiny (dest, imm));
> - return;
> + {
> + rtx insn;
> + machine_mode mode = GET_MODE (dest);
> +
> + if (mode == ptr_mode)
> + {
> + if (mode == DImode)
> + insn = gen_ldr_got_tiny_di (dest, imm);
> + else
> + insn = gen_ldr_got_tiny_si (dest, imm);
> + }
With the .md change mentioned below, we can instead use:
if (mode == ptr_mode)
insn = gen_ldr_got_tiny (mode, dest, imm);
> + else
> + {
> + gcc_assert (mode == Pmode);
> + insn = gen_ldr_got_tiny_sidi (dest, imm);
> + }
> +
> + emit_insn (insn);
> + return;
> + }
>
> case SYMBOL_TINY_TLSIE:
>{
> diff --git a/gcc/config/aarch64/aarch64.md
> b/gcc/config/aarch64/aarch64.md index 7ad4e918578..debc6656670 100644
> --- a/gcc/config/aarch64/aarch64.md
> +++ b/gcc/config/aarch64/aarch64.md
> @@ -6766,13 +6766,23 @@
>[(set_attr "type" "load_4")]
> )
>
> -(define_insn "ldr_got_tiny"
> - [(set (match_operand:DI 0 "register_operand" "=r")
> - (unspec:DI [(match_operand:DI 1 "aarch64_valid_symref" "S")]
> -UNSPEC_GOTTINYPIC))]
> +(define_insn "ldr_got_tiny_"
Making this "@ldr_got_tiny_" creates a gen_ldr_got_tiny function that
takes the mode as the first argument. We can then use this function in the
aarch64.c code above.
> + [(set (match_operand:PTR 0 "register_operand" "=r")
> + (unspec:PTR [(match_operand:PTR 1 "aarch64_valid_symref" "S")]
> + UNSPEC_GOTTINYPIC))]
Very minor formatting issue, but: the usual style in the aarch64 port is to
indent the unspec name to the same column as the "[", like the original pattern
did.
>""
> - "ldr\\t%0, %L1"
> - [(set_attr "type" "load_8")]
> + "ldr\\t%0, %L1"
Pre-existing, not your fault, but: there only needs to be a single backslash
here.
> + [(set_attr "type" "load_")]
> +)
> +
> +(define_insn "ldr_got_tiny_sidi"
> + [(set (match_operand:DI 0 "register_operand" "=r")
> + (zero_extend:DI
> + (unspec:SI [(match_operand:DI 1 "aarch64_valid_symref" "S")]
> + UNSPEC_GOTTINYPIC)))]
Same unspec formatting comment as above. Also, the usual style in the aarch64
port is to indent the operand of something like (zero_extend by two extra
spaces, giving:
(define_insn "ldr_got_tiny_sidi"
[(set (match_operand:DI 0 "register_operand" "=r")
(zero_extend:DI
(unspec:SI [(match
