[PATCH] Fix up --enable-checking=fold (PR middle-end/89503)
Hi!
Some of the builtin folding sets TREE_NO_WARNING flags, which triggers as
--enable-checking=fold errors. I think we should allow setting of
TREE_NO_WARNING flag when folding, so this patch arranges that.
Tested on:
../configure --enable-languages=c,c++,fortran --enable-checking=fold
--disable-bootstrap
make -jN && make -jN -k check
No extra FAILs compared to normal regtest. Ok for trunk?
2019-03-01 Jakub Jelinek
PR middle-end/89503
* fold-const.c (fold_checksum_tree): Ignore TREE_NO_WARNING bit
on DECL_P and EXPR_P.
--- gcc/fold-const.c.jj 2019-02-21 00:01:05.714931643 +0100
+++ gcc/fold-const.c2019-02-27 12:27:38.749353680 +0100
@@ -12130,6 +12130,7 @@ fold_checksum_tree (const_tree expr, str
memcpy ((char *) , expr, tree_size (expr));
SET_DECL_ASSEMBLER_NAME ((tree), NULL);
buf.decl_with_vis.symtab_node = NULL;
+ buf.base.nowarning_flag = 0;
expr = (tree)
}
else if (TREE_CODE_CLASS (code) == tcc_type
@@ -12155,6 +12156,13 @@ fold_checksum_tree (const_tree expr, str
TYPE_CACHED_VALUES (tmp) = NULL;
}
}
+ else if (TREE_NO_WARNING (expr) && (DECL_P (expr) || EXPR_P (expr)))
+{
+ /* Allow TREE_NO_WARNING to be set. */
+ memcpy ((char *) , expr, tree_size (expr));
+ buf.base.nowarning_flag = 0;
+ expr = (tree)
+}
md5_process_bytes (expr, tree_size (expr), ctx);
if (CODE_CONTAINS_STRUCT (code, TS_TYPED))
fold_checksum_tree (TREE_TYPE (expr), ctx, ht);
Jakub
[PATCH PR89487]Avoid taking address of register variable in loop list
Hi, This patch fixes PR89487 by following comments in PR. It simply avoid checking runtime alias by versioning in loop distribution if address of register variable may need to be taken. One thing I am not sure is if we should avoid generating data reference in the first place: Creating dr for pc analyze_innermost: success. base_address: offset from base address: 0 constant offset from base address: 0 step: 0 base alignment: 8 base misalignment: 0 offset alignment: 128 step alignment: 128 base_object: pc Here 'pc' is the register variable. Bootstrap and test on x86_64, any comment? Thanks, bin 2019-02-28 Bin Cheng PR tree-optimization/89487 * tree-loop-distribution.c (has_nonaddressable_dataref_p): New. (create_rdg_vertices): Compute has_nonaddressable_dataref_p. (distribute_loop): Don't do runtime alias check if there is non- addressable data reference. * tree-ssa-loop-ivopts.c (may_be_nonaddressable_p): Check if VAR_DECL is a register variable. 2018-02-28 Bin Cheng PR tree-optimization/89487 * gcc/testsuite/gcc.dg/tree-ssa/pr89487.c: New test. pr89487-20190301.txt Description: Binary data
gotools patch committed: Double timeout
In PR 89406 the cmd/go tests are timing out after 10 minutes. Double the timeout to give them a better chance of completing. Bootstrapped and ran gotools tests on x86_64-pc-linux-gnu. Committed to mainline. Ian 2019-02-28 Ian Lance Taylor PR go/89406 * Makefile.am (GOTOOLS_TEST_TIMEOUT): Double. * Makefile.in: Regenerate. Index: Makefile.am === --- Makefile.am (revision 269299) +++ Makefile.am (working copy) @@ -141,7 +141,7 @@ uninstall-local: GOTESTFLAGS = # Number of seconds before tests time out. -GOTOOLS_TEST_TIMEOUT = 600 +GOTOOLS_TEST_TIMEOUT = 1200 # Run tests using the go tool, and frob the output to look like that # generated by DejaGNU. The main output of this is two files:
[PATCH] PR c/89524 - Ignore -Wno-error=
* opts.c: Ignore -Wno-error=.
---
gcc/opts.c | 5 -
gcc/testsuite/c-c++-common/pr89524.c | 7 +++
2 files changed, 11 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/c-c++-common/pr89524.c
diff --git a/gcc/opts.c b/gcc/opts.c
index 468abb16334..f9a490cc7c2 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -3079,7 +3079,10 @@ enable_warning_as_error (const char *arg, int value,
unsigned int lang_mask,
strcpy (new_option + 1, arg);
option_index = find_opt (new_option, lang_mask);
if (option_index == OPT_SPECIAL_unknown)
-error_at (loc, "-Werror=%s: no option -%s", arg, new_option);
+{
+ if (value)
+ error_at (loc, "-Werror=%s: no option -%s", arg, new_option);
+}
else if (!(cl_options[option_index].flags & CL_WARNING))
error_at (loc, "-Werror=%s: -%s is not an option that controls warnings",
arg, new_option);
diff --git a/gcc/testsuite/c-c++-common/pr89524.c
b/gcc/testsuite/c-c++-common/pr89524.c
new file mode 100644
index 000..71bf745f57d
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/pr89524.c
@@ -0,0 +1,7 @@
+/* PR c/89524 */
+/* { dg-options "-Werror -Wno-error=some-future-warning" } */
+
+int main(int argc, char **argv)
+{
+ return 0;
+}
--
2.21.0
libgo patch committed: Default to -O2 when using the go tool
This libgo patch changes the go tool to default to invoking gccgo with
-O2. That seems like the right default for people who choose to use
this toolchain. It can be overridden with the go tool's -gccgoflags
option. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 269298)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-66ac9466852d11e968f8fd2ad6ffc7386cee49e1
+d5e4595784fb744f5fa0e0f90e77de9b5448b793
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: libgo/go/cmd/go/internal/work/gccgo.go
===
--- libgo/go/cmd/go/internal/work/gccgo.go (revision 269196)
+++ libgo/go/cmd/go/internal/work/gccgo.go (working copy)
@@ -76,7 +76,7 @@ func (tools gccgoToolchain) gc(b *Builde
gcargs = append(gcargs,
"-fgo-relative-import-path="+p.Internal.LocalPrefix)
}
- args := str.StringList(tools.compiler(), "-c", gcargs, "-o", ofile,
forcedGccgoflags)
+ args := str.StringList(tools.compiler(), "-c", "-O2", gcargs, "-o",
ofile, forcedGccgoflags)
if importcfg != nil {
if b.gccSupportsFlag(args[:1], "-fgo-importcfg=/dev/null") {
if err := b.writeFile(objdir+"importcfg", importcfg);
err != nil {
Re: libgo patch committed: Run examples
On Thu, Feb 28, 2019 at 1:59 AM Rainer Orth
wrote:
>
> > On Thu, Feb 21, 2019 at 1:47 AM Andreas Schwab wrote:
> >>
> >> On Feb 20 2019, Ian Lance Taylor wrote:
> >>
> >> > if test x$hasoutput = xtrue; then
> >> > - echo ' {"'$n'", '$j', "'"$output"'",
> >> > '$unordered'},'
> >> > + echo ' {"'$n'", '$j', "'"$(cat example2.txt)"'", '$unordered'},'
> >>
> >> That still has a problematic echo with backslashes.
> >
> > How does this version look? Does it fix the problem?
>
> it does indeed: just tested on i386-pc-solaris2.11 and
> sparc-sun-solaris2.11 without issues.
Thanks. Committed to mainline.
Ian
[C++ PATCH] PR c++/88183 - ICE with .* fold-expression.
build_m_component_ref can't handle type-dependent operands, so let's use the
default case; tsubst_copy_and_build also uses build_x_binary_op for
substituting a DOTSTAR_EXPR.
Tested x86_64-pc-linux-gnu, applying to trunk.
* pt.c (fold_expression) [DOTSTAR_EXPR]: Remove special handling.
---
gcc/cp/pt.c | 2 --
gcc/cp/ChangeLog | 3 +++
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index d678e278078..7295839ebd2 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -11784,8 +11784,6 @@ fold_expression (tree t, tree left, tree right,
tsubst_flags_t complain)
{
case COMPOUND_EXPR:
return build_x_compound_expr (input_location, left, right, complain);
-case DOTSTAR_EXPR:
- return build_m_component_ref (left, right, complain);
default:
return build_x_binary_op (input_location, code,
left, TREE_CODE (left),
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 30cc1ce46b3..a86ffa3c33b 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,5 +1,8 @@
2019-02-28 Jason Merrill
+ PR c++/88183 - ICE with .* fold-expression.
+ * pt.c (fold_expression) [DOTSTAR_EXPR]: Remove special handling.
+
PR c++/86969 - ICE with constexpr if and recursive generic lambdas.
* class.c, lambda.c, pt.c: Revert earlier change.
* lambda.c (add_capture): Don't special-case capture of dependent
base-commit: 9b4cf3ba9e18c87adde90f3a7c7e1b770714a754
--
2.20.1
[C++ PATCH] * name-lookup.c (print_binding_level): Print this_entity.
I wanted this when messing with binding levels for 86969. This function is
only used interactively from the debugger, so it's safe to go in now.
---
gcc/cp/name-lookup.c | 2 ++
gcc/cp/ChangeLog | 4
2 files changed, 6 insertions(+)
diff --git a/gcc/cp/name-lookup.c b/gcc/cp/name-lookup.c
index 2e1b851341b..1ddcde26ef4 100644
--- a/gcc/cp/name-lookup.c
+++ b/gcc/cp/name-lookup.c
@@ -3589,6 +3589,8 @@ print_binding_level (cp_binding_level* lvl)
{
tree t;
int i = 0, len;
+ if (lvl->this_entity)
+print_node_brief (stderr, "entity=", lvl->this_entity, 1);
fprintf (stderr, " blocks=%p", (void *) lvl->blocks);
if (lvl->more_cleanups_ok)
fprintf (stderr, " more-cleanups-ok");
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index 8ad0f221efc..3124aa9e02f 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,7 @@
+2019-02-28 Jason Merrill
+
+ * name-lookup.c (print_binding_level): Print this_entity.
+
2019-02-27 Marek Polacek
PR c++/88857 - ICE with value-initialization of argument in template.
base-commit: 35e99d5d3bd98eb2e2cee5d94ba09b6166dbeab2
--
2.20.1
Re: [C++ PATCH] PR c++/86969 - ICE with constexpr if and recursive generic lambdas.
On Wed, Feb 27, 2019 at 4:54 PM Jason Merrill wrote:
>
> Immediately capturing a VLA means we need to create a dependent VLA capture
> type, and not in the context of the lambda op(), since trying to look up the
> instantiation of the op() while we're substituting into the capture list
> would crash. So I force TYPE_CONTEXT and the binding level out to the
> enclosing function before pushtag, avoid adding a TAG_DEFN, and instead
> force the type to be complete in tsubst_lambda_expr.
...or we could delay doing the special VLA handling until its type
becomes non-dependent, which is a lot simpler and less kludgey.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit eb6c46bbc819c27e1730c935248a23e3a6746a9b
Author: Jason Merrill
Date: Thu Feb 28 16:10:12 2019 -0500
PR c++/86969 - ICE with constexpr if and recursive generic lambdas.
* class.c, lambda.c, pt.c: Revert earlier change.
* lambda.c (add_capture): Don't special-case capture of dependent
VLA.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 830ede56af8..f44acfd62b5 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -7246,7 +7246,6 @@ finish_struct (tree t, tree attributes)
error ("trying to finish struct, but kicked out due to previous parse errors");
if (processing_template_decl && at_function_scope_p ()
- && TYPE_CONTEXT (t) == current_function_decl
/* Lambdas are defined by the LAMBDA_EXPR. */
&& !LAMBDA_TYPE_P (t))
add_stmt (build_min (TAG_DEFN, t));
diff --git a/gcc/cp/lambda.c b/gcc/cp/lambda.c
index c25df2fbc0e..e7f0fda65be 100644
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -479,31 +479,9 @@ static GTY(()) tree max_id;
an array of runtime length. */
static tree
-vla_capture_type (tree array_type, tree lambda)
+vla_capture_type (tree array_type)
{
- tree closure = LAMBDA_EXPR_CLOSURE (lambda);
- tree type = make_class_type (RECORD_TYPE);
- cp_binding_level *slev = current_binding_level;
- if (closure)
-{
- /* If we're already inside the lambda body, force the capture type out
- into the enclosing context, so we don't crash trying to instantiate
- the capture field in tsubst_lambda_expr. We won't have a TAG_DEFN
- from finish_struct in the enclosing context, which we work around in
- tsubst_lambda_expr. */
- TYPE_CONTEXT (type) = TYPE_CONTEXT (closure);
- cp_binding_level *b = current_binding_level;
- for (;; b = b->level_chain)
- if (b->this_entity == closure)
- {
- while (b->this_entity == closure)
- b = b->level_chain;
- break;
- }
- current_binding_level = b;
-}
- type = pushtag (make_anon_name (), type, ts_current);
- current_binding_level = slev;
+ tree type = xref_tag (record_type, make_anon_name (), ts_current, false);
xref_basetypes (type, NULL_TREE);
type = begin_class_definition (type);
if (!ptr_id)
@@ -549,7 +527,7 @@ add_capture (tree lambda, tree id, tree orig_init, bool by_reference_p,
if (type == error_mark_node)
return error_mark_node;
- if (array_of_runtime_bound_p (type))
+ if (!dependent_type_p (type) && array_of_runtime_bound_p (type))
{
vla = true;
if (!by_reference_p)
@@ -563,7 +541,7 @@ add_capture (tree lambda, tree id, tree orig_init, bool by_reference_p,
initializer = build_constructor_va (init_list_type_node, 2,
NULL_TREE, build_address (elt),
NULL_TREE, array_type_nelts (type));
- type = vla_capture_type (type, lambda);
+ type = vla_capture_type (type);
}
else if (!dependent_type_p (type)
&& variably_modified_type_p (type, NULL_TREE))
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 673ea8e2258..d678e278078 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -17989,10 +17989,6 @@ tsubst_lambda_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl)
if (PACK_EXPANSION_P (ofield))
ofield = PACK_EXPANSION_PATTERN (ofield);
tree field = tsubst_decl (ofield, args, complain);
- if (DECL_VLA_CAPTURE_P (ofield))
- /* The type of a VLA capture might not have a TAG_DEFN in the enclosing
- context, so complete it here. */
- complete_type (TREE_TYPE (field));
if (DECL_PACK_P (ofield) && !DECL_NORMAL_CAPTURE_P (ofield))
{
Re: [patch] Fix wrong code for boolean negation in condition at -O
On Fri, Mar 01, 2019 at 12:19:36AM +0100, Eric Botcazou wrote: > > I know Eric has committed a tweak here, but I view this magic handling as > > something meant for boolean types only (if it is correct at all and the > > right fix wouldn't be avoid the BIT_NOT_EXPR for the prec > 1 booleans, I > > believe the expansion of BIT_NOT_EXPR doesn't have any special case for > > BOOLEAN_TYPE). This patch just restores previous behavior for non-boolean > > types (basically inlines the first two cases from ssa_name_has_boolean_range > > while leaving the problematic third one out, normal integral types with > > just known value range of [0,1]). > > IMO you haven't justified why this is problematic in the BIT_NOT_EXPR case > and > not in the BIT_AND_EXPR case... The BIT_AND_EXPR case is clearly correct for all possible values. The code says that if the result of BIT_AND_EXPR is known to be a non-zero constant, and one or both of the BIT_AND_EXPR arguments have known value ranges [0,1] (or boolean or precision 1, not talking about those now), then that value with the [0,1] range actually had to be 1, otherwise BIT_AND_EXPR result would be 0. The BIT_NOT_EXPR case is different, ~0 is -1 and ~1 is -2. If an SSA_NAME has [0,1] range, then BIT_NOT_EXPR of that will be [-2,-1]. If value is one of those two, then with your today's patch the assumption will be correct, 1 or 0. If value is some other one, which should hopefully happen only in dead code that we haven't been able to optimize, then we'd replace different values though. Jakub
Re: [patch] Fix wrong code for boolean negation in condition at -O
> I know Eric has committed a tweak here, but I view this magic handling as > something meant for boolean types only (if it is correct at all and the > right fix wouldn't be avoid the BIT_NOT_EXPR for the prec > 1 booleans, I > believe the expansion of BIT_NOT_EXPR doesn't have any special case for > BOOLEAN_TYPE). This patch just restores previous behavior for non-boolean > types (basically inlines the first two cases from ssa_name_has_boolean_range > while leaving the problematic third one out, normal integral types with > just known value range of [0,1]). IMO you haven't justified why this is problematic in the BIT_NOT_EXPR case and not in the BIT_AND_EXPR case... -- Eric Botcazou
Re: [patch] Fix wrong code for boolean negation in condition at -O
On Mon, Feb 25, 2019 at 10:07:10AM +0100, Eric Botcazou wrote:
> 2019-02-25 Eric Botcazou
>
> * tree-ssa-dom.c (edge_info::derive_equivalences) : Fix
> and move around comment.
> : Likewise.
> : Add specific handling for boolean types.
This broke the following testcase, as mentioned in the PR we have
expected value of the BIT_NOT_EXPR -2 and because that is not zero, the
code assumed that it must be zero, when it actually must be ~-2, i.e. 1.
I know Eric has committed a tweak here, but I view this magic handling as
something meant for boolean types only (if it is correct at all and the
right fix wouldn't be avoid the BIT_NOT_EXPR for the prec > 1 booleans, I
believe the expansion of BIT_NOT_EXPR doesn't have any special case for
BOOLEAN_TYPE). This patch just restores previous behavior for non-boolean
types (basically inlines the first two cases from ssa_name_has_boolean_range
while leaving the problematic third one out, normal integral types with just
known value range of [0,1]).
2019-02-28 Jakub Jelinek
PR tree-optimization/89536
* tree-ssa-dom.c (edge_info::derive_equivalences) :
Don't use ssa_name_has_boolean_range here, check only for boolean type
or unsigned integral type with precision 1.
* gcc.c-torture/execute/pr89536.c: New test.
--- gcc/tree-ssa-dom.c.jj 2019-02-26 14:13:08.296824100 +0100
+++ gcc/tree-ssa-dom.c 2019-02-28 15:52:08.737369799 +0100
@@ -346,7 +346,14 @@ edge_info::derive_equivalences (tree nam
boolean types with precision > 1. */
if (code == BIT_NOT_EXPR
&& TREE_CODE (rhs) == SSA_NAME
- && ssa_name_has_boolean_range (rhs))
+ /* Don't call ssa_name_has_boolean_range here, that returns
+ true for the following condition, but also when VRP
+ determines [0, 1] range on anything else. BIT_NOT_EXPR
+ of such numbers is [-2, -1] or [-2U, -1U] though. */
+ && (TREE_CODE (TREE_TYPE (rhs)) == BOOLEAN_TYPE
+ || (INTEGRAL_TYPE_P (TREE_TYPE (rhs))
+ && TYPE_UNSIGNED (TREE_TYPE (rhs))
+ && TYPE_PRECISION (TREE_TYPE (rhs)) == 1)))
{
if (integer_zerop (value))
res = build_one_cst (TREE_TYPE (rhs));
--- gcc/testsuite/gcc.c-torture/execute/pr89536.c.jj2019-02-28
15:53:37.792924793 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr89536.c 2019-02-28
15:53:08.357402412 +0100
@@ -0,0 +1,14 @@
+/* PR tree-optimization/89536 */
+
+int a = 1;
+
+int
+main ()
+{
+ a = ~(a && 1);
+ if (a < -1)
+a = ~a;
+ if (!a)
+__builtin_abort ();
+ return 0;
+}
Jakub
Re: [patch] Fix wrong code for boolean negation in condition at -O
> > Given the new code for BIT_AND_EXPR in edge_info::derive_equivalences for
> > boolean types, I think that the same special treatment must be added for
> > boolean types in the BIT_NOT_EXPR case to preserve the 0-or-1-value
> > invariant.
> >
> > Bootstrapped/regtested on x86_64-suse-linux, OK for mainline and 8 branch?
>
> OK.
Thanks. However, as reported under PR tree-opt/89536, there is an annoying
oversight in the reasoning: the predicate to be used is not integer_zerop but
whether bit #0 is 0 or 1. I have applied the attached fixlet as obviously
more correct than the current code, but Jakub has a different opinion on the
whole change so this will probably be revisited in the near future.
PR tree-optimization/89536
* tree-ssa-dom.c (edge_info::derive_equivalences) : Test
only whether bit #0 of the value is 0 instead of the entire value.
* gcc.c-torture/execute/20190228-1.c: New test.
--
Eric Botcazou/* PR tree-optimization/89536 */
/* Testcase by Zhendong Su */
int a = 1;
int main (void)
{
a = ~(a && 1);
if (a < -1)
a = ~a;
if (!a)
__builtin_abort ();
return 0;
}
Index: tree-ssa-dom.c
===
--- tree-ssa-dom.c (revision 269211)
+++ tree-ssa-dom.c (working copy)
@@ -348,7 +348,7 @@ edge_info::derive_equivalences (tree nam
&& TREE_CODE (rhs) == SSA_NAME
&& ssa_name_has_boolean_range (rhs))
{
- if (integer_zerop (value))
+ if ((TREE_INT_CST_LOW (value) & 1) == 0)
res = build_one_cst (TREE_TYPE (rhs));
else
res = build_zero_cst (TREE_TYPE (rhs));
[C++ PATCH] Reject constexpr functions with function-try-block (PR c++/89513, take 2)
On Wed, Feb 27, 2019 at 06:48:13PM -0500, Jason Merrill wrote:
> > Or would you prefer to have P1002R1 implemented and thus make this perhaps a
> > pedwarn before cxx2a, similarly for the error on try block in the body and
> > tweak build_constexpr_constructor_member_initializers? I think constexpr
> > evaluation handles TRY_BLOCK already.
>
> That sounds better, yes.
Ok, here is an updated patch that does that.
Bootstrapped/regtested on x86_64-linux and i686-linux (98,11,14,17,2a in
both cases), ok for trunk?
2019-02-28 Jakub Jelinek
Implement P1002R1, Try-catch blocks in constexpr functions
PR c++/89513
* parser.c (cp_parser_ctor_initializer_opt_and_function_body):
Diagnose constexpr ctor or function with function-try-block with
pedwarn for c++17 and earlier. Formatting fix.
(cp_parser_try_block): Use pedwarn instead of error and only for
c++17 and earlier when try block appears in constexpr function.
* constexpr.c (build_constexpr_constructor_member_initializers):
Handle TRY_BLOCK here instead of erroring on it.
* g++.dg/cpp2a/constexpr-try1.C: New test.
* g++.dg/cpp2a/constexpr-try2.C: New test.
* g++.dg/cpp2a/constexpr-try3.C: New test.
* g++.dg/cpp2a/constexpr-try4.C: New test.
* g++.dg/cpp2a/constexpr-try5.C: New test.
* g++.dg/cpp0x/constexpr-ctor10.C: Don't expect error for C++2a.
--- gcc/cp/parser.c.jj 2019-02-28 08:14:58.240563115 +0100
+++ gcc/cp/parser.c 2019-02-28 09:37:21.498804731 +0100
@@ -22590,11 +22590,25 @@ cp_parser_ctor_initializer_opt_and_funct
bool in_function_try_block)
{
tree body, list;
- const bool check_body_p =
- DECL_CONSTRUCTOR_P (current_function_decl)
- && DECL_DECLARED_CONSTEXPR_P (current_function_decl);
+ const bool check_body_p
+ = (DECL_CONSTRUCTOR_P (current_function_decl)
+ && DECL_DECLARED_CONSTEXPR_P (current_function_decl));
tree last = NULL;
+ if (in_function_try_block
+ && DECL_DECLARED_CONSTEXPR_P (current_function_decl)
+ && cxx_dialect < cxx2a)
+{
+ if (DECL_CONSTRUCTOR_P (current_function_decl))
+ pedwarn (input_location, 0,
+"function-try-block body of % constructor only "
+"available with -std=c++2a or -std=gnu++2a");
+ else
+ pedwarn (input_location, 0,
+"function-try-block body of % function only "
+"available with -std=c++2a or -std=gnu++2a");
+}
+
/* Begin the function body. */
body = begin_function_body ();
/* Parse the optional ctor-initializer. */
@@ -25329,8 +25343,11 @@ cp_parser_try_block (cp_parser* parser)
cp_parser_require_keyword (parser, RID_TRY, RT_TRY);
if (parser->in_function_body
- && DECL_DECLARED_CONSTEXPR_P (current_function_decl))
-error ("% in % function");
+ && DECL_DECLARED_CONSTEXPR_P (current_function_decl)
+ && cxx_dialect < cxx2a)
+pedwarn (input_location, 0,
+"% in % function only "
+"available with -std=c++2a or -std=gnu++2a");
try_block = begin_try_block ();
cp_parser_compound_statement (parser, NULL, BCS_TRY_BLOCK, false);
--- gcc/cp/constexpr.c.jj 2019-02-27 15:49:26.946419095 +0100
+++ gcc/cp/constexpr.c 2019-02-28 10:07:48.219840527 +0100
@@ -601,6 +601,12 @@ build_constexpr_constructor_member_initi
gcc_unreachable ();
}
found:
+ if (TREE_CODE (body) == TRY_BLOCK)
+{
+ body = TREE_OPERAND (body, 0);
+ if (TREE_CODE (body) == BIND_EXPR)
+ body = BIND_EXPR_BODY (body);
+}
if (TREE_CODE (body) == CLEANUP_POINT_EXPR)
{
body = TREE_OPERAND (body, 0);
@@ -626,12 +632,6 @@ build_constexpr_constructor_member_initi
break;
}
}
- else if (TREE_CODE (body) == TRY_BLOCK)
-{
- error ("body of % constructor cannot be "
-"a function-try-block");
- return error_mark_node;
-}
else if (EXPR_P (body))
ok = build_data_member_initialization (body, );
else
--- gcc/testsuite/g++.dg/cpp2a/constexpr-try1.C.jj 2019-02-28
09:38:13.651949049 +0100
+++ gcc/testsuite/g++.dg/cpp2a/constexpr-try1.C 2019-02-28 10:15:15.301509905
+0100
@@ -0,0 +1,44 @@
+// PR c++/89513
+// { dg-do compile { target c++11 } }
+
+constexpr bool foo ()
+try { // { dg-error "function-try-block body of 'constexpr'
function only available with" "" { target c++17_down } }
+ return true;
+} catch (...) {// { dg-error "compound-statement in
'constexpr' function" "" { target c++11_only } }
+ return false;
+} // { dg-error "body of 'constexpr' function" "" {
target c++11_only } }
+
+constexpr bool bar ()
+try { // { dg-error "function-try-block body of 'constexpr'
function only available with" "" { target c++17_down } }
+ try {// { dg-error "'try' in
Re: PATCH for c++/87068, missing diagnostic with fallthrough statement
On Thu, Feb 28, 2019 at 05:16:14PM -0500, Marek Polacek wrote: > 2019-02-28 Marek Polacek > > PR c++/87068 - missing diagnostic with fallthrough statement. > * gimplify.c (expand_FALLTHROUGH_r): If IFN_FALLTHROUGH was found > at the end of a seq, save its location to walk_stmt_info. > (expand_FALLTHROUGH): Warn if IFN_FALLTHROUGH is at the end of > a switch. > > * c-c++-common/Wimplicit-fallthrough-37.c: New test. Ok, thanks. Jakub
Re: PATCH for c++/87068, missing diagnostic with fallthrough statement
On Thu, Aug 30, 2018 at 11:24:50PM +0200, Jakub Jelinek wrote:
> On Thu, Aug 30, 2018 at 05:17:03PM -0400, Marek Polacek wrote:
> > > 2018-08-23 Marek Polacek
> > >
> > > PR c++/87068
> > > * gimplify.c (expand_FALLTHROUGH_r): If IFN_FALLTHROUGH was found
> > > at the end of a seq, save its location to walk_stmt_info.
> > > (expand_FALLTHROUGH): Warn if IFN_FALLTHROUGH is at the end of
> > > a switch.
> > >
> > > * c-c++-common/Wimplicit-fallthrough-37.c: New test.
> > >
> > > diff --git gcc/gimplify.c gcc/gimplify.c
> > > index e35137aec2c..04c15016f18 100644
> > > --- gcc/gimplify.c
> > > +++ gcc/gimplify.c
> > > @@ -2231,7 +2231,7 @@ maybe_warn_implicit_fallthrough (gimple_seq seq)
> > >
> > > static tree
> > > expand_FALLTHROUGH_r (gimple_stmt_iterator *gsi_p, bool *handled_ops_p,
> > > - struct walk_stmt_info *)
> > > + struct walk_stmt_info *wi)
> > > {
> > >gimple *stmt = gsi_stmt (*gsi_p);
> > >
> > > @@ -2250,11 +2250,14 @@ expand_FALLTHROUGH_r (gimple_stmt_iterator
> > > *gsi_p, bool *handled_ops_p,
> > >if (gimple_call_internal_p (stmt, IFN_FALLTHROUGH))
> > > {
> > > gsi_remove (gsi_p, true);
> > > + location_t loc = gimple_location (stmt);
> > > if (gsi_end_p (*gsi_p))
> > > - return integer_zero_node;
> > > + {
> > > + wi->info =
> > > + return integer_zero_node;
>
> This looks incorrect. loc is an automatic variable in
> expand_FALLTHROUGH_r, you set wi->info to the address of that variable,
> then immediately return and then:
>
> > > @@ -2317,6 +2320,14 @@ expand_FALLTHROUGH (gimple_seq *seq_p)
> > >struct walk_stmt_info wi;
> > >memset (, 0, sizeof (wi));
> > >walk_gimple_seq_mod (seq_p, expand_FALLTHROUGH_r, NULL, );
> > > + if (wi.callback_result == integer_zero_node)
> > > +{
> > > + /* We've found [[fallthrough]]; at the end of a switch, which the
> > > C++
> > > + standard says is ill-formed; see [dcl.attr.fallthrough]. */
> > > + location_t *loc = static_cast(wi.info);
> > > + warning_at (*loc, 0, "attribute % not preceding "
>
> dereference it here, when the loc variable is no longer in scope.
> -fsanitize-use-after-scope should complain here...
>
> > > + "a case label or default label");
> > > +}
>
> If the only spot that ises wi->info is in these two new spots, can't you
> e.g. set in the expand_FALLTHROUGH function:
> location_t loc;
> wi.info = (void *)
> and then in expand_FALLTHROUGH_r do:
> *static_cast(wi.info) = gimple_location (stmt);
> ?
Sorry for the ridiculous delay and an embarassing thinko :(.
Here's an updated patch.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-02-28 Marek Polacek
PR c++/87068 - missing diagnostic with fallthrough statement.
* gimplify.c (expand_FALLTHROUGH_r): If IFN_FALLTHROUGH was found
at the end of a seq, save its location to walk_stmt_info.
(expand_FALLTHROUGH): Warn if IFN_FALLTHROUGH is at the end of
a switch.
* c-c++-common/Wimplicit-fallthrough-37.c: New test.
diff --git gcc/gimplify.c gcc/gimplify.c
index 7e37e500d81..983635ba21f 100644
--- gcc/gimplify.c
+++ gcc/gimplify.c
@@ -2263,7 +2263,7 @@ maybe_warn_implicit_fallthrough (gimple_seq seq)
static tree
expand_FALLTHROUGH_r (gimple_stmt_iterator *gsi_p, bool *handled_ops_p,
- struct walk_stmt_info *)
+ struct walk_stmt_info *wi)
{
gimple *stmt = gsi_stmt (*gsi_p);
@@ -2283,7 +2283,10 @@ expand_FALLTHROUGH_r (gimple_stmt_iterator *gsi_p, bool
*handled_ops_p,
{
gsi_remove (gsi_p, true);
if (gsi_end_p (*gsi_p))
- return integer_zero_node;
+ {
+ *static_cast(wi->info) = gimple_location (stmt);
+ return integer_zero_node;
+ }
bool found = false;
location_t loc = gimple_location (stmt);
@@ -2347,8 +2350,15 @@ static void
expand_FALLTHROUGH (gimple_seq *seq_p)
{
struct walk_stmt_info wi;
+ location_t loc;
memset (, 0, sizeof (wi));
+ wi.info = (void *)
walk_gimple_seq_mod (seq_p, expand_FALLTHROUGH_r, NULL, );
+ if (wi.callback_result == integer_zero_node)
+/* We've found [[fallthrough]]; at the end of a switch, which the C++
+ standard says is ill-formed; see [dcl.attr.fallthrough]. */
+warning_at (loc, 0, "attribute % not preceding "
+ "a case label or default label");
}
diff --git gcc/testsuite/c-c++-common/Wimplicit-fallthrough-37.c
gcc/testsuite/c-c++-common/Wimplicit-fallthrough-37.c
new file mode 100644
index 000..644003af47d
--- /dev/null
+++ gcc/testsuite/c-c++-common/Wimplicit-fallthrough-37.c
@@ -0,0 +1,13 @@
+/* PR c++/87068 */
+/* { dg-do compile } */
+
+void
+f (int n)
+{
+ switch (n)
+{
+case 4:
+ ++n;
+ __attribute__((fallthrough)); /* { dg-warning "not preceding" } */
+}
+}
[wwwdocs] Update gcc-9/changes.html #2
One more. Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v retrieving revision 1.48 diff -u -r1.48 changes.html --- changes.html28 Feb 2019 20:51:28 - 1.48 +++ changes.html28 Feb 2019 21:48:53 - @@ -191,6 +191,8 @@ std::move. https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wpessimizing-move;>-Wpessimizing-move, implied by -Wall, warns when a call to std::move prevents copy elision. +https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wclass-conversion;>-Wclass-conversion, on by default, warns when a conversion function will never be +called due to the type it converts to.
[PATCH] ARM cmpsi2_addneg fixes (PR target/89506)
Hi!
The following testcase ICEs on ARM, because the backend creates CONST_INTs
that aren't valid for SImode, in which they are used (0x8000 rather than
the canonical -0x8000). This is fixed by the 3 gen_int_mode calls
instead of just GEN_INT.
Once that is fixed, we ICE because if both the CONST_INTs are -0x8000,
then INTVAL (operands[2]) == -INTVAL (operands[3]) is no longer true and
thus cmpsi2_addneg doesn't match and no other pattern does.
Fixing that is pretty obvious thing to do as well, similarly to the recent
*subsi3_carryin_compare_const fix.
The next problem is that the result doesn't bootstrap. The problem is that
the instruction emitted for that -0x8000 immediate - adds reg, reg,
#-0x8000
actually doesn't do what the RTL pattern for it says.
The pattern is like subsi3_compare, except that the MINUS with
constant second argument is canonicalized as RTL normally does into PLUS of
the negated constant. The mode on the condition code register is CCmode,
so all Z, N, C and V bits should be valid, and the pattern is like that of
a cmp instruction, so the behavior vs. condition codes should be like cmp
instruction, which is what the subs instruction does. The adds r1, r2, #N
and subs r1, r2, #-N instructions actually behave the same most of the time.
The result is the same, Z and N flags are always the same as well. And,
it seems that for all N except for 0 and 0x8000 also the C and V bits
are the same (I've proved that by using the valgrind subs condition code
algorithm (which is the same as cmp) vs. valgrind adds condition code
algorithm (which is the same as cmn) and even emulated it using 8-bit x
8-bit exhaustive check). For 0 and 0x8000 it is different and as can be
seen by the bootstrap failure, it is significant.
Previously before the above change we got by by the pattern never triggering
by the combiner for 0x8000 (because the combiner would always try
canonical CONST_INTs for both and those don't have INTVAL == -INTVAL), but
it worked for the *compare_scc splitter/*negscc/*thumb2_negscc patterns
(which created invalid RTL and used adds rather than subs, but didn't care,
as it only tested the Z bit using ne condition).
My next attempt was just to switch the two alternatives, so that if
operands[2] matches both "I" and "L" constraints and we can choose, we'd
use subs. That cured the bootstrap failure, but introduced
+FAIL: gcc.target/arm/pr43920-2.c object-size text <= 54
+FAIL: gcc.target/arm/thumb2-cmpneg2add-2.c scan-assembler adds
regressions, in those 2 testcases neither the problematic 0 nor INT_MIN
is used, so both adds and subs are equivalent, but
- addsr2, r4, #1
+ subsr2, r4, #-1
results in larger code.
Note, I've seen the patch creating smaller code in some cases too,
when the combiner matched the cmpsi2_addneg pattern with INT_MIN and
previously emitted loading the constant into some register and performing
subs with 3 registers instead of 2 and immediate.
So, this is another alternative I'm proposing, just make sure we use
subs for #0 and #-2147483648 (where it is essential for correctness)
and for others keep previous behavior.
Ok for trunk?
Or is there an easy way to estimate if a constant satisfies both "I" and "L"
constraints at the same time and is not one of 0 and INT_MIN, which
of the two (positive or negated) would have smaller encoding and decide
based on that?
2019-02-28 Jakub Jelinek
PR target/89506
* config/arm/arm.md (cmpsi2_addneg): Use
trunc_int_for_mode (-INTVAL (...), SImode) instead of -INTVAL (...).
If operands[2] is 0 or INT_MIN, force use of subs.
(*compare_scc splitter): Use gen_int_mode.
(*negscc): Likewise.
* config/arm/thumb2.md (*thumb2_negscc): Likewise.
* gcc.dg/pr89506.c: New test.
--- gcc/config/arm/arm.md.jj2019-02-28 14:13:08.368267536 +0100
+++ gcc/config/arm/arm.md 2019-02-28 22:09:03.089588596 +0100
@@ -867,10 +867,21 @@ (define_insn "cmpsi2_addneg"
(set (match_operand:SI 0 "s_register_operand" "=r,r")
(plus:SI (match_dup 1)
(match_operand:SI 3 "arm_addimm_operand" "I,L")))]
- "TARGET_32BIT && INTVAL (operands[2]) == -INTVAL (operands[3])"
- "@
- adds%?\\t%0, %1, %3
- subs%?\\t%0, %1, #%n3"
+ "TARGET_32BIT
+ && (INTVAL (operands[2])
+ == trunc_int_for_mode (-INTVAL (operands[3]), SImode))"
+{
+ /* For 0 and INT_MIN it is essential that we use subs, as adds
+ will result in different condition codes (like cmn rather than
+ like cmp). For other immediates, we should choose whatever
+ will have smaller encoding. */
+ if (operands[2] == const0_rtx
+ || INTVAL (operands[2]) == -HOST_WIDE_INT_C (0x8000)
+ || which_alternative == 1)
+return "subs%?\\t%0, %1, #%n3";
+ else
+return "adds%?\\t%0, %1, %3";
+}
[(set_attr "conds" "set")
(set_attr "type" "alus_sreg")]
)
@@ -9302,7 +9313,7 @@ (define_split
(cond_exec (ne:CC
Re: [PR72741] Encode OpenACC 'routine' directive inside Fortran module files
On Thu, Feb 28, 2019 at 10:12:00PM +0100, Thomas Schwinge wrote: > On Wed, 15 Jun 2016 20:12:15 -0700, Cesar Philippidis > wrote: > The code changes now are actually very simple. The "problem" is that > we're incrementing the Fortran module version, 'MOD_VERSION', which > breaks binary compatibility with Fortran module files created with > earlier versions of GCC, which is something that is to be avoided, as > I've heard. Or, is it not that bad actually? It is bad and we certainly shouldn't change it on release branches. There are many ways to deal with it without bumping MOD_VERSION in a backwards but not forwards compatible way, so that a newer compiler will be able to parse old *.mod files, and newer compiler new ones as long as this problematic stuff doesn't appear in. Jakub
[PR72741] Encode OpenACC 'routine' directive inside Fortran module files
Hi!
On Wed, 15 Jun 2016 20:12:15 -0700, Cesar Philippidis
wrote:
> [...], this patch updates the way that
> the fortran FE handles the 'acc routine' attribute in modules. Before,
> it only recorded that a function was marked as an acc routine.
(By means of 'OMP_DECLARE_TARGET', that is.)
> With this
> patch, it now records the level of parallelism the routine has. This is
> necessary for the middle end to validate compatible parallelism between
> the loop calling the routine and the routine itself.
This patch has seen a bunch of further revisions later on. I've now
singled out the changes that are actually relevant for the feature under
discussion here, and added test cases that actually test what they
describe to be testing... ;-)
The code changes now are actually very simple. The "problem" is that
we're incrementing the Fortran module version, 'MOD_VERSION', which
breaks binary compatibility with Fortran module files created with
earlier versions of GCC, which is something that is to be avoided, as
I've heard. Or, is it not that bad actually?
We might be able to resolve this by encoding individual "bits" for the
'gang'/'worker'/'vector'/'seq' clauses, instead of using the values for
'enum oacc_routine_lop' via 'oacc_routine_lop_types'. The earlier
Fortran module files would simply not have these bits set, and could thus
still be read (given 'MOD_VERSION' not incremented). Would that be a
solution to this issue? (You'd then get a parse error when trying to use
with an older version of GCC any Fortran module files created with a
newer version, which seems OK?)
Or, an idea I just had (but not yet verified), guard the stream-out and
stream-in of 'attr->oacc_routine_lop' to just happen if '-fopenacc' is
active (or some such), which thus won't affect that majority of users.
Would that be a solution to this issue?
See attached, any comments?
And, can this still go into trunk now? (Rationale: I'd like to later fix
this issue on GCC release branches also, because this is quite a
limitation to usage. This will thus again bring up the 'MOD_VERSION'
issue.)
Grüße
Thomas
From f2c4627045e70a6f6c52914cf6334392aca75230 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Thu, 28 Feb 2019 17:45:13 +0100
Subject: [PATCH 1/2] [testsuite, Fortran] Provide 'dg-compile-aux-modules' in
'gfortran.dg/goacc/goacc.exp'
..., as yet another copy from 'gfortran.dg/dg.exp', which there are a few
already.
gcc/testsuite/
* gfortran.dg/goacc/goacc.exp (dg-compile-aux-modules): New proc.
---
gcc/testsuite/gfortran.dg/goacc/goacc.exp | 25 +++
1 file changed, 25 insertions(+)
diff --git a/gcc/testsuite/gfortran.dg/goacc/goacc.exp b/gcc/testsuite/gfortran.dg/goacc/goacc.exp
index f1adb186a1e4..409c5fe54003 100644
--- a/gcc/testsuite/gfortran.dg/goacc/goacc.exp
+++ b/gcc/testsuite/gfortran.dg/goacc/goacc.exp
@@ -28,6 +28,31 @@ if ![check_effective_target_fopenacc] {
# Initialize `dg'.
dg-init
+global gfortran_test_path
+global gfortran_aux_module_flags
+set gfortran_test_path $srcdir/$subdir
+set gfortran_aux_module_flags "-fopenacc"
+proc dg-compile-aux-modules { args } {
+global gfortran_test_path
+global gfortran_aux_module_flags
+if { [llength $args] != 2 } {
+ error "dg-set-target-env-var: needs one argument"
+ return
+}
+
+set level [info level]
+if { [info procs dg-save-unknown] != [list] } {
+ rename dg-save-unknown dg-save-unknown-level-$level
+}
+
+dg-test $gfortran_test_path/[lindex $args 1] "" $gfortran_aux_module_flags
+# cleanup-modules is intentionally not invoked here.
+
+if { [info procs dg-save-unknown-level-$level] != [list] } {
+ rename dg-save-unknown-level-$level dg-save-unknown
+}
+}
+
# Main loop.
gfortran-dg-runtest [lsort \
[find $srcdir/$subdir *.\[fF\]{,90,95,03,08} ] ] "" "-fopenacc"
--
2.17.1
From d947a297d224ced389abd7ad74d3519b4a0e8d32 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Thu, 28 Feb 2019 21:58:14 +0100
Subject: [PATCH 2/2] [PR72741] Encode OpenACC 'routine' directive inside
Fortran module files
gcc/fortran/
* gfortran.h (oacc_routine_lop_types): Declare.
* module.c (MOD_VERSION): Increment
(oacc_routine_lop): New DECL_MIO_NAME.
(mio_symbol_attribute): Set the oacc_routine_lop attribute.
* symbol.c (oacc_routine_lop_types): Define.
gcc/testsuite/
* gfortran.dg/goacc/routine-module-1.f90: New file.
* gfortran.dg/goacc/routine-module-2.f90: Likewise.
* gfortran.dg/goacc/routine-module-mod-1.f90: Likewise.
---
gcc/fortran/gfortran.h| 1 +
gcc/fortran/module.c | 6 +-
gcc/fortran/symbol.c | 12 +++
.../gfortran.dg/goacc/routine-module-1.f90| 47 +++
.../gfortran.dg/goacc/routine-module-2.f90| 31
.../goacc/routine-module-mod-1.f90| 79 +++
6 files changed, 175 insertions(+), 1 deletion(-)
create mode 100644
[wwwdocs] Update gcc-9/changes.html
Applied. Index: gcc-9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v retrieving revision 1.47 diff -u -r1.47 changes.html --- gcc-9/changes.html 28 Feb 2019 10:31:50 - 1.47 +++ gcc-9/changes.html 28 Feb 2019 20:51:01 - @@ -187,6 +187,10 @@ of std::initializer_list that are likely to result in a dangling pointer, such as returning or assigning from a temporary list. +https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wredundant-move;>-Wredundant-move, implied by -Wextra, warns about redundant calls to +std::move. +https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#index-Wpessimizing-move;>-Wpessimizing-move, implied by -Wall, warns when a call to +std::move prevents copy elision.
[PR72741, PR89433] Repeated use of the Fortran OpenACC 'routine' directive
Hi!
On Mon, 15 Aug 2016 18:54:49 -0700, Cesar Philippidis
wrote:
> [...]
>
> Note that besides for checking for multiple acc routine directives, this
> patch also handles the case where the optional name argument in 'acc
> routine (NAME)' is the name of the current procedure. This was a TODO
> item in gomp4.
> --- a/gcc/fortran/openmp.c
> +++ b/gcc/fortran/openmp.c
> @@ -1969,6 +1971,13 @@ gfc_match_oacc_routine (void)
> gfc_current_locus = old_loc;
> return MATCH_ERROR;
> }
> +
> + /* Set sym to NULL if it matches the current procedure's
> + name. This will simplify the check for duplicate ACC
> + ROUTINE attributes. */
> + if (gfc_current_ns->proc_name
> + && !strcmp (buffer, gfc_current_ns->proc_name->name))
> + sym = NULL;
> }
>else
> {
I re-worked the code a bit, didn't find this necessary.
>dims = gfc_oacc_routine_dims (c);
>if (dims == OACC_FUNCTION_NONE)
> {
>gfc_error ("Multiple loop axes specified in !$ACC ROUTINE at %C");
> - goto cleanup;
> +
> + /* Don't abort early, because it's important to let the user
> + know of any potential duplicate routine directives. */
> + seen_error = true;
> }
Same for this.
> + bool needs_entry = true;
> +
> + /* Scan for any repeated routine directives on 'sym' and report
> + an error if necessary. TODO: Extend this function to scan
> + for compatible DEVICE_TYPE dims. */
> + for (n = gfc_current_ns->oacc_routine_names; n; n = n->next)
> + if (n->sym == sym)
> + {
> + needs_entry = false;
> + if (dims != gfc_oacc_routine_dims (n->clauses))
> + {
> + gfc_error ("$!ACC ROUTINE already applied at %C");
> + goto cleanup;
> + }
> + }
> +
> + if (needs_entry)
> + {
> + n = gfc_get_oacc_routine_name ();
This would leave us with a stray non-NULL 'n' in the '!needs_entry' case
(which potentially could confuse later processing?).
> + n->next = NULL;
> +
> + if (gfc_current_ns->oacc_routine_names != NULL)
> + n->next = gfc_current_ns->oacc_routine_names;
That's just 'n->next = gfc_current_ns->oacc_routine_names;'. ;-)
>else if (gfc_current_ns->proc_name)
> {
> + if (gfc_current_ns->proc_name->attr.oacc_function != OACC_FUNCTION_NONE
> + && !seen_error)
> + {
> + gfc_error ("!$ACC ROUTINE already applied at %C");
> + goto cleanup;
> + }
That need not emit an error if the previous is equal to current clause
specifying the level of parallelism.
> --- a/gcc/testsuite/gfortran.dg/goacc/pr72741-intrinsic-1.f
> +++ b/gcc/testsuite/gfortran.dg/goacc/pr72741-intrinsic-1.f
> @@ -1,17 +1,13 @@
> -! Check for valid clauses with intrinsic function specified in !$ACC ROUTINE
> ( NAME ).
> -
>SUBROUTINE sub_1
>IMPLICIT NONE
> -!$ACC ROUTINE (ABORT)
> -!$ACC ROUTINE (ABORT) SEQ
> +!$ACC ROUTINE (ABORT) SEQ VECTOR ! { dg-error "Intrinsic symbol specified in
> \\!\\\$ACC ROUTINE \\( NAME \\) at \\(1\\), with incompatible clauses
> specifying the level of parallelism" }
That changes what this test cases is supposed to be testing.
All that re-worked, and now committed to trunk in r269287 "[PR72741,
PR89433] Repeated use of the Fortran OpenACC 'routine' directive", as
attached.
Grüße
Thomas
From 35e99d5d3bd98eb2e2cee5d94ba09b6166dbeab2 Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Thu, 28 Feb 2019 20:31:36 +
Subject: [PATCH 3/3] [PR72741, PR89433] Repeated use of the Fortran OpenACC
'routine' directive
gcc/fortran/
PR fortran/72741
PR fortran/89433
* openmp.c (gfc_match_oacc_routine): Handle repeated use of the
Fortran OpenACC 'routine' directive.
gcc/testsuite/
PR fortran/72741
PR fortran/89433
* gfortran.dg/goacc/routine-multiple-directives-1.f90: New file.
* gfortran.dg/goacc/routine-multiple-directives-2.f90: Likewise.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@269287 138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/fortran/ChangeLog | 5 ++
gcc/fortran/openmp.c | 43 --
gcc/testsuite/ChangeLog | 5 ++
.../goacc/routine-multiple-directives-1.f90 | 58 +
.../goacc/routine-multiple-directives-2.f90 | 82 +++
5 files changed, 185 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/goacc/routine-multiple-directives-1.f90
create mode 100644 gcc/testsuite/gfortran.dg/goacc/routine-multiple-directives-2.f90
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 1c8f71252980..6adb90aa4c01 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,6 +1,11 @@
2019-02-28 Thomas Schwinge
Cesar Philippidis
+ PR fortran/72741
+ PR fortran/89433
+ * openmp.c (gfc_match_oacc_routine): Handle repeated use of the
+ Fortran OpenACC 'routine'
[PR72741] For all Fortran OpenACC 'routine' directive variants check for multiple clauses specifying the level of parallelism
Hi!
On Thu, 28 Jul 2016 21:21:29 -0700, Cesar Philippidis
wrote:
> Thomas found a bug in the fortran routine parser where errors involving
> invalid combinations of gang, worker, vector and seq clauses were
> getting suppressed. [...]
> This bug is also present in trunk, but [...]
Re-worked a bit, and committed to trunk in r269286 "[PR72741] For all
Fortran OpenACC 'routine' directive variants check for multiple clauses
specifying the level of parallelism", as attached.
Grüße
Thomas
From 7378dd70e000e78ba7a266349077ab6ef36b5c62 Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Thu, 28 Feb 2019 20:31:23 +
Subject: [PATCH 2/3] [PR72741] For all Fortran OpenACC 'routine' directive
variants check for multiple clauses specifying the level of parallelism
gcc/fortran/
PR fortran/72741
* gfortran.h (enum oacc_routine_lop): Add OACC_ROUTINE_LOP_ERROR.
* openmp.c (gfc_oacc_routine_lop, gfc_match_oacc_routine): Use it.
* trans-decl.c (add_attributes_to_decl): Likewise.
gcc/testsuite/
PR fortran/72741
* gfortran.dg/goacc/routine-multiple-lop-clauses-1.f90: New file.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@269286 138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/fortran/ChangeLog | 5 +++
gcc/fortran/gfortran.h| 3 +-
gcc/fortran/openmp.c | 13 ++--
gcc/fortran/trans-decl.c | 1 +
gcc/testsuite/ChangeLog | 3 ++
.../goacc/routine-multiple-lop-clauses-1.f90 | 32 +++
6 files changed, 53 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/goacc/routine-multiple-lop-clauses-1.f90
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 78c6324d1b83..1c8f71252980 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,6 +1,11 @@
2019-02-28 Thomas Schwinge
Cesar Philippidis
+ PR fortran/72741
+ * gfortran.h (enum oacc_routine_lop): Add OACC_ROUTINE_LOP_ERROR.
+ * openmp.c (gfc_oacc_routine_lop, gfc_match_oacc_routine): Use it.
+ * trans-decl.c (add_attributes_to_decl): Likewise.
+
PR fortran/72741
PR fortran/89433
* openmp.c (gfc_match_oacc_routine): Accept intrinsic symbols.
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index f0258b39ffd1..3e0f634c3a8e 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -323,7 +323,8 @@ enum oacc_routine_lop
OACC_ROUTINE_LOP_GANG,
OACC_ROUTINE_LOP_WORKER,
OACC_ROUTINE_LOP_VECTOR,
- OACC_ROUTINE_LOP_SEQ
+ OACC_ROUTINE_LOP_SEQ,
+ OACC_ROUTINE_LOP_ERROR
};
/* Strings for all symbol attributes. We use these for dumping the
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 6999ac34a1a9..50b91f2150ab 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -2265,7 +2265,7 @@ gfc_oacc_routine_lop (gfc_omp_clauses *clauses)
}
if (n_lop_clauses > 1)
- gfc_error ("Multiple loop axes specified for routine");
+ ret = OACC_ROUTINE_LOP_ERROR;
}
return ret;
@@ -2280,6 +2280,7 @@ gfc_match_oacc_routine (void)
gfc_symbol *sym = NULL;
gfc_omp_clauses *c = NULL;
gfc_oacc_routine_name *n = NULL;
+ oacc_routine_lop lop = OACC_ROUTINE_LOP_NONE;
old_loc = gfc_current_locus;
@@ -2352,6 +2353,13 @@ gfc_match_oacc_routine (void)
!= MATCH_YES))
return MATCH_ERROR;
+ lop = gfc_oacc_routine_lop (c);
+ if (lop == OACC_ROUTINE_LOP_ERROR)
+{
+ gfc_error ("Multiple loop axes specified for routine at %C");
+ goto cleanup;
+}
+
if (isym != NULL)
{
/* Diagnose any OpenACC 'routine' directive that doesn't match the
@@ -2381,8 +2389,7 @@ gfc_match_oacc_routine (void)
gfc_current_ns->proc_name->name,
_loc))
goto cleanup;
- gfc_current_ns->proc_name->attr.oacc_routine_lop
- = gfc_oacc_routine_lop (c);
+ gfc_current_ns->proc_name->attr.oacc_routine_lop = lop;
}
else
/* Something has gone wrong, possibly a syntax error. */
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 20d453051a29..36b7fdd2701f 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1425,6 +1425,7 @@ add_attributes_to_decl (symbol_attribute sym_attr, tree list)
code = OMP_CLAUSE_SEQ;
break;
case OACC_ROUTINE_LOP_NONE:
+ case OACC_ROUTINE_LOP_ERROR:
default:
gcc_unreachable ();
}
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index c45e7b7546a9..9f4c598951c3 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,6 +1,9 @@
2019-02-28 Thomas Schwinge
Cesar Philippidis
+ PR fortran/72741
+ * gfortran.dg/goacc/routine-multiple-lop-clauses-1.f90: New file.
+
PR fortran/72741
PR fortran/89433
* gfortran.dg/goacc/routine-6.f90: Update
diff --git a/gcc/testsuite/gfortran.dg/goacc/routine-multiple-lop-clauses-1.f90 b/gcc/testsuite/gfortran.dg/goacc/routine-multiple-lop-clauses-1.f90
new file mode 100644
index
[PR72741, PR89433] Accept intrinsic symbols in Fortran OpenACC 'routine' directives
Hi!
On Fri, 12 Aug 2016 18:13:43 +0200, I wrote:
> Let me actually break this out of the other pending patches; this should
> be uncontroversial. Originally by Cesar, extended by me. OK for trunk?
>
> commit a0fee96c0f204814e87ddf6635f9cbec2afc6887
> Author: Thomas Schwinge
> Date: Fri Aug 12 17:19:05 2016 +0200
>
> [PR fortran/72741] Handle intrinsic functions specified in !$ACC ROUTINE
> ( NAME )
Re-worked a bit, and committed to trunk in r269285 "[PR72741, PR89433]
Accept intrinsic symbols in Fortran OpenACC 'routine' directives", as
attached.
Grüße
Thomas
From 1d86d0eb3e7b6c3d799c91fad4bc12da572160fd Mon Sep 17 00:00:00 2001
From: tschwinge
Date: Thu, 28 Feb 2019 20:31:01 +
Subject: [PATCH 1/3] [PR72741, PR89433] Accept intrinsic symbols in Fortran
OpenACC 'routine' directives
gcc/fortran/
PR fortran/72741
PR fortran/89433
* openmp.c (gfc_match_oacc_routine): Accept intrinsic symbols.
gcc/testsuite/
PR fortran/72741
PR fortran/89433
* gfortran.dg/goacc/routine-6.f90: Update
* gfortran.dg/goacc/routine-intrinsic-1.f: New file.
* gfortran.dg/goacc/routine-intrinsic-2.f: Likewise.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@269285 138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/fortran/ChangeLog | 7
gcc/fortran/openmp.c | 33 ---
gcc/testsuite/ChangeLog | 9 +
gcc/testsuite/gfortran.dg/goacc/routine-6.f90 | 7
.../gfortran.dg/goacc/routine-intrinsic-1.f | 21
.../gfortran.dg/goacc/routine-intrinsic-2.f | 23 +
6 files changed, 95 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/goacc/routine-intrinsic-1.f
create mode 100644 gcc/testsuite/gfortran.dg/goacc/routine-intrinsic-2.f
diff --git a/gcc/fortran/ChangeLog b/gcc/fortran/ChangeLog
index 85ce5bce5604..78c6324d1b83 100644
--- a/gcc/fortran/ChangeLog
+++ b/gcc/fortran/ChangeLog
@@ -1,3 +1,10 @@
+2019-02-28 Thomas Schwinge
+ Cesar Philippidis
+
+ PR fortran/72741
+ PR fortran/89433
+ * openmp.c (gfc_match_oacc_routine): Accept intrinsic symbols.
+
2019-02-26 Harald Anlauf
PR fortran/89492
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index dfd4be86d50e..6999ac34a1a9 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -2275,8 +2275,9 @@ match
gfc_match_oacc_routine (void)
{
locus old_loc;
- gfc_symbol *sym = NULL;
match m;
+ gfc_intrinsic_sym *isym = NULL;
+ gfc_symbol *sym = NULL;
gfc_omp_clauses *c = NULL;
gfc_oacc_routine_name *n = NULL;
@@ -2296,12 +2297,19 @@ gfc_match_oacc_routine (void)
if (m == MATCH_YES)
{
char buffer[GFC_MAX_SYMBOL_LEN + 1];
- gfc_symtree *st;
m = gfc_match_name (buffer);
if (m == MATCH_YES)
{
- st = gfc_find_symtree (gfc_current_ns->sym_root, buffer);
+ gfc_symtree *st = NULL;
+
+ /* First look for an intrinsic symbol. */
+ isym = gfc_find_function (buffer);
+ if (!isym)
+ isym = gfc_find_subroutine (buffer);
+ /* If no intrinsic symbol found, search the current namespace. */
+ if (!isym)
+ st = gfc_find_symtree (gfc_current_ns->sym_root, buffer);
if (st)
{
sym = st->n.sym;
@@ -2310,7 +2318,7 @@ gfc_match_oacc_routine (void)
sym = NULL;
}
- if (st == NULL
+ if ((isym == NULL && st == NULL)
|| (sym
&& !sym->attr.external
&& !sym->attr.function
@@ -2344,7 +2352,19 @@ gfc_match_oacc_routine (void)
!= MATCH_YES))
return MATCH_ERROR;
- if (sym != NULL)
+ if (isym != NULL)
+{
+ /* Diagnose any OpenACC 'routine' directive that doesn't match the
+ (implicit) one with a 'seq' clause. */
+ if (c && (c->gang || c->worker || c->vector))
+ {
+ gfc_error ("Intrinsic symbol specified in !$ACC ROUTINE ( NAME )"
+ " at %C marked with incompatible GANG, WORKER, or VECTOR"
+ " clause");
+ goto cleanup;
+ }
+}
+ else if (sym != NULL)
{
n = gfc_get_oacc_routine_name ();
n->sym = sym;
@@ -2364,6 +2384,9 @@ gfc_match_oacc_routine (void)
gfc_current_ns->proc_name->attr.oacc_routine_lop
= gfc_oacc_routine_lop (c);
}
+ else
+/* Something has gone wrong, possibly a syntax error. */
+goto cleanup;
if (n)
n->clauses = c;
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 79de60324e3b..c45e7b7546a9 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,12 @@
+2019-02-28 Thomas Schwinge
+ Cesar Philippidis
+
+ PR fortran/72741
+ PR fortran/89433
+ * gfortran.dg/goacc/routine-6.f90: Update
+ * gfortran.dg/goacc/routine-intrinsic-1.f: New file.
+ * gfortran.dg/goacc/routine-intrinsic-2.f: Likewise.
+
2019-02-28 Jakub Jelinek
PR c/89521
diff --git a/gcc/testsuite/gfortran.dg/goacc/routine-6.f90 b/gcc/testsuite/gfortran.dg/goacc/routine-6.f90
index 10943cff3045..0201b8d1fee5 100644
---
[patch, fortran] Fix pointers not escaping via C_PTR
Hello world,
the attached patch fixes a wrong-code bug for gfortran where pointers
were not marked as escaping. A C_PTR can be stashed away and reused
later (at least as long as the variable it points to remains active).
This is not a regression, but IMHO a bad wrong-code bug. The chances
of this patch introducing regressions are really, really low.
Regression-tested. OK for trunk?
Regards
Thomas
2019-02-29 Thomas Koenig
PR fortran/71544
* trans-types.c (gfc_typenode_for_spec) Set ts->is_c_interop of
C_PTR and
C_FUNPTR.
(create_fn_spec): Mark argument as escaping if ts->is_c_interop
is set.
2019-02-29 Thomas Koenig
PR fortran/71544
* gfortran.dg/c_ptr_tests_19.f90: New test.
Index: trans-types.c
===
--- trans-types.c (Revision 269260)
+++ trans-types.c (Arbeitskopie)
@@ -1176,7 +1176,8 @@ gfc_typenode_for_spec (gfc_typespec * spec, int co
{
spec->type = BT_INTEGER;
spec->kind = gfc_index_integer_kind;
- spec->f90_type = BT_VOID;
+ spec->f90_type = BT_VOID;
+ spec->is_c_interop = 1; /* Mark as escaping later. */
}
break;
case BT_VOID:
@@ -2957,7 +2958,8 @@ create_fn_spec (gfc_symbol *sym, tree fntype)
|| f->sym->ts.u.derived->attr.pointer_comp))
|| (f->sym->ts.type == BT_CLASS
&& (CLASS_DATA (f->sym)->ts.u.derived->attr.proc_pointer_comp
- || CLASS_DATA (f->sym)->ts.u.derived->attr.pointer_comp)))
+ || CLASS_DATA (f->sym)->ts.u.derived->attr.pointer_comp))
+ || (f->sym->ts.type == BT_INTEGER && f->sym->ts.is_c_interop))
spec[spec_len++] = '.';
else if (f->sym->attr.intent == INTENT_IN)
spec[spec_len++] = 'r';
! { dg-do run }
! PR 71544 - this failed with some optimization options due to a
! pointer not being marked as escaping.
module store_cptr
use, intrinsic :: iso_c_binding
implicit none
public
type(c_ptr), save :: cptr
end module store_cptr
subroutine init()
use, intrinsic :: iso_c_binding
implicit none
integer(c_int), pointer :: a
allocate(a)
call save_cptr(c_loc(a))
a = 100
end subroutine init
subroutine save_cptr(cptr_in)
use store_cptr
implicit none
type(c_ptr), intent(in) :: cptr_in
cptr = cptr_in
end subroutine save_cptr
program init_fails
use store_cptr
implicit none
integer(c_int), pointer :: val
call init()
call c_f_pointer(cptr,val)
print *,'The following line should print 100'
print *,val
end program init_fails
C++ PATCH for c++/89532 - ICE with incomplete type in decltype
If get_target_expr_sfinae gets an expression whose type is incomplete, it's
upset. digest_init returns error_mark_node if it gets an expression with
incomplete type, so we need to respect that, and not call
get_target_expr_sfinae on ORIG_CL in that case.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-02-28 Marek Polacek
PR c++/89532 - ICE with incomplete type in decltype.
* semantics.c (finish_compound_literal): Return error_mark_node
if digest_init_flags returns error_mark_node.
* g++.dg/cpp2a/nontype-class14.C: New test.
diff --git gcc/cp/semantics.c gcc/cp/semantics.c
index d1a378acd98..c03e4ef247c 100644
--- gcc/cp/semantics.c
+++ gcc/cp/semantics.c
@@ -2859,6 +2859,9 @@ finish_compound_literal (tree type, tree compound_literal,
compound_literal = digest_init_flags (type, compound_literal,
LOOKUP_NORMAL | LOOKUP_NO_NARROWING,
complain);
+ if (compound_literal == error_mark_node)
+return error_mark_node;
+
/* If we're in a template, return the original compound literal. */
if (orig_cl)
{
diff --git gcc/testsuite/g++.dg/cpp2a/nontype-class14.C
gcc/testsuite/g++.dg/cpp2a/nontype-class14.C
new file mode 100644
index 000..4b19f81f97a
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp2a/nontype-class14.C
@@ -0,0 +1,10 @@
+// PR c++/89532
+// { dg-do compile { target c++2a } }
+
+struct tuple;
+
+template // { dg-error "invalid use of incomplete type" }
+struct S { };
+
+template
+decltype(tuple {}) d; // { dg-error "invalid use of incomplete type" }
Re: A bug in vrp_meet?
On 2/28/19 10:05 AM, Qing Zhao wrote:
> Hi,
>
> I have been debugging a runtime error caused by value range propagation. and
> finally located to the following gcc routine:
>
> vrp_meet_1 in gcc/tree-vrp.c
>
>
> /* Meet operation for value ranges. Given two value ranges VR0 and
>VR1, store in VR0 a range that contains both VR0 and VR1. This
>may not be the smallest possible such range. */
>
> static void
> vrp_meet_1 (value_range *vr0, const value_range *vr1)
> {
> value_range saved;
>
> if (vr0->type == VR_UNDEFINED)
> {
> set_value_range (vr0, vr1->type, vr1->min, vr1->max, vr1->equiv);
> return;
> }
>
> if (vr1->type == VR_UNDEFINED)
> {
> /* VR0 already has the resulting range. */
> return;
> }
>
>
> In the above, when one of vr0 or vr1 is VR_UNDEFINED, the meet result of
> these two will be the other VALUE.
>
> This seems not correct to me.
That's the optimistic nature of VRP. It's generally desired behavior.
>
> For example, the following is the located incorrect value range propagation:
> (portion from the dump file *.181t.dom3)
>
>
> Visiting PHI node: i_83 = PHI <_152(20), 0(22)>
> Argument #0 (20 -> 10 executable)
> _152: UNDEFINED
> Argument #1 (22 -> 10 executable)
> 0: [0, 0]
> Meeting
> UNDEFINED
> and
> [0, 0]
> to
> [0, 0]
> Intersecting
> [0, 0]
> and
> [0, 65535]
> to
> [0, 0]
>
>
>
> In the above, “i_83” is defined as PHI <_152(20), 0(22)>, the 1st argument
> is UNDEFINED at this time(but its value range definitely is NOT [0,0]),
> and the 2nd argument is 0.
If it's value is undefined then it can be any value we want. We choose
to make it equal to the other argument.
If VRP later finds that _152 changes, then it will go back and
reevaluate the PHI. That's one of the basic design principles of the
optimistic propagators.
>
> “vrp_meet” generate a VR_RANGE with [0,0] for “i_83” based on the current
> algorithm. Obviously, this result VR_RANGE with [0,0] does NOT
> contain the value ranges for _152.
>
> the result of “vrp_meet” is Not correct. and this incorrect value range
> result finally caused the runtime error.
>
> I ‘d like to modify the vrp_meet_1 as following:
>
>
> static void
> vrp_meet_1 (value_range *vr0, const value_range *vr1)
> {
> value_range saved;
>
> if (vr0->type == VR_UNDEFINED)
> {
> /* VR0 already has the resulting range. */
> return;
> }
>
> if (vr1->type == VR_UNDEFINED)
> {
> set_value_range_to_undefined (vr0)
> return;
> }
>
>
> let me know your opinion.
>
> thanks a lot for the help.
I think we (Richi and I) went through this about a year ago and the
conclusion was we should be looking at how you're getting into the
vrp_meet with the VR_UNDEFINED.
If it happens because the user's code has an undefined use, then, the
consensus has been to go ahead and optimize it.
If it happens for any other reason, then it's likely a bug in GCC. We
had a couple of these when we made EVRP a re-usable module and started
exploiting its data in the jump threader.
So you need to work backwards from this point to figure out how you got
here.
jeff
Re: C++ PATCH for c++/89537 - missing location for error with non-static member fn
On Thu, Feb 28, 2019 at 02:33:37PM -0500, Jason Merrill wrote:
> On 2/28/19 2:00 PM, Marek Polacek wrote:
> > Here we issued the "invalid use of non-static member function" error with
> > UNKNOWN_LOCATION, which merely shows "cc1plus" and no file/line. We can
> > greatly improve this situation with the below.
> >
> > The patch is IMHO trivial (though it's user-provided) to go in even at
> > this point.
> >
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >
> > 2019-02-28 Marek Polacek
> >
> > PR c++/89537 - missing location for error with non-static member fn.
> > * call.c (resolve_args): Use EXPR_LOCATION.
> > * typeck.c (build_class_member_access_expr): Use input_location.
> >
> > * g++.dg/diagnostic/member-fn-1.C: New test.
> >
> > diff --git gcc/cp/call.c gcc/cp/call.c
> > index fb67d905acd..d9073d7c23d 100644
> > --- gcc/cp/call.c
> > +++ gcc/cp/call.c
> > @@ -4246,7 +4246,7 @@ resolve_args (vec *args, tsubst_flags_t
> > complain)
> > error ("invalid use of void expression");
> > return NULL;
> > }
> > - else if (invalid_nonstatic_memfn_p (arg->exp.locus, arg, complain))
> > + else if (invalid_nonstatic_memfn_p (EXPR_LOCATION (arg), arg,
> > complain))
>
> Maybe cp_expr_loc_or_loc (arg, input_location)?
That gives a suboptimal location:
values(p1->values) {}
^
whereas with my fix:
values(p1->values) {}
^~
> > return NULL;
> > }
> > return args;
> > diff --git gcc/cp/typeck.c gcc/cp/typeck.c
> > index 1db9333b5ff..1bf9ad88141 100644
> > --- gcc/cp/typeck.c
> > +++ gcc/cp/typeck.c
> > @@ -2562,7 +2562,8 @@ build_class_member_access_expr (cp_expr object, tree
> > member,
> > type = unknown_type_node;
> > /* Note that we do not convert OBJECT to the BASELINK_BINFO
> > base. That will happen when the function is called. */
> > - result = build3 (COMPONENT_REF, type, object, member, NULL_TREE);
> > + result = build3_loc (input_location, COMPONENT_REF, type, object,
> > member,
> > + NULL_TREE);
>
> Then I think this change shouldn't be needed.
The build3 call above this block also uses input_location.
Marek
Re: C++ PATCH for c++/89537 - missing location for error with non-static member fn
On 2/28/19 2:00 PM, Marek Polacek wrote:
Here we issued the "invalid use of non-static member function" error with
UNKNOWN_LOCATION, which merely shows "cc1plus" and no file/line. We can
greatly improve this situation with the below.
The patch is IMHO trivial (though it's user-provided) to go in even at
this point.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-02-28 Marek Polacek
PR c++/89537 - missing location for error with non-static member fn.
* call.c (resolve_args): Use EXPR_LOCATION.
* typeck.c (build_class_member_access_expr): Use input_location.
* g++.dg/diagnostic/member-fn-1.C: New test.
diff --git gcc/cp/call.c gcc/cp/call.c
index fb67d905acd..d9073d7c23d 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -4246,7 +4246,7 @@ resolve_args (vec *args, tsubst_flags_t
complain)
error ("invalid use of void expression");
return NULL;
}
- else if (invalid_nonstatic_memfn_p (arg->exp.locus, arg, complain))
+ else if (invalid_nonstatic_memfn_p (EXPR_LOCATION (arg), arg, complain))
Maybe cp_expr_loc_or_loc (arg, input_location)?
return NULL;
}
return args;
diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index 1db9333b5ff..1bf9ad88141 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -2562,7 +2562,8 @@ build_class_member_access_expr (cp_expr object, tree
member,
type = unknown_type_node;
/* Note that we do not convert OBJECT to the BASELINK_BINFO
base. That will happen when the function is called. */
- result = build3 (COMPONENT_REF, type, object, member, NULL_TREE);
+ result = build3_loc (input_location, COMPONENT_REF, type, object, member,
+ NULL_TREE);
Then I think this change shouldn't be needed.
Jason
Re: [fortran, patch] IEEE intrinsic modules (ping)
Hi!
While looking for something else -- isn't that always how it happens ;-)
-- I noticed one thing here:
On Wed, 25 Jun 2014 01:41:02 +0200, FX wrote:
> I’ll wait a few more days to commit, so others can comment/review and I am
> sure to be around if there is fallout.
(This got committed to trunk in r212102.)
> --- gcc/testsuite/gfortran.dg/ieee/ieee.exp (revision 0)
> +++ gcc/testsuite/gfortran.dg/ieee/ieee.exp (revision 0)
> @@ -0,0 +1,59 @@
> +[...]
> +global DEFAULT_FFLAGS
> +if ![info exists DEFAULT_FFLAGS] then {
> +set DEFAULT_FFLAGS ""
> +}
> +[...]
Per my understanding of DejaGnu (and please correct me if that's wrong),
in the same 'runtest' instance, 'global' variables persist from one
'*.exp' file to another. (Which is something debatable, in my
opinion...)
All other '*.exp' files that back then did define 'DEFAULT_FFLAGS' (using
this same construct as shown above), and it's still the same now, are
using " -pedantic-errors" instead of the empty string. Thus this setting
of 'DEFAULT_FFLAGS' is not idempotent, depends on whether
'gfortran.dg/ieee/ieee.exp', or an other defining '*.exp' file is
executed first.
By default, first comes 'gfortran.dg/coarray/caf.exp' (nowadays, did not
yet exist back then), then 'gfortran.dg/dg.exp', then
'gfortran.dg/ieee/ieee.exp'. (And, sometimes also
'gcc.target/powerpc/ppc-fortran/ppc-fortran.exp'.)
And, as I just noticed, 'runtest' seems to always sort the specified
'*.exp' files (?!), so even when you invoke something like
"check-gcc-fortran RUNTESTFLAGS='ieee.exp dg.exp'" to try to provoke some
regressions to appear, you'd still get 'dg.exp' executed first. The
empty string setting in 'ieee.exp' was never really active -- only if
executed on its own, etc.
Fortunately, 'ieee.exp' seems to behave the same way whether running with
or without '-pedantic-errors', so I propose to simply unify that setting,
see attached. OK to commit this to all relevant branches? If approving
this patch, please respond with "Reviewed-by: NAME " so that your
effort will be recorded in the commit log, see
.
Grüße
Thomas
From 214a3ac1b44343c5b1bbd2963bc256b056dac764 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Thu, 28 Feb 2019 20:08:25 +0100
Subject: [PATCH] [testsuite, Fortran] Consistently set 'DEFAULT_FFLAGS'
In the same 'runtest' instance, 'global' variables persist from one '*.exp'
file to another.
All other '*.exp' files are using " -pedantic-errors" instead of the empty
string as the default for 'DEFAULT_FFLAGS'. Thus this setting of
'DEFAULT_FFLAGS' is not idempotent, depends on whether
'gfortran.dg/ieee/ieee.exp', or an other defining '*.exp' file is executed
first.
gcc/testsuite/
PR fortran/29383
* gfortran.dg/ieee/ieee.exp (DEFAULT_FFLAGS): Set the same as in
other '*.exp' files.
---
gcc/testsuite/gfortran.dg/ieee/ieee.exp | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/ieee/ieee.exp b/gcc/testsuite/gfortran.dg/ieee/ieee.exp
index 05383ce94331..68d4b7816144 100644
--- a/gcc/testsuite/gfortran.dg/ieee/ieee.exp
+++ b/gcc/testsuite/gfortran.dg/ieee/ieee.exp
@@ -22,15 +22,15 @@
load_lib gfortran-dg.exp
load_lib target-supports.exp
-# Initialize `dg'.
-dg-init
-
-# Flags specified in each test
+# If a testcase doesn't have special options, use these.
global DEFAULT_FFLAGS
if ![info exists DEFAULT_FFLAGS] then {
-set DEFAULT_FFLAGS ""
+set DEFAULT_FFLAGS " -pedantic-errors"
}
+# Initialize `dg'.
+dg-init
+
# Flags for finding the IEEE modules
if [info exists TOOL_OPTIONS] {
set specpath [get_multilibs ${TOOL_OPTIONS}]
--
2.17.1
signature.asc
Description: PGP signature
Re: [PATCH] haifa-sched: handle fallthru edge to EXIT block (PR 85899)
> So it looks to me that the assert has to allow this. I've bootstrapped the > following (not that it matters much as it simply relaxes the assert) and > verified it fixes the testcase. Yes, fallthrough edges to the exit block exist in RTL, see could_fall_through. > OK for trunk? > > * haifa-sched.c (find_fallthru_edge_from): Relax assert to account for > fallthru edges leading to the exit block. > > * gcc.dg/pr85899.c: New test. OK, thanks. -- Eric Botcazou
[PATCH] x32: Add addr32 prefix to UNSPEC_VSIBADDR instructions
32-bit indices in VSIB address are sign-extended to 64 bits. In x32,
when 32-bit indices are used as addresses, like in
vgatherdps %ymm7, 0(,%ymm9,1), %ymm6
32-bit indices, 0xf7fa3010, is sign-extended to 0xf7fa3010 which
is invalid address. Add addr32 prefix to UNSPEC_VSIBADDR instructions
for x32 if there is no base register nor symbol.
This fixes 175.vpr and 254.gap in SPEC CPU 2000 on x32 with
-Ofast -funroll-loops -march=haswell
gcc/
PR target/89523
* config/i386/i386.c (ix86_print_operand): Also handle '_' to
add addr32 prefix if required.
(ix86_print_operand_punct_valid_p): Allow '_'.
* config/i386/sse.md (*avx512pf_gatherpfsf_mask): Prepend
"%_".
(*avx512pf_gatherpfdf_mask): Likewise.
(*avx512pf_scatterpfsf_mask): Likewise.
(*avx512pf_scatterpfdf_mask): Likewise.
(*avx2_gathersi): Likewise.
(*avx2_gathersi_2): Likewise.
(*avx2_gatherdi): Likewise.
(*avx2_gatherdi_2): Likewise.
(*avx2_gatherdi_3): Likewise.
(*avx2_gatherdi_4): Likewise.
(*avx512f_gathersi): Likewise.
(*avx512f_gathersi_2): Likewise.
(*avx512f_gatherdi): Likewise.
(*avx512f_gatherdi_2): Likewise.
(*avx512f_scattersi): Likewise.
(*avx512f_scatterdi): Likewise.
gcc/testsuite/
PR target/89523
* gcc.target/i386/pr89523-1.c: New test.
* gcc.target/i386/pr89523-2.c: Likewise.
* gcc.target/i386/pr89523-3.c: Likewise.
* gcc.target/i386/pr89523-4.c: Likewise.
* gcc.target/i386/pr89523-5.c: Likewise.
* gcc.target/i386/pr89523-6.c: Likewise.
* gcc.target/i386/pr89523-7.c: Likewise.
* gcc.target/i386/pr89523-8.c: Likewise.
* gcc.target/i386/pr89523-9.c: Likewise.
xxx
---
gcc/config/i386/i386.c| 39 ++-
gcc/config/i386/sse.md| 46 +++
gcc/testsuite/gcc.target/i386/pr89523-1.c | 24
gcc/testsuite/gcc.target/i386/pr89523-2.c | 17 +
gcc/testsuite/gcc.target/i386/pr89523-3.c | 17 +
gcc/testsuite/gcc.target/i386/pr89523-4.c | 16
gcc/testsuite/gcc.target/i386/pr89523-5.c | 18 +
gcc/testsuite/gcc.target/i386/pr89523-6.c | 17 +
gcc/testsuite/gcc.target/i386/pr89523-7.c | 19 ++
gcc/testsuite/gcc.target/i386/pr89523-8.c | 19 ++
gcc/testsuite/gcc.target/i386/pr89523-9.c | 16
11 files changed, 224 insertions(+), 24 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr89523-1.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr89523-2.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr89523-3.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr89523-4.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr89523-5.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr89523-6.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr89523-7.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr89523-8.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr89523-9.c
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b8357a7db5d..336696136de 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -17805,6 +17805,7 @@ print_reg (rtx x, int code, FILE *file)
~ -- print "i" if TARGET_AVX2, "f" otherwise.
^ -- print addr32 prefix if TARGET_64BIT and Pmode != word_mode
! -- print NOTRACK prefix for jxx/call/ret instructions if required.
+ _ -- print addr32 prefix if required.
*/
void
@@ -18356,6 +18357,42 @@ ix86_print_operand (FILE *file, rtx x, int code)
fputs ("addr32 ", file);
return;
+ case '_':
+ if (TARGET_X32)
+ {
+ subrtx_var_iterator::array_type array;
+ FOR_EACH_SUBRTX_VAR (iter, array,
+ PATTERN (current_output_insn), ALL)
+ {
+ rtx addr = *iter;
+ if (!MEM_P (addr))
+ continue;
+ addr = XEXP (addr, 0);
+ if (GET_CODE (addr) == UNSPEC
+ && XINT (addr, 1) == UNSPEC_VSIBADDR)
+ {
+ /* NB: 32-bit indices in VSIB address are
+sign-extended to 64 bits. In x32, if 32-bit
+address 0xf7fa3010 is sign-extended to
+0xf7fa3010 which is invalid address.
+Add addr32 prefix if there is no base register
+nor symbol. */
+ bool ok;
+ struct ix86_address parts;
+ ok = ix86_decompose_address (XVECEXP (addr, 0, 0),
+ );
+ gcc_assert (ok && parts.index == NULL_RTX);
+ if (parts.base == NULL_RTX
+ && (parts.disp == NULL_RTX
+
C++ PATCH for c++/89537 - missing location for error with non-static member fn
Here we issued the "invalid use of non-static member function" error with
UNKNOWN_LOCATION, which merely shows "cc1plus" and no file/line. We can
greatly improve this situation with the below.
The patch is IMHO trivial (though it's user-provided) to go in even at
this point.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-02-28 Marek Polacek
PR c++/89537 - missing location for error with non-static member fn.
* call.c (resolve_args): Use EXPR_LOCATION.
* typeck.c (build_class_member_access_expr): Use input_location.
* g++.dg/diagnostic/member-fn-1.C: New test.
diff --git gcc/cp/call.c gcc/cp/call.c
index fb67d905acd..d9073d7c23d 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -4246,7 +4246,7 @@ resolve_args (vec *args, tsubst_flags_t
complain)
error ("invalid use of void expression");
return NULL;
}
- else if (invalid_nonstatic_memfn_p (arg->exp.locus, arg, complain))
+ else if (invalid_nonstatic_memfn_p (EXPR_LOCATION (arg), arg, complain))
return NULL;
}
return args;
diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index 1db9333b5ff..1bf9ad88141 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -2562,7 +2562,8 @@ build_class_member_access_expr (cp_expr object, tree
member,
type = unknown_type_node;
/* Note that we do not convert OBJECT to the BASELINK_BINFO
base. That will happen when the function is called. */
- result = build3 (COMPONENT_REF, type, object, member, NULL_TREE);
+ result = build3_loc (input_location, COMPONENT_REF, type, object, member,
+ NULL_TREE);
}
else if (TREE_CODE (member) == CONST_DECL)
{
diff --git gcc/testsuite/g++.dg/diagnostic/member-fn-1.C
gcc/testsuite/g++.dg/diagnostic/member-fn-1.C
new file mode 100644
index 000..6d965d464fb
--- /dev/null
+++ gcc/testsuite/g++.dg/diagnostic/member-fn-1.C
@@ -0,0 +1,38 @@
+// PR c++/89537
+// { dg-do compile { target c++11 } }
+
+template class A {};
+template class B;
+class C {
+ using mapped_type = int;
+
+public:
+ template
+ C(B, A> *p1, unsigned)
+ : keys(p1->keys), // { dg-error "18: invalid use of non-static member
function" }
+values(p1->values) {} // { dg-error "20: invalid use of non-static
member function" }
+ A keys;
+ A values;
+};
+class D {
+public:
+ using key_compare = int;
+ template D(key_compare, _Alloc);
+};
+template > class B {
+ using _Impl = D;
+ _Impl _M_impl;
+
+public:
+ using key_compare = int;
+ using iterator = C;
+ template B(key_compare p1, _Alloc p2) : _M_impl(p1, p2) {}
+ template B(_Alloc p1) : B(key_compare(), p1) {}
+ iterator begin() { return {this, 0}; }
+ void keys();
+ void values();
+};
+void fn1() {
+ B> m(fn1);
+ m.begin();
+}
[PATCH] i386: Support ISAs enabled at command-line with target attribute
__attribute__ ((target("arch=broadwell"))) should enable AVX with -mavx
at command-line. When we apply target attribute, we need to clear
x_ix86_isa_flags_explicit and x_ix86_isa_flags2_explicit, which are
turned on at command-line, so that target features will be enabled.
mv17.C has a version for Haswell. On machines with Haswell ISAs, when
GCC is configured with --with-arch=native, all versions will be compiled
with Haswell ISAs. Compile mv17.C with -march=x86-64 to force that only
Haswell version is compiled with -march=haswell.
gcc/
PR target/89456
* config/i386/i386.c (ix86_valid_target_attribute_tree): Allow
enabling ISAs which have been enabled at command-line.
gcc/testsuite/
PR target/89456
* g++.target/i386/mv17.C: Add -march=x86-64.
* gcc.target/i386/pr89456-1.c: New test.
---
gcc/config/i386/i386.c| 6 ++
gcc/testsuite/g++.target/i386/mv17.C | 2 +-
gcc/testsuite/gcc.target/i386/pr89456-1.c | 9 +
3 files changed, 16 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr89456-1.c
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index c8f9957163b..2b72ca8359f 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -5539,6 +5539,12 @@ ix86_valid_target_attribute_tree (tree args,
= TREE_TARGET_OPTION (target_option_default_node);
struct gcc_options enum_opts_set;
+ /* Allow enabling ISAs which have been enabled at command-line so
+ that __attribute__ ((target("arch=broadwell"))) enables AVX when
+ there is -mavx at command-line. */
+ opts->x_ix86_isa_flags_explicit &= ~ix86_isa_flags;
+ opts->x_ix86_isa_flags2_explicit &= ~ix86_isa_flags2;
+
memset (_opts_set, 0, sizeof (enum_opts_set));
/* Process each of the options on the chain. */
diff --git a/gcc/testsuite/g++.target/i386/mv17.C
b/gcc/testsuite/g++.target/i386/mv17.C
index fefbfaac6ff..17d125227d7 100644
--- a/gcc/testsuite/g++.target/i386/mv17.C
+++ b/gcc/testsuite/g++.target/i386/mv17.C
@@ -2,7 +2,7 @@
// { dg-do run }
// { dg-require-ifunc "" }
-// { dg-options "-O2" }
+// { dg-options "-O2 -march=x86-64" }
#include
diff --git a/gcc/testsuite/gcc.target/i386/pr89456-1.c
b/gcc/testsuite/gcc.target/i386/pr89456-1.c
new file mode 100644
index 000..87a3a820898
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr89456-1.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mavx -march=x86-64" } */
+
+__attribute__ ((target("arch=broadwell")))
+float
+foo (float x)
+{
+ return x;
+}
--
2.20.1
Re: [PATCH] haifa-sched: handle fallthru edge to EXIT block (PR 85899)
On Thu, 28 Feb 2019, Alexander Monakov wrote: > Hi, > > in PR 85899 an assert is failing in find_fallthru_edge_from because the code > tries to verify the invariant e->dest == e->src->next_bb for a fallthru edge > and does not anticipate that it will fail if e->dest is the exit block (bb 1): > in this case next_bb is fairly arbitrary (it's just the next bb that appears > in the insn sequence and has nothing to do with the "fake" fallthru to exit). Or is the bug in out-of-cfglayout code creating such bogus fallthru edge? Thanks. Alexander
[PATCH] [ARC] Fix logic set UNALIGNED_ACCESS
From: Claudiu Zissulescu
gcc/
-xx-xx Claudiu Zissulescu
* config/arc/arc-c.def (__ARC_UNALIGNED__): Set it on
unaligned_access variable.
* config/arc/arc.c (arc_override_options): Set unaligned access
default on for HS CPUs.
* config/arc/arc.h (STRICT_ALIGNMENT): Fix logic.
Signed-off-by: Vineet Gupta
---
gcc/config/arc/arc-c.def | 2 +-
gcc/config/arc/arc.c | 4
gcc/config/arc/arc.h | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/gcc/config/arc/arc-c.def b/gcc/config/arc/arc-c.def
index 9c0ba2c9c294..9472b48aa7bc 100644
--- a/gcc/config/arc/arc-c.def
+++ b/gcc/config/arc/arc-c.def
@@ -29,7 +29,7 @@ ARC_C_DEF ("__ARC_MUL64__", TARGET_MUL64_SET)
ARC_C_DEF ("__ARC_MUL32BY16__", TARGET_MULMAC_32BY16_SET)
ARC_C_DEF ("__ARC_SIMD__", TARGET_SIMD_SET)
ARC_C_DEF ("__ARC_RF16__", TARGET_RF16)
-ARC_C_DEF ("__ARC_UNALIGNED__", !STRICT_ALIGNMENT)
+ARC_C_DEF ("__ARC_UNALIGNED__", unaligned_access)
ARC_C_DEF ("__ARC_BARREL_SHIFTER__", TARGET_BARREL_SHIFTER)
diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index de2c8d5df9cf..3b8c29981b9a 100644
--- a/gcc/config/arc/arc.c
+++ b/gcc/config/arc/arc.c
@@ -1313,6 +1313,10 @@ arc_override_options (void)
if (TARGET_LONG_CALLS_SET)
target_flags &= ~MASK_MILLICODE_THUNK_SET;
+ /* Set unaligned to all HS cpus. */
+ if (!global_options_set.x_unaligned_access && TARGET_HS)
+unaligned_access = 1;
+
/* These need to be done at start up. It's convenient to do them here. */
arc_init ();
}
diff --git a/gcc/config/arc/arc.h b/gcc/config/arc/arc.h
index 12b4b62bba7b..894eb3946000 100644
--- a/gcc/config/arc/arc.h
+++ b/gcc/config/arc/arc.h
@@ -285,7 +285,7 @@ if (GET_MODE_CLASS (MODE) == MODE_INT \
/* On the ARC the lower address bits are masked to 0 as necessary. The chip
won't croak when given an unaligned address, but the insn will still fail
to produce the correct result. */
-#define STRICT_ALIGNMENT (!unaligned_access && !TARGET_HS)
+#define STRICT_ALIGNMENT (!unaligned_access)
/* Layout of source language data types. */
--
2.7.4
[PATCH] haifa-sched: handle fallthru edge to EXIT block (PR 85899)
Hi,
in PR 85899 an assert is failing in find_fallthru_edge_from because the code
tries to verify the invariant e->dest == e->src->next_bb for a fallthru edge
and does not anticipate that it will fail if e->dest is the exit block (bb 1):
in this case next_bb is fairly arbitrary (it's just the next bb that appears
in the insn sequence and has nothing to do with the "fake" fallthru to exit).
So it looks to me that the assert has to allow this. I've bootstrapped the
following (not that it matters much as it simply relaxes the assert) and
verified it fixes the testcase.
OK for trunk?
* haifa-sched.c (find_fallthru_edge_from): Relax assert to account for
fallthru edges leading to the exit block.
* gcc.dg/pr85899.c: New test.
diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 72178b68999..5025aae421d 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -8082,7 +8082,7 @@ find_fallthru_edge_from (basic_block pred)
if (e)
{
- gcc_assert (e->dest == succ);
+ gcc_assert (e->dest == succ || e->dest->index == EXIT_BLOCK);
return e;
}
}
diff --git a/gcc/testsuite/gcc.dg/pr85899.c b/gcc/testsuite/gcc.dg/pr85899.c
index e69de29bb2d..eb2b175339c 100644
--- a/gcc/testsuite/gcc.dg/pr85899.c
+++ b/gcc/testsuite/gcc.dg/pr85899.c
@@ -0,0 +1,17 @@
+/* { dg-do compile { target powerpc*-*-* ia64-*-* i?86-*-* x86_64-*-* } } */
+/* { dg-options "-O2 -fschedule-insns -fselective-scheduling -funroll-loops
-fno-gcse -fno-if-conversion -fno-ivopts" } */
+
+#define N 4096
+int cb[N];
+int cc[N];
+int cd[N];
+
+void init ()
+{
+ int i;
+ for (i = 0; i < N; ++i) {
+cb[i] = 3 * i - 2048;
+cc[i] = -5 * i + 93;
+cd[i] = i % 2 ? 1 : -1;
+ }
+}
Re: RFA: PATCH to gimple-fold.c for c++/80916, bogus "static but not defined" warning
On Thu, Feb 28, 2019 at 11:58 AM Jan Hubicka wrote: > > Hi, > sorry for late reply - I did not identify it as a patch to symbol table. > Indeed we want can_refer_decl_in_current_unit_p is a good place to test > this. Is there a reason to resrict this to functions with no body? If the function has a definition, then of course we can refer to it in its own unit. Am I missing something? > I see that we may be able to inline the function, but all the > devirtualization code works by first turning call to a direct call and > inlining later. We would need to teach the code that it can't > devirtualize without inlining (which can be done by the speculative call > macinery) and probably we will need to check that the function body does > not contain some calls to similar symbols. > > We don't have support for this (do we want to do that in future)? > For GCC 9 it would thus seem more consistent to simply return false on > all symbols with this combination of flags. We probably also can teach > symtab verifiers that we do not contain any references to such symbols. > > Thanks, > Honza > > Ping^3? > > > > On Wed, Feb 13, 2019 at 4:28 PM Jason Merrill wrote: > > > > > > Ping^2 > > > > > > On Mon, Feb 4, 2019 at 4:09 PM Jason Merrill wrote: > > > > > > > > Ping > > > > > > > > On Fri, Jan 25, 2019 at 10:06 AM Jason Merrill wrote: > > > > > > > > > > Here we warn because i::dispatch has internal linkage (because l > > > > > does) and is never instantiated (because the vtable is never emitted). > > > > > The regression happened because devirtualization started adding it to > > > > > cgraph as a possible target. I think the way to fix this is to avoid > > > > > adding an undefined internal function to cgraph as a possible target, > > > > > since it is not, in fact, possible for it to be the actual target. > > > > > > > > > > I think that the best place to fix this would be in > > > > > can_refer_decl_in_current_unit_p, since the same reasoning applies to > > > > > other possible references. But we could fix it only in > > > > > gimple_get_virt_method_for_vtable. > > > > > > > > > > First patch tested x86_64-pc-linux-gnu. > > > > >
A bug in vrp_meet?
Hi,
I have been debugging a runtime error caused by value range propagation. and
finally located to the following gcc routine:
vrp_meet_1 in gcc/tree-vrp.c
/* Meet operation for value ranges. Given two value ranges VR0 and
VR1, store in VR0 a range that contains both VR0 and VR1. This
may not be the smallest possible such range. */
static void
vrp_meet_1 (value_range *vr0, const value_range *vr1)
{
value_range saved;
if (vr0->type == VR_UNDEFINED)
{
set_value_range (vr0, vr1->type, vr1->min, vr1->max, vr1->equiv);
return;
}
if (vr1->type == VR_UNDEFINED)
{
/* VR0 already has the resulting range. */
return;
}
In the above, when one of vr0 or vr1 is VR_UNDEFINED, the meet result of these
two will be the other VALUE.
This seems not correct to me.
For example, the following is the located incorrect value range propagation:
(portion from the dump file *.181t.dom3)
Visiting PHI node: i_83 = PHI <_152(20), 0(22)>
Argument #0 (20 -> 10 executable)
_152: UNDEFINED
Argument #1 (22 -> 10 executable)
0: [0, 0]
Meeting
UNDEFINED
and
[0, 0]
to
[0, 0]
Intersecting
[0, 0]
and
[0, 65535]
to
[0, 0]
In the above, “i_83” is defined as PHI <_152(20), 0(22)>, the 1st argument is
UNDEFINED at this time(but its value range definitely is NOT [0,0]),
and the 2nd argument is 0.
“vrp_meet” generate a VR_RANGE with [0,0] for “i_83” based on the current
algorithm. Obviously, this result VR_RANGE with [0,0] does NOT
contain the value ranges for _152.
the result of “vrp_meet” is Not correct. and this incorrect value range
result finally caused the runtime error.
I ‘d like to modify the vrp_meet_1 as following:
static void
vrp_meet_1 (value_range *vr0, const value_range *vr1)
{
value_range saved;
if (vr0->type == VR_UNDEFINED)
{
/* VR0 already has the resulting range. */
return;
}
if (vr1->type == VR_UNDEFINED)
{
set_value_range_to_undefined (vr0)
return;
}
let me know your opinion.
thanks a lot for the help.
Qing
Re: [Patch, Fortran + Testsuite] Fix coarray handling in modules
Hi!
On Fri, 02 Jan 2015 12:28:10 +0100, Tobias Burnus wrote:
> [...]
>
> I additionally propagated the dg-compile-aux-modules support to caf.dg
That got committed in r219143:
> --- a/gcc/testsuite/gfortran.dg/coarray/caf.exp
> +++ b/gcc/testsuite/gfortran.dg/coarray/caf.exp
> @@ -43,6 +43,21 @@ global DG_TORTURE_OPTIONS torture_with_loops
> torture-init
> set-torture-options $DG_TORTURE_OPTIONS
>
> +global gfortran_test_path
> +global gfortran_aux_module_flags
> +set gfortran_test_path $srcdir/$subdir
> +set gfortran_aux_module_flags $DEFAULT_FFLAGS
> +proc dg-compile-aux-modules { args } {
> +global gfortran_test_path
> +global gfortran_aux_module_flags
> +if { [llength $args] != 2 } {
> + error "dg-set-target-env-var: needs one argument"
> + return
> +}
> +dg-test $gfortran_test_path/[lindex $args 1] ""
> $gfortran_aux_module_flags
> +# cleanup-modules isn't intentionally invoked here.
> +}
I just noticed that this copy is missing Jakub's r215293 changes that he
had applied a few months *earlier* to the master copy of
'dg-compile-aux-modules', in 'gcc/testsuite/gfortran.dg/dg.exp', see
attached, and/or
.
I can't easily test it with the affected DejaGnu version 1.4.4 (which is
still the minimum version required now), but it tests fine with DejaGnu
1.5, and seems straight-forward, so I propose I commit "as obvious" these
changes to the 'gcc/testsuite/gfortran.dg/coarray/caf.exp' copy, too?
(It's exactly these changes missing to make the two copies identical.)
The other copy, created later, in
'gcc/testsuite/gcc.target/powerpc/ppc-fortran/ppc-fortran.exp' already
does exactly match the master copy.
And then, of course, we really should unify all 'dg-compile-aux-modules'
copies into one shared file. (But it's not completely straight-forward,
because of the handling of 'gfortran_test_path', and
'gfortran_aux_module_flags'.)
Grüße
Thomas
From 6278a9a2afb7d4d730c585f93d2bd435ed63f963 Mon Sep 17 00:00:00 2001
From: jakub
Date: Tue, 16 Sep 2014 09:35:00 +
Subject: [PATCH] PR fortran/56408 * gfortran.dg/dg.exp
(dg-compile-aux-modules): Workaround missing nexted dg-test call support in
dejaGNU 1.4.4.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215293 138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/testsuite/ChangeLog | 6 ++
gcc/testsuite/gfortran.dg/dg.exp | 12 +++-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index fdb706a8d8dd..4d3c96beee2c 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2014-09-16 Jakub Jelinek
+
+ PR fortran/56408
+ * gfortran.dg/dg.exp (dg-compile-aux-modules): Workaround
+ missing nexted dg-test call support in dejaGNU 1.4.4.
+
2014-09-15 Andi Kleen
* gcc.dg/pg-override.c: New test.
diff --git a/gcc/testsuite/gfortran.dg/dg.exp b/gcc/testsuite/gfortran.dg/dg.exp
index e8c39231db00..6bd69e6c88d0 100644
--- a/gcc/testsuite/gfortran.dg/dg.exp
+++ b/gcc/testsuite/gfortran.dg/dg.exp
@@ -39,8 +39,18 @@ proc dg-compile-aux-modules { args } {
error "dg-set-target-env-var: needs one argument"
return
}
+
+set level [info level]
+if { [info procs dg-save-unknown] != [list] } {
+ rename dg-save-unknown dg-save-unknown-level-$level
+}
+
dg-test $gfortran_test_path/[lindex $args 1] "" $gfortran_aux_module_flags
-# cleanup-modules isn't intentionally invoked here.
+# cleanup-modules is intentionally not invoked here.
+
+if { [info procs dg-save-unknown-level-$level] != [list] } {
+ rename dg-save-unknown-level-$level dg-save-unknown
+}
}
# Main loop.
--
2.17.1
signature.asc
Description: PGP signature
Re: RFA: PATCH to gimple-fold.c for c++/80916, bogus "static but not defined" warning
Hi, sorry for late reply - I did not identify it as a patch to symbol table. Indeed we want can_refer_decl_in_current_unit_p is a good place to test this. Is there a reason to resrict this to functions with no body? I see that we may be able to inline the function, but all the devirtualization code works by first turning call to a direct call and inlining later. We would need to teach the code that it can't devirtualize without inlining (which can be done by the speculative call macinery) and probably we will need to check that the function body does not contain some calls to similar symbols. We don't have support for this (do we want to do that in future)? For GCC 9 it would thus seem more consistent to simply return false on all symbols with this combination of flags. We probably also can teach symtab verifiers that we do not contain any references to such symbols. Thanks, Honza > Ping^3? > > On Wed, Feb 13, 2019 at 4:28 PM Jason Merrill wrote: > > > > Ping^2 > > > > On Mon, Feb 4, 2019 at 4:09 PM Jason Merrill wrote: > > > > > > Ping > > > > > > On Fri, Jan 25, 2019 at 10:06 AM Jason Merrill wrote: > > > > > > > > Here we warn because i::dispatch has internal linkage (because l > > > > does) and is never instantiated (because the vtable is never emitted). > > > > The regression happened because devirtualization started adding it to > > > > cgraph as a possible target. I think the way to fix this is to avoid > > > > adding an undefined internal function to cgraph as a possible target, > > > > since it is not, in fact, possible for it to be the actual target. > > > > > > > > I think that the best place to fix this would be in > > > > can_refer_decl_in_current_unit_p, since the same reasoning applies to > > > > other possible references. But we could fix it only in > > > > gimple_get_virt_method_for_vtable. > > > > > > > > First patch tested x86_64-pc-linux-gnu. > > > >
Re: Fix canonical types of atomic types
> > + /* Atomic types increase minimal alignment. We must to do so as well
> > + or we get duplicated canonical types. See PR88686. */
> > + if ((TYPE_QUALS (cand) & TYPE_QUAL_ATOMIC))
> > +{
> > + /* See if this object can map to a basic atomic type. */
> > + tree atomic_type = find_atomic_core_type (cand);
>
> build_qualified_type handles the case this function returns NULL,
> I think you should as well.
Done.
>
> > + if (TYPE_ALIGN (atomic_type) == TYPE_ALIGN (cand)
> > + && TYPE_ALIGN (base) < TYPE_ALIGN (cand))
>
> Why the second condition? build_qualified_type simply does
>
> if (((type_quals & TYPE_QUAL_ATOMIC) == TYPE_QUAL_ATOMIC))
> {
> /* See if this object can map to a basic atomic type. */
> tree atomic_type = find_atomic_core_type (type);
> if (atomic_type)
> {
> /* Ensure the alignment of this type is compatible with
> the required alignment of the atomic type. */
> if (TYPE_ALIGN (atomic_type) > TYPE_ALIGN (t))
> SET_TYPE_ALIGN (t, TYPE_ALIGN (atomic_type));
>
> without caring for TYPE_ALIGN of the base type.A
It only increases the alignment if necessary but if the alignment
is kept, it is handled by the earlier code. So i have dropped this.
>
> Note we seem to happily accept build_aligned_type that produce
> under-aligned atomics :/
Yep :(
This is updated patch I re-tested x86_64-linux and comitted.
Index: ChangeLog
===
--- ChangeLog (revision 269281)
+++ ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2019-02-28 Jan Hubicka
+
+ PR lto/88585
+ * tree.c (find_atomic_core_type): Move ahead in file.
+ (check_base_type): Correctly compare alignments of atomic types.
+
2019-02-28 H.J. Lu
PR target/89455
Index: tree.c
===
--- tree.c (revision 269280)
+++ tree.c (working copy)
@@ -6329,51 +6329,11 @@ check_lang_type (const_tree cand, const_
return lang_hooks.types.type_hash_eq (cand, base);
}
-/* Returns true iff unqualified CAND and BASE are equivalent. */
-
-bool
-check_base_type (const_tree cand, const_tree base)
-{
- return (TYPE_NAME (cand) == TYPE_NAME (base)
- /* Apparently this is needed for Objective-C. */
- && TYPE_CONTEXT (cand) == TYPE_CONTEXT (base)
- /* Check alignment. */
- && TYPE_ALIGN (cand) == TYPE_ALIGN (base)
- && attribute_list_equal (TYPE_ATTRIBUTES (cand),
- TYPE_ATTRIBUTES (base)));
-}
-
-/* Returns true iff CAND is equivalent to BASE with TYPE_QUALS. */
-
-bool
-check_qualified_type (const_tree cand, const_tree base, int type_quals)
-{
- return (TYPE_QUALS (cand) == type_quals
- && check_base_type (cand, base)
- && check_lang_type (cand, base));
-}
-
-/* Returns true iff CAND is equivalent to BASE with ALIGN. */
-
-static bool
-check_aligned_type (const_tree cand, const_tree base, unsigned int align)
-{
- return (TYPE_QUALS (cand) == TYPE_QUALS (base)
- && TYPE_NAME (cand) == TYPE_NAME (base)
- /* Apparently this is needed for Objective-C. */
- && TYPE_CONTEXT (cand) == TYPE_CONTEXT (base)
- /* Check alignment. */
- && TYPE_ALIGN (cand) == align
- && attribute_list_equal (TYPE_ATTRIBUTES (cand),
- TYPE_ATTRIBUTES (base))
- && check_lang_type (cand, base));
-}
-
/* This function checks to see if TYPE matches the size one of the built-in
atomic types, and returns that core atomic type. */
static tree
-find_atomic_core_type (tree type)
+find_atomic_core_type (const_tree type)
{
tree base_atomic_type;
@@ -6410,6 +6370,58 @@ find_atomic_core_type (tree type)
return base_atomic_type;
}
+/* Returns true iff unqualified CAND and BASE are equivalent. */
+
+bool
+check_base_type (const_tree cand, const_tree base)
+{
+ if (TYPE_NAME (cand) != TYPE_NAME (base)
+ /* Apparently this is needed for Objective-C. */
+ || TYPE_CONTEXT (cand) != TYPE_CONTEXT (base)
+ || !attribute_list_equal (TYPE_ATTRIBUTES (cand),
+ TYPE_ATTRIBUTES (base)))
+return false;
+ /* Check alignment. */
+ if (TYPE_ALIGN (cand) == TYPE_ALIGN (base))
+return true;
+ /* Atomic types increase minimal alignment. We must to do so as well
+ or we get duplicated canonical types. See PR88686. */
+ if ((TYPE_QUALS (cand) & TYPE_QUAL_ATOMIC))
+{
+ /* See if this object can map to a basic atomic type. */
+ tree atomic_type = find_atomic_core_type (cand);
+ if (atomic_type && TYPE_ALIGN (atomic_type) == TYPE_ALIGN (cand))
+ return true;
+}
+ return false;
+}
+
+/* Returns true iff CAND is equivalent to BASE with TYPE_QUALS. */
+
+bool
+check_qualified_type (const_tree cand, const_tree
Re: [arm][RFC] PR target/88469 fix incorrect argument passing with 64-bit bitfields
On 2/28/19 1:10 PM, Richard Earnshaw (lists) wrote:
> On 27/01/2019 11:20, Bernd Edlinger wrote:
>>
>> $ arm-linux-gnueabihf-gcc -march=armv5te -O3 -S test.c
>> $ cat test.s
>> f:
>> @ args = 12, pretend = 0, frame = 0
>> @ frame_needed = 0, uses_anonymous_args = 0
>> @ link register save eliminated.
>> push{r4, r5}
>> mov r0, #8
>> ldrdr4, [sp, #12]
>
> So this is wrong; before the compiler can use 'f' it has to copy it to a
> suitably aligned location; it can't directly reuse the value on the
> stack as that is not sufficiently aligned for the type.
>
Yes, meanwhile I found out that the value would be copied in a new place
if an address was taken, but there is an issue with
output_move_double not checking the value's MEM_ALIGN.
>>
>> So isn't this wrong code, returning 8 for alignof when it is really 4,
>> and wouldn't it crash on armv5 and armv6 with SCTLR.U=0 ?
>
> Returning 8 is correct; since that is the alignment of the type; but GCC
> does need to copy underaligned types to suitably aligned memory before
> it uses them; it must not use the *value* that is passed directly,
> unless it can prove that doing so is safe (and as you point out, on
> armv5 it is not).
>
> I think technically, this is separate bug from the PCS one that was
> fixed, so needs a new PR.
>
Could you have a look at the patch I sent to fix the wrong code issue:
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00248.html
Is there a chance that this can still go into gcc-9?
Or do I have to to open a PR for it first?
Thanks
Bernd.
Re: [PATCH] i386: Identify Westmere from PCLMUL
On Thu, Feb 28, 2019 at 2:50 PM H.J. Lu wrote:
>
> Since AES has been removed from Westmere in GCC 9, we should identify
> Westmere from PCLMUL, instead of AES.
>
> PR target/89455
> * config/i386/i386.c (get_builtin_code_for_version): Identify
> Westmere from PCLMUL, instead of AES.
OK.
Thanks,
Uros.
> ---
> gcc/config/i386/i386.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index b8357a7db5d..c8f9957163b 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -31992,10 +31992,10 @@ get_builtin_code_for_version (tree decl, tree
> *predicate_list)
> priority = P_PROC_SSSE3;
> break;
> case PROCESSOR_NEHALEM:
> - if (new_target->x_ix86_isa_flags & OPTION_MASK_ISA_AES)
> + if (new_target->x_ix86_isa_flags & OPTION_MASK_ISA_PCLMUL)
> {
> arg_str = "westmere";
> - priority = P_AES;
> + priority = P_PCLMUL;
> }
> else
> {
> --
> 2.20.1
>
[committed] Add testcases for already fixed PR c/89521
Hi!
These testcases were actually also fixed by the PR89520 fix (the ICE was
during expansion, but only because convert.c made invalid transformation).
The following patch adds those to the testsuite so that we can close the PR,
tested on x86_64-linux, committed to trunk as obvious.
2019-02-28 Jakub Jelinek
PR c/89521
* gcc.dg/pr89521-1.c: New test.
* gcc.dg/pr89521-2.c: New test.
--- gcc/testsuite/gcc.dg/pr89521-1.c.jj 2019-02-28 14:46:18.333843992 +0100
+++ gcc/testsuite/gcc.dg/pr89521-1.c2019-02-28 14:46:42.268458231 +0100
@@ -0,0 +1,13 @@
+/* PR c/89521 */
+/* { dg-do compile } */
+/* { dg-options "-Ofast -w" } */
+
+#define A(name) __typeof (__builtin_##name (0)) name (); long name##1 () {
return name (1); }
+#define B(name) A(name) A(name##f) A(name##l)
+B (ceil)
+B (floor)
+B (round)
+B (trunc)
+B (nearbyint)
+B (rint)
+B (logb)
--- gcc/testsuite/gcc.dg/pr89521-2.c.jj 2019-02-28 14:46:21.517792675 +0100
+++ gcc/testsuite/gcc.dg/pr89521-2.c2019-02-28 14:46:56.754224768 +0100
@@ -0,0 +1,42 @@
+/* PR c/89521 */
+/* { dg-do compile } */
+/* { dg-options "-Ofast -w" } */
+
+#define A(name) __typeof (__builtin_##name (0)) name (); \
+ float name##1 () { return name (1); } \
+ double name##2 () { return name (1); }
+#define B(name) A(name) A(name##l)
+B (cosh)
+B (exp)
+B (exp10)
+B (exp2)
+B (expm1)
+B (gamma)
+B (j0)
+B (j1)
+B (lgamma)
+B (pow10)
+B (sinh)
+B (tgamma)
+B (y0)
+B (y1)
+B (acos)
+B (acosh)
+B (asin)
+B (asinh)
+B (atan)
+B (atanh)
+B (cbrt)
+B (cos)
+B (erf)
+B (erfc)
+B (log)
+B (log10)
+B (log2)
+B (log1p)
+B (sin)
+B (tan)
+B (tanh)
+B (sqrt)
+B (fabs)
+B (logb)
Jakub
[PATCH] i386: Identify Westmere from PCLMUL
Since AES has been removed from Westmere in GCC 9, we should identify
Westmere from PCLMUL, instead of AES.
PR target/89455
* config/i386/i386.c (get_builtin_code_for_version): Identify
Westmere from PCLMUL, instead of AES.
---
gcc/config/i386/i386.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b8357a7db5d..c8f9957163b 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -31992,10 +31992,10 @@ get_builtin_code_for_version (tree decl, tree
*predicate_list)
priority = P_PROC_SSSE3;
break;
case PROCESSOR_NEHALEM:
- if (new_target->x_ix86_isa_flags & OPTION_MASK_ISA_AES)
+ if (new_target->x_ix86_isa_flags & OPTION_MASK_ISA_PCLMUL)
{
arg_str = "westmere";
- priority = P_AES;
+ priority = P_PCLMUL;
}
else
{
--
2.20.1
[committed] Fix ARM ICE on glibc (PR target/89434)
Hi! 0x8000 (in RTL (const_int 0x8000)) is valid the "I" constraint and should be allowed for sbcs, but because HOST_WIDE_INT is 64-bit, UINTVAL (operands[2]) == -UINTVAL (operands[3]) is actually not true for that. Fixed thusly, bootstrapped/regtested on armv7hl-linux-gnueabi, preapproved in the PR by Kyrill, committed to trunk. Sorry for the breakage. Note, using UINTVAL actually isn't necessary, I used it for the fear that there might be UB in the compiler, but because these values must be valid SImode CONST_INTs and -INTVAL is only UB for 0x8000 which is not a valid SImode CONST_INT, we don't need to negate in unsigned type. 2019-02-28 Jakub Jelinek PR target/89434 * config/arm/arm.md (*subsi3_carryin_compare_const): Use trunc_int_for_mode (-INTVAL (...), SImode), just instead of -UINTVAL (...). --- gcc/config/arm/arm.md.jj2019-02-25 11:32:02.914684615 +0100 +++ gcc/config/arm/arm.md 2019-02-26 14:41:41.128767480 +0100 @@ -1185,7 +1187,9 @@ (define_insn "*subsi3_carryin_compare_co (minus:SI (plus:SI (match_dup 1) (match_operand:SI 3 "arm_neg_immediate_operand" "L")) (ltu:SI (reg:CC_C CC_REGNUM) (const_int 0] - "TARGET_32BIT && UINTVAL (operands[2]) == -UINTVAL (operands[3])" + "TARGET_32BIT + && (INTVAL (operands[2]) + == trunc_int_for_mode (-INTVAL (operands[3]), SImode))" "sbcs\\t%0, %1, #%n3" [(set_attr "conds" "set") (set_attr "type" "adcs_imm")] Jakub
Fixing ifcvt issue as exposed by BZ89430
To solve BZ89430 the followings are needed,
(1) The code below in noce_try_cmove_arith needs to be fixed.
/* ??? We could handle this if we knew that a load from A or B could
not trap or fault. This is also true if we've already loaded
from the address along the path from ENTRY. */
else if (may_trap_or_fault_p (a) || may_trap_or_fault_p (b))
return FALSE;
Finding dominating memory access could help to decide whether the memory access
following the conditional move is valid or not.
* If there is a dominating memory write to the same memory address in test_bb
as the one from x=a, it is always safe.
* When the dominating memory access to the same memory address in test_bb is a
read, for the load out of x=a, it is always safe. For the store out of x=a, if
the memory is on stack, it is still safe.
Besides, there is a bug around rearranging the then_bb and else_bb layout,
which needs to be fixed.
(2) The fix by https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02998.html is an
overkill. If the write target following conditional move is a memory access, it
exits shortly.
if (!set_b && MEM_P (orig_x))
/* We want to avoid store speculation to avoid cases like
if (pthread_mutex_trylock(mutex))
++global_variable;
Rather than go to much effort here, we rely on the SSA optimizers,
which do a good enough job these days. */
return FALSE;
It looks a bit hard for compiler to know the program semantic is related to
mutex and avoid store speculation. Without removing this overkill, the fix
mentioned by (1) would not work. Any idea? An alternative solution is to detect
the following pattern conservatively,
if (a_function_call(...))
++local_variable;
If the local_variable doesn't have address taken at all in current function, it
mustn't be a pthread mutex lock semantic, and then the following patch would
work to solve (1) and pass the last case as described in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430.
Index: gcc/cse.c
===
--- gcc/cse.c (revision 268256)
+++ gcc/cse.c (working copy)
@@ -540,7 +540,6 @@
already as part of an already processed extended basic block. */
static sbitmap cse_visited_basic_blocks;
-static bool fixed_base_plus_p (rtx x);
static int notreg_cost (rtx, machine_mode, enum rtx_code, int);
static int preferable (int, int, int, int);
static void new_basic_block (void);
@@ -606,30 +605,7 @@
static const struct rtl_hooks cse_rtl_hooks = RTL_HOOKS_INITIALIZER;
-/* Nonzero if X has the form (PLUS frame-pointer integer). */
-static bool
-fixed_base_plus_p (rtx x)
-{
- switch (GET_CODE (x))
-{
-case REG:
- if (x == frame_pointer_rtx || x == hard_frame_pointer_rtx)
- return true;
- if (x == arg_pointer_rtx && fixed_regs[ARG_POINTER_REGNUM])
- return true;
- return false;
-
-case PLUS:
- if (!CONST_INT_P (XEXP (x, 1)))
- return false;
- return fixed_base_plus_p (XEXP (x, 0));
-
-default:
- return false;
-}
-}
-
/* Dump the expressions in the equivalence class indicated by CLASSP.
This function is used only for debugging. */
DEBUG_FUNCTION void
Index: gcc/ifcvt.c
===
--- gcc/ifcvt.c (revision 268256)
+++ gcc/ifcvt.c (working copy)
@@ -76,6 +76,9 @@
/* Whether conditional execution changes were made. */
static int cond_exec_changed_p;
+/* bitmap for stack frame pointer definition insns. */
+static bitmap bba_sets_sfp;
+
/* Forward references. */
static int count_bb_insns (const_basic_block);
static bool cheap_bb_rtx_cost_p (const_basic_block, profile_probability, int);
@@ -99,6 +102,7 @@
edge, int);
static void noce_emit_move_insn (rtx, rtx);
static rtx_insn *block_has_only_trap (basic_block);
+static void collect_all_fp_insns (void);
/* Count the number of non-jump active insns in BB. */
@@ -2029,6 +2033,110 @@
return true;
}
+/* Return true if MEM x is on stack. a_insn contains x, if it exists. */
+
+static bool
+noce_mem_is_on_stack (rtx_insn *a_insn, const_rtx x)
+{
+ df_ref use;
+
+ gcc_assert (x);
+ gcc_assert (MEM_P (x));
+
+ /* Early exits if find base register is a stack register. */
+ rtx a = XEXP (x, 0);
+ if (fixed_base_plus_p(a))
+return true;
+
+ if (!a_insn)
+return false;
+
+ /* Check if x is on stack. Assume a mem expression using registers
+ related to stack register is always on stack. */
+ FOR_EACH_INSN_USE (use, a_insn)
+{
+ if (bitmap_bit_p (bba_sets_sfp, DF_REF_REGNO (use)))
+return true;
+}
+
+ return false;
+}
+
+/* Always return true, if there is a dominating write.
+
+ When there is a dominating read from memory on stack,
+ 1) if x = a is a memory read, return true.
+ 2) if x = a is a memory write, return true if the memory is on stack.
+ This
Re: [arm][RFC] PR target/88469 fix incorrect argument passing with 64-bit bitfields
On 27/01/2019 11:20, Bernd Edlinger wrote:
> Hi,
>
> I know I am a bit late on the party.
Sorry for the delay replying, I've been off sick...
>
> But I have a question...
>
> Consider this test case:
>
> $ cat test.c
> struct s {
> int a, b;
> } __attribute__((aligned(8)));
>
> struct s f0;
> int f(int a, int b, int c, int d, int e, struct s f)
> {
> f0 = f;
> return __alignof(f);
This is equivalent to writing __alignof (struct s), so the returned
value should be 8.
HOWEVER, f itself is just a value in terms of the PCS, so it is correct
for it to be passed at SP+4.
> }
>
> $ arm-linux-gnueabihf-gcc -march=armv5te -O3 -S test.c
> $ cat test.s
> f:
> @ args = 12, pretend = 0, frame = 0
> @ frame_needed = 0, uses_anonymous_args = 0
> @ link register save eliminated.
> push{r4, r5}
> mov r0, #8
> ldrdr4, [sp, #12]
So this is wrong; before the compiler can use 'f' it has to copy it to a
suitably aligned location; it can't directly reuse the value on the
stack as that is not sufficiently aligned for the type.
> ldr r3, .L4
> strdr4, [r3]
> pop {r4, r5}
> bx lr
>
> I am pretty sure, although there is no warning, this ABI changed in GCC 5.2
There was no explicit ABI for overaligned types in the past; so anything
could have happened.
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473m/dom1361290002364.html
> says:
>
> "In ARMv5TE, or in ARMv6 when SCTLR.U is 0, LDRD and STRD doubleword data
> transfers must be
> eight-byte aligned. Use ALIGN 8 before memory allocation directives such as
> DCQ if the data
> is to be accessed using LDRD or STRD. This is not required in ARMv6 when
> SCTLR.U is 1, or in
> ARMv7, because in these versions, doubleword data transfers can be
> word-aligned."
>
>
> So isn't this wrong code, returning 8 for alignof when it is really 4,
> and wouldn't it crash on armv5 and armv6 with SCTLR.U=0 ?
Returning 8 is correct; since that is the alignment of the type; but GCC
does need to copy underaligned types to suitably aligned memory before
it uses them; it must not use the *value* that is passed directly,
unless it can prove that doing so is safe (and as you point out, on
armv5 it is not).
I think technically, this is separate bug from the PCS one that was
fixed, so needs a new PR.
>
>
> Bernd.
>
Thanks,
R.
[wwwdocs][arm] Update for PR target/88469
This patch to wwwdocs updates the changes file for the fix to PR target/88469 in gcc-9. Committed. Index: htdocs/gcc-9/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v retrieving revision 1.46 diff -u -r1.46 changes.html --- htdocs/gcc-9/changes.html 26 Feb 2019 18:40:04 - 1.46 +++ htdocs/gcc-9/changes.html 28 Feb 2019 10:29:37 - @@ -28,6 +28,18 @@ Caveats + +On Arm targets (arm*-*-*), +https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469;>a bug +in the implementation of the procedure call standard (AAPCS) +in the GCC 6, 7 and 8 releases has been fixed: a structure +containing a bit-field based on a 64-bit integral type and where +no other element in a structure required 64-bit alignment could be +passed incorrectly to functions. This is an ABI change. If the +option -Wpsabi is enabled (on by default) the +compiler will emit a diagnostic note for code that might be +affected. + Support for a number of older systems and recently unmaintained or untested target ports of GCC has been declared obsolete in GCC 9. Unless there is activity to revive them, the
Re: libgo patch committed: Run examples
Hi Ian,
> On Thu, Feb 21, 2019 at 1:47 AM Andreas Schwab wrote:
>>
>> On Feb 20 2019, Ian Lance Taylor wrote:
>>
>> > if test x$hasoutput = xtrue; then
>> > - echo ' {"'$n'", '$j', "'"$output"'", '$unordered'},'
>> > + echo ' {"'$n'", '$j', "'"$(cat example2.txt)"'", '$unordered'},'
>>
>> That still has a problematic echo with backslashes.
>
> How does this version look? Does it fix the problem?
it does indeed: just tested on i386-pc-solaris2.11 and
sparc-sun-solaris2.11 without issues.
Thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
