broken check: You should edit tm.texi.in rather than tm.texi
Hello. I hit the following issue: /bin/sh /home/marxin/Programming/gcc/gcc/../move-if-change tmp-tm.texi tm.texi You should edit /home/marxin/Programming/gcc/gcc/doc/tm.texi.in rather than /home/marxin/Programming/gcc/gcc/doc/tm.texi . Steps to reproduce: 1) modify target.def 2) you will see: Verify that you have permission to grant a GFDL license for all new text in /dev/shm/objdir/gcc/tm.texi, then copy it to /home/marxin/Programming/gcc/gcc/doc/tm.texi. I copy and commit the changes. 3) I made another modification to target.def Now I face the issue as elif test $(srcdir)/doc/tm.texi -nt $(srcdir)/doc/tm.texi.in \ && ( test $(srcdir)/doc/tm.texi -nt $(srcdir)/target.def \ So tm.texi.in is older that tm.texi, but it's fine as both tm.texi.in and tm.texi are not modified. Ideas how to improve the error message? It took me some time to realize that 'touch tm.texi.in' is what I need. Martin
Re: broken check: You should edit tm.texi.in rather than tm.texi
On Fri, Nov 20, 2020 at 5:24 AM Martin Liška wrote: > > Hello. > > I hit the following issue: > /bin/sh /home/marxin/Programming/gcc/gcc/../move-if-change tmp-tm.texi tm.texi > You should edit /home/marxin/Programming/gcc/gcc/doc/tm.texi.in rather than > /home/marxin/Programming/gcc/gcc/doc/tm.texi . > > Steps to reproduce: > 1) modify target.def > 2) you will see: > > Verify that you have permission to grant a GFDL license for all > new text in /dev/shm/objdir/gcc/tm.texi, then copy it to > /home/marxin/Programming/gcc/gcc/doc/tm.texi. > > I copy and commit the changes. > > 3) I made another modification to target.def > > Now I face the issue as > elif test $(srcdir)/doc/tm.texi -nt $(srcdir)/doc/tm.texi.in \ > && ( test $(srcdir)/doc/tm.texi -nt $(srcdir)/target.def \ > > So tm.texi.in is older that tm.texi, but it's fine as both tm.texi.in > and tm.texi are not modified. > > Ideas how to improve the error message? It took me some time to realize > that 'touch tm.texi.in' is what I need. Should contrib/gcc_update handle it? -- H.J.
Re: broken check: You should edit tm.texi.in rather than tm.texi
On 11/20/20 2:42 PM, H.J. Lu wrote: Should contrib/gcc_update handle it? I don't know how publicly known is the script? I personally do not used it. Martin
Re: broken check: You should edit tm.texi.in rather than tm.texi
On 11/20/20 4:26 PM, Martin Liška wrote: On 11/20/20 2:42 PM, H.J. Lu wrote: Should contrib/gcc_update handle it? I don't know how publicly known is the script? I personally do not used it. Martin ... or we can add a hint: diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 778ec09c75d..f079930dade 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -2580,6 +2580,7 @@ s-tm-texi: build/genhooks$(build_exeext) $(srcdir)/doc/tm.texi.in ); then \ echo >&2 ; \ echo You should edit $(srcdir)/doc/tm.texi.in rather than $(srcdir)/doc/tm.texi . >&2 ; \ + echo "(or you may need to touch $(srcdir)/doc/tm.texi.in if $(srcdir)/doc/tm.texi is not modified)" >&2 ; \ false; \ else \ echo >&2 ; \ Thoughs? Martin
Re: broken check: You should edit tm.texi.in rather than tm.texi
On Fri, Nov 20, 2020 at 7:26 AM Martin Liška wrote: > > On 11/20/20 2:42 PM, H.J. Lu wrote: > > Should contrib/gcc_update handle it? > > I don't know how publicly known is the script? > I personally do not used it. > I always run $ ./contrib/gcc_update --touch after rebase. -- H.J.
DWARF64 gcc/clang flag discussion
Hello On llvm side of compiler world there has been work done by Igor Kudrin to enable DWARF64. I am trying to add a flag to Clang to enable DWARF64 generation. https://reviews.llvm.org/D90507 In review David Blaikie pointed out that there has been a discussion on what to call this flag: https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html Reading through that it doesn't look like there is a consensus on what it should be. >From discussion there is seems to be mixed opinion if it should be -f or >-g. Primarily centered around if -g prefix implies turning on generation >of debug information. Now that LLVM can actually generate DWARF64 for ELF, can we come to consensus on the name? Thank You Alex
gcc-9-20201120 is now available
Snapshot gcc-9-20201120 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20201120/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision c368cd5d88521ecf63e793f50bf8e69792577894 You'll find: gcc-9-20201120.tar.xzComplete GCC SHA256=f609d6d36969f69f0d909fac3988d59fc2c7a1ba242e943c6479ab1ba4506518 SHA1=14396a41376f660f4990cc156470c5d4695742e9 Diffs from 9-20201113 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: DWARF64 gcc/clang flag discussion
On Fri, Nov 20, 2020 at 08:22:26PM +, Alexander Yermolovich wrote: > On llvm side of compiler world there has been work done by Igor Kudrin to > enable DWARF64. > I am trying to add a flag to Clang to enable DWARF64 generation. > https://reviews.llvm.org/D90507 > In review David Blaikie pointed out that there has been a discussion on what > to call this flag: > https://linuxplumbersconf.org/event/7/contributions/746/attachments/578/1018/DWARF5-64.pdf > https://linuxplumbersconf.org/event/7/sessions/90/attachments/583/1201/dwarf-bof-notes-aug24-lpc-2020.txt > https://www.mail-archive.com/gcc@gcc.gnu.org/msg92495.html > > Reading through that it doesn't look like there is a consensus on what it > should be. > > From discussion there is seems to be mixed opinion if it should be > -f or -g. Primarily centered around if -g prefix implies > turning on generation of debug information. > > Now that LLVM can actually generate DWARF64 for ELF, can we come to consensus > on the name? I don't believe any firm consensus was reached on naming yet. But I would pick -fdwarf32/-fdwarf64. Cheers, Mark
Re: Incremental updating of SSA_NAMEs that are passed to b_c_p
On 10/27/20 12:34 PM, Ilya Leoshkevich wrote:
> Hi,
>
> I'd like to revive the old discussion regarding the interaction of
> jump threading and b_c_p causing the latter to incorrectly return 1 in
> certain cases:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547236.html
> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549288.html
>
> The conclusion was that this happening during threading is just a
> symptom of a deeper problem: SSA_NAMEs that are passed to b_c_p should
> not be registered for incremental updating.
That's perhaps not as precise as we'd like to be.
Simply registering the SSA_NAME isn't the problem. It's the need to
generate a PHI to resolve the incremental update that causes the
problems. And as much as anything it's a sanity check that we're not
filtering out jump threading cases that we should (ignore the case for
now where the PHI we generate is a degenerate).
Now it may be painful to actually detect those cases. I haven't looked
at the into-ssa bits in years.
>
> I performed a little experiment and added an assertion to
> create_new_def_for:
>
> --- a/gcc/tree-into-ssa.c
> +++ b/gcc/tree-into-ssa.c
> @@ -2996,6 +3014,8 @@ create_new_def_for (tree old_name, gimple *stmt,
> def_operand_p def)
> {
>tree new_name;
>
> + gcc_checking_assert (!used_by_bcp_p (old_name));
> +
>timevar_push (TV_TREE_SSA_INCREMENTAL);
>
>if (!update_ssa_initialized_fn)
>
> This has of course fired when performing basic block duplication during
> threading, which can be fixed by avoiding duplication of basic blocks
> wi
> th b_c_p calls:
>
> --- a/gcc/tree-cfg.c
> +++ b/gcc/tree-cfg.c
> @@ -6224,7 +6224,8 @@ gimple_can_duplicate_bb_p (const_basic_block bb)
> || gimple_call_internal_p (g, IFN_GOMP_SIMT_EXIT)
> || gimple_call_internal_p (g, IFN_GOMP_SIMT_VOTE_ANY)
> || gimple_call_internal_p (g, IFN_GOMP_SIMT_XCHG_BFLY)
> - || gimple_call_internal_p (g, IFN_GOMP_SIMT_XCHG_IDX)))
> + || gimple_call_internal_p (g, IFN_GOMP_SIMT_XCHG_IDX)
> + || gimple_call_builtin_p (g, BUILT_IN_CONSTANT_P)))
> return false;
> }
Yea, that's a reasonable place to start with the checking assert to see
how pervasive these problems are. I probably wouldn't just blindly
disable threading through blocks with b_c_p call, but again, it seems
like a reasonable thing to do to help get a sense of other problem areas.
>
> The second occurrence is a bit more interesting:
>
> gimple *
> vrp_insert::build_assert_expr_for (tree cond, tree v)
> {
> ...
> a = build2 (ASSERT_EXPR, TREE_TYPE (v), v, cond);
> assertion = gimple_build_assign (NULL_TREE, a);
> ...
> tree new_def = create_new_def_for (v, assertion, NULL);
>
> The fix is also simple though:
>
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@ -3101,6 +3101,9 @@ vrp_insert::process_assert_insertions_for (tree
> name, assert_locus *loc)
>if (loc->expr == loc->val)
> return false;
>
> + if (used_by_bcp_p (name))
> +return false;
> +
>cond = build2 (loc->comp_code, boolean_type_node, loc->expr, loc-
>> val);
>assert_stmt = build_assert_expr_for (cond, name);
>if (loc->e)
>
> My original testcase did not trigger anything else. I'm planning to
> check how this affects the testsuite, but before going further I would
> like to ask: is this the right direction now? To me it looks a
> little-bit more heavy-handed than the original approach, but maybe it's
> worth it.
It seems a bit heavy-handed. But that's not based on any hard data,
just a sense that we may not want to disable threading this aggressively.
jeff
