Re: [committed] Remove bogus initial lines from test.
> Hi!
>
> I've noticed
> FAIL: g++.dg/lto/odr-8 cp_lto_odr-8_1.o assemble, -O0 -flto
> -flto-partition=none -fuse-linker-plugin
> FAIL: g++.dg/lto/odr-8 cp_lto_odr-8_1.o assemble, -O2 -flto
> -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects
> FAIL: g++.dg/lto/odr-8 cp_lto_odr-8_1.o assemble, -O0 -flto
> -flto-partition=1to1 -fno-use-linker-plugin
> FAIL: g++.dg/lto/odr-8 cp_lto_odr-8_1.o assemble, -O2 -flto
> -flto-partition=1to1 -fno-use-linker-plugin
> FAIL: g++.dg/lto/odr-8 cp_lto_odr-8_1.o assemble, -O0 -flto
> -fuse-linker-plugin -fno-fat-lto-objects
> FAIL: g++.dg/lto/odr-8 cp_lto_odr-8_1.o assemble, -O2 -flto
> -fuse-linker-plugin
> on both x86_64-linux and i686-linux, dunno how those lines made it into the
> test. Anyway, fixed thusly, tested on x86_64-linux, test passes now,
> committed to trunk as obvious.
Ah, sorry.
I had bit of problem git oversmarting me on this commint. I was in my
branch and then switched to master, but instead that I created another
branch of same name as master where I made and comitted the original
patch. Then noticed that push does nothing so worked out that I am in
bogus branch. After that I removed the branch and used diff I produced
earlier to bring it over to trunk, but for some reason in that diff the
testcase was relative to time I added the file and not new file.
I had to do that twice since first time I ended in detached head and I
gess second time I failed to check that testcase is OK.
Eventually I hope to get smarter than git :)
Honza
>
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index ea37d69fa88..8e99328feb2 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,13 +1,16 @@
> 2020-01-15 Jakub Jelinek
>
> + PR lto/91576
> + * g++.dg/lto/odr-8_1.C: Remove bogus initial lines.
> +
> PR target/93009
> * gcc.target/i386/avx512vl-pr93009.c: New test.
>
> 2020-01-14 Jan Hubicka
>
> PR lto/91576
> - * testsuite/g++.dg/lto/odr-8_0.C: New testcase.
> - * testsuite/g++.dg/lto/odr-8_1.C: New testcase.
> + * g++.dg/lto/odr-8_0.C: New testcase.
> + * g++.dg/lto/odr-8_1.C: New testcase.
>
> 2020-01-14 David Malcolm
>
> diff --git a/gcc/testsuite/g++.dg/lto/odr-8_1.C
> b/gcc/testsuite/g++.dg/lto/odr-8_1.C
> index 742df8cc906..cbcd15d76ad 100644
> --- a/gcc/testsuite/g++.dg/lto/odr-8_1.C
> +++ b/gcc/testsuite/g++.dg/lto/odr-8_1.C
> @@ -1,6 +1,3 @@
> a/gcc/testsuite/g++.dg/lto/odr-8_1.C
> -+++ b/gcc/testsuite/g++.dg/lto/odr-8_1.C
> -@@ -1,9 +1,9 @@
> struct a {char c; a() {} a(struct a &) {}}; // { dg-lto-message "one type
> needs to be constructed while other not" }
> extern int test (struct a *a);
> int
>
> Jakub
>
Re: Fix for LTO compromised autoconf test in libiberty
On Jan 14 2020, Jeff Law wrote: > On Tue, 2020-01-14 at 23:21 +0100, Andreas Schwab wrote: >> On Jan 14 2020, Jeff Law wrote: >> >> > diff --git a/libiberty/aclocal.m4 b/libiberty/aclocal.m4 >> > index bf8a907100f..381ed3b27e3 100644 >> > --- a/libiberty/aclocal.m4 >> > +++ b/libiberty/aclocal.m4 >> > @@ -147,7 +147,7 @@ if test $ac_cv_os_cray = yes; then >> > fi >> > >> > AC_CACHE_CHECK(stack direction for C alloca, ac_cv_c_stack_direction, >> > -[AC_TRY_RUN([find_stack_direction () >> > +[AC_TRY_RUN([__attribute__ ((noclone,noinline)) find_stack_direction () >> >> That makes the test GCC specific, which doesn't actually need the test >> in the first place. That looks pointless. > It's used by alloca.c to implement a C based alloca. Nothing uses C alloca. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: GCC 8 backports
Hi.
There's one more backport commit I've just tested and installed.
Martin
>From 67c0ee2c48a5e154bf00fa8326536881a92e287c Mon Sep 17 00:00:00 2001
From: Jan Hubicka
Date: Sun, 14 Apr 2019 22:56:45 +0200
Subject: [PATCH] Backport d2a0371d2641e85c5e6ca396029be32204d976df
gcc/ChangeLog:
2019-04-14 Jan Hubicka
PR lto/89358
* ipa-devirt.c (skip_in_fields_list_p): New.
(odr_types_equivalent_p): Use it.
gcc/testsuite/ChangeLog:
2019-04-14 Jan Hubicka
PR lto/89358
* g++.dg/lto/pr89358_0.C: New testcase.
* g++.dg/lto/pr89358_1.C: New testcase.
---
gcc/ipa-devirt.c | 22 --
gcc/testsuite/g++.dg/lto/pr89358_0.C | 11 +++
gcc/testsuite/g++.dg/lto/pr89358_1.C | 7 +++
3 files changed, 38 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/lto/pr89358_0.C
create mode 100644 gcc/testsuite/g++.dg/lto/pr89358_1.C
diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index 5b6b130fa3a..380102020f9 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -1241,6 +1241,24 @@ warn_types_mismatch (tree t1, tree t2, location_t loc1, location_t loc2)
inform (loc_t2, "the incompatible type is defined here");
}
+/* Return true if T should be ignored in TYPE_FIELDS for ODR comparsion. */
+
+static bool
+skip_in_fields_list_p (tree t)
+{
+ if (TREE_CODE (t) != FIELD_DECL)
+return true;
+ /* C++ FE introduces zero sized fields depending on -std setting, see
+ PR89358. */
+ if (DECL_SIZE (t)
+ && integer_zerop (DECL_SIZE (t))
+ && DECL_ARTIFICIAL (t)
+ && DECL_IGNORED_P (t)
+ && !DECL_NAME (t))
+return true;
+ return false;
+}
+
/* Compare T1 and T2, report ODR violations if WARN is true and set
WARNED to true if anything is reported. Return true if types match.
If true is returned, the types are also compatible in the sense of
@@ -1525,9 +1543,9 @@ odr_types_equivalent_p (tree t1, tree t2, bool warn, bool *warned,
f1 = TREE_CHAIN (f1), f2 = TREE_CHAIN (f2))
{
/* Skip non-fields. */
- while (f1 && TREE_CODE (f1) != FIELD_DECL)
+ while (f1 && skip_in_fields_list_p (f1))
f1 = TREE_CHAIN (f1);
- while (f2 && TREE_CODE (f2) != FIELD_DECL)
+ while (f2 && skip_in_fields_list_p (f2))
f2 = TREE_CHAIN (f2);
if (!f1 || !f2)
break;
diff --git a/gcc/testsuite/g++.dg/lto/pr89358_0.C b/gcc/testsuite/g++.dg/lto/pr89358_0.C
new file mode 100644
index 000..aebd2127c0c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lto/pr89358_0.C
@@ -0,0 +1,11 @@
+/* { dg-do link } */
+/* { dg-options "-std=c++17" } */
+#include
+
+extern void test();
+
+int main()
+{
+std::map m;
+test();
+}
diff --git a/gcc/testsuite/g++.dg/lto/pr89358_1.C b/gcc/testsuite/g++.dg/lto/pr89358_1.C
new file mode 100644
index 000..68b80a37662
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lto/pr89358_1.C
@@ -0,0 +1,7 @@
+/* { dg-options "-std=c++14" } */
+#include
+
+void test()
+{
+std::map m;
+}
--
2.24.1
[PATCH] Record outer non-cleanup region in TREE EH.
Hi.
The patch is about caching of outer non-CLEANUP region
for a leh_state. It's a spin off the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93199#c19,
now it's not using a hash_map, but a cached value in leh_state.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
2020-01-14 Martin Liska
PR tree-optimization/93199
* tree-eh.c (struct leh_state): Add
new field outer_non_cleanup.
(cleanup_is_dead_in): Pass leh_state instead
of eh_region. Add a checking that state->outer_non_cleanup
points to outer non-clean up region.
(lower_try_finally): Record outer_non_cleanup
for this_state.
(lower_catch): Likewise.
(lower_eh_filter): Likewise.
(lower_eh_must_not_throw): Likewise.
(lower_cleanup): Likewise.
---
gcc/tree-eh.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index dc80f574a2c..802c25d4b4b 100644
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -356,6 +356,9 @@ struct leh_state
split out into a separate structure so that we don't have to
copy so much when processing other nodes. */
struct leh_tf_state *tf;
+
+ /* Outer non-clean up region. */
+ eh_region outer_non_cleanup;
};
struct leh_tf_state
@@ -1624,7 +1627,8 @@ decide_copy_try_finally (int ndests, bool may_throw, gimple_seq finally)
return f_estimate < 40 || f_estimate * 2 < sw_estimate * 3;
}
-/* REG is the enclosing region for a possible cleanup region, or the region
+/* REG is current region of a LEH state.
+ is the enclosing region for a possible cleanup region, or the region
itself. Returns TRUE if such a region would be unreachable.
Cleanup regions within a must-not-throw region aren't actually reachable
@@ -1632,10 +1636,18 @@ decide_copy_try_finally (int ndests, bool may_throw, gimple_seq finally)
routine will call terminate before unwinding. */
static bool
-cleanup_is_dead_in (eh_region reg)
+cleanup_is_dead_in (leh_state *state)
{
- while (reg && reg->type == ERT_CLEANUP)
-reg = reg->outer;
+ if (flag_checking)
+{
+ eh_region reg = state->cur_region;
+ while (reg && reg->type == ERT_CLEANUP)
+ reg = reg->outer;
+
+ gcc_assert (reg == state->outer_non_cleanup);
+}
+
+ eh_region reg = state->cur_region;
return (reg && reg->type == ERT_MUST_NOT_THROW);
}
@@ -1658,15 +1670,17 @@ lower_try_finally (struct leh_state *state, gtry *tp)
this_tf.try_finally_expr = tp;
this_tf.top_p = tp;
this_tf.outer = state;
- if (using_eh_for_cleanups_p () && !cleanup_is_dead_in (state->cur_region))
+ if (using_eh_for_cleanups_p () && !cleanup_is_dead_in (state))
{
this_tf.region = gen_eh_region_cleanup (state->cur_region);
this_state.cur_region = this_tf.region;
+ this_state.outer_non_cleanup = state->outer_non_cleanup;
}
else
{
this_tf.region = NULL;
this_state.cur_region = state->cur_region;
+ this_state.outer_non_cleanup = this_state.cur_region;
}
this_state.ehp_region = state->ehp_region;
@@ -1768,6 +1782,7 @@ lower_catch (struct leh_state *state, gtry *tp)
{
try_region = gen_eh_region_try (state->cur_region);
this_state.cur_region = try_region;
+ this_state.outer_non_cleanup = this_state.cur_region;
}
lower_eh_constructs_1 (&this_state, gimple_try_eval_ptr (tp));
@@ -1781,6 +1796,7 @@ lower_catch (struct leh_state *state, gtry *tp)
emit_resx (&new_seq, try_region);
this_state.cur_region = state->cur_region;
+ this_state.outer_non_cleanup = state->outer_non_cleanup;
this_state.ehp_region = try_region;
/* Add eh_seq from lowering EH in the cleanup sequence after the cleanup
@@ -1857,6 +1873,7 @@ lower_eh_filter (struct leh_state *state, gtry *tp)
this_region = gen_eh_region_allowed (state->cur_region,
gimple_eh_filter_types (inner));
this_state.cur_region = this_region;
+ this_state.outer_non_cleanup = this_state.cur_region;
}
lower_eh_constructs_1 (&this_state, gimple_try_eval_ptr (tp));
@@ -1912,6 +1929,7 @@ lower_eh_must_not_throw (struct leh_state *state, gtry *tp)
TREE_USED (this_region->u.must_not_throw.failure_decl) = 1;
this_state.cur_region = this_region;
+ this_state.outer_non_cleanup = this_state.cur_region;
}
lower_eh_constructs_1 (&this_state, gimple_try_eval_ptr (tp));
@@ -1929,12 +1947,13 @@ lower_cleanup (struct leh_state *state, gtry *tp)
eh_region this_region = NULL;
struct leh_tf_state fake_tf;
gimple_seq result;
- bool cleanup_dead = cleanup_is_dead_in (state->cur_region);
+ bool cleanup_dead = cleanup_is_dead_in (state);
if (flag_exceptions && !cleanup_dead)
{
this_region = gen_eh_region_cleanup (state->cur_region);
this_state.cur_region = this_region;
+ this
Re: [PATCH v7] Missed function specialization + partial devirtualization
Hi, On Tue, 14 Jan 2020 at 15:35, luoxhu wrote: > > Hi, > > On 2020/1/14 21:03, Martin Liška wrote: > > On 1/13/20 4:23 AM, luoxhu wrote: > >> Thanks a lot! Rebased & updated, will commit below patch shortly when > >> git push is ready. > > > > Hello. > > > > I'm pretty sure the patch contains failure of the following tests: > > > > FAIL: gcc.dg/tree-prof/crossmodule-indir-call-topn-1.c > > scan-pgo-wpa-ipa-dump profile_estimate "2 \\(200.00%\\) speculations > > produced." > > FAIL: gcc.dg/tree-prof/crossmodule-indir-call-topn-2.c > > scan-pgo-wpa-ipa-dump profile_estimate "2 \\(200.00%\\) speculations > > produced." > > FAIL: gcc.dg/tree-prof/crossmodule-indircall-1.c execution, > > -fprofile-use -D_PROFILE_USE > > > > Can you please take a look? > > Thanks for reporting. > This seems fails only on some platforms. I tested it before commit and > just verified it again on my Power8-LE with gcc.sum andd log attached. > I suppose you are trying on x86 platforms and sorry that I don't have one > at hand, these failures should be easy to fix, If not, I will investigate > it after returning from Chinese New Year vacation. > It fails on arm and aarch64 too. > make check-gcc RUNTESTFLAGS="tree-prof.exp=crossmodule-* -v -v" > log > > > Thanks, > > Martin
[PATCH] PR tree-optimization/93247 - ICE in get_load_store_type
My earlier update_epilogue_loop_vinfo patch introduced an ICE on these
tests for AVX512. If we use pattern stmts, STMT_VINFO_GATHER_SCATTER_P
is valid for both the original stmt and the pattern stmt, but
STMT_VINFO_MEMORY_ACCESS_TYPE is valid only for the latter.
Tested on x86_64-linux-gnu and aarch64-linux-gnu. OK to install?
Richard
2020-01-15 Richard Sandiford
gcc/
PR tree-optimization/93247
* tree-vect-loop.c (update_epilogue_loop_vinfo): Check the access
type of the stmt that we're going to vectorize.
gcc/testsuite/
PR tree-optimization/93247
* gcc.dg/vect/pr93247-1.c: New test.
* gcc.dg/vect/pr93247-2.c: Likewise.
diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index faf816116de..8e318a037a7 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -8452,7 +8452,8 @@ update_epilogue_loop_vinfo (class loop *epilogue, tree
advance)
updated offset we set using ADVANCE. Instead we have to make sure the
reference in the data references point to the corresponding copy of
the original in the epilogue. */
- if (STMT_VINFO_MEMORY_ACCESS_TYPE (stmt_vinfo) == VMAT_GATHER_SCATTER)
+ if (STMT_VINFO_MEMORY_ACCESS_TYPE (vect_stmt_to_vectorize (stmt_vinfo))
+ == VMAT_GATHER_SCATTER)
{
DR_REF (dr)
= simplify_replace_tree (DR_REF (dr), NULL_TREE, NULL_TREE,
diff --git a/gcc/testsuite/gcc.dg/vect/pr93247-1.c
b/gcc/testsuite/gcc.dg/vect/pr93247-1.c
new file mode 100644
index 000..a3087b81d67
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr93247-1.c
@@ -0,0 +1,49 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=skylake" { target x86_64-*-* i?86-*-* } } */
+
+typedef struct {
+ unsigned num;
+} VEC_tree_base;
+
+enum {
+ LTO_DECL_STREAM_NAMESPACE_DECL,
+ LTO_DECL_STREAM_LABEL_DECL,
+ LTO_N_DECL_STREAMS
+};
+
+struct lto_tree_ref_encoder {
+ VEC_tree_base *trees;
+} typedef *lto_out_decl_state_ptr;
+
+typedef struct {
+ lto_out_decl_state_ptr vec[1];
+} VEC_lto_out_decl_state_ptr_base;
+
+VEC_lto_out_decl_state_ptr_base *a;
+int f;
+long g;
+int
+fn1(struct lto_tree_ref_encoder *p1) {
+ int i;
+ long b;
+ i = 0;
+ for (; i < LTO_N_DECL_STREAMS; i++) {
+struct lto_tree_ref_encoder c = *p1;
+int d;
+VEC_tree_base *e = c.trees;
+d = e ? e->num : 0;
+b += d;
+ }
+ return b;
+}
+int
+fn2() {
+ lto_out_decl_state_ptr h;
+ struct lto_tree_ref_encoder j;
+ unsigned k;
+ for (; k < f; k++) {
+h = a->vec[k];
+j = *h;
+g += fn1(&j);
+ }
+}
diff --git a/gcc/testsuite/gcc.dg/vect/pr93247-2.c
b/gcc/testsuite/gcc.dg/vect/pr93247-2.c
new file mode 100644
index 000..e229e15d87a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/pr93247-2.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-march=skylake-avx512" { target x86_64-*-*
i?86-*-* } } */
+
+int
+foo (int *a, double *b, int *c)
+{
+ int f, g = 0;
+ for (f = 0; f < 100; f++)
+if (b[f] && c[a[f]])
+ g++;
+ return g;
+}
Backport: Add support for gcc as git submodule of another repository.
This is a straight backport of
https://gcc.gnu.org/ml/gcc-patches/2018-04/msg01352.html. Without this
contrib/gcc_update fails if run from a worktree, while git pull works
just fine.
Pushed to the gcc-8 branch.
diff --git a/contrib/ChangeLog b/contrib/ChangeLog
index 039dc251ebb..47ac7c47dcc 100644
--- a/contrib/ChangeLog
+++ b/contrib/ChangeLog
@@ -1,3 +1,10 @@
+2020-01-15 Richard Earnshaw
+
+ Backport:
+ 2018-05-01 Jim Wilson
+
+ * gcc_update: Check for .git as a file.
+
2019-08-16 Uros Bizjak
* test_summary: Do not escape "=".
diff --git a/contrib/gcc_update b/contrib/gcc_update
index a33bb543902..c9c71548f53 100755
--- a/contrib/gcc_update
+++ b/contrib/gcc_update
@@ -286,7 +286,7 @@ p
esac
# Check for known version control systems.
-if [ -d .git ]; then
+if [ -d .git ] || [ -f .git ]; then
GCC_GIT=${GCC_GIT-${GIT-git}}
vcs_type="git"
elif [ -d .hg ]; then
Re: [PATCH 2/2] Optimize alias subset recording
On Tue, 14 Jan 2020, Richard Biener wrote:
> On Tue, 14 Jan 2020, Richard Biener wrote:
>
> > On Tue, 14 Jan 2020, Richard Biener wrote:
> >
> > > When an alias-set is an already existing subset there is no need
> > > to re-record its children as childs of the parent.
> > >
> > > I noticed this when doing 1/2 as trivial opportunity to squeeze
> > > back some performance for the non-caching recursion I added. The
> > > whole thing is still quadratic in the depth of the structure, of course.
> > >
> > > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > >
> > > Since I'm curious I'll test a variant which checks the children
> > > are actually recorded before pushing this ... (OK, maybe I shouldn't
> > > do this...)
> >
> > So I did it. It works but for
> >
> > FAIL: gnat.dg/interface2.adb 3 blank line(s) in output
> > FAIL: gnat.dg/interface2.adb (test for excess errors)
> > UNRESOLVED: gnat.dg/interface2.adb compilation failed to produce
> > executable
> > FAIL: gnat.dg/predicate2_main.adb 3 blank line(s) in output
> > FAIL: gnat.dg/predicate2_main.adb (test for excess errors)
> >
> > which ICE with the adjusted patch below. Ada calls
> > record_component_aliases itself and eventually too early when
> > some types are not yet complete? Which would also mean that
> > subsets could be failed to recorded properly.
> >
> > So I'm still inclined to go with the original non-checking patch
> > unless Eric tells me I'm completely wrong and there isn't a
> > latent issue in the Ada frontend.
>
> Btw, all the dance the Ada FE performs in relate_alias_sets isn't
> going to work with LTO unless it is no longer necessary anyways.
>
> Oh, and we miss libbacktrace support for GNAT bug boxes, for the
> above I'd like to know whether its from record_component_aliases
> calls or calls of record_alias_subset.
And if I delay checking until we actually look for subsets
(alias_sets_conflict or alias_set_subset_of), verifying we collected
all subsets that fails when building the RTS, for example when
building g-awk.adb. The patch below does that verification,
it doesn't actually look for a case where the final answer of
those predicates is wrong though.
It seems that Ada is the only frontend affected by this "bug" so
I pushed the original change.
Richard.
diff --git a/gcc/alias.c b/gcc/alias.c
index 9629b5a9f48..ffb2af9b34f 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -154,7 +154,7 @@ static int base_alias_check (rtx, rtx, rtx, rtx,
machine_mode,
machine_mode);
static rtx find_base_value (rtx);
static int mems_in_disjoint_alias_sets_p (const_rtx, const_rtx);
-static alias_set_entry *get_alias_set_entry (alias_set_type);
+static alias_set_entry *get_alias_set_entry (alias_set_type, bool = false);
static tree decl_for_component_ref (tree);
static int write_dependence_p (const_rtx,
const_rtx, machine_mode, rtx,
@@ -372,9 +372,37 @@ rtx_refs_may_alias_p (const_rtx x, const_rtx mem, bool
tbaa_p)
such an entry, or NULL otherwise. */
static inline alias_set_entry *
-get_alias_set_entry (alias_set_type alias_set)
+get_alias_set_entry (alias_set_type alias_set, bool check)
{
- return (*alias_sets)[alias_set];
+ alias_set_entry *e = (*alias_sets)[alias_set];
+ if (check && e && e->children)
+{
+ bitmap_obstack_initialize (NULL);
+ auto_vec worklist;
+ auto_bitmap visited;
+ hash_map::iterator iter
+ = e->children->begin ();
+ for (; iter != e->children->end (); ++iter)
+ worklist.safe_push ((*iter).first);
+ while (!worklist.is_empty ())
+ {
+ alias_set_type subset = worklist.pop ();
+ if (!bitmap_set_bit (visited, subset))
+ continue;
+ alias_set_entry *se = (*alias_sets)[subset];
+ if (se && se->children)
+ for (iter = se->children->begin ();
+iter != se->children->end (); ++iter)
+ {
+ if ((*iter).first == alias_set)
+ continue;
+ gcc_assert (e->children->get ((*iter).first) != NULL);
+ worklist.safe_push ((*iter).first);
+ }
+ }
+ bitmap_obstack_release (NULL);
+}
+ return e;
}
/* Returns nonzero if the alias sets for MEM1 and MEM2 are such that
@@ -404,7 +432,7 @@ alias_set_subset_of (alias_set_type set1, alias_set_type
set2)
return true;
/* Check if set1 is a subset of set2. */
- ase2 = get_alias_set_entry (set2);
+ ase2 = get_alias_set_entry (set2, true);
if (ase2 != 0
&& (ase2->has_zero_child
|| (ase2->children && ase2->children->get (set1
@@ -433,7 +461,7 @@ alias_set_subset_of (alias_set_type set1, alias_set_type
set2)
get_alias_set for more details. */
if (ase2 && ase2->has_pointer)
{
- alias_set_entry *ase1 = get_alias_set_entry (set1);
+ alias_set_entry *ase1 = get_alias_set_entry (set1, true);
if (ase1 && ase1->is_pointer)
Re: [PATCH v7] Missed function specialization + partial devirtualization
Hi. I know the root cause of the failure and will send a patch soon to the mailing list. Martin
Re: [PATCH] contrib: git descr/undescr aliases fix for older git
On 14/01/2020 23:44, Jakub Jelinek wrote:
On Tue, Jan 14, 2020 at 10:12:09AM +0100, Jakub Jelinek wrote:
Note, for the scripts running on sourceware I also had to remove those tags/
part, but thought it is because of running against the bare repo.
We could change those into ^\\(tags/\\)\\?basepoints/gcc- etc. (and adjust
the \\1.
I'll post a patch.
Here it is, tested on x86_64-linux, ok for trunk?
2020-01-15 Jakub Jelinek
* gcc-git-customization.sh: Handle output of older git which doesn't
print tags/ prefixes before branchpoint/gcc-.
--- contrib/gcc-git-customization.sh.jj 2020-01-13 15:15:00.472393417 +0100
+++ contrib/gcc-git-customization.sh2020-01-14 15:09:33.364634082 +0100
@@ -22,8 +22,8 @@ git config alias.svn-rev '!f() { rev=$1;
# Add git commands to convert git commit to monotonically increasing revision number
# and vice versa
-git config alias.gcc-descr \!"f() { if test \${1:-no} = --full; then r=\$(git describe --all
--abbrev=40 --match 'basepoints/gcc-[0-9]*' \${2:-master} | sed -n 's,^tags/basepoints/gcc-,r,p'); expr
match \${r:-no} '^r[0-9]\\+\$' >/dev/null && r=\${r}-0-g\$(git rev-parse \${2:-master}); test -n
\$r && echo \${r}; else git describe --all --match 'basepoints/gcc-[0-9]*' \${1:-master} | sed -n
's,^tags/basepoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\1-\\2,p;s,^tags/basepoints/gcc-\\([0-9]\\+\\)\$,r\\1-0,p';
fi; }; f"
-git config alias.gcc-undescr \!"f() { o=\$(git config --get gcc-config.upstream); r=\$(echo \$1 | sed -n
's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n 's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z
\$r && echo Invalid id \$1 && exit 1; h=\$(git rev-parse --verify --quiet
\${o:-origin}/releases/gcc-\$r); test -z \$h && h=\$(git rev-parse --verify --quiet
\${o:-origin}/master); p=\$(git describe --all --match 'basepoints/gcc-'\$r \$h | sed -n
's,^tags/basepoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\1,p;s,^tags/basepoints/gcc-[0-9]\\+\$,0,p'); git
rev-parse --verify \$h~\$(expr \$p - \$n); }; f"
+git config alias.gcc-descr \!"f() { if test \${1:-no} = --full; then r=\$(git describe --all
--abbrev=40 --match 'basepoints/gcc-[0-9]*' \${2:-master} | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-,r,p');
expr match \${r:-no} '^r[0-9]\\+\$' >/dev/null && r=\${r}-0-g\$(git rev-parse \${2:-master});
test -n \$r && echo \${r}; else git describe --all --match 'basepoints/gcc-[0-9]*' \${1:-master} |
sed -n
's,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\2-\\3,p;s,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)\$,r\\2-0,p';
fi; }; f"
+git config alias.gcc-undescr \!"f() { o=\$(git config --get gcc-config.upstream); r=\$(echo \$1 | sed -n
's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n 's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z
\$r && echo Invalid id \$1 && exit 1; h=\$(git rev-parse --verify --quiet
\${o:-origin}/releases/gcc-\$r); test -z \$h && h=\$(git rev-parse --verify --quiet
\${o:-origin}/master); p=\$(git describe --all --match 'basepoints/gcc-'\$r \$h | sed -n
's,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\2,p;s,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+\$,0,p');
git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"
# Make diff on MD files uses "(define" as a function marker.
# Use this in conjunction with a .gitattributes file containing
Jakub
I'm not going to pretend I understand all that foo. But these are your
aliases anyway.
OK.
R.
Re: [PATCH] PR tree-optimization/93247 - ICE in get_load_store_type
On Wed, Jan 15, 2020 at 11:15 AM Richard Sandiford
wrote:
>
> My earlier update_epilogue_loop_vinfo patch introduced an ICE on these
> tests for AVX512. If we use pattern stmts, STMT_VINFO_GATHER_SCATTER_P
> is valid for both the original stmt and the pattern stmt, but
> STMT_VINFO_MEMORY_ACCESS_TYPE is valid only for the latter.
>
> Tested on x86_64-linux-gnu and aarch64-linux-gnu. OK to install?
OK.
Richard.
> Richard
>
>
> 2020-01-15 Richard Sandiford
>
> gcc/
> PR tree-optimization/93247
> * tree-vect-loop.c (update_epilogue_loop_vinfo): Check the access
> type of the stmt that we're going to vectorize.
>
> gcc/testsuite/
> PR tree-optimization/93247
> * gcc.dg/vect/pr93247-1.c: New test.
> * gcc.dg/vect/pr93247-2.c: Likewise.
>
> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
> index faf816116de..8e318a037a7 100644
> --- a/gcc/tree-vect-loop.c
> +++ b/gcc/tree-vect-loop.c
> @@ -8452,7 +8452,8 @@ update_epilogue_loop_vinfo (class loop *epilogue, tree
> advance)
> updated offset we set using ADVANCE. Instead we have to make sure
> the
> reference in the data references point to the corresponding copy of
> the original in the epilogue. */
> - if (STMT_VINFO_MEMORY_ACCESS_TYPE (stmt_vinfo) == VMAT_GATHER_SCATTER)
> + if (STMT_VINFO_MEMORY_ACCESS_TYPE (vect_stmt_to_vectorize (stmt_vinfo))
> + == VMAT_GATHER_SCATTER)
> {
> DR_REF (dr)
> = simplify_replace_tree (DR_REF (dr), NULL_TREE, NULL_TREE,
> diff --git a/gcc/testsuite/gcc.dg/vect/pr93247-1.c
> b/gcc/testsuite/gcc.dg/vect/pr93247-1.c
> new file mode 100644
> index 000..a3087b81d67
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/vect/pr93247-1.c
> @@ -0,0 +1,49 @@
> +/* { dg-do compile } */
> +/* { dg-additional-options "-march=skylake" { target x86_64-*-* i?86-*-* } }
> */
> +
> +typedef struct {
> + unsigned num;
> +} VEC_tree_base;
> +
> +enum {
> + LTO_DECL_STREAM_NAMESPACE_DECL,
> + LTO_DECL_STREAM_LABEL_DECL,
> + LTO_N_DECL_STREAMS
> +};
> +
> +struct lto_tree_ref_encoder {
> + VEC_tree_base *trees;
> +} typedef *lto_out_decl_state_ptr;
> +
> +typedef struct {
> + lto_out_decl_state_ptr vec[1];
> +} VEC_lto_out_decl_state_ptr_base;
> +
> +VEC_lto_out_decl_state_ptr_base *a;
> +int f;
> +long g;
> +int
> +fn1(struct lto_tree_ref_encoder *p1) {
> + int i;
> + long b;
> + i = 0;
> + for (; i < LTO_N_DECL_STREAMS; i++) {
> +struct lto_tree_ref_encoder c = *p1;
> +int d;
> +VEC_tree_base *e = c.trees;
> +d = e ? e->num : 0;
> +b += d;
> + }
> + return b;
> +}
> +int
> +fn2() {
> + lto_out_decl_state_ptr h;
> + struct lto_tree_ref_encoder j;
> + unsigned k;
> + for (; k < f; k++) {
> +h = a->vec[k];
> +j = *h;
> +g += fn1(&j);
> + }
> +}
> diff --git a/gcc/testsuite/gcc.dg/vect/pr93247-2.c
> b/gcc/testsuite/gcc.dg/vect/pr93247-2.c
> new file mode 100644
> index 000..e229e15d87a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/vect/pr93247-2.c
> @@ -0,0 +1,12 @@
> +/* { dg-do compile } */
> +/* { dg-additional-options "-march=skylake-avx512" { target x86_64-*-*
> i?86-*-* } } */
> +
> +int
> +foo (int *a, double *b, int *c)
> +{
> + int f, g = 0;
> + for (f = 0; f < 100; f++)
> +if (b[f] && c[a[f]])
> + g++;
> + return g;
> +}
Re: [PATCH] Record outer non-cleanup region in TREE EH.
On Wed, Jan 15, 2020 at 10:57 AM Martin Liška wrote:
>
> Hi.
>
> The patch is about caching of outer non-CLEANUP region
> for a leh_state. It's a spin off the
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93199#c19,
> now it's not using a hash_map, but a cached value in leh_state.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
+
+ eh_region reg = state->cur_region;
shouldn't that be reg = state->outer_non_cleanup?
- if (using_eh_for_cleanups_p () && !cleanup_is_dead_in (state->cur_region))
+ if (using_eh_for_cleanups_p () && !cleanup_is_dead_in (state))
{
this_tf.region = gen_eh_region_cleanup (state->cur_region);
this_state.cur_region = this_tf.region;
+ this_state.outer_non_cleanup = state->outer_non_cleanup;
}
else
{
this_tf.region = NULL;
this_state.cur_region = state->cur_region;
+ this_state.outer_non_cleanup = this_state.cur_region;
why can't we copy state->outer_non_cleanup here?
}
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2020-01-14 Martin Liska
>
> PR tree-optimization/93199
> * tree-eh.c (struct leh_state): Add
> new field outer_non_cleanup.
> (cleanup_is_dead_in): Pass leh_state instead
> of eh_region. Add a checking that state->outer_non_cleanup
> points to outer non-clean up region.
> (lower_try_finally): Record outer_non_cleanup
> for this_state.
> (lower_catch): Likewise.
> (lower_eh_filter): Likewise.
> (lower_eh_must_not_throw): Likewise.
> (lower_cleanup): Likewise.
> ---
> gcc/tree-eh.c | 31 +--
> 1 file changed, 25 insertions(+), 6 deletions(-)
>
>
Re: [patch] contrib: Don't add push rules for personal and vendor spaces.
On 14/01/2020 14:55, Richard Earnshaw (lists) wrote: Originally, it seemed like a good idea to add automatic 'push' rules to the git configuration, so that personal- and vendor-space commits would automatically push to the right place. Unfortunately, this changes git's behaviour and with these settings "git push" will try to push all branches in a local tree up to the corresponding location on the server (ignoring the push.default setting). The only known mitigation for this is to ALWAYS use "git push ". So instead, we no-longer add those rules by default and will document the options on the wiki. We don't automatically remove the push entries but do print out the command that will do so, if the user so wishes. OK? * gcc-git-customization.sh: Explain why we want the user's upstream account name. Don't add push rules. Check if push rules have been added and suggest that they should be removed. * git-fetch-vendor.sh: Don't add push rules. I've now checked this in. R.
[PATCH] .gitattributes: Add *.md diff=md
Hi!
As discussed on IRC, this patch adds the .gitattributes part of the
better diff for *.md files customization.
Tested in a tree with contrib/gcc-git-customization.sh performed,
config/i386/i386.md diffing then nicely shows the pattern, and in
a tree without the customization, where it works as if the *.md diff=md
line wasn't there.
Ok for trunk (and eventually release branches)?
2020-01-15 Segher Boessenkool
Jakub Jelinek
* .gitattributes: Add *.md diff=md.
contrib/
* gcc-git-customization.sh: Change uses to use in comment.
diff --git a/.gitattributes b/.gitattributes
index 13debfd97e9..e75bfc595bf 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -4,3 +4,7 @@
*.[cCh] whitespace=indent-with-non-tab,space-before-tab,trailing-space
*.cc whitespace=indent-with-non-tab,space-before-tab,trailing-space
ChangeLog whitespace=indent-with-non-tab,space-before-tab,trailing-space
+# Make diff on MD files use "(define" as a function marker.
+# Use together with git config diff.md.xfuncname '^\(define.*$'
+# which is run by contrib/gcc-git-customization.sh too.
+*.md diff=md
diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index af7d210217f..f4261592b1d 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -25,7 +25,7 @@ git config alias.svn-rev '!f() { rev=$1; shift; git log --all
--grep="From-SVN:
git config alias.gcc-descr \!"f() { if test \${1:-no} = --full; then r=\$(git
describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*' \${2:-master} | sed
-n 's,^\\(tags/\\)\\?basepoints/gcc-,r,p'); expr match \${r:-no} '^r[0-9]\\+\$'
>/dev/null && r=\${r}-0-g\$(git rev-parse \${2:-master}); test -n \$r && echo
\${r}; else git describe --all --match 'basepoints/gcc-[0-9]*' \${1:-master} |
sed -n
's,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\2-\\3,p;s,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)\$,r\\2-0,p';
fi; }; f"
git config alias.gcc-undescr \!"f() { o=\$(git config --get
gcc-config.upstream); r=\$(echo \$1 | sed -n
's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n
's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z \$r && echo Invalid id \$1 &&
exit 1; h=\$(git rev-parse --verify --quiet \${o:-origin}/releases/gcc-\$r);
test -z \$h && h=\$(git rev-parse --verify --quiet \${o:-origin}/master);
p=\$(git describe --all --match 'basepoints/gcc-'\$r \$h | sed -n
's,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\2,p;s,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+\$,0,p');
git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"
-# Make diff on MD files uses "(define" as a function marker.
+# Make diff on MD files use "(define" as a function marker.
# Use this in conjunction with a .gitattributes file containing
# *.mddiff=md
git config diff.md.xfuncname '^\(define.*$'
Jakub
Re: [PATCH] Record outer non-cleanup region in TREE EH.
On 1/15/20 12:08 PM, Richard Biener wrote:
On Wed, Jan 15, 2020 at 10:57 AM Martin Liška wrote:
Hi.
The patch is about caching of outer non-CLEANUP region
for a leh_state. It's a spin off the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93199#c19,
now it's not using a hash_map, but a cached value in leh_state.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
+
+ eh_region reg = state->cur_region;
Huh, stupid mistake.
shouldn't that be reg = state->outer_non_cleanup?
- if (using_eh_for_cleanups_p () && !cleanup_is_dead_in (state->cur_region))
+ if (using_eh_for_cleanups_p () && !cleanup_is_dead_in (state))
{
this_tf.region = gen_eh_region_cleanup (state->cur_region);
this_state.cur_region = this_tf.region;
+ this_state.outer_non_cleanup = state->outer_non_cleanup;
}
else
{
this_tf.region = NULL;
this_state.cur_region = state->cur_region;
+ this_state.outer_non_cleanup = this_state.cur_region;
why can't we copy state->outer_non_cleanup here?
We can, I'm re-testing that patch.
Martin
}
Thanks,
Martin
gcc/ChangeLog:
2020-01-14 Martin Liska
PR tree-optimization/93199
* tree-eh.c (struct leh_state): Add
new field outer_non_cleanup.
(cleanup_is_dead_in): Pass leh_state instead
of eh_region. Add a checking that state->outer_non_cleanup
points to outer non-clean up region.
(lower_try_finally): Record outer_non_cleanup
for this_state.
(lower_catch): Likewise.
(lower_eh_filter): Likewise.
(lower_eh_must_not_throw): Likewise.
(lower_cleanup): Likewise.
---
gcc/tree-eh.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
Re: [PR90916] ICE in retrieve specialization
On 1/14/20 4:21 PM, Marek Polacek wrote: On Tue, Jan 14, 2020 at 04:10:07PM -0500, Nathan Sidwell wrote: 2020-01-14 Nathan Sidwell + PT c++/90916 Note this has PT instead of PR :). yeah, I caught the typo on the followup. Thanks for noticing! nathan -- Nathan Sidwell
Re: Analyzer committed to master (was Re: Analyzer status)
Hi David, > I've rebased and squashed the analyzer patch kit and squashed patch 2 > of the hash_table fix into it, and re-tested it successfully, so I've > pushed it to master (as 757bf1dff5e8cee34c0a75d06140ca972bfecfa7). > > I'm going to work through the various followup patches I had on my > branch and re-test and push to master those that seem appropriate. I'm seeing quite a number of failures on Solaris (both sparc and x86), but also some on 32-bit Linux/x86: Running target unix/-m32 +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 610) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 611) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 615) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 616) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 657) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 658) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 662) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 663) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 705) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 706) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 710) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 711) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 753) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 754) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 758) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 759) +FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors) I'll file PRs for the Solaris ones once I get to it. Wasn't analyzer supposed to be off by default, though? Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH v7] Missed function specialization + partial devirtualization
On 1/15/20 11:49 AM, Martin Liška wrote:
Hi.
I know the root cause of the failure and will send a patch soon
to the mailing list.
Martin
There's an obvious patch that I'm going to install. Note that
order of function call evaluation in a function call is undefined.
It's a similar issue we had some time ago in IPA VRP streaming.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Thanks,
Martin
>From 674f2a3f4786fb61576c9152446937d617b1b4ce Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Wed, 15 Jan 2020 11:49:48 +0100
Subject: [PATCH] Do not call streamer_read_hwi in a function call.
gcc/ChangeLog:
2020-01-15 Martin Liska
* ipa-profile.c (ipa_profile_read_edge_summary): Do not allow
2 calls of streamer_read_hwi in a function call.
---
gcc/ipa-profile.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/ipa-profile.c b/gcc/ipa-profile.c
index fc231c916b7..03272f20987 100644
--- a/gcc/ipa-profile.c
+++ b/gcc/ipa-profile.c
@@ -451,8 +451,9 @@ ipa_profile_read_edge_summary (class lto_input_block *ib, cgraph_edge *edge)
for (i = 0; i < len; i++)
{
-speculative_call_target item (streamer_read_hwi (ib),
- streamer_read_hwi (ib));
+unsigned int target_id = streamer_read_hwi (ib);
+int target_probability = streamer_read_hwi (ib);
+speculative_call_target item (target_id, target_probability);
csum->speculative_call_targets.safe_push (item);
}
}
--
2.24.1
[PATCH] middle-end/93273 - fix sinking clobbers across backedges
The previous work to fix PR93199 didn't take into account backedges
when defering insertion. The following simply avoids to defer in that
case since we know we'll not take secondary opportunities there.
Bootstrap & regtest on x86_64-unknown-linux-gnu in progress.
Richard.
2020-01-15 Richard Biener
PR middle-end/93273
* tree-eh.c (sink_clobbers): If we already visited the destination
block do not defer insertion.
(pass_lower_eh_dispatch::execute): Maintain BB_VISITED for
the purpose of defered insertion.
* g++.dg/torture/pr93273.C: New testcase.
---
gcc/ChangeLog | 8
gcc/testsuite/ChangeLog| 5 +
gcc/testsuite/g++.dg/torture/pr93273.C | 12
gcc/tree-eh.c | 4 +++-
4 files changed, 28 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/torture/pr93273.C
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 8ef85773d7a..a4d772b1c69 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-01-15 Richard Biener
+
+ PR middle-end/93273
+ * tree-eh.c (sink_clobbers): If we already visited the destination
+ block do not defer insertion.
+ (pass_lower_eh_dispatch::execute): Maintain BB_VISITED for
+ the purpose of defered insertion.
+
2020-01-15 Richard Biener
* alias.c (record_alias_subset): Avoid redundant work when
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 879d7b1d4a3..7ab3e33c134 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-01-15 Richard Biener
+
+ PR middle-end/93273
+ * g++.dg/torture/pr93273.C: New testcase.
+
2020-01-15 Joseph Myers
PR c/93072
diff --git a/gcc/testsuite/g++.dg/torture/pr93273.C
b/gcc/testsuite/g++.dg/torture/pr93273.C
new file mode 100644
index 000..229642b5456
--- /dev/null
+++ b/gcc/testsuite/g++.dg/torture/pr93273.C
@@ -0,0 +1,12 @@
+// { dg-do compile }
+
+void _setjmp(void *);
+struct S { ~S(); };
+void * (* fn)();
+void f();
+void g()
+{
+ S s;
+ _setjmp(fn());
+ []{ f(); }();
+}
diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index dc80f574a2c..454b22cddec 100644
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -3622,7 +3622,7 @@ sink_clobbers (basic_block bb,
gimple *first_sunk = NULL;
gimple *last_sunk = NULL;
- if (sunk)
+ if (sunk && !(succbb->flags & BB_VISITED))
dgsi = gsi_start (sunk[succbb->index]);
else
dgsi = gsi_after_labels (succbb);
@@ -3910,6 +3910,7 @@ pass_lower_eh_dispatch::execute (function *fun)
else if (!any_resx_to_process)
sink_clobbers (bb, NULL, &any_resx_to_process);
}
+ bb->flags &= ~BB_VISITED;
}
if (redirected)
{
@@ -3940,6 +3941,7 @@ pass_lower_eh_dispatch::execute (function *fun)
gsi_insert_seq_before (&gsi, sunk[bb->index], GSI_NEW_STMT);
sunk[bb->index] = NULL;
}
+ bb->flags |= BB_VISITED;
}
free (rpo);
free (sunk);
--
2.16.4
Re: [PATCH v7] Missed function specialization + partial devirtualization
> gcc/ChangeLog:
>
> 2020-01-15 Martin Liska
>
> * ipa-profile.c (ipa_profile_read_edge_summary): Do not allow
> 2 calls of streamer_read_hwi in a function call.
Good catch, Martin!
> ---
> gcc/ipa-profile.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/ipa-profile.c b/gcc/ipa-profile.c
> index fc231c916b7..03272f20987 100644
> --- a/gcc/ipa-profile.c
> +++ b/gcc/ipa-profile.c
> @@ -451,8 +451,9 @@ ipa_profile_read_edge_summary (class lto_input_block *ib,
> cgraph_edge *edge)
>
>for (i = 0; i < len; i++)
>{
> -speculative_call_target item (streamer_read_hwi (ib),
> - streamer_read_hwi (ib));
> +unsigned int target_id = streamer_read_hwi (ib);
> +int target_probability = streamer_read_hwi (ib);
> +speculative_call_target item (target_id, target_probability);
David, this may be interesting case for analyzer/warning. This surfaced
in LTO stremaing for second time quite recently and leads to hard to
find bugs.
While day before yesterday in pub I argued that warning for nested
function calls is not a good way since it would warn too often, perhaps
we want to have some way to annotate streamer functions to make it clear
that we do not want them to appear inside function call parameters where
evaluation order is undefined.
Honza
> csum->speculative_call_targets.safe_push (item);
>}
> }
> --
> 2.24.1
>
Add attribute to match *.md and *.pd to the git diff hook
The gcc-git-customization script sets up a diff hook to match (define as a function name hook so that diff -p style annotations will match a pattern name. This patch does the other half of this in the gcc configuration by matching *.pd and *.md to this new rule * .gitattributes: Use the md diff rule for *.md and *.pd. OK? diff --git a/.gitattributes b/.gitattributes index 13debfd97e9..4d6c031112c 100644 --- a/.gitattributes +++ b/.gitattributes @@ -4,3 +4,9 @@ *.[cCh] whitespace=indent-with-non-tab,space-before-tab,trailing-space *.cc whitespace=indent-with-non-tab,space-before-tab,trailing-space ChangeLog whitespace=indent-with-non-tab,space-before-tab,trailing-space + +# match '(define_' as a function name for diff headers. +# To use the following hook, you'll need to run: +# git config [--global] diff.md.xfuncname '\(define.*$' +# contrib/gcc-git-customization.sh will do this for you. +*.[mp]d diff=md
[PATCH] adjust object size computation for union accesses and PHIs (PR 92765)
The strcmp optimization newly introduced in GCC 10 relies on
the size of the smallest referenced array object to determine
whether the function can return zero. When the size of
the object is smaller than the length of the other string
argument the optimization folds the equality to false.
The bug report has identified a couple of problems here:
1) when the access to the array object is via a pointer to
a (possibly indirect) member of a union, in GIMPLE the pointer
may actually point to a different member than the one in
the original source code. Thus the size of the array may
appear to be smaller than in the source code which can then
result in the optimization being invalid.
2) when the pointer in the access may point to two or more
arrays of different size (i.e., it's the result of a PHI),
assuming it points to the smallest of them can also lead
to an incorrect result when the optimization is applied.
The attached patch adjusts the optimization to 1) avoid making
any assumptions about the sizes of objects accessed via union
types, and b) use the size of the largest object in PHI nodes.
Tested on x86_64-linux.
Martin
PR tree-optimization/92765 - wrong code for strcmp of a union member
gcc/testsuite/ChangeLog:
PR tree-optimization/92765
* gcc.dg/strlenopt-92.c: New test.
gcc/ChangeLog:
PR tree-optimization/92765
* tree-ssa-strlen.c (component_ref_via_union_p): New function.
(determine_min_objsize): Call it. Use the maximum object size
for PHI arguments.
diff --git a/gcc/testsuite/gcc.dg/strlenopt-92.c b/gcc/testsuite/gcc.dg/strlenopt-92.c
new file mode 100644
index 000..44ad5b88854
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/strlenopt-92.c
@@ -0,0 +1,94 @@
+/* PR tree-optimization/92765 - wrong code for strcmp of a union member
+ { dg-do run }
+ { dg-options "-O2 -Wall" } */
+
+#include "strlenopt.h"
+
+extern void free (void*);
+extern void* calloc (size_t, size_t);
+extern void* malloc (size_t);
+
+
+/* Test from comment #0. */
+struct S0 {
+ char a[2];
+};
+
+union U0 {
+ char b[4];
+ struct S0 s;
+};
+
+union U0 u0;
+union U0 *p0 = &u0;
+
+int test_0 ()
+{
+ u0.b[0] = 'a';
+ u0.b[1] = 'b';
+ u0.b[2] = '\0';
+
+ int x = memcmp (p0->s.a, "x", 2);
+
+ if (strcmp (p0->b, "ab"))
+abort ();
+
+ return x;
+}
+
+
+/* Test from comment #6. */
+union U1 { struct S1 { char a[2]; char b[2]; char c[2]; } s; char d[6]; } u1;
+
+__attribute__((noipa)) void
+barrier (char *p)
+{
+ asm volatile ("" : : "g" (p) : "memory");
+}
+
+__attribute__((noipa)) void
+test_1 (union U1 *x)
+{
+ char *p = (char *) &x->s.b;
+ barrier (p);
+ if (strcmp (&x->d[2], "cde"))
+abort ();
+}
+
+/* Test from comment #7. */
+
+__attribute__((noipa)) int
+barrier_copy (char *x, int y)
+{
+ asm volatile ("" : : "g" (x), "g" (y) : "memory");
+ if (y == 0)
+strcpy (x, "abcd");
+ return y;
+}
+
+__attribute__((noipa)) char *
+test_2 (int x)
+{
+ char *p;
+ if (x)
+p = malloc (2);
+ else
+p = calloc (16, 1);
+ if (barrier_copy (p, x))
+return p;
+ if (strcmp (p, "abcd") != 0)
+abort ();
+ return p;
+}
+
+
+int main (void)
+{
+ test_0 ();
+
+ strcpy (u1.d, "abcde");
+ test_1 (&u1);
+
+ free (test_2 (0));
+ free (test_2 (1));
+}
diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index ad9e98973b1..f4b6aadae47 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c
@@ -4087,6 +4087,29 @@ compute_string_length (int idx)
return string_leni;
}
+/* Returns true if REF is a reference to a member of a union type,
+ or a member of such a type (traversing all references along
+ the path). Used to avoid making assumptions about accesses
+ to members that could also be accessed by other members of
+ incompatible types. */
+
+static bool
+component_ref_via_union_p (tree ref)
+{
+ if (TREE_CODE (ref) == ADDR_EXPR)
+ref = TREE_OPERAND (ref, 0);
+
+ while (TREE_CODE (ref) == MEM_REF || handled_component_p (ref))
+{
+ tree type = TREE_TYPE (ref);
+ if (TREE_CODE (type) == UNION_TYPE)
+ return true;
+ ref = TREE_OPERAND (ref, 0);
+}
+
+ return false;
+}
+
/* Determine the minimum size of the object referenced by DEST expression
which must have a pointer type.
Return the minimum size of the object if successful or HWI_M1U when
@@ -4099,14 +4122,18 @@ determine_min_objsize (tree dest)
init_object_sizes ();
- if (compute_builtin_object_size (dest, 2, &size))
-return size;
-
/* Try to determine the size of the object through the RHS
of the assign statement. */
if (TREE_CODE (dest) == SSA_NAME)
{
gimple *stmt = SSA_NAME_DEF_STMT (dest);
+
+ /* Determine the size of the largest object when DEST refers
+ to two or more via a PHI, otherwise the smallest. */
+ int ostype = gimple_code (stmt) == GIMPLE_PHI ? 0 : 2;
+ if (compute_builtin_object_size (dest, ostype, &size))
+ return size;
+
if (!is_gimple_assign (stmt))
return HOST_WIDE_INT_M1U;
@@ -4118,6 +4145
Re: [PATCH] .gitattributes: Add *.md diff=md
On 15/01/2020 11:45, Jakub Jelinek wrote:
Hi!
As discussed on IRC, this patch adds the .gitattributes part of the
better diff for *.md files customization.
Tested in a tree with contrib/gcc-git-customization.sh performed,
config/i386/i386.md diffing then nicely shows the pattern, and in
a tree without the customization, where it works as if the *.md diff=md
line wasn't there.
Ok for trunk (and eventually release branches)?
2020-01-15 Segher Boessenkool
Jakub Jelinek
* .gitattributes: Add *.md diff=md.
contrib/
* gcc-git-customization.sh: Change uses to use in comment.
diff --git a/.gitattributes b/.gitattributes
index 13debfd97e9..e75bfc595bf 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -4,3 +4,7 @@
*.[cCh] whitespace=indent-with-non-tab,space-before-tab,trailing-space
*.cc whitespace=indent-with-non-tab,space-before-tab,trailing-space
ChangeLog whitespace=indent-with-non-tab,space-before-tab,trailing-space
+# Make diff on MD files use "(define" as a function marker.
+# Use together with git config diff.md.xfuncname '^\(define.*$'
+# which is run by contrib/gcc-git-customization.sh too.
+*.md diff=md
diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index af7d210217f..f4261592b1d 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -25,7 +25,7 @@ git config alias.svn-rev '!f() { rev=$1; shift; git log --all
--grep="From-SVN:
git config alias.gcc-descr \!"f() { if test \${1:-no} = --full; then r=\$(git describe --all
--abbrev=40 --match 'basepoints/gcc-[0-9]*' \${2:-master} | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-,r,p');
expr match \${r:-no} '^r[0-9]\\+\$' >/dev/null && r=\${r}-0-g\$(git rev-parse \${2:-master});
test -n \$r && echo \${r}; else git describe --all --match 'basepoints/gcc-[0-9]*' \${1:-master} |
sed -n
's,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\2-\\3,p;s,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)\$,r\\2-0,p';
fi; }; f"
git config alias.gcc-undescr \!"f() { o=\$(git config --get gcc-config.upstream); r=\$(echo \$1 | sed -n
's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n 's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z
\$r && echo Invalid id \$1 && exit 1; h=\$(git rev-parse --verify --quiet
\${o:-origin}/releases/gcc-\$r); test -z \$h && h=\$(git rev-parse --verify --quiet
\${o:-origin}/master); p=\$(git describe --all --match 'basepoints/gcc-'\$r \$h | sed -n
's,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\2,p;s,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+\$,0,p');
git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"
-# Make diff on MD files uses "(define" as a function marker.
+# Make diff on MD files use "(define" as a function marker.
# Use this in conjunction with a .gitattributes file containing
# *.mddiff=md
git config diff.md.xfuncname '^\(define.*$'
Jakub
I'd just posted nearly the same patch...
Suggest
*.[mp]d diff=md
Then match.pd will pick up this rule as well.
OK with that change.
R.
Re: Add attribute to match *.md and *.pd to the git diff hook
On 15/01/2020 13:17, Richard Earnshaw (lists) wrote: The gcc-git-customization script sets up a diff hook to match (define as a function name hook so that diff -p style annotations will match a pattern name. This patch does the other half of this in the gcc configuration by matching *.pd and *.md to this new rule * .gitattributes: Use the md diff rule for *.md and *.pd. OK? Dropped. Let's use Jakub's version. R.
Re: [PATCH] .gitattributes: Add *.md diff=md
On 15/01/2020 13:19, Richard Earnshaw (lists) wrote:
On 15/01/2020 11:45, Jakub Jelinek wrote:
Hi!
As discussed on IRC, this patch adds the .gitattributes part of the
better diff for *.md files customization.
Tested in a tree with contrib/gcc-git-customization.sh performed,
config/i386/i386.md diffing then nicely shows the pattern, and in
a tree without the customization, where it works as if the *.md diff=md
line wasn't there.
Ok for trunk (and eventually release branches)?
2020-01-15 Segher Boessenkool
Jakub Jelinek
* .gitattributes: Add *.md diff=md.
contrib/
* gcc-git-customization.sh: Change uses to use in comment.
diff --git a/.gitattributes b/.gitattributes
index 13debfd97e9..e75bfc595bf 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -4,3 +4,7 @@
*.[cCh] whitespace=indent-with-non-tab,space-before-tab,trailing-space
*.cc whitespace=indent-with-non-tab,space-before-tab,trailing-space
ChangeLog
whitespace=indent-with-non-tab,space-before-tab,trailing-space
+# Make diff on MD files use "(define" as a function marker.
+# Use together with git config diff.md.xfuncname '^\(define.*$'
+# which is run by contrib/gcc-git-customization.sh too.
+*.md diff=md
diff --git a/contrib/gcc-git-customization.sh
b/contrib/gcc-git-customization.sh
index af7d210217f..f4261592b1d 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -25,7 +25,7 @@ git config alias.svn-rev '!f() { rev=$1; shift; git
log --all --grep="From-SVN:
git config alias.gcc-descr \!"f() { if test \${1:-no} = --full; then
r=\$(git describe --all --abbrev=40 --match 'basepoints/gcc-[0-9]*'
\${2:-master} | sed -n 's,^\\(tags/\\)\\?basepoints/gcc-,r,p'); expr
match \${r:-no} '^r[0-9]\\+\$' >/dev/null && r=\${r}-0-g\$(git
rev-parse \${2:-master}); test -n \$r && echo \${r}; else git describe
--all --match 'basepoints/gcc-[0-9]*' \${1:-master} | sed -n
's,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\2-\\3,p;s,^\\(tags/\\)\\?basepoints/gcc-\\([0-9]\\+\\)\$,r\\2-0,p';
fi; }; f"
git config alias.gcc-undescr \!"f() { o=\$(git config --get
gcc-config.upstream); r=\$(echo \$1 | sed -n
's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n
's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z \$r && echo Invalid id
\$1 && exit 1; h=\$(git rev-parse --verify --quiet
\${o:-origin}/releases/gcc-\$r); test -z \$h && h=\$(git rev-parse
--verify --quiet \${o:-origin}/master); p=\$(git describe --all
--match 'basepoints/gcc-'\$r \$h | sed -n
's,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\2,p;s,^\\(tags/\\)\\?basepoints/gcc-[0-9]\\+\$,0,p');
git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"
-# Make diff on MD files uses "(define" as a function marker.
+# Make diff on MD files use "(define" as a function marker.
# Use this in conjunction with a .gitattributes file containing
# *.md diff=md
git config diff.md.xfuncname '^\(define.*$'
Jakub
I'd just posted nearly the same patch...
Suggest
*.[mp]d diff=md
Then match.pd will pick up this rule as well.
OK with that change.
R.
As discussed on IRC, the original is fine.
R.
Re: [PATCH v7] Missed function specialization + partial devirtualization
On Wed, Jan 15, 2020 at 1:37 PM Jan Hubicka wrote:
>
> > gcc/ChangeLog:
> >
> > 2020-01-15 Martin Liska
> >
> > * ipa-profile.c (ipa_profile_read_edge_summary): Do not allow
> > 2 calls of streamer_read_hwi in a function call.
>
> Good catch, Martin!
> > ---
> > gcc/ipa-profile.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/gcc/ipa-profile.c b/gcc/ipa-profile.c
> > index fc231c916b7..03272f20987 100644
> > --- a/gcc/ipa-profile.c
> > +++ b/gcc/ipa-profile.c
> > @@ -451,8 +451,9 @@ ipa_profile_read_edge_summary (class lto_input_block
> > *ib, cgraph_edge *edge)
> >
> >for (i = 0; i < len; i++)
> >{
> > -speculative_call_target item (streamer_read_hwi (ib),
> > - streamer_read_hwi (ib));
> > +unsigned int target_id = streamer_read_hwi (ib);
> > +int target_probability = streamer_read_hwi (ib);
> > +speculative_call_target item (target_id, target_probability);
>
> David, this may be interesting case for analyzer/warning. This surfaced
> in LTO stremaing for second time quite recently and leads to hard to
> find bugs.
>
> While day before yesterday in pub I argued that warning for nested
> function calls is not a good way since it would warn too often, perhaps
> we want to have some way to annotate streamer functions to make it clear
> that we do not want them to appear inside function call parameters where
> evaluation order is undefined.
Maybe one can always warn if you call the same function twice (and the
function appears to have side-effects)? Might fire too often for tree checking
functions tho.
Richard.
> Honza
> > csum->speculative_call_targets.safe_push (item);
> >}
> > }
> > --
> > 2.24.1
> >
>
[committed] Bump gcc/BASE-VER to 10.0.1 now that we are in stage4.
Hi! Committed to trunk. diff --git a/gcc/ChangeLog b/gcc/ChangeLog index 3099ec4143c..e0c961d059c 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,7 @@ +2020-01-15 Jakub Jelinek + + * BASE-VER: Bump to 10.0.1. + 2020-01-15 Richard Sandiford PR tree-optimization/93247 diff --git a/gcc/BASE-VER b/gcc/BASE-VER index a13e7b9c87e..1532420512a 100644 --- a/gcc/BASE-VER +++ b/gcc/BASE-VER @@ -1 +1 @@ -10.0.0 +10.0.1 Jakub
Re: [PATCH v7] Missed function specialization + partial devirtualization
> On Wed, Jan 15, 2020 at 1:37 PM Jan Hubicka wrote:
> >
> > > gcc/ChangeLog:
> > >
> > > 2020-01-15 Martin Liska
> > >
> > > * ipa-profile.c (ipa_profile_read_edge_summary): Do not allow
> > > 2 calls of streamer_read_hwi in a function call.
> >
> > Good catch, Martin!
> > > ---
> > > gcc/ipa-profile.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/gcc/ipa-profile.c b/gcc/ipa-profile.c
> > > index fc231c916b7..03272f20987 100644
> > > --- a/gcc/ipa-profile.c
> > > +++ b/gcc/ipa-profile.c
> > > @@ -451,8 +451,9 @@ ipa_profile_read_edge_summary (class lto_input_block
> > > *ib, cgraph_edge *edge)
> > >
> > >for (i = 0; i < len; i++)
> > >{
> > > -speculative_call_target item (streamer_read_hwi (ib),
> > > - streamer_read_hwi (ib));
> > > +unsigned int target_id = streamer_read_hwi (ib);
> > > +int target_probability = streamer_read_hwi (ib);
> > > +speculative_call_target item (target_id, target_probability);
> >
> > David, this may be interesting case for analyzer/warning. This surfaced
> > in LTO stremaing for second time quite recently and leads to hard to
> > find bugs.
> >
> > While day before yesterday in pub I argued that warning for nested
> > function calls is not a good way since it would warn too often, perhaps
> > we want to have some way to annotate streamer functions to make it clear
> > that we do not want them to appear inside function call parameters where
> > evaluation order is undefined.
>
> Maybe one can always warn if you call the same function twice (and the
> function appears to have side-effects)? Might fire too often for tree
> checking
> functions tho.
Yep warning always when function calls appear within different
parameters of a function calls seems like something we would not be able
to enable by default...
Honza
>
> Richard.
>
> > Honza
> > > csum->speculative_call_targets.safe_push (item);
> > >}
> > > }
> > > --
> > > 2.24.1
> > >
> >
[PATCH, WWW-DOCS] Deprecate non-standard hexadecimal BOZ constants
Add a note the the Fortran changes to the effect that non-standard BOZ constants are deprecated. Is the wording OK? -- https://www.codethink.co.uk/privacy.html
Re: [PATCH] Record outer non-cleanup region in TREE EH.
On 1/15/20 12:48 PM, Martin Liška wrote:
On 1/15/20 12:08 PM, Richard Biener wrote:
On Wed, Jan 15, 2020 at 10:57 AM Martin Liška wrote:
Hi.
The patch is about caching of outer non-CLEANUP region
for a leh_state. It's a spin off the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93199#c19,
now it's not using a hash_map, but a cached value in leh_state.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
+
+ eh_region reg = state->cur_region;
Huh, stupid mistake.
shouldn't that be reg = state->outer_non_cleanup?
- if (using_eh_for_cleanups_p () && !cleanup_is_dead_in (state->cur_region))
+ if (using_eh_for_cleanups_p () && !cleanup_is_dead_in (state))
{
this_tf.region = gen_eh_region_cleanup (state->cur_region);
this_state.cur_region = this_tf.region;
+ this_state.outer_non_cleanup = state->outer_non_cleanup;
}
else
{
this_tf.region = NULL;
this_state.cur_region = state->cur_region;
+ this_state.outer_non_cleanup = this_state.cur_region;
why can't we copy state->outer_non_cleanup here?
We can, I'm re-testing that patch.
Martin
}
Thanks,
Martin
gcc/ChangeLog:
2020-01-14 Martin Liska
PR tree-optimization/93199
* tree-eh.c (struct leh_state): Add
new field outer_non_cleanup.
(cleanup_is_dead_in): Pass leh_state instead
of eh_region. Add a checking that state->outer_non_cleanup
points to outer non-clean up region.
(lower_try_finally): Record outer_non_cleanup
for this_state.
(lower_catch): Likewise.
(lower_eh_filter): Likewise.
(lower_eh_must_not_throw): Likewise.
(lower_cleanup): Likewise.
---
gcc/tree-eh.c | 31 +--
1 file changed, 25 insertions(+), 6 deletions(-)
There's a tested version.
Ready to be installed?
Thanks,
Martin
>From a3f2486df27cbad26988b6f8bc6adcb1752657cb Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Tue, 14 Jan 2020 14:41:52 +0100
Subject: [PATCH] Record outer non-cleanup region in TREE EH.
gcc/ChangeLog:
2020-01-14 Martin Liska
PR tree-optimization/93199
* tree-eh.c (struct leh_state): Add
new field outer_non_cleanup.
(cleanup_is_dead_in): Pass leh_state instead
of eh_region. Add a checking that state->outer_non_cleanup
points to outer non-clean up region.
(lower_try_finally): Record outer_non_cleanup
for this_state.
(lower_catch): Likewise.
(lower_eh_filter): Likewise.
(lower_eh_must_not_throw): Likewise.
(lower_cleanup): Likewise.
---
gcc/tree-eh.c | 30 --
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/gcc/tree-eh.c b/gcc/tree-eh.c
index dc80f574a2c..7fc99d658bd 100644
--- a/gcc/tree-eh.c
+++ b/gcc/tree-eh.c
@@ -356,6 +356,9 @@ struct leh_state
split out into a separate structure so that we don't have to
copy so much when processing other nodes. */
struct leh_tf_state *tf;
+
+ /* Outer non-clean up region. */
+ eh_region outer_non_cleanup;
};
struct leh_tf_state
@@ -1624,7 +1627,8 @@ decide_copy_try_finally (int ndests, bool may_throw, gimple_seq finally)
return f_estimate < 40 || f_estimate * 2 < sw_estimate * 3;
}
-/* REG is the enclosing region for a possible cleanup region, or the region
+/* REG is current region of a LEH state.
+ is the enclosing region for a possible cleanup region, or the region
itself. Returns TRUE if such a region would be unreachable.
Cleanup regions within a must-not-throw region aren't actually reachable
@@ -1632,10 +1636,18 @@ decide_copy_try_finally (int ndests, bool may_throw, gimple_seq finally)
routine will call terminate before unwinding. */
static bool
-cleanup_is_dead_in (eh_region reg)
+cleanup_is_dead_in (leh_state *state)
{
- while (reg && reg->type == ERT_CLEANUP)
-reg = reg->outer;
+ if (flag_checking)
+{
+ eh_region reg = state->cur_region;
+ while (reg && reg->type == ERT_CLEANUP)
+ reg = reg->outer;
+
+ gcc_assert (reg == state->outer_non_cleanup);
+}
+
+ eh_region reg = state->outer_non_cleanup;
return (reg && reg->type == ERT_MUST_NOT_THROW);
}
@@ -1658,7 +1670,7 @@ lower_try_finally (struct leh_state *state, gtry *tp)
this_tf.try_finally_expr = tp;
this_tf.top_p = tp;
this_tf.outer = state;
- if (using_eh_for_cleanups_p () && !cleanup_is_dead_in (state->cur_region))
+ if (using_eh_for_cleanups_p () && !cleanup_is_dead_in (state))
{
this_tf.region = gen_eh_region_cleanup (state->cur_region);
this_state.cur_region = this_tf.region;
@@ -1669,6 +1681,7 @@ lower_try_finally (struct leh_state *state, gtry *tp)
this_state.cur_region = state->cur_region;
}
+ this_state.outer_non_cleanup = state->outer_non_cleanup;
this_state.ehp_region = state->ehp_region;
this_state.tf = &this_tf;
@@ -1768,6 +1781,7 @@ lower_catch (struct leh_state *state, gtry *tp)
[PATCH, WWW-DOCS] Deprecate non-standard hexadecimal BOZ constants.
Add a note the the Fortran changes to the effect that non-standard BOZ constants are deprecated. Is the wording OK? second attempt this time with attachment! -- https://www.codethink.co.uk/privacy.html diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html index 8e72bd4..3e73cea 100644 --- a/htdocs/gcc-10/changes.html +++ b/htdocs/gcc-10/changes.html @@ -269,6 +269,11 @@ a work-in-progress. can be used to disable inline argument packing. +Deprecating non-standard hexadecimal BOZ constants. Hexadecimal BOZ using the +'X' prefix or suffix e.g. X'ABC' or 'ABC'X will only be allowed with the +-fallow-invalid-boz option. + + Legacy extensions:
Use canonical command to set remote URL
On Jan 14 2020, Joseph Myers wrote: > diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html > index 85a0da2d..f420fe22 100644 > --- a/htdocs/gitwrite.html > +++ b/htdocs/gitwrite.html > @@ -78,7 +78,7 @@ git clone git+ssh://username@gcc.gnu.org/git/gcc.git > gcc > using git config: > > > -git config --set remote.origin.url > git+ssh://username@gcc.gnu.org/git/gcc.git > +git config remote.origin.url > git+ssh://username@gcc.gnu.org/git/gcc.git The canonical way is to use git remote. Andreas. diff --git a/htdocs/gitwrite.html b/htdocs/gitwrite.html index 3cda6a46..87a18fa7 100644 --- a/htdocs/gitwrite.html +++ b/htdocs/gitwrite.html @@ -71,10 +71,10 @@ git clone git+ssh://username@gcc.gnu.org/git/gcc.git gcc where username is your user name at gcc.gnu.org. It is also possible to convert an existing Git tree to use SSH by -using git config: +using git remote: -git config remote.origin.url git+ssh://username@gcc.gnu.org/git/gcc.git +git remote set-url origin git+ssh://username@gcc.gnu.org/git/gcc.git To avoid the nuisance of having to supply your passphrase for each -- 2.25.0 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH] Relax invalidation of TOP N counters in PGO.
Hi.
So I'm sending first version of the relaxation patch and a demonstration
source file that can demonstrate how me merge profile for indirect
functions provided on input. There are some demonstrations:
1) rm indir-call.gcda -f ; ./a.out ABCD && gcov-dump -l indir-call.gcda | grep
-A2 'indirect_call 9'
indir-call.gcda:01a9: 18:COUNTERS indirect_call 9 counts
indir-call.gcda: 0: 4 51084318 4 1042717606 4 1451412899 4
1149064406
indir-call.gcda: 8: 4
All 4 values will fit in the counter (note that profile read code will divide
all values by 4).
2) rm indir-call.gcda -f ; ./a.out AAABB && ./a.out B && ./a.out C && gcov-dump
-l indir-call.gcda | grep -A2 'indirect_call 9'
indir-call.gcda:01a9: 18:COUNTERS indirect_call 9 counts
indir-call.gcda: 0: 7 51084318 12 1042717606 12 0 0 0
indir-call.gcda: 8: 0
Here A, B, C have frequency < 5/4.
3) rm indir-call.gcda -f ; ./a.out AABCDE && gcov-dump -l indir-call.gcda |
grep -A2 'indirect_call 9'
indir-call.gcda:01a9: 18:COUNTERS indirect_call 9 counts
indir-call.gcda: 0: 6 51084318 7 0 0 0 0 0
indir-call.gcda: 8: 0
Here only A survives (2 * 4 - 1).
4) rm indir-call.gcda -f ; ./a.out AAABB && ./a.out B && gcov-dump -l
indir-call.gcda | grep -A2 'indirect_call 9'
indir-call.gcda:01a9: 18:COUNTERS indirect_call 9 counts
indir-call.gcda: 0: 6 51084318 12 1042717606 12 0 0 0
indir-call.gcda: 8: 0
Merging works in between runs properly
5) rm indir-call.gcda -f ; ./a.out AAABB && ./a.out B && ./a.out C && gcov-dump
-l indir-call.gcda | grep -A2 'indirect_call 9'
indir-call.gcda:01a9: 18:COUNTERS indirect_call 9 counts
indir-call.gcda: 0: 7 51084318 12 1042717606 12 0 0 0
indir-call.gcda: 8: 0
Same here, where C is discarded due to small count.
Can you please Honza take a look and provide a feedback? About the new option:
I would like not to invent a bigger complexity. Even now, the merging is quite
complex.
Martin
>From 0965602cd24d29e6d4442a0e530794e70650328e Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Wed, 15 Jan 2020 15:39:55 +0100
Subject: [PATCH] Smart relaxation of TOP N counter.
---
gcc/gcov-io.c | 25 +
gcc/gcov-io.h | 1 +
gcc/profile.c | 9 ++-
libgcc/libgcov-driver.c | 33 ++-
libgcc/libgcov-merge.c| 57 ---
libgcc/libgcov-profiler.c | 27 +--
6 files changed, 113 insertions(+), 39 deletions(-)
diff --git a/gcc/gcov-io.c b/gcc/gcov-io.c
index 213c413b3a0..0bdc49bc108 100644
--- a/gcc/gcov-io.c
+++ b/gcc/gcov-io.c
@@ -587,6 +587,31 @@ mangle_path (char const *base)
return buffer;
}
+/* Prune TOP N value COUNTERS. */
+
+void
+prune_topn_counter (gcov_type *counters, gcov_type all)
+{
+ if (counters[1] == -1)
+return;
+
+ // TODO
+#if 0
+ fprintf (stderr, "prune_topn_counter for all=%d\n", all);
+ for (unsigned i = 0; i < GCOV_TOPN_VALUES; i++)
+fprintf (stderr, "%d:%d:%d\n", i, counters[2 * i], counters[2 * i + 1]);
+#endif
+
+ for (unsigned i = 0; i < GCOV_TOPN_VALUES; i++)
+{
+ if (counters[2 * i + 1] < all)
+ {
+ counters[2 * i] = 0;
+ counters[2 * i + 1] = 0;
+ }
+}
+}
+
/* We need to expose the below function when compiling for gcov-tool. */
#if !IN_LIBGCOV || defined (IN_GCOV_TOOL)
diff --git a/gcc/gcov-io.h b/gcc/gcov-io.h
index d21a43c4c31..61bb7def23b 100644
--- a/gcc/gcov-io.h
+++ b/gcc/gcov-io.h
@@ -338,6 +338,7 @@ GCOV_LINKAGE const char *gcov_read_string (void);
GCOV_LINKAGE void gcov_sync (gcov_position_t /*base*/,
gcov_unsigned_t /*length */);
char *mangle_path (char const *base);
+void prune_topn_counter (gcov_type *counters, gcov_type all);
#if !IN_GCOV
/* Available outside gcov */
diff --git a/gcc/profile.c b/gcc/profile.c
index 6a2de21c3bd..1a6caf75a61 100644
--- a/gcc/profile.c
+++ b/gcc/profile.c
@@ -863,7 +863,14 @@ compute_value_histograms (histogram_values values, unsigned cfg_checksum,
if (hist->type == HIST_TYPE_TOPN_VALUES
|| hist->type == HIST_TYPE_INDIR_CALL)
- sort_hist_values (hist);
+ {
+ /* Each count value is multiplied by GCOV_TOPN_VALUES. */
+ if (hist->hvalue.counters[2] != -1)
+ for (unsigned i = 0; i < GCOV_TOPN_VALUES; i++)
+ hist->hvalue.counters[2 * i + 2] /= GCOV_TOPN_VALUES;
+
+ sort_hist_values (hist);
+ }
/* Time profiler counter is not related to any statement,
so that we have to read the counter and set the value to
diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
index 1c07761b7f1..de5e2eea29b 100644
--- a/libgcc/libgcov-driver.c
+++ b/libgcc/libgcov-driver.c
@@ -213,6 +213,35 @@ static struct gcov_fn_buffer *fn_buffer;
/* Including system dependent components. */
#include "libgcov-driver-system.c"
+/* Prune c
analyzer branch renamed to "devel/analyzer"
Although most of the analyzer work is now on master I'm tracking additional work in a branch (for future features, work that isn't quite ready yet, etc). This used to be "dmalcolm/analyzer" on the git mirror. The new git server doesn't seem to like such branch names [1], so I'm now using "devel/analyzer" Dave [1] remote: *** Shared development branches should be named devel/*, and should be documented in https://gcc.gnu.org/git.html . remote: error: hook declined to update refs/heads/dmalcolm/analyzer
Re: [PATCH, i386]: Fix PR93254, -msse generates sse2 instructions
Also, we can remove existing SSE2 ISA requirements for alternatives 14 and 15.
Remove invalid SSE2 ISA requirements in *movsf_internal.
2020-01-15 Uroš Bizjak
* config/i386/i386.md (*movsf_internal): Do not require
SSE2 ISA for alternatives 14 and 15.
Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline, will be backported to gcc-9 branch.
Uros.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index a5133c6d765..6d70af211e0 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2020-01-15 Uroš Bizjak
+
+ * config/i386/i386.md (*movsf_internal): Do not require
+ SSE2 ISA for alternatives 14 and 15.
+
2020-01-14 Uroš Bizjak
PR target/93254
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index f08410a471e..c9d2f338fe9 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -3696,7 +3696,7 @@
}
}
[(set (attr "isa")
- (cond [(eq_attr "alternative" "9,10,14,15")
+ (cond [(eq_attr "alternative" "9,10")
(const_string "sse2")
]
(const_string "*")))
Re: [PATCH] Fix ctz issues (PR93231)
Hi Jakub,
>> (note the diff uses the old tree and includes Jakub's bootstrap fixes)
> You should rebase it because you'll be committing it against trunk
> which already has those changes.
Sure, it was just the small matter of updating the many GCC checkouts I have...
>> - unsigned shiftval = tree_to_uhwi (tshift);
>> + unsigned shiftval = tree_to_shwi (tshift);
>
> This relies on the FEs to narrow the type of say:
> x >> (((__uint128_t) 0x12 << 64) | 0x1234567812345678ULL)
Gimple canonicalizes all shifts to integer type, eg.
x >> 0xabcdef0001 is converted to x >> 1 with a warning.
>> - unsigned HOST_WIDE_INT val = tree_to_uhwi (mulc);
>> + /* Extract the binary representation of the multiply constant. */
>> + unsigned HOST_WIDE_INT val = TREE_INT_CST_LOW (mulc);
>
> Will it work properly with the signed types though?
> The difference is whether the C code we are matching will use logical or
> arithmetic right shift. And if the power of two times mulc ever can have
> sign bit set, it will then use negative indexes into the array.
The multiply can be signed or unsigned, and the immediate can be positive or
negative, but the shift must be unsigned indeed. I thought the match.pd
pattern only allows unsigned shifts, but the shift operator allows signed shifts
too, so I've added an unsigned check on the input_type.
>> - if (TREE_CODE (ctor) == STRING_CST)
>> + if (TREE_CODE (ctor) == STRING_CST && TYPE_PRECISION (type) == 8)
>
> Isn't another precondition that BITS_PER_UNIT is 8 (because STRING_CSTs are
> really bytes)?
I've used CHAR_TYPE_SIZE instead of 8, but I don't think GCC supports anything
other
than BITS_PER_UNIT == 8 and CHAR_TYPE_SIZE == 8. GCC uses memcmp/strlen
on STRING_CST (as well as direct accesses as 'char') which won't work if the
host and
target chars are not the same size.
Here is the updated version:
Further improve the ctz recognition: Avoid ICEing on negative shift
counts or multiply constants. Check the type is a char type for the
string constant case to avoid accidentally matching a wide STRING_CST.
Add a tree_expr_nonzero_p check to allow the optimization even if
CTZ_DEFINED_VALUE_AT_ZERO returns 0 or 1. Add extra test cases.
Bootstrap OK on AArch64 and x64.
ChangeLog:
2020-01-15 Wilco Dijkstra
PR tree-optimization/93231
* tree-ssa-forwprop.c
(optimize_count_trailing_zeroes): Check input_type is unsigned.
Use tree_to_shwi for shift constant. Check CST_STRING element
size is CHAR_TYPE_SIZE bits.
(simplify_count_trailing_zeroes): Add test to handle known non-zero
inputs more efficiently.
testsuite/
* gcc.dg/pr90838.c: New test.
* gcc.dg/pr93231.c: New test.
--
diff --git a/gcc/testsuite/gcc.dg/pr90838.c b/gcc/testsuite/gcc.dg/pr90838.c
new file mode 100644
index
..8070d439f6404dc6884a11e58f1db41c435e61fb
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr90838.c
@@ -0,0 +1,59 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-forwprop2-details" } */
+
+int ctz1 (unsigned x)
+{
+ static const char table[32] = "\x00\x01\x1c\x02\x1d\x0e\x18\x03\x1e\x16\x14"
+"\x0f\x19\x11\x04\b\x1f\x1b\r\x17\x15\x13\x10\x07\x1a\f\x12\x06\v\x05\n\t";
+
+ return table[((unsigned)((x & -x) * 0x077CB531U)) >> 27];
+}
+
+int ctz2 (unsigned x)
+{
+ const int u = 0;
+ static short table[64] =
+{
+ 32, 0, 1,12, 2, 6, u,13, 3, u, 7, u, u, u, u,14,
+ 10, 4, u, u, 8, u, u,25, u, u, u, u, u,21,27,15,
+ 31,11, 5, u, u, u, u, u, 9, u, u,24, u, u,20,26,
+ 30, u, u, u, u,23, u,19,29, u,22,18,28,17,16, u
+};
+
+ x = (x & -x) * 0x0450FBAF;
+ return table[x >> 26];
+}
+
+int ctz3 (unsigned x)
+{
+ static int table[32] =
+{
+ 0, 1, 2,24, 3,19, 6,25, 22, 4,20,10,16, 7,12,26,
+ 31,23,18, 5,21, 9,15,11,30,17, 8,14,29,13,28,27
+};
+
+ if (x == 0) return 32;
+ x = (x & -x) * 0x04D7651F;
+ return table[x >> 27];
+}
+
+static const unsigned long long magic = 0x03f08c5392f756cdULL;
+
+static const char table[64] = {
+ 0, 1, 12, 2, 13, 22, 17, 3,
+14, 33, 23, 36, 18, 58, 28, 4,
+62, 15, 34, 26, 24, 48, 50, 37,
+19, 55, 59, 52, 29, 44, 39, 5,
+63, 11, 21, 16, 32, 35, 57, 27,
+61, 25, 47, 49, 54, 51, 43, 38,
+10, 20, 31, 56, 60, 46, 53, 42,
+ 9, 30, 45, 41, 8, 40, 7, 6,
+};
+
+int ctz4 (unsigned long x)
+{
+ unsigned long lsb = x & -x;
+ return table[(lsb * magic) >> 58];
+}
+
+/* { dg-final { scan-tree-dump-times {= \.CTZ} 4 "forwprop2" { target
aarch64*-*-* } } } */
diff --git a/gcc/testsuite/gcc.dg/pr93231.c b/gcc/testsuite/gcc.dg/pr93231.c
new file mode 100644
index
..cd0b3f320f78ffdd3d82cf487a63e861d0bf8eab
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr93231.c
@@ -0,0 +1,35 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-forwprop2-details -Wno-shift-count-negative"
} */
+
+int ctz_ice1 (int x)
+{
+ static const char table[32
Re: [PATCH] Fix ctz issues (PR93231)
On Wed, Jan 15, 2020 at 03:50:01PM +, Wilco Dijkstra wrote:
> The multiply can be signed or unsigned, and the immediate can be positive or
> negative, but the shift must be unsigned indeed. I thought the match.pd
> pattern only allows unsigned shifts, but the shift operator allows signed
> shifts
> too, so I've added an unsigned check on the input_type.
I guess in theory if there is some multiplication constant that for all the
power of twos + 0 would give a positive result even arithetic right shift
would be ok, and we could also in the match.pd pattern use convert? or
nop_convert? to allow signed multiplication with a cast to unsigned after
it, but guess it isn't that important and we can just go with TYPE_UNSIGNED
requirement for now.
> >> - if (TREE_CODE (ctor) == STRING_CST)
> >> + if (TREE_CODE (ctor) == STRING_CST && TYPE_PRECISION (type) == 8)
> >
> > Isn't another precondition that BITS_PER_UNIT is 8 (because STRING_CSTs are
> > really bytes)?
>
> I've used CHAR_TYPE_SIZE instead of 8, but I don't think GCC supports
> anything other
> than BITS_PER_UNIT == 8 and CHAR_TYPE_SIZE == 8. GCC uses memcmp/strlen
> on STRING_CST (as well as direct accesses as 'char') which won't work if the
> host and
> target chars are not the same size.
Yes, we even don't support anything else ATM, but are trying to document in
the source when we rely on it.
So e.g. VIEW_CONVERT_EXPR folding has
/* Check that the host and target are sane. */
if (CHAR_BIT != 8 || BITS_PER_UNIT != 8)
return NULL_TREE;
etc.
> 2020-01-15 Wilco Dijkstra
>
> PR tree-optimization/93231
> * tree-ssa-forwprop.c
> (optimize_count_trailing_zeroes): Check input_type is unsigned.
No need to wrap line before (optimize_count_trailing_zeroes), please use:
* tree-ssa-forwprop.c (optimize_count_trailing_zeroes): Check
input_type is unsigned.
> +int ctz2 (unsigned x)
> +{
> + const int u = 0;
> + static short table[64] =
> +{
> + 32, 0, 1,12, 2, 6, u,13, 3, u, 7, u, u, u, u,14,
> + 10, 4, u, u, 8, u, u,25, u, u, u, u, u,21,27,15,
> + 31,11, 5, u, u, u, u, u, 9, u, u,24, u, u,20,26,
> + 30, u, u, u, u,23, u,19,29, u,22,18,28,17,16, u
This is just a GNU extension that we accept it in C, more portable would be
enum U { u = 0; };
or #define u 0
But no big deal.
> @@ -1894,7 +1894,7 @@ optimize_count_trailing_zeroes (tree array_ref, tree x,
> tree mulc,
>if (TREE_CODE (ctor) == CONSTRUCTOR)
> return check_ctz_array (ctor, val, zero_val, shiftval, input_bits);
>
> - if (TREE_CODE (ctor) == STRING_CST)
> + if (TREE_CODE (ctor) == STRING_CST && TYPE_PRECISION (type) ==
> CHAR_TYPE_SIZE)
Too long line, please wrap.
Ok for trunk with those nits tweaked.
Jakub
[Patch, Fortran + wwwdocs] PR93253 – Document BOZ changes, make it friendlier in legacy code
Fortran before 2013 only allowed binary-octal-hex values (BOZ literals)
in DATA statements; Fortran 2013 extended it to support them also as
argument to INT(), REAL() etc. — Additionally, various compilers
(including gfortran) support more as (legacy) extension.
Diagnostic: DATA vs. non DATA usage was/is diagnosed with -std=f95
("Error: Fortran 2003: …"). Using "X" instead of "Z" for hexadecimals
was/is diagnosed (accepted: before GCC 10 with -std=legacy, now with
-fallow-invalid-boz).
However, GCC 9 and older silently accepted nonstandard use, e.g. "print
*, Z'A'" – even with -std=f2003/f2008! Since GCC 10, it is now rejected
unless -fallow-invalid-boz is used.
Main issue: While gfortran 10 still documents the BOZ extensions,
neither the extension documentation nor the error message nor point to
-fallow-invalid-boz – and the release notes is completely silent
regarding BOZ.
Hence, I included two patches:
* The WWWDOCS patch now mentions the change in GCC 10.
* The Fortran patch does: (a) Mention 'X' in the flag documentation (as
it is not in an invalid context but just an invalid letter). (b) Tweak
error message for 'X' to state how to fix it. (c) When both -std=legacy
and -fallow-invalid-boz has been used, it no longer prints a warning;
for -std=gnu and -std=f... (+ -fallow…) we still do. (d) If -std=legacy
has been used without -fallow-invalid-boz, it now suggests to use
-fallow…, but only if fixing is not possible.
I hope with this patch, that using the compiler is more user friendly
but still giving the intensive to actually fix the legacy code.
Are the two patches OK – for wwwdocs and for the trunk, respectively?
Tobias
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index caa9df70..7df5124f 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -260,6 +260,13 @@ a work-in-progress.
with -std=legacy. -Wargument-mismatch
has been removed.
+
+Nonstandard use of BOZ literals now requires the
+-fallow-invalid-boz flag. Before, some nonstandard
+use was only accepted with -std=legacy while
+other nonstandard usage was silently accepted even with
+-std=f2003.
+
At any optimization level except-Os, gfortran now
uses inline packing for arguments instead of calling a library
PR fortran/93253
* check.c (gfc_invalid_boz): With -std=legacy, suggest the new
-fallow-invalid-boz flag. With -std=legacy and that flag, no
longer warn.
* gfortran.texi (BOZ literal constants): List another missing
extension and refer to -fallow-invalid-boz.
* lang.opt (fallow-invalid-boz): Also mention 'X' in the help text
as it is not covered by the previous wording.
* primary.c (match_boz_constant): Tweak wording such that it is
clear how to fix the nonstandard use.
PR fortran/93253
* fortran.dg/boz_7.f90: Updated dg-error.
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index c7f0187b377..f03764abaef 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -56,18 +56,30 @@ reset_boz (gfc_expr *x)
gfc_invalid_boz() is a helper function to simplify error/warning
generation. gfortran accepts the nonstandard 'X' for 'Z', and gfortran
allows the BOZ indicator to appear as a suffix. If -fallow-invalid-boz
- is used, then issue a warning; otherwise issue an error. */
+ is used, then issue a warning (unless -std=legacy); otherwise issue an
+ error. */
bool
gfc_invalid_boz (const char *msg, locus *loc)
{
if (flag_allow_invalid_boz)
{
- gfc_warning (0, msg, loc);
+ if (gfc_option.warn_std & GFC_STD_LEGACY)
+ gfc_warning (0, msg, loc);
return false;
}
- gfc_error (msg, loc);
+ if (!(gfc_option.warn_std & GFC_STD_LEGACY))
+{
+ const char hint[] = ". Use %<-fallow-invalid-boz%> if you cannot fix it";
+ size_t len = strlen (msg) + strlen (hint) + 1;
+ char *msg2 = (char *) alloca (len);
+ strcpy (msg2, msg);
+ strcat (msg2, hint);
+ gfc_error (msg2, loc);
+}
+ else
+gfc_error (msg, loc);
return true;
}
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 4cf8b3a5c24..98fc74f3e67 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -1863,9 +1863,11 @@ Fortran standard states that the treatment of the sign bit is processor
dependent. Gfortran interprets the sign bit as a user would expect.
As a deprecated extension, GNU Fortran allows hexadecimal BOZ literal
-constants to be specified using the @code{X} prefix. The BOZ literal
+constants to be specified using the @code{X} prefix. That the BOZ literal
constant can also be specified by adding a suffix to the string, for
-example, @code{Z'ABC'} and @code{'ABC'X} are equivalent.
+example, @code{Z'ABC'} and @code{'ABC'X} are equivalent. And BOZ literals
+outside @code{DATA} and the intrinsic functions listed in the Fortran
+standard. Use @option{-fallow-invalid-boz} to enable the extension.
Re: [PATCH, WWW-DOCS] Deprecate non-standard hexadecimal BOZ constants.
Hi Mark,
it is more than just 'X' – also B/O/Z when used as postfix ('AB'Z) are
nonstandard as in general the use outside DATA and a handful of
intrinsic functions. For instance, print *, Z'ABC' is also nonstandard
and affected by -fallow-invalid-boz. (GCC < 10 silently accepted the
latter.)
I also come up with a gcc-10/changes.html wording; however, I am sure
that my wording should be tweaked as well.
See https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00896.html — I
additionally also modified the diagnostic and the documentation;
hopefully, in a sensible way.
Thanks,
Tobias
On 1/15/20 3:50 PM, Mark Eggleston wrote:
Add a note the the Fortran changes to the effect that non-standard BOZ
constants are deprecated.
Is the wording OK?
second attempt this time with attachment!
--
https://www.codethink.co.uk/privacy.html
deprecated.diff
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 8e72bd4..3e73cea 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -269,6 +269,11 @@ a work-in-progress.
can be used to disable inline argument packing.
+Deprecating non-standard hexadecimal BOZ constants. Hexadecimal BOZ using
the
+'X' prefix or suffix e.g. X'ABC' or 'ABC'X will only be allowed with the
+-fallow-invalid-boz option.
+
+
Legacy extensions:
contrib: Check and if needed set user.name and user.email in gcc-git-customization.sh
As discussed on IRC, this adds a couple more checks in the customization
setup for git. If the variables user.name and user.email are not set
anywhere in the git config hierarchy, we set some local values. We
always ask about the values we detect and if the user gives an answer
that is new, we save that in the local config: this gives the
opportunity to use different values to those configured for the global
space.
I've also cleaned up a couple of minor niggles, such as using $() rather
than `` for subshells and some quoting issues when using eval.
* gcc-git-customization.sh: Use $() instead of ``, and fix variable
quoting with eval. Set user.name and user.email if not found in the
local or config.
diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index dae2c35bb57..60694fd8cc0 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -11,12 +11,49 @@ ask () {
read answer
if [ "x$answer" = "x" ]
then
- eval $var=$default
+ eval $var=\"$default\"
else
- eval $var=$answer
+ eval $var=\"$answer\"
fi
}
+# Search the git config in multiple scopes upto the level specified.
+# Start in --local, if not set there then try global, then system.
+get_conf_upto () {
+if [ $# -ne 3 ]
+then
+ echo "get_conf_upto --local|--global|--system "
+ exit 1
+fi
+opt=$1
+conf=$2
+result=$3
+case $opt in
+ --local|--global|--system) ;;
+ *) echo "get_conf_upto --local|--global|--system "
+ exit 1
+ ;;
+esac
+v=$(git config --get --local $conf)
+if [ -n "$v" -o "$opt" = "--local" ]
+then
+ eval $result=\"$v\"
+ return
+fi
+
+v=$(git config --get --global $conf)
+if [ -n "$v" -o "$opt" = "--global" ]
+then
+ eval $result=\"$v\"
+ return
+fi
+
+v=$(git config --get --system $conf)
+eval $result=\"$v\"
+return
+}
+
+
# Add a git command to find the git commit equivalent to legacy SVN revision NNN
git config alias.svn-rev '!f() { rev=$1; shift; git log --all --grep="From-SVN: r\\?$rev\\b" "${@}"; } ; f'
@@ -30,7 +67,52 @@ git config alias.gcc-undescr \!"f() { o=\$(git config --get gcc-config.upstream)
# *.mddiff=md
git config diff.md.xfuncname '^\(define.*$'
-upstream=`git config --get "gcc-config.upstream"`
+get_conf_upto --global "user.name" set_user
+get_conf_upto --global "user.email" set_email
+
+if [ "x$set_user" = "x" ]
+then
+# Try to guess the user's name by looking it up in the password file
+new_user=$(getent passwd $(whoami) | awk -F: '{ print $5 }')
+if [ "x$new_user" = "x" ]
+then
+ new_user="(no default)"
+fi
+else
+new_user=$set_user
+fi
+ask "Your name" "${new_user}" new_user
+if [ "x$new_user" = "x(no default)" ]
+then
+echo "Cannot continue, git needs to record your name against commits"
+exit 1
+fi
+
+if [ "x$set_email" = "x" ]
+then
+new_email="(no_default)"
+else
+new_email=$set_email
+fi
+
+ask "Your email address (for git commits)" "${new_email}" new_email
+if [ "x$new_email" = "x(no default)" ]
+then
+echo "Cannot continue, git needs to record your email address against commits"
+exit 1
+fi
+
+if [ "x$set_user" != "x$new_user" ]
+then
+git config "user.name" "$new_user"
+fi
+
+if [ "x$set_email" != "x$new_email" ]
+then
+git config "user.email" "$new_email"
+fi
+
+upstream=$(git config --get "gcc-config.upstream")
if [ "x$upstream" = "x" ]
then
upstream="origin"
@@ -38,27 +120,27 @@ fi
ask "Local name for upstream repository" "origin" upstream
git config "gcc-config.upstream" "$upstream"
-remote_id=`git config --get "gcc-config.user"`
+remote_id=$(git config --get "gcc-config.user")
if [ "x$remote_id" = "x" ]
then
# See if the url specifies the remote user name.
-url=`git config --get "remote.$upstream.url"`
+url=$(git config --get "remote.$upstream.url")
if [ "x$url" = "x" ]
then
# This is a pure guess, but for many people it might be OK.
- remote_id=`whoami`
+ remote_id=$(whoami)
else
- remote_id=`echo $url | sed -r "s|^.*ssh://(.+)@gcc.gnu.org.*$|\1|"`
+ remote_id=$(echo $url | sed -r "s|^.*ssh://(.+)@gcc.gnu.org.*$|\1|")
if [ x$remote_id = x$url ]
then
- remote_id=`whoami`
+ remote_id=$(whoami)
fi
fi
fi
ask "Account name on gcc.gnu.org (for your personal branches area)" $remote_id remote_id
git config "gcc-config.user" "$remote_id"
-old_pfx=`git config --get "gcc-config.userpfx"`
+old_pfx=$(git config --get "gcc-config.userpfx")
if [ "x$old_pfx" = "x" ]
then
old_pfx="me"
@@ -72,7 +154,7 @@ echo "Setting up tracking for personal namespace $remote_id in remotes/$upstream
git config --replace-all "remote.${upstream}.fetch" "+refs/users/${remote_id}/heads/*:refs/remotes/${upstream}/${new_pfx}/*" ":refs/remotes/${upstream}/${old_pfx}/"
git config --replace-all "remote.${upstream}.fetch" "+refs/users/${remote_id}/tags/*:refs/tags/${new_pfx}/*" ":refs/tags/${ol
[PATCH] libstdc++: Fix weakly_incrementable to allow __int128 (PR 93267)
The __iota_diff_t alias can be the type __int128, but that does not
satisfy the signed_integral and __is_signed_integer_like concepts when
__STRICT_ANSI__ is defined (which is true for -std=c++2a).
Because weakly_incrementable is defined in terms of signed_integral, it
is not satisfied by __int128, which means iota_view's iterator doesn't
always satisfy input_or_output_iterator and so iota_view is not always a
range.
The solution is to define __max_size_type and __max_diff_type using
__int128, so that __is_signed_integer_like allows __int128, and then
make weakly_incrementable use __is_signed_integer_like instead of
signed_integral.
PR libstdc++/93267
* include/bits/iterator_concepts.h (__max_diff_type, __max_size_type):
Move here from and define using __int128 when
available.
(__is_integer_like, __is_signed_integer_like): Move here from
.
(weakly_incrementable): Use __is_signed_integer_like.
* include/bits/range_access.h (__max_diff_type, __max_size_type)
(__is_integer_like, __is_signed_integer_like): Move to
.
(__make_unsigned_like_t): Move here from .
* include/std/ranges (__make_unsigned_like_t): Move to
.
(iota_view): Replace using-directive with using-declarations.
* testsuite/std/ranges/iota/93267.cc: New test.
* testsuite/std/ranges/iota_view.cc: Move to new 'iota' sub-directory.
Tested powerpc64le-linux, committed to trunk.
commit 2a0f6c61b4db19535c632be68bddad74b6adb6cf
Author: Jonathan Wakely
Date: Wed Jan 15 14:09:35 2020 +
libstdc++: Fix weakly_incrementable to allow __int128 (PR 93267)
The __iota_diff_t alias can be the type __int128, but that does not
satisfy the signed_integral and __is_signed_integer_like concepts when
__STRICT_ANSI__ is defined (which is true for -std=c++2a).
Because weakly_incrementable is defined in terms of signed_integral, it
is not satisfied by __int128, which means iota_view's iterator doesn't
always satisfy input_or_output_iterator and so iota_view is not always a
range.
The solution is to define __max_size_type and __max_diff_type using
__int128, so that __is_signed_integer_like allows __int128, and then
make weakly_incrementable use __is_signed_integer_like instead of
signed_integral.
PR libstdc++/93267
* include/bits/iterator_concepts.h (__max_diff_type,
__max_size_type):
Move here from and define using __int128 when
available.
(__is_integer_like, __is_signed_integer_like): Move here from
.
(weakly_incrementable): Use __is_signed_integer_like.
* include/bits/range_access.h (__max_diff_type, __max_size_type)
(__is_integer_like, __is_signed_integer_like): Move to
.
(__make_unsigned_like_t): Move here from .
* include/std/ranges (__make_unsigned_like_t): Move to
.
(iota_view): Replace using-directive with using-declarations.
* testsuite/std/ranges/iota/93267.cc: New test.
* testsuite/std/ranges/iota_view.cc: Move to new 'iota'
sub-directory.
diff --git a/libstdc++-v3/include/bits/iterator_concepts.h
b/libstdc++-v3/include/bits/iterator_concepts.h
index 4ba32a0859e..bf581597229 100644
--- a/libstdc++-v3/include/bits/iterator_concepts.h
+++ b/libstdc++-v3/include/bits/iterator_concepts.h
@@ -492,6 +492,28 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
= std::forward<_Tp>(__t);
};
+ namespace ranges::__detail
+ {
+#if __SIZEOF_INT128__
+using __max_diff_type = __int128;
+using __max_size_type = unsigned __int128;
+#else
+using __max_diff_type = long long;
+using __max_size_type = unsigned long long;
+#endif
+
+template
+ concept __is_integer_like = integral<_Tp>
+ || same_as<_Tp, __max_diff_type> || same_as<_Tp, __max_size_type>;
+
+template
+ concept __is_signed_integer_like = signed_integral<_Tp>
+ || same_as<_Tp, __max_diff_type>;
+
+ } // namespace ranges::__detail
+
+ namespace __detail { using ranges::__detail::__is_signed_integer_like; }
+
/// Requirements on types that can be incremented with ++.
template
concept weakly_incrementable = default_initializable<_Iter>
@@ -499,7 +521,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
&& requires(_Iter __i)
{
typename iter_difference_t<_Iter>;
- requires signed_integral>;
+ requires __detail::__is_signed_integer_like>;
{ ++__i } -> same_as<_Iter&>;
__i++;
};
diff --git a/libstdc++-v3/include/bits/range_access.h
b/libstdc++-v3/include/bits/range_access.h
index 721c755f48c..8b546a58840 100644
--- a/libstdc++-v3/include/bits/range_access.h
+++ b/libstdc++-v3/include/bits/range_access.h
@@ -347,22 +347,15 @@ namespace ranges
namespace __detail
{
-using __max_diff_type = long long;
-using __ma
Re: analyzer branch renamed to "devel/analyzer"
On 15/01/2020 15:19, David Malcolm wrote: Although most of the analyzer work is now on master I'm tracking additional work in a branch (for future features, work that isn't quite ready yet, etc). This used to be "dmalcolm/analyzer" on the git mirror. The new git server doesn't seem to like such branch names [1], so I'm now using "devel/analyzer" Dave [1] remote: *** Shared development branches should be named devel/*, and should be documented in https://gcc.gnu.org/git.html . remote: error: hook declined to update refs/heads/dmalcolm/analyzer All developers have a personal space in refs/users//heads. Whether branches go there, or in devel/ will depend on the expected level of community participation in the work. Personal branches are not pulled by default (users have to add fetch rules to see them), but all devel branches are in the default pull set. R.
[PATCH] doc: Replace references to SVN with those to Git
Hi,
when going over stuff linked from the SummerOfCode wiki page, I found
out that doc/install.texi still refers to Subversion. The following
patch replaces SVN to Git almost mechanically. Tested with make info
and make html. OK for trunk?
And then perhaps for the opened release branches too?
Thanks,
Martin
2020-01-15 Martin Jambor
* doc/install.texi (Prerequisites): Replace references to SVN with
references to Git.
(Downloading the source): Likewise.
(Configuration): Likewise.
(Building): Likewise.
---
gcc/ChangeLog| 8
gcc/doc/install.texi | 22 +++---
2 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index fc25469452c..18f73d5c394 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2020-01-15 Martin Jambor
+
+ * doc/install.texi (Prerequisites): Replace references to SVN with
+ references to Git.
+ (Downloading the source): Likewise.
+ (Configuration): Likewise.
+ (Building): Likewise.
+
2020-01-13 Martin Liska
* opts.c (print_help): Do not print CL_PARAM
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index e62b3dae545..1a62cee2ab5 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -356,7 +356,7 @@ and up works.
Necessary when regenerating @file{Makefile} dependencies in libiberty.
Necessary when regenerating @file{libiberty/functions.texi}.
Necessary when generating manpages from Texinfo manuals.
-Used by various scripts to generate some files included in SVN (mainly
+Used by various scripts to generate some files included in Git (mainly
Unicode-related and rarely changing) from source tables.
Used by @command{automake}.
@@ -482,7 +482,7 @@ Necessary to regenerate the top level @file{Makefile.in}
file from
Necessary when modifying @file{*.l} files.
Necessary to build GCC during development because the generated output
-files are not included in the SVN repository. They are included in
+files are not included in the Git repository. They are included in
releases.
@item Texinfo version 4.7 (or later)
@@ -495,7 +495,7 @@ create printable documentation in DVI or PDF format.
Texinfo version
4.8 or later is required for @command{make pdf}.
Necessary to build GCC documentation during development because the
-generated output files are not included in the SVN repository. They are
+generated output files are not included in the Git repository. They are
included in releases.
@item @TeX{} (any working version)
@@ -509,10 +509,10 @@ DVI or PDF files, respectively.
Necessary to regenerate @file{jit/docs/_build/texinfo} from the @file{.rst}
files in the directories below @file{jit/docs}.
-@item SVN (any version)
+@item Git (any version)
@itemx SSH (any version)
-Necessary to access the SVN repository. Public releases and weekly
+Necessary to access the Git repository. Public releases and weekly
snapshots of the development sources are also available via HTTPS@.
@item GNU diffutils version 2.7 (or later)
@@ -547,7 +547,7 @@ own sources.
@cindex Downloading GCC
@cindex Downloading the Source
-GCC is distributed via @uref{http://gcc.gnu.org/svn.html,,SVN} and via
+GCC is distributed via @uref{https://gcc.gnu.org/git.html,,Git} and via
HTTPS as tarballs compressed with @command{gzip} or @command{bzip2}.
Please refer to the @uref{http://gcc.gnu.org/releases.html,,releases web page}
@@ -606,7 +606,7 @@ for both native and cross targets.
We use @var{srcdir} to refer to the toplevel source directory for
GCC; we use @var{objdir} to refer to the toplevel build/object directory.
-If you obtained the sources via SVN, @var{srcdir} must refer to the top
+If you obtained the sources via Git, @var{srcdir} must refer to the top
@file{gcc} directory, the one where the @file{MAINTAINERS} file can be
found, and not its @file{gcc} subdirectory, otherwise the build will fail.
@@ -1543,7 +1543,7 @@ with @option{--enable-bootstrap}.
@item --enable-generated-files-in-srcdir
Neither the .c and .h files that are generated from Bison and flex nor the
info manuals and man pages that are built from the .texi files are present
-in the SVN development tree. When building GCC from that development tree,
+in the Git development tree. When building GCC from that development tree,
or from one of our snapshots, those generated files are placed in your
build directory, which allows for the source to be in a readonly
directory.
@@ -1843,7 +1843,7 @@ consistency checks of the requested complexity. This
does not change the
generated code, but adds error checking within the compiler. This will
slow down the compiler and may only work properly if you are building
the compiler with GCC@. This is @samp{yes,extra} by default when building
-from SVN or snapshots, but @samp{release} for releases. The default
+from Git or snapshots, but @samp{release} for releases. The default
[PATCH][gcc] libgccjit: introduce version entry points
Hi all,
I think would be quite useful for client code to be able to probe for
the libgccjit version.
This patch add three entry points for that: gcc_jit_version_major,
gcc_jit_version_minor, gcc_jit_version_patchlevel.
Does not introduce regressions running make check-jit.
Feedback are welcome.
Andrea
gcc/jit/ChangeLog
2020-??-?? Andrea Corallo
* Make-lang.in (libgccjit.o): Add dependecy plus define BASEVER.
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_13): New ABI tag
plus add version paragraph.
* libgccjit++.h (namespace gccjit::version): Add new namespace.
* libgccjit.c (gcc_jit_version_major, gcc_jit_version_minor)
(gcc_jit_version_patchlevel): New functions.
* libgccjit.h (LIBGCCJIT_HAVE_gcc_jit_version): New macro.
(gcc_jit_version_major, gcc_jit_version_minor)
(gcc_jit_version_patchlevel): New functions.
* libgccjit.map (LIBGCCJIT_ABI_13) New ABI tag.
gcc/testsuite/ChangeLog
2020-??-?? Andrea Corallo
* jit.dg/test-version.c: New testcase.
diff --git a/gcc/jit/Make-lang.in b/gcc/jit/Make-lang.in
index 38ddfad2889..d9430672283 100644
--- a/gcc/jit/Make-lang.in
+++ b/gcc/jit/Make-lang.in
@@ -84,6 +84,9 @@ jit_OBJS = attribs.o \
jit/jit-spec.o \
gcc.o
+CFLAGS-jit/libgccjit.o += -DBASEVER=$(BASEVER_s)
+libgccjit.o: $(BASEVER)
+
# Use strict warnings for this front end.
jit-warn = $(STRICT_WARN)
diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index a6faee0810e..0c0ce070d72 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -61,6 +61,28 @@ You can see the symbol tags provided by libgccjit.so using ``objdump``:
LIBGCCJIT_ABI_0
[...snip...]
+Programmatically checking version
+***
+
+Client code can programmatically check libgccjit version using:
+
+.. function:: int gcc_jit_version_major (void)
+
+ Return libgccjit major version. This is analogous to __GNUC__ in C code.
+
+.. function:: int gcc_jit_version_minor (void)
+
+ Return libgccjit minor version. This is analogous to
+ __GNUC_MINOR__ in C code.
+
+.. function:: int gcc_jit_version_patchlevel (void)
+
+ Return libgccjit patchlevel version. This is analogous to
+ __GNUC_PATCHLEVEL__ in C code.
+
+.. note:: These entry points has been added with ``LIBGCCJIT_ABI_13``
+ (see below).
+
ABI symbol tags
***
@@ -182,3 +204,14 @@ entrypoints:
``LIBGCCJIT_ABI_12`` covers the addition of
:func:`gcc_jit_context_new_bitfield`
+
+``LIBGCCJIT_ABI_13``
+
+``LIBGCCJIT_ABI_13`` covers the addition of version functions via API
+entrypoints:
+
+ * :func:`gcc_jit_version_major`
+
+ * :func:`gcc_jit_version_minor`
+
+ * :func:`gcc_jit_version_patchlevel`
diff --git a/gcc/jit/libgccjit++.h b/gcc/jit/libgccjit++.h
index 82a62d614c5..afb92194c28 100644
--- a/gcc/jit/libgccjit++.h
+++ b/gcc/jit/libgccjit++.h
@@ -49,6 +49,8 @@ namespace gccjit
class timer;
class auto_time;
+ namespace version {};
+
/* Errors within the API become C++ exceptions of this class. */
class error
{
@@ -1913,6 +1915,26 @@ auto_time::~auto_time ()
m_timer.pop (m_item_name);
}
+namespace version
+{
+inline int
+major ()
+{
+ return gcc_jit_version_major ();
+}
+
+inline int
+minor ()
+{
+ return gcc_jit_version_minor ();
+}
+
+inline int
+patchlevel ()
+{
+ return gcc_jit_version_patchlevel ();
+}
+} // namespace version
} // namespace gccjit
#endif /* #ifndef LIBGCCJIT_PLUS_PLUS_H */
diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
index 83055fc297b..572c82f053c 100644
--- a/gcc/jit/libgccjit.c
+++ b/gcc/jit/libgccjit.c
@@ -23,6 +23,7 @@ along with GCC; see the file COPYING3. If not see
#include "coretypes.h"
#include "timevar.h"
#include "typed-splay-tree.h"
+#include "cppbuiltin.h"
#include "libgccjit.h"
#include "jit-recording.h"
@@ -3175,3 +3176,27 @@ gcc_jit_context_new_rvalue_from_vector (gcc_jit_context *ctxt,
as_vec_type,
(gcc::jit::recording::rvalue **)elements);
}
+
+extern int
+gcc_jit_version_major (void)
+{
+ int major, minor, patchlevel;
+ parse_basever (&major, &minor, &patchlevel);
+ return major;
+}
+
+extern int
+gcc_jit_version_minor (void)
+{
+ int major, minor, patchlevel;
+ parse_basever (&major, &minor, &patchlevel);
+ return minor;
+}
+
+extern int
+gcc_jit_version_patchlevel (void)
+{
+ int major, minor, patchlevel;
+ parse_basever (&major, &minor, &patchlevel);
+ return patchlevel;
+}
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 21a0dc09b03..1c5a12e9c01 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -1487,6 +1487,22 @@ gcc_jit_context_new_rvalue_from_vector (gcc_jit_context *ctxt,
size_t num_elements,
gcc_jit_rvalue **elements);
+#define LIBGCCJIT_HAVE_gcc_jit_version
+
+/* Functions to retrive libgccjit version.
+ Analogous to __GNUC__, __GNUC_M
Re: [Patch, Fortran + wwwdocs] PR93253 – Document BOZ changes, make it friendlier in legacy code
On Wed, Jan 15, 2020 at 05:37:11PM +0100, Tobias Burnus wrote:
> Fortran before 2013 only allowed binary-octal-hex values (BOZ literals)
> in DATA statements; Fortran 2013 extended it to support them also as
> argument to INT(), REAL() etc. — Additionally, various compilers
> (including gfortran) support more as (legacy) extension.
>
> Diagnostic: DATA vs. non DATA usage was/is diagnosed with -std=f95
> ("Error: Fortran 2003: …"). Using "X" instead of "Z" for hexadecimals
> was/is diagnosed (accepted: before GCC 10 with -std=legacy, now with
> -fallow-invalid-boz).
>
> However, GCC 9 and older silently accepted nonstandard use, e.g. "print
> *, Z'A'" – even with -std=f2003/f2008! Since GCC 10, it is now rejected
> unless -fallow-invalid-boz is used.
It was much worse than your simple example suggests. My rework fixed
a poor design decision I made some 15 years ago. Prior to the BOZ rework,
a BOZ could appear anywhere an INTEGER(8) or INTEGER(16) could appear
(kind=8 or 16 is target dependent!). This allowed things like
% gfortran9 -o z a.f90
program foo
real a(100), b(4)
a = [(i,i=0,99)]
print *, a(z'2f') ! BOZ index?
a = a * b'11' + o'7' ! BOZ in an expression?
print *, a(z'2f') ! BOZ index?
b = [z'0', z'1', z'2', z'3'] ! BOZ in an array construct?
print '(4(F8.3))', b
end
Note, the above requires INTEGER(8/16) conversion to default integer
kind for the array index reference, and INTEGER(8/16) to default
real kind for assignment. Yes, those conversions are folded, but this
is requiring the compiler to do unneeded work. Also note, that in
F08 and F18, a BOZ is a typeless and kindless entity. Why should
'a*b'11' treat the BOZ as an integer. Why not convert it to type
of 'a' (using the rules of F08/18) and then do the multiplication?
% ./z
46.000
145.00
0.000 1.000 2.000 3.000
All of the above use cases are invalid. gfortran now rejects the
above code, and more importantly, -fallow-invalid-boz *DOES NOT*
allow these uses cases.
% gfcx -o z -fallow-invalid-boz a.f90
a.f90:4:20:
4 |print *, a(z'2f') ! BOZ index?
|1
Error: Invalid BOZ literal constant used in subscript at (1)
a.f90:6:20:
6 |print *, a(z'2f') ! BOZ index?
|1
Error: Invalid BOZ literal constant used in subscript at (1)
a.f90:7:8:
7 |b = [z'0', z'1', z'2', z'3'] ! BOZ in an array construct?
|1
Error: BOZ literal constant at (1) cannot appear in an array constructor
a.f90:5:7:
5 |a = a * b'11' + o'7' ! BOZ in an expression?
| 1
Error: Operands of binary numeric operator '*' at (1) are REAL(4)/BOZ
A side effect of the BOZ rework is that one no longer needs to use
-fno-range-check for things like Inf and NaN and negative integers.
Consider
program foo
real :: inf = z'7f80'! Extension: BOZ in initialization expr.
real :: nan = z'ffc0'! Extension: BOZ in initialization expr.
integer :: neg = z'8111' ! Extension: BOZ in initialization expr.
real b
print '(Z8.8,1X,F8.3)', inf, inf
print '(Z8.8,1X,F8.3)', nan, nan
print '(Z8.8,1X,I0)', neg, neg
end
% gfortran9 -o z a.f90
a.f90:2:16:
2 |real :: inf = z'7f80' ! Extension: BOZ in initialization expr.
|1
Error: Arithmetic overflow of bit-wise transferred BOZ at (1). This check can
be disabled with the option '-fno-range-check'
a.f90:3:16:
3 |real :: nan = z'ffc0' ! Extension: BOZ in initialization expr.
|1
Error: Arithmetic NaN of bit-wise transferred BOZ at (1). This check can be
disabled with the option '-fno-range-check'
a.f90:4:19:
4 |integer :: neg = z'8111'
| 1
Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1). This
check can be disabled with the option '-fno-range-check'
% gfortran9 -o z -fno-range-check a.f90
./z
7F80 Infinity
7FC0 NaN
8111 -2129587951
There is no warning about extension!
Because of the extension for a BOZ in an initialization expression, one
needs the new -fallow-invalid-boz.
gfcx -o z -fallow-invalid-boz a.f90
a.f90:2:16:
2 |real :: inf = z'7f80' ! Extension: BOZ in initialization expr.
|1
Warning: BOZ literal constant at (1) is neither a data-stmt-constant nor an
actual argument to INT, REAL, DBLE, or CMPLX intrinsic function
a.f90:3:16:
3 |real :: nan = z'ffc0' ! Extension: BOZ in initialization expr.
|1
Warning: BOZ literal constant at (1) is neither a data-stmt-constant nor an
actual argument to INT, REAL, DBLE, or CMPLX intrinsic function
a.f90:4:19:
4 |integer :: neg = z'8111'
| 1
Warning: BOZ literal constant at (1) is neither a data-stmt-constant nor an
actual argument to INT, REAL, DBLE, or CMPLX intrinsi
Re: Analyzer committed to master (was Re: Analyzer status)
On Wed, 15.01.2020, 14:30:43 EET Rainer Orth wrote: > Hi David, > > > I've rebased and squashed the analyzer patch kit and squashed patch 2 > > of the hash_table fix into it, and re-tested it successfully, so I've > > pushed it to master (as 757bf1dff5e8cee34c0a75d06140ca972bfecfa7). > > > > I'm going to work through the various followup patches I had on my > > branch and re-test and push to master those that seem appropriate. > > I'm seeing quite a number of failures on Solaris (both sparc and x86), > but also some on 32-bit Linux/x86: > > Running target unix/-m32 > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 610) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 611) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 615) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 616) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 657) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 658) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 662) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 663) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 705) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 706) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 710) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 711) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 753) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 754) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 758) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 759) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors) > I see those errors on PRU and AVR backends. Regards, Dimitar
[C++ PATCH] PR c++/92871 - bad code with xvalue and GNU ?: extension.
I steered Jakub wrong on the desired behavior for temp-extend1.C in the
context of bug 92831; it doesn't make sense to try to extend the lifetime of
a temporary that we've already materialized to evaluate the test. So this
patch munges the stabilized expression so that it won't be subject to
lifetime extension.
Tested x86_64-pc-linux-gnu, applying to trunk.
* call.c (prevent_lifetime_extension): New.
(build_conditional_expr_1): Use it.
---
gcc/cp/call.c | 24 +++-
gcc/testsuite/g++.dg/ext/temp-extend1.C | 2 +-
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 9a22398e794..32ccfc973e4 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -217,6 +217,7 @@ static conversion *merge_conversion_sequences (conversion
*, conversion *);
static tree build_temp (tree, tree, int, diagnostic_t *, tsubst_flags_t);
static conversion *build_identity_conv (tree, tree);
static inline bool conv_binds_to_array_of_unknown_bound (conversion *);
+static tree prevent_lifetime_extension (tree);
/* Returns nonzero iff the destructor name specified in NAME matches BASETYPE.
NAME can take many forms... */
@@ -5078,7 +5079,10 @@ build_conditional_expr_1 (const op_location_t &loc,
/* Make sure that lvalues remain lvalues. See g++.oliva/ext1.C. */
if (glvalue_p (arg1))
- arg2 = arg1 = cp_stabilize_reference (arg1);
+ {
+ arg2 = arg1 = cp_stabilize_reference (arg1);
+ arg2 = arg1 = prevent_lifetime_extension (arg1);
+ }
else
arg2 = arg1 = cp_save_expr (arg1);
}
@@ -12168,6 +12172,24 @@ initialize_reference (tree type, tree expr,
return expr;
}
+/* If *P is an xvalue expression, prevent temporary lifetime extension if it
+ gets used to initialize a reference. */
+
+static tree
+prevent_lifetime_extension (tree t)
+{
+ tree *p = &t;
+ while (TREE_CODE (*p) == COMPOUND_EXPR)
+p = &TREE_OPERAND (*p, 1);
+ while (handled_component_p (*p))
+p = &TREE_OPERAND (*p, 0);
+ /* Change a TARGET_EXPR from prvalue to xvalue. */
+ if (TREE_CODE (*p) == TARGET_EXPR)
+*p = build2 (COMPOUND_EXPR, TREE_TYPE (*p), *p,
+move (TARGET_EXPR_SLOT (*p)));
+ return t;
+}
+
/* Subroutine of extend_ref_init_temps. Possibly extend one initializer,
which is bound either to a reference or a std::initializer_list. */
diff --git a/gcc/testsuite/g++.dg/ext/temp-extend1.C
b/gcc/testsuite/g++.dg/ext/temp-extend1.C
index 7df9ca51681..aaef115494c 100644
--- a/gcc/testsuite/g++.dg/ext/temp-extend1.C
+++ b/gcc/testsuite/g++.dg/ext/temp-extend1.C
@@ -21,7 +21,7 @@ baz (int i)
{
const bool&& a = id{false, true, false}[i].s
? : id{true, false, true, false}[i].s;
- if (S::c != (i ? 3 : 4))
+ if (S::c != (i ? 0 : 4))
__builtin_abort ();
}
base-commit: bc071d3a951a98284a3f46043afd44c03c123376
--
2.18.1
Re: Analyzer committed to master (was Re: Analyzer status)
Dimitar Dimitrov wrote: On Wed, 15.01.2020, 14:30:43 EET Rainer Orth wrote: Hi David, I've rebased and squashed the analyzer patch kit and squashed patch 2 of the hash_table fix into it, and re-tested it successfully, so I've pushed it to master (as 757bf1dff5e8cee34c0a75d06140ca972bfecfa7). I'm going to work through the various followup patches I had on my branch and re-test and push to master those that seem appropriate. I'm seeing quite a number of failures on Solaris (both sparc and x86), but also some on 32-bit Linux/x86: Running target unix/-m32 +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 610) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 611) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 615) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 616) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 657) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 658) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 662) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 663) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 705) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 706) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 710) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 711) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 753) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 754) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 758) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 759) +FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors) I see those errors on PRU and AVR backends. Likewise, on 32b Darwin host and 32b multilib on 64b hosts. + a couple of others related to setjmp not had a chance to triage any further yet. cheers Iain
[C++ PATCH] PR c++/93257 - consteval void function.
A prvalue can have void type, and if it doesn't do anything prohibited in a
constant expression, it's vacuously constant.
Tested x86_64-pc-linux-gnu, applying to trunk.
* constexpr.c (verify_constant): Allow void_node.
---
gcc/cp/constexpr.c | 3 ++-
gcc/testsuite/g++.dg/cpp2a/consteval-void1.C | 10 ++
2 files changed, 12 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval-void1.C
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index bb126a9c006..17b04d7b055 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2609,7 +2609,8 @@ static bool
verify_constant (tree t, bool allow_non_constant, bool *non_constant_p,
bool *overflow_p)
{
- if (!*non_constant_p && !reduced_constant_expression_p (t))
+ if (!*non_constant_p && !reduced_constant_expression_p (t)
+ && t != void_node)
{
if (!allow_non_constant)
error ("%q+E is not a constant expression", t);
diff --git a/gcc/testsuite/g++.dg/cpp2a/consteval-void1.C
b/gcc/testsuite/g++.dg/cpp2a/consteval-void1.C
new file mode 100644
index 000..783cf4c7ef7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/consteval-void1.C
@@ -0,0 +1,10 @@
+// PR c++/93257
+// { dg-do compile { target c++2a } }
+
+template
+consteval void test() {}
+
+int main() {
+test();
+return 0;
+}
base-commit: 7192b1ec12484f5ca8b20930d8dc4d28ab4a533a
--
2.18.1
Re: [RFA (gimplify) PATCH] PR c++/33799 - destroy return value if local cleanup throws.
On 1/11/20 12:12 AM, Jason Merrill wrote: This is a pretty rare situation since the C++11 change to make all destructors default to noexcept, but it is still possible to define throwing destructors, and if a destructor for a local variable throws during the return, we've already constructed the return value, so now we need to destroy it. I handled this somewhat like the new-expression cleanup; as in that case, this cleanup can't properly nest with the cleanups for local variables, so I introduce a cleanup region around the whole function and a flag variable to indicate whether the return value actually needs to be destroyed. This patch was interfering with the coroutines merge, so I've reverted it for the moment and will look at adjusting my approach. Jason
Re: Analyzer committed to master (was Re: Analyzer status)
On Wed, 2020-01-15 at 13:30 +0100, Rainer Orth wrote: > Hi David, > > > I've rebased and squashed the analyzer patch kit and squashed patch > > 2 > > of the hash_table fix into it, and re-tested it successfully, so > > I've > > pushed it to master (as 757bf1dff5e8cee34c0a75d06140ca972bfecfa7). > > > > I'm going to work through the various followup patches I had on my > > branch and re-test and push to master those that seem appropriate. > > I'm seeing quite a number of failures on Solaris (both sparc and > x86), > but also some on 32-bit Linux/x86: > > Running target unix/-m32 > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 610) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 611) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 615) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 616) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 657) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 658) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 662) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 663) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 705) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 706) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 710) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 711) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 753) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 754) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 758) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 759) > +FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors) Thanks, and sorry about this; I've filed this for myself as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93281 and have been investigating. > I'll file PRs for the Solaris ones once I get to it. > > Wasn't analyzer supposed to be off by default, though? It's configured on by default but can be disabled with --disable- analyzer. It doesn't *run* by default; it needs -fanalyzer for that. Dave
Re: [PATCH] adjust object size computation for union accesses and PHIs (PR 92765)
On Wed, 2020-01-15 at 13:18 +, Martin Sebor wrote: > The strcmp optimization newly introduced in GCC 10 relies on > the size of the smallest referenced array object to determine > whether the function can return zero. When the size of > the object is smaller than the length of the other string > argument the optimization folds the equality to false. > > The bug report has identified a couple of problems here: > 1) when the access to the array object is via a pointer to > a (possibly indirect) member of a union, in GIMPLE the pointer > may actually point to a different member than the one in > the original source code. Thus the size of the array may > appear to be smaller than in the source code which can then > result in the optimization being invalid. > 2) when the pointer in the access may point to two or more > arrays of different size (i.e., it's the result of a PHI), > assuming it points to the smallest of them can also lead > to an incorrect result when the optimization is applied. > > The attached patch adjusts the optimization to 1) avoid making > any assumptions about the sizes of objects accessed via union > types, and b) use the size of the largest object in PHI nodes. > > Tested on x86_64-linux. > > Martin > PR tree-optimization/92765 - wrong code for strcmp of a union member > > gcc/testsuite/ChangeLog: > > PR tree-optimization/92765 > * gcc.dg/strlenopt-92.c: New test. > > gcc/ChangeLog: > > PR tree-optimization/92765 > * tree-ssa-strlen.c (component_ref_via_union_p): New function. > (determine_min_objsize): Call it. Use the maximum object size > for PHI arguments. OK jeff
Re: [PATCH] Fix PR libgcc/92988
On Mon, 2019-12-30 at 14:23 -0500, John David Anglin wrote: > Tested on hppa64-hp-hpux11.11. > > Okay? > > Dave > > 2019-12-30 John David Anglin > > PR libgcc/92988 > * crtstuff.c (__do_global_dtors_aux): Only call __cxa_finalize if > DEFAULT_USE_CXA_ATEXIT is true. Who is supposed to define DEFAULT_USE_CXA_ATEXIT? I can't seem to find any references to it within GCC itself. I don't doubt there's a problem, I'm just not sure we've got the right #ifdef around the code in question. Jeff >
Re: [PATCH] adjust object size computation for union accesses and PHIs (PR 92765)
On Wed, Jan 15, 2020 at 01:18:54PM +, Martin Sebor wrote:
> @@ -4099,14 +4122,18 @@ determine_min_objsize (tree dest)
>
>init_object_sizes ();
>
> - if (compute_builtin_object_size (dest, 2, &size))
> -return size;
> -
>/* Try to determine the size of the object through the RHS
> of the assign statement. */
>if (TREE_CODE (dest) == SSA_NAME)
> {
>gimple *stmt = SSA_NAME_DEF_STMT (dest);
> +
> + /* Determine the size of the largest object when DEST refers
> + to two or more via a PHI, otherwise the smallest. */
> + int ostype = gimple_code (stmt) == GIMPLE_PHI ? 0 : 2;
> + if (compute_builtin_object_size (dest, ostype, &size))
> + return size;
> +
>if (!is_gimple_assign (stmt))
> return HOST_WIDE_INT_M1U;
>
> @@ -4118,6 +4145,10 @@ determine_min_objsize (tree dest)
>return determine_min_objsize (dest);
> }
>
> + /* Try to determine the size of the referenced object itself. */
> + if (compute_builtin_object_size (dest, 2, &size))
> +return size;
> +
This looks wrong. For one, this function is used for two purposes now and
you tweak it for one, but more importantly, whether he initial stmt
you see is a PHI or not can't make a difference, how is that case e.g.
different from _1 = PHI <_3, _4>; _2 = _1 + 1; and asking about _2?
For _1, you'd use (correctly) the maximum, but if called on _2, you'd ask
(wrongly) for minimum instead of maximum.
>/* The size of a flexible array cannot be determined. Otherwise,
> - for arrays with more than one element, return the size of its
> - type. GCC itself misuses arrays of both zero and one elements
> - as flexible array members so they are excluded as well. */
> + unless the reference involves a union, for arrays with more than
> + one element, return the size of its type. GCC itself misuses
> + arrays of both zero and one elements as flexible array members
> + so they are excluded as well. */
>if (TREE_CODE (type) != ARRAY_TYPE
> - || !array_at_struct_end_p (dest))
> + || (!component_ref_via_union_p (dest)
> + && !array_at_struct_end_p (dest)))
> {
>tree type_size = TYPE_SIZE_UNIT (type);
>if (type_size && TREE_CODE (type_size) == INTEGER_CST
This also looks like a hack to shut up the particular testcases instead of
really playing with what the IL provides. Instead of the unions, consider
e.g. C++ placement new, have a pointer to a buffer into which you placement
new one structure, take address of some member in it, pass it to something,
if it doesn't have a destructor do a C++ placement new into the same buffer
but with different structure, take address of a different member with the
same address as the first member, do the str*cmp on it that invokes this
stuff. SCCVN will (likely) find out that the values of those two pointers
are the same and just use the former pointer in the latter case.
Jakub
Re: [PATCH] Clean up references to Subversion in documentation sources.
On 13/01/20 09:02 -0500, Eric S. Raymond wrote: diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml index b4bf333e26a..21c312dce35 100644 --- a/libstdc++-v3/doc/xml/faq.xml +++ b/libstdc++-v3/doc/xml/faq.xml @@ -34,9 +34,8 @@ clauses 20 through 33 and annex D (prior to the 2017 standard the library clauses started with 17). For those who want to see exactly how far the project has come, or just want the latest - bleeding-edge code, the up-to-date source is available over - anonymous SVN, and can be browsed over the - http://www.w3.org/1999/xlink"; xlink:href="https://gcc.gnu.org/svn.html";>web. + bleeding-edge code, the up-to-date source , and can be cloned via Git: see + http://www.w3.org/1999/xlink"; xlink:href="https://gcc.gnu.org/git.html";>web. This makes the text say: "the up-to-date source , and can be cloned via Git: see [web]." NACK. Please fix. @@ -299,23 +298,11 @@ Current libstdc++ sources can always be checked out of the main GCC source repository using the appropriate version control tool. At this time, that tool -is Subversion. +is Git. I think "Since January 2020 that tool is Git" would be better. It's unfortunate that all the closed branches will continue to say "at this time" forever, as it's unclear when that was written. -Subversion, or SVN, is -one of several revision control packages. It was selected for GNU -projects because it's free (speech), free (beer), and very high -quality. The http://www.w3.org/1999/xlink"; xlink:href="http://subversion.tigris.org";> Subversion -home page has a better description. - - -The anonymous client checkout feature of SVN is -similar to anonymous FTP in that it allows anyone to retrieve -the latest libstdc++ sources. - - For more information -see http://www.w3.org/1999/xlink"; xlink:href="https://gcc.gnu.org/svn.html";>SVN +see http://www.w3.org/1999/xlink"; xlink:href="https://gcc.gnu.org/git.html";> details. "For more information see [details]." diff --git a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml index b399e71d482..d2913b1663c 100644 --- a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml +++ b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml @@ -170,14 +170,11 @@ - The patch itself. If you are accessing the SVN - repository use svn update; svn diff NEW; + The patch itself. If you are accessing the Git + repository use git pull; git diff >NEW; I don't think that git command is the equivalent of the previous svn one. I think originally NEW was meant to be the modified file ... but I'm not really sure. I don't think "git diff > NEW" is very helpful though. Also, if you've just done "git pull" then presumably you have a clean working tree, and "git diff" won't show anything. I think we should either completely avoid trying to tell people how to produce patches from git, or should do it right. The libstdc++ hunks of this patch above are not OK. Please fix the grammar so the updated text make sense, or leave those bits to me to fix. Let me know if you want me to do that (and I can also commit the rest of the patch for you, which Sandra approved). else, use diff -cp OLD NEW ... If your I don't know why we suggest -p here, that *never* shows anything useful for libstdc++ code. I'll consider fixing that separately though. The rest of the libstdc++ changes below are OK to commit. version of diff does not support these options, then get the - latest version of GNU - diff. The http://www.w3.org/1999/xlink"; xlink:href="http://gcc.gnu.org/wiki/SvnTricks";>SVN - Tricks wiki page has information on customising the - output of svn diff. + latest version of GNU diff. diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml index 2b05ff6601a..cf5722377a6 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml @@ -18,7 +18,7 @@ This status table is based on the table of contents of ISO/IEC 14882:2003. -This page describes the C++ support in mainline GCC SVN, not in any +This page describes the C++ support in mainline GCC, not in any particular release. diff --git a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml index 6f3551ff65d..9d2de532f3d 100644 --- a/libstdc++-v3/doc/xml/manual/status_cxx2011.xml +++ b/libstdc++-v3/doc/xml/manual/status_cxx2011.xml @@ -27,7 +27,7 @@ presence of the required flag. -This page describes the C++11 support in mainline GCC SVN, not in any +This page describes the C++11 support in mainline GCC, not in any particular release. diff --git a/libstdc++-v3/doc/xml/manu
[wwwdocs] Swap links to our previous SVN documentation with those for Git.
Pushed. Gerald - Log - commit 335d0b9345d12398b14ad6f69c3572861ce49d5b Author: Gerald Pfeifer Date: Wed Jan 15 22:34:53 2020 +0100 Swap links to our previous SVN documentation with those for Git. diff --git a/htdocs/style.mhtml b/htdocs/style.mhtml index 0026d6c4..677fd05a 100644 --- a/htdocs/style.mhtml +++ b/htdocs/style.mhtml @@ -109,8 +109,8 @@ Sources - SVN read access - SVN write access + Git + ...write access Rsync
Re: [PATCH] libstdc++/91223 Improve unordered containers == operator
On 14/01/20 22:25 +0100, François Dumont wrote: On 1/13/20 10:53 PM, Jonathan Wakely wrote: On 13/01/20 22:41 +0100, François Dumont wrote: For the multi-keys we could still avoid redundant comparisons when _Equal is just doing == on the key type. On unordered_multiset we could just avoids the call to is_permuation and on the unordered_multimap we could check the is_permutation only on the associated value rather than on the std::pair. I don't think that's necessary, or helpful. The idea of https://gcc.gnu.org/ml/libstdc++/2020-01/msg00070.html is that you shouldn't be using _Equal at all, and therefore it doesn't matter whether it's std::equal_to or not. And it was indeed possible. Nice! PR libstdc++/91223 * include/bits/hashtable.h (_Hashtable<>): Make _Equality<> friend. * include/bits/hashtable_policy.h: Include . (_Equality_base): Remove. (_Equality<>::_M_equal): Review implementation. Use std::is_permutation. * testsuite/23_containers/unordered_multiset/operators/1.cc (Hash, Equal, test02, test03): New. * testsuite/23_containers/unordered_set/operators/1.cc (Hash, Equal, test02, test03): New. Tested under Linux x86_64. Ok to commit ? Yes, OK for trunk (we're in stage4 but your patch was posted in stage3 and fixes a pretty nasty performance bug, so is OK now). N.B. GCC has moved to Git instead of Subversion. If you don't have Git access set up let me know and I can commit the patch for you.
Re: [PATCH] libstdc++/91223 Improve unordered containers == operator
On 15/01/20 21:48 +, Jonathan Wakely wrote: On 14/01/20 22:25 +0100, François Dumont wrote: On 1/13/20 10:53 PM, Jonathan Wakely wrote: On 13/01/20 22:41 +0100, François Dumont wrote: For the multi-keys we could still avoid redundant comparisons when _Equal is just doing == on the key type. On unordered_multiset we could just avoids the call to is_permuation and on the unordered_multimap we could check the is_permutation only on the associated value rather than on the std::pair. I don't think that's necessary, or helpful. The idea of https://gcc.gnu.org/ml/libstdc++/2020-01/msg00070.html is that you shouldn't be using _Equal at all, and therefore it doesn't matter whether it's std::equal_to or not. And it was indeed possible. Nice! PR libstdc++/91223 * include/bits/hashtable.h (_Hashtable<>): Make _Equality<> friend. * include/bits/hashtable_policy.h: Include . (_Equality_base): Remove. (_Equality<>::_M_equal): Review implementation. Use std::is_permutation. * testsuite/23_containers/unordered_multiset/operators/1.cc (Hash, Equal, test02, test03): New. * testsuite/23_containers/unordered_set/operators/1.cc (Hash, Equal, test02, test03): New. Tested under Linux x86_64. Ok to commit ? Yes, OK for trunk (we're in stage4 but your patch was posted in stage3 and fixes a pretty nasty performance bug, so is OK now). N.B. GCC has moved to Git instead of Subversion. If you don't have Git access set up let me know and I can commit the patch for you. P.S. some performance numbers using the code in the bug report (calling Nested(n+1) and Nested(n) where n is the number of levels shown) ... Before: 10 levels of nesting, 0.90 seconds 20 levels of nesting, 0.082400 seconds 22 levels of nesting, 0.285758 seconds 24 levels of nesting, 1.146782 seconds 26 levels of nesting, 4.659524 seconds 28 levels of nesting, 17.739022 seconds 30 levels of nesting, 76.288977 seconds real1m40.204s user1m40.039s sys 0m0.005s After: 10 levels of nesting, 0.01 seconds 20 levels of nesting, 0.01 seconds 22 levels of nesting, 0.01 seconds 24 levels of nesting, 0.01 seconds 26 levels of nesting, 0.01 seconds 28 levels of nesting, 0.01 seconds 30 levels of nesting, 0.01 seconds 2 levels of nesting, 0.002905 seconds real0m0.002s user0m0.001s sys 0m0.001s
Re: [Patch, Fortran + wwwdocs] PR93253 – Document BOZ changes, make it friendlier in legacy code
Hi Steve,
regarding the release-notes text: I like your version – it helps if
someone writes the text, who knows what changed. I have fixed a typo and
adapted the syntax – see attachment. Any comment to it? Otherwise, I
intent to commit it tomorrow.
Regarding the patch, I enclosed a revised version. Do you have more
suggestions – or does it look okay now?
Thanks,
Tobias
On 1/15/20 7:56 PM, Steve Kargl wrote:
+{
+ const char hint[] = ". Use %<-fallow-invalid-boz%> if you cannot fix it";
Suggest adding ". [See %<-fallow-invalid-boz%>.]"
Followed your suggestion.
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
I have reworded it a bit.
- "nonstandard syntax", &gfc_current_locus))
+ "nonstandard X instead of Z", &gfc_current_locus))
I suppose ok, but don't think a change is needed.
I still think the new version is more helpful. Hence …
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index caa9df70..83404a1a 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -260,6 +260,16 @@ a work-in-progress.
with -std=legacy. -Wargument-mismatch
has been removed.
+
+The handling of a BOZ literal constant has been reworked to provide
+better conformance to the Fortran 2008 and 2018 standards. In these
+Fortran standards, a BOZ literal constant is a typeless and kindless
+entity. As a part of the rework, documented and undocumented
+extensions to the Fortran standard now emit errors during compilation.
+Some these extensions are permitted with the
+-fallow-invalid-boz, where the error is degraded to a
+warning and the code is compiled as with older gfortran.
+
At any optimization level except-Os, gfortran now
uses inline packing for arguments instead of calling a library
PR fortran/93253
* check.c (gfc_invalid_boz): Mention -fallow-invalid-boz
in the error message.
* gfortran.texi (BOZ literal constants): List another missing
extension and refer to -fallow-invalid-boz.
* lang.opt (fallow-invalid-boz): Also mention 'X' in the help text
as it is not covered by the previous wording.
* primary.c (match_boz_constant): Tweak wording such that it is
clear how to fix the nonstandard use.
PR fortran/93253
* fortran.dg/boz_7.f90: Updated dg-error.
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index c7f0187b377..519aa8b8c2b 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -67,7 +67,12 @@ gfc_invalid_boz (const char *msg, locus *loc)
return false;
}
- gfc_error (msg, loc);
+ const char hint[] = " [see %<-fno-allow-invalid-boz%>]";
+ size_t len = strlen (msg) + strlen (hint) + 1;
+ char *msg2 = (char *) alloca (len);
+ strcpy (msg2, msg);
+ strcat (msg2, hint);
+ gfc_error (msg2, loc);
return true;
}
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 4cf8b3a5c24..a50634ab9d2 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -1863,9 +1863,12 @@ Fortran standard states that the treatment of the sign bit is processor
dependent. Gfortran interprets the sign bit as a user would expect.
As a deprecated extension, GNU Fortran allows hexadecimal BOZ literal
-constants to be specified using the @code{X} prefix. The BOZ literal
+constants to be specified using the @code{X} prefix. That the BOZ literal
constant can also be specified by adding a suffix to the string, for
-example, @code{Z'ABC'} and @code{'ABC'X} are equivalent.
+example, @code{Z'ABC'} and @code{'ABC'X} are equivalent. Additionally,
+as extension, BOZ literals are permitted in some contexts outside of
+@code{DATA} and the intrinsic functions listed in the Fortran standard.
+Use @option{-fallow-invalid-boz} to enable the extension.
@node Real array indices
@subsection Real array indices
diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt
index 3858331bcc0..59523f74acf 100644
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -387,7 +387,7 @@ All intrinsics procedures are available regardless of selected standard.
fallow-invalid-boz
Fortran RejectNegative Var(flag_allow_invalid_boz)
-Allow a BOZ literal constant to appear in an invalid context.
+Allow a BOZ literal constant to appear in an invalid context and with X instead of Z.
fallow-leading-underscore
Fortran Undocumented Var(flag_allow_leading_underscore)
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index e2b6fcb2106..07b8ac08ba2 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -433,7 +433,7 @@ match_boz_constant (gfc_expr **result)
if (x_hex
&& gfc_invalid_boz ("Hexadecimal constant at %L uses "
- "nonstandard syntax", &gfc_current_locus))
+ "nonstandard X instead of Z", &gfc_current_locus))
return MATCH_ERROR;
old_loc = gfc_current_locus;
diff --git a/gcc/testsuite/gfortran.dg/boz_7.f90 b/gcc/testsuite/gfortran.dg/boz_7.f90
inde
Re: [PATCH] Fix PR libgcc/92988
On 2020-01-15 3:45 p.m., Jeff Law wrote: > On Mon, 2019-12-30 at 14:23 -0500, John David Anglin wrote: >> Tested on hppa64-hp-hpux11.11. >> >> Okay? >> >> Dave >> >> 2019-12-30 John David Anglin >> >> PR libgcc/92988 >> * crtstuff.c (__do_global_dtors_aux): Only call __cxa_finalize if >> DEFAULT_USE_CXA_ATEXIT is true. > Who is supposed to define DEFAULT_USE_CXA_ATEXIT? I can't seem to find > any references to it within GCC itself. > > I don't doubt there's a problem, I'm just not sure we've got the right > #ifdef around the code in question. It is defined by configure. In gcc/defaults.h: /* Determine whether __cxa_atexit, rather than atexit, is used to register C++ destructors for local statics and global objects. */ #ifndef DEFAULT_USE_CXA_ATEXIT #define DEFAULT_USE_CXA_ATEXIT 0 #endif Dave -- John David Anglin dave.ang...@bell.net
Re: [PATCH] Fix PR libgcc/92988
On Wed, 2020-01-15 at 17:27 -0500, John David Anglin wrote: > On 2020-01-15 3:45 p.m., Jeff Law wrote: > > On Mon, 2019-12-30 at 14:23 -0500, John David Anglin wrote: > > > Tested on hppa64-hp-hpux11.11. > > > > > > Okay? > > > > > > Dave > > > > > > 2019-12-30 John David Anglin > > > > > > PR libgcc/92988 > > > * crtstuff.c (__do_global_dtors_aux): Only call __cxa_finalize if > > > DEFAULT_USE_CXA_ATEXIT is true. > > Who is supposed to define DEFAULT_USE_CXA_ATEXIT? I can't seem to find > > any references to it within GCC itself. > > > > I don't doubt there's a problem, I'm just not sure we've got the right > > #ifdef around the code in question. > It is defined by configure. In gcc/defaults.h: > > /* Determine whether __cxa_atexit, rather than atexit, is used to >register C++ destructors for local statics and global objects. */ > #ifndef DEFAULT_USE_CXA_ATEXIT > #define DEFAULT_USE_CXA_ATEXIT 0 > #endif Uber-weird. I grepped for it more than once and didn't see anything. Thanks. OK for the trunk. jeff
Re: [patch] contrib: Don't add push rules for personal and vendor spaces.
A reasonable replacement for those push rules might be command aliases (e.g. "git upush " to push the user branch ). -- Joseph S. Myers jos...@codesourcery.com
Re: [Patch, Fortran + wwwdocs] PR93253 – Document BOZ changes, make it friendlier in legacy code
On Wed, Jan 15, 2020 at 11:25:44PM +0100, Tobias Burnus wrote:
>
> regarding the release-notes text: I like your version – it helps if
> someone writes the text, who knows what changed. I have fixed a typo and
> adapted the syntax – see attachment. Any comment to it? Otherwise, I
> intent to commit it tomorrow.
>
> Regarding the patch, I enclosed a revised version. Do you have more
> suggestions – or does it look okay now?
One missing word in the release-notes. See below.
>
> On 1/15/20 7:56 PM, Steve Kargl wrote:
> >> +{
> >> + const char hint[] = ". Use %<-fallow-invalid-boz%> if you cannot
> >> fix it";
> > Suggest adding ". [See %<-fallow-invalid-boz%>.]"
>
> Followed your suggestion.
Thanks.
>
> >> --- a/gcc/fortran/gfortran.texi
> >> +++ b/gcc/fortran/gfortran.texi
> I have reworded it a bit.
> >> -"nonstandard syntax", &gfc_current_locus))
> >> +"nonstandard X instead of Z", &gfc_current_locus))
> > I suppose ok, but don't think a change is needed.
> I still think the new version is more helpful. Hence …
Ok.
> diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
> index caa9df70..83404a1a 100644
> --- a/htdocs/gcc-10/changes.html
> +++ b/htdocs/gcc-10/changes.html
> @@ -260,6 +260,16 @@ a work-in-progress.
> with -std=legacy. -Wargument-mismatch
> has been removed.
>
> +
> +The handling of a BOZ literal constant has been reworked to provide
> +better conformance to the Fortran 2008 and 2018 standards. In these
> +Fortran standards, a BOZ literal constant is a typeless and kindless
> +entity. As a part of the rework, documented and undocumented
> +extensions to the Fortran standard now emit errors during compilation.
> +Some these extensions are permitted with the
s/Some/Some of
> +-fallow-invalid-boz, where the error is degraded to a
> +warning and the code is compiled as with older gfortran.
> +
>
> At any optimization level except-Os, gfortran now
> uses inline packing for arguments instead of calling a library
Everything else looks good.
The original patch was submitted with
https://gcc.gnu.org/ml/fortran/2019-07/msg00054.html
--
Steve
[committed] analyzer: fix comment
I rewrote class impl_region_model_context to avoid using multiple inheritance during patch review but forgot to update this comment. Fix it. Pushed to origin/master as 49e9a9996ab334133c78f1445173d8e663edd3e9 gcc/analyzer/ChangeLog: * engine.cc (class impl_region_model_context): Fix comment. --- gcc/analyzer/engine.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc index 9092024d3a4..92615e6cd4f 100644 --- a/gcc/analyzer/engine.cc +++ b/gcc/analyzer/engine.cc @@ -64,7 +64,7 @@ along with GCC; see the file COPYING3. If not see static int readability_comparator (const void *p1, const void *p2); -/* class impl_region_model_context : public region_model_context, public log_user. */ +/* class impl_region_model_context : public region_model_context. */ impl_region_model_context:: impl_region_model_context (exploded_graph &eg, -- 2.21.0
[committed] analyzer: add note about -fdump-ipa-analyzer to internal docs
Pushed to origin/master as 5b6681201ae54a3272d49e390f96a1a45a6eb435
gcc/ChangeLog:
* doc/analyzer.texi (Overview): Add note about
-fdump-ipa-analyzer.
---
gcc/doc/analyzer.texi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/doc/analyzer.texi b/gcc/doc/analyzer.texi
index 67efa52953b..b4e9b01da2e 100644
--- a/gcc/doc/analyzer.texi
+++ b/gcc/doc/analyzer.texi
@@ -28,6 +28,8 @@ do whole-program analysis).
The implementation is read-only: it doesn't attempt to change anything,
just emit warnings.
+The gimple representation can be seen using @option{-fdump-ipa-analyzer}.
+
First, we build a @code{supergraph} which combines the callgraph and all
of the CFGs into a single directed graph, with both interprocedural and
intraprocedural edges. The nodes and edges in the supergraph are called
--
2.21.0
[PATCH] analyzer: fix handling of negative byte offsets (PR 93281)
Various 32-bit targets show failures in gcc.dg/analyzer/data-model-1.c
with tests of the form:
__analyzer_eval (q[-2].x == 107024); /* { dg-warning "TRUE" } */
__analyzer_eval (q[-2].y == 107025); /* { dg-warning "TRUE" } */
where they emit UNKNOWN instead.
The root cause is that gimple has a byte-based twos-complement offset
of -16 expressed like this:
_55 = q_92 + 4294967280; (32-bit)
or:
_55 = q_92 + 18446744073709551600; (64-bit)
Within region_model::convert_byte_offset_to_array_index that unsigned
offset was being divided by the element size to get an offset within
an array.
This happened to work on 64-bit target and host, but not elsewhere;
the offset needs to be converted to a signed type before the division
is meaningful.
This patch does so, fixing the failures.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;
verified with -m32 and -m64.
OK for master?
gcc/analyzer/ChangeLog:
PR analyzer/93281
* region-model.cc
(region_model::convert_byte_offset_to_array_index): Convert
offset_cst to ssizetype before dividing by byte_size.
---
gcc/analyzer/region-model.cc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index 5c39be4fd7f..b62ddf82a40 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -6414,9 +6414,12 @@ region_model::convert_byte_offset_to_array_index (tree
ptr_type,
/* This might not be a constant. */
tree byte_size = size_in_bytes (elem_type);
+ /* Ensure we're in a signed representation before doing the division. */
+ tree signed_offset_cst = fold_convert (ssizetype, offset_cst);
+
tree index
= fold_build2 (TRUNC_DIV_EXPR, integer_type_node,
- offset_cst, byte_size);
+ signed_offset_cst, byte_size);
if (CONSTANT_CLASS_P (index))
return get_or_create_constant_svalue (index);
--
2.21.0
[PATCH 1/2] Fix uninitialized field in expand_operand.
From: Andrew Pinski
Commit g:f96bf49a0 added the target field to expand_operand.
But it leaves it uninitialized when doing a full initialization
inside create_expand_operand. This fixes the problem and improves
the code generation inside create_expand_operand too.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
ChangeLog:
* optabs.h (create_expand_operand): Initialize target field also.
Change-Id: Ib653fbfbb2b0709970db87fb94de14b59758bc6c
---
gcc/optabs.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/optabs.h b/gcc/optabs.h
index 07bdc56586e..5bd19503a0a 100644
--- a/gcc/optabs.h
+++ b/gcc/optabs.h
@@ -78,6 +78,7 @@ create_expand_operand (class expand_operand *op,
{
op->type = type;
op->unsigned_p = unsigned_p;
+ op->target = 0;
op->unused = 0;
op->mode = mode;
op->value = value;
--
2.17.1
[PATCH 2/2] Uninitialized padding in struct _dep.
From: Andrew Pinski In struct _dep, there is an implicit padding of 4bits. This bit-field padding is uninitialized when init_dep_1 is being called. This means we access uninitialized memory but never use it for anything. Adding an unused bit-field field and initializing it in init_dep_1 will improve code generation also as we initialize the whole 32bits now rather than just part of it. OK? Bootstrapped and tested on x86_64-linux-gnu. Thanks, Andrew Pinski ChangeLog: * sched-int.h (_dep): Add unused bit-field field for the padding. * sched-deps.c (init_dep_1): Init unused field. Change-Id: I27000323e728f8a73189426e0b9a98c5235b8c55 --- gcc/sched-deps.c | 1 + gcc/sched-int.h | 2 ++ 2 files changed, 3 insertions(+) diff --git a/gcc/sched-deps.c b/gcc/sched-deps.c index 9182aba5588..331af5ffdb3 100644 --- a/gcc/sched-deps.c +++ b/gcc/sched-deps.c @@ -101,6 +101,7 @@ init_dep_1 (dep_t dep, rtx_insn *pro, rtx_insn *con, enum reg_note type, ds_t ds DEP_NONREG (dep) = 0; DEP_MULTIPLE (dep) = 0; DEP_REPLACE (dep) = NULL; + dep->unused = 0; } /* Init DEP with the arguments. diff --git a/gcc/sched-int.h b/gcc/sched-int.h index 833b552a340..a847f876e65 100644 --- a/gcc/sched-int.h +++ b/gcc/sched-int.h @@ -238,6 +238,8 @@ struct _dep /* Cached cost of the dependency. Make sure to update UNKNOWN_DEP_COST when changing the size of this field. */ int cost:20; + + unsigned unused:4; }; #define UNKNOWN_DEP_COST ((int) ((unsigned int) -1 << 19)) -- 2.17.1
Re: [PATCH] libstdc++/91223 Improve unordered containers == operator
On 1/15/20 10:52 PM, Jonathan Wakely wrote: On 15/01/20 21:48 +, Jonathan Wakely wrote: On 14/01/20 22:25 +0100, François Dumont wrote: On 1/13/20 10:53 PM, Jonathan Wakely wrote: On 13/01/20 22:41 +0100, François Dumont wrote: For the multi-keys we could still avoid redundant comparisons when _Equal is just doing == on the key type. On unordered_multiset we could just avoids the call to is_permuation and on the unordered_multimap we could check the is_permutation only on the associated value rather than on the std::pair. I don't think that's necessary, or helpful. The idea of https://gcc.gnu.org/ml/libstdc++/2020-01/msg00070.html is that you shouldn't be using _Equal at all, and therefore it doesn't matter whether it's std::equal_to or not. And it was indeed possible. Nice! PR libstdc++/91223 * include/bits/hashtable.h (_Hashtable<>): Make _Equality<> friend. * include/bits/hashtable_policy.h: Include . (_Equality_base): Remove. (_Equality<>::_M_equal): Review implementation. Use std::is_permutation. * testsuite/23_containers/unordered_multiset/operators/1.cc (Hash, Equal, test02, test03): New. * testsuite/23_containers/unordered_set/operators/1.cc (Hash, Equal, test02, test03): New. Tested under Linux x86_64. Ok to commit ? Yes, OK for trunk (we're in stage4 but your patch was posted in stage3 and fixes a pretty nasty performance bug, so is OK now). N.B. GCC has moved to Git instead of Subversion. If you don't have Git access set up let me know and I can commit the patch for you. I haven't done the move yet and won't be able to do it before the week-end. So please proceed to the commit for me, thanks. P.S. some performance numbers using the code in the bug report (calling Nested(n+1) and Nested(n) where n is the number of levels shown) ... Before: 10 levels of nesting, 0.90 seconds 20 levels of nesting, 0.082400 seconds 22 levels of nesting, 0.285758 seconds 24 levels of nesting, 1.146782 seconds 26 levels of nesting, 4.659524 seconds 28 levels of nesting, 17.739022 seconds 30 levels of nesting, 76.288977 seconds real 1m40.204s user 1m40.039s sys 0m0.005s After: 10 levels of nesting, 0.01 seconds 20 levels of nesting, 0.01 seconds 22 levels of nesting, 0.01 seconds 24 levels of nesting, 0.01 seconds 26 levels of nesting, 0.01 seconds 28 levels of nesting, 0.01 seconds 30 levels of nesting, 0.01 seconds 2 levels of nesting, 0.002905 seconds real 0m0.002s user 0m0.001s sys 0m0.001s Very nice indeed !
Re: [PATCH] analyzer: fix handling of negative byte offsets (PR 93281)
On January 16, 2020 12:56:48 AM GMT+01:00, David Malcolm
wrote:
>Various 32-bit targets show failures in gcc.dg/analyzer/data-model-1.c
>with tests of the form:
> __analyzer_eval (q[-2].x == 107024); /* { dg-warning "TRUE" } */
> __analyzer_eval (q[-2].y == 107025); /* { dg-warning "TRUE" } */
>where they emit UNKNOWN instead.
>
>The root cause is that gimple has a byte-based twos-complement offset
>of -16 expressed like this:
> _55 = q_92 + 4294967280; (32-bit)
>or:
> _55 = q_92 + 18446744073709551600; (64-bit)
>
>Within region_model::convert_byte_offset_to_array_index that unsigned
>offset was being divided by the element size to get an offset within
>an array.
>
>This happened to work on 64-bit target and host, but not elsewhere;
>the offset needs to be converted to a signed type before the division
>is meaningful.
>
>This patch does so, fixing the failures.
>
>Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu;
>verified with -m32 and -m64.
>
>OK for master?
Technically it depends on where you get that offset from. For MEM_REF there's
mem_ref_offset which does the change for you for example.
But, OK.
Richard.
>
>gcc/analyzer/ChangeLog:
> PR analyzer/93281
> * region-model.cc
> (region_model::convert_byte_offset_to_array_index): Convert
> offset_cst to ssizetype before dividing by byte_size.
>---
> gcc/analyzer/region-model.cc | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
>diff --git a/gcc/analyzer/region-model.cc
>b/gcc/analyzer/region-model.cc
>index 5c39be4fd7f..b62ddf82a40 100644
>--- a/gcc/analyzer/region-model.cc
>+++ b/gcc/analyzer/region-model.cc
>@@ -6414,9 +6414,12 @@ region_model::convert_byte_offset_to_array_index
>(tree ptr_type,
> /* This might not be a constant. */
> tree byte_size = size_in_bytes (elem_type);
>
>+ /* Ensure we're in a signed representation before doing the
>division. */
>+ tree signed_offset_cst = fold_convert (ssizetype, offset_cst);
>+
> tree index
> = fold_build2 (TRUNC_DIV_EXPR, integer_type_node,
>- offset_cst, byte_size);
>+ signed_offset_cst, byte_size);
>
> if (CONSTANT_CLASS_P (index))
> return get_or_create_constant_svalue (index);
[wwwdocs] Refer to the new pages describing our Git setup.
Replace two references to svn.html and svnwrite.html by git.html and gitwrite.html, respectively. Reduce an explicit reference to whatever tool we use on the way. Pushed. --- htdocs/contribute.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/htdocs/contribute.html b/htdocs/contribute.html index 381aa02a..e7ff3990 100644 --- a/htdocs/contribute.html +++ b/htdocs/contribute.html @@ -251,9 +251,9 @@ acceptable, as long as the ChangeLog is still posted as plain text. When you have all these pieces, bundle them up in a mail message and send it to the appropriate mailing list(s). (Patches will go to one or more lists depending on what you are -changing.) For further information on the GCC SVN repository, see -the Anonymous read-only SVN access and Read-write SVN access pages. +changing.) For further information on our source repository, see +the Anonymous read-only Git access and Read-write Git access pages. (Everything listed here still applies if you can check in the patch without further approval under the
Re: [PATCH] doc: Replace references to SVN with those to Git
On Wed, 15 Jan 2020, Martin Jambor wrote: > when going over stuff linked from the SummerOfCode wiki page, > I found out that doc/install.texi still refers to Subversion. We've got a fair number of references left in various places; working through that slowly and appreciate your help! > The following patch replaces SVN to Git almost mechanically. I'm wondering whether we can/should see where to use a more generic term in a few cases; let me propose some such cases. > OK for trunk? And then perhaps for the opened release branches too? Yes (considering the notes below), and yes, please! > -Used by various scripts to generate some files included in SVN (mainly > +Used by various scripts to generate some files included in Git (mainly Do you think we could say "in our repository"? > -files are not included in the SVN repository. They are included in > +files are not included in the Git repository. They are included in ...in our repository...? > -generated output files are not included in the SVN repository. They are > +generated output files are not included in the Git repository. They are Same here? Thank you, Gerald
Re: [C++ coroutines 4/6] Middle end expanders and transforms.
> > + gassign *get_res = gimple_build_assign (lhs, done);
> > + gsi_replace (gsi, get_res, true);
> > + *handled_ops_p = true;
> > + }
> > + break;
> > + }
> > +}
> > + return NULL_TREE;
> > +}
> > +
> > +/* Main entry point for lowering coroutine FE builtins. */
> > +
> > +static unsigned int
> > +execute_lower_coro_builtins (void)
> > +{
> > + struct walk_stmt_info wi;
> > + gimple_seq body;
> > +
> > + body = gimple_body (current_function_decl);
> > + memset (&wi, 0, sizeof (wi));
> > + walk_gimple_seq_mod (&body, lower_coro_builtin, NULL, &wi);
> > + gimple_set_body (current_function_decl, body);
>
> it would be nice to elide the function walk for functions not
> containing any CO* stuff (you noted that below for other parts).
> We can spend a bit in struct function noting functions with
> coroutine code inside and set the bit from frontends or from
> the gimplifier for example. Since it's behind the flag_coroutines
> paywall this can be addressed as followup.
Yes, this bit flag is necessary for following optimization passes, I
wonder which bit you would suggest?
Thanks,
bin
