Re: Incremental updating of SSA_NAMEs that are passed to b_c_p
On Tue, Oct 27, 2020 at 7:36 PM Ilya Leoshkevich via Gcc
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.
>
> 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;
> }
>
> 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.
Disabling threading looks reasonable but I'd rather not disallow BB duplication
or renaming. For VRP I guess we want to instead change
register_edge_assert_for* to not register assertions for the result of
__builtin_constant_p rather than just not allowing VRP to process it
(there are other consumers still).
Richard.
> Best regards,
> Ilya
>
GCC 10 and Coverity Scan
Hi This isn't the perfect place to ask this but someone here may have insight. And getting help with Coverity Scan directly isn't easy. I'm hoping someone here has some insight or can point me to someone who does. We have been using Coverity Scan a long time with RTEMS. It works fine using gcc 7.5.0 but Coverity appears to have a problem with gcc 10. This is what --version reports for both toolchains: $ ~/rtems-work/tools/5/bin/sparc-rtems5-gcc --version sparc-rtems5-gcc (GCC) 7.5.0 20191114 (RTEMS 5, RSB 5 (cbae90a5817a), Newlib 7947581) $ sparc-rtems6-gcc --version sparc-rtems6-gcc (GCC) 10.2.1 20201028 (RTEMS 6, RSB 4c5af1f7c1553e53739ca4e9892de26924ec2b3f, Newlib fcaaf40) I am a bit suspicious that Coverity isn't handling the transition from 1 to 2 digits in the major number. All I am changing is the name of the target in the script that does the analysis build. This is the output from Coverity: /home/joel/coverity/cov-analysis-linux64-2019.03/bin/cov-emit --dir=/home/joel/rtems-work/b-coverity-sparc-rtems6/cov-int --ignore_path=/tmp/cov-joel/d83f12de08465ee5db7c3d5793b61b7f/cov-configure --ignore_path=/tmp/cov-joel/d83f12de08465ee5db7c3d5793b61b7f/cov-joel/4c6332bd8a8cc093158cd207a79a6edf --pre_preinclude /home/joel/coverity/cov-analysis-linux64-2019.03/config/gcc-config-0/coverity-macro-compat.h --pre_preinclude /home/joel/coverity/cov-analysis-linux64-2019.03/config/gcc-config-0/coverity-compiler-compat.h --add_type_modifier=__coverity___fpreg --add_type_modifier=__coverity_decimal --add_type_modifier=__coverity_float --add_type_modifier=__coverity_floatx --no_predefined_feature_test_macros --no_stdarg_builtin --no_predefined_cplusplus -w --no_predefines --comp_ver 0.2.1 --char_bit_size=8 --restrict --gnu_carriage_return_line_terminator --no_multiline_string --no_trigraphs --ignore_calling_convention --c11 --no_enable_80bit_float --no_enable_128bit_float --allow__bool --macro_stack_pragmas --inline_keyword --has_include_macro --has_include_next_macro --has_cpp_attribute_macro --no_predefines --c --no_builtin_emulation --ppp_translator "replace%#\s*ident\s*([^;]*);%#ident $1" --gcc --gnu_version 201 -I. -I/home/joel/rtems-work/b-coverity-sparc-rtems6/sparc-rtems6/c/leon3/include -I/home/joel/rtems-work/rtems/cpukit/include -I/home/joel/rtems-work/rtems/cpukit/score/cpu/sparc/include --sys_include /home/joel/rtems-work/tools/6/lib/gcc/sparc-rtems6/10.2.1/include --sys_include /home/joel/rtems-work/tools/6/lib/gcc/sparc-rtems6/10.2.1/include-fixed --sys_include /home/joel/rtems-work/tools/6/lib/gcc/sparc-rtems6/10.2.1/../../../../sparc-rtems6/include -DHAVE_CONFIG_H -D__OPTIMIZE__ --type_sizes=dex8Pfil4s2 --type_alignments=dex8Pfil4s2 --size_t_type=j --wchar_t_type=l --ptrdiff_t_type=i ../../../../../rtems/cpukit/zlib/zutil.c Command-line error #1359: invalid GNU version number: 201 [ERROR] 1 catastrophic error detected in this compilation. Compilation terminated. WARNING: cov-emit returned with code 2 Any insight or pointers to someone who might be of help is appreciated. --joel
Re: GCC 10 and Coverity Scan
- Original Message - > Hi > > This isn't the perfect place to ask this but someone here may have > insight. > And getting help with Coverity Scan directly isn't easy. I'm hoping > someone > here has some insight or can point me to someone who does. > > We have been using Coverity Scan a long time with RTEMS. It works > fine > using gcc 7.5.0 but Coverity appears to have a problem with gcc 10. > This is > what --version reports for both toolchains: > > $ ~/rtems-work/tools/5/bin/sparc-rtems5-gcc --version > sparc-rtems5-gcc (GCC) 7.5.0 20191114 (RTEMS 5, RSB 5 (cbae90a5817a), > Newlib 7947581) > > $ sparc-rtems6-gcc --version > sparc-rtems6-gcc (GCC) 10.2.1 20201028 (RTEMS 6, RSB > 4c5af1f7c1553e53739ca4e9892de26924ec2b3f, Newlib fcaaf40) Hi Putting aside politics (I used to work for Synopsys and now work for a competitor, but not at all in the domain of static analysis), I'll take a stab. When you switched compilers, did you re-run cov-configure? A+ Paul
Re: gsi_remove on a call
Martin,
After some digging and a little luck, I found that this does what I wanted:
cgraph_update_edges_for_call_stmt ( stmt, gimple_call_fndecl ( stmt), NULL);
Thanks,
Gary
From: Martin Jambor
Sent: Tuesday, October 27, 2020 5:44 AM
To: Gary Oblock ; gcc@gcc.gnu.org
Subject: Re: gsi_remove on a call
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Tue, Oct 27 2020, Gary Oblock via Gcc wrote:
> I'm running into grief in verify_node in cgraph.c
> when I use gsi_remove on a call statement.
>
> Specifically it's a free statement which I've replaced
> with other free statements as part of my structure
> reorg optimizations. Note, in other working code
> I do this with malloc and it doesn't seem to be a problem.
>
> Where it happens it's trying to look at the call graph edges.
> Is there a way to remove the edge in question or mark it
> to be ignored?
Have you tried using cgraph_edge::set_call_stmt to update the edge?
> I see that line below about built in unreachable
> and wonder if I'm supposed to set the decl to that but I
> don't see others doing it so...
The comment you quoted explains why __builtin_unreachable is special.
Martin
>
> Here's the code in cgraph (e->call_stmt is the free in question:)
>
> if (gimple_has_body_p (e->caller->decl)
> && !e->caller->inlined_to
> && !e->speculative
> /* Optimized out calls are redirected to __builtin_unreachable. */
> && (e->count.nonzero_p ()
> || ! e->callee->decl
> || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
> && count == ENTRY_BLOCK_PTR_FOR_FN(DECL_STRUCT_FUNCTION (decl))->count
> && (!e->count.ipa_p ()
> && e->count.differs_from_p (gimple_bb (e->call_stmt)->count)))
>{
> :
>
> Thanks,
>
> Gary
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
> for the sole use of the intended recipient(s) and contains information that
> is confidential and proprietary to Ampere Computing or its subsidiaries. It
> is to be used solely for the purpose of furthering the parties' business
> relationship. Any unauthorized review, copying, or distribution of this email
> (or any attachments thereto) is strictly prohibited. If you are not the
> intended recipient, please contact the sender immediately and permanently
> delete the original and any copies of this email and any attachments thereto.
[1-800-GIT-HELP] Pushing a merge with master to a branch fails with git gcc-verify
I tried to update the coarray_native branch to current master with "git merge master" as given by https://gcc.gnu.org/gitwrite.html#branches That worked without any error message. Next, I tried to verify that a "git push" would succeed, and got an error: $ git gcc-verify Checking bf6dad60c338a42a7fb85f7b2a5870c0fb2e20f8: FAILED ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates should be done separately from normal commits This case is not covered by gitwrite.html, what is the best way to proceed? Best regards Thomas
Re: [1-800-GIT-HELP] Pushing a merge with master to a branch fails with git gcc-verify
Hi Thomas, at work we usually do not merge master back into a dev branch, but use 'git rebase -i master'. This will so to say stash any commits on the dev-branch, i.e. roll it back, then apply all changes of master and then apply the stashed changes again. This should allow to bypass any server side checks, which I suppose you are hindered now by. To try this you can git reset --hard where commit-hash is the last one from the coarray devel branch you want to keep. Be careful and try this only on a copy of the checkout, because reset hard will drop anything without any chance for easy recovery. - Andre Andre Vehreschild
Top Website & Mobile App Design and Development
Hi gcc@gcc.gnu.org, This is Rona, From India, hope you are fine. We are an app development and web design company that turns ideas into exceptional solutions. We are offering: . Native Applications . Android & iOS Apps . Custom Web Design . Website development . Wordpress Website . e-Commerce Website . PHP Website If you are interested in our services, the please share your valuable requirements with us so that we can analyze your requirements and provide you the best solution accordingly. Best Regards, Rona!
Re: [1-800-GIT-HELP] Pushing a merge with master to a branch fails with git gcc-verify
Thomas Koenig via Gcc wrote: I tried to update the coarray_native branch to current master with "git merge master" as given by https://gcc.gnu.org/gitwrite.html#branches That worked without any error message. Next, I tried to verify that a "git push" would succeed, and got an error: $ git gcc-verify Checking bf6dad60c338a42a7fb85f7b2a5870c0fb2e20f8: FAILED ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates should be done separately from normal commits This case is not covered by gitwrite.html, what is the best way to proceed? FWIW, for 99.99% of my devt I do the same as Andre mentioned in the other reply (keep patches rebased on top of master). But i have the c++-coroutine branch which inherits its rules from svn days. The convention from svn times is for the branch to have a private ChangeLog.branch file (if it uses one at all). Thus merges from master should not encounter any case where there’s a change to a ChangeLog that isn’t from an existing master commit. I keep devel/c++-coroutines up to date with current master thus: checkout master fast forward master checkout devel/c++-coroutines git merge —edit master the commit message is editted to read something like Merge master r11-4499. * Merge master r11-4499-g323dd4255203. ^ today’s update. That’s a valid commit message from the PoV of the upstream hooks, I then test the merged branch... assuming that succeeds … git push upstream devel/c++-coroutines. That set of actions has been working for me for months. ——— This might not solve your immediate issue - (it’s not clear how you’ve violated the changes mentioned) but it is a sequence of actions that ought to work going forward (avoiding making changes to those files on the branch). probably look at what’s changed in the merge commit and see if you can revert the offending changes? Iain
Re: [1-800-GIT-HELP] Pushing a merge with master to a branch fails with git gcc-verify
On Wed, Oct 28, 2020 at 06:53:35PM +0100, Thomas Koenig via Gcc wrote: > I tried to update the coarray_native branch to current master with > "git merge master" as given by > > https://gcc.gnu.org/gitwrite.html#branches > > That worked without any error message. > > Next, I tried to verify that a "git push" would succeed, and > got an error: > > $ git gcc-verify > Checking bf6dad60c338a42a7fb85f7b2a5870c0fb2e20f8: FAILED > ERR: ChangeLog, DATESTAMP, BASE-VER and DEV-PHASE updates should be done > separately from normal commits > > This case is not covered by gitwrite.html, what is the best way to > proceed? Don't use git gcc-verify for development branches or user branches, it checks the rules required for release branches and the trunk only. Other branches have different rules. Jakub
Re: [1-800-GIT-HELP] Pushing a merge with master to a branch fails with git gcc-verify
Hi, Don't use git gcc-verify for development branches or user branches, it checks the rules required for release branches and the trunk only. Other branches have different rules. Thanks to everybody for their help. I have now pushed the merge to the branch successfully. I'm glad that the particular rules for ChangeLogs are not enforced on branches. Best regards Thomas
